摘要：在谈及客户端（桌面、浏覽器和设备）和基于服务器使用一种或多种Internet（cloud）服务的应用程序时本期杂志中的许多文章都使用术语“软件+服务”（Software + Services，S+S）虽然这种模型具备“软件即服务”（Software as a Service，SaaS）的某些特征但对于企业IT来说它们之间还是存在明显的差别。

本文比较了采用S+S与采用SaaS面临的各种挑战；很显嘫对于企业来说，使用定义明确的外部服务比使用全套服务（finished service）所面临的挑战更少

当今，通过Internet交付的应用程序（即SaaS）大多数都针对消費者和小型企业市场使用业务货币化模型（无论是捐赠还是广告投资）在很大程度上都表现出长尾经济的特征；通过可伸缩的分发渠道將很少的东西出售给许多客户，Chris Anderson对此已有描述（请参阅参考资料）

但是，企业的需求与消费者和小企业部门的需求完全不同因此，可鉯假设支持长尾经济和服务交付（和消费）不适用于企业环境例如，消费者不必担心遵从性和企业应用程序集成(EAI)这些也基本上不牵扯箌小型企业。

因此从企业角度看，软件服务会带来很多问题谁拥有数据？什么是服务等级协议（Service Level AgreementSLA）？内部身份标识可以扩展到防火牆外部以访问cloud服务吗存在法规限制吗？

软件服务：新的集成挑战

IT预算中约有70%用于维持现有系统其余约30%才投入于新的解决方案。虽然硬件和软件成本逐渐低于管理成本但支持成本正在不断增长。相比以前企业现在期望从IT获得更多回报，这部分由于网络公司（dot.com）倒闭后企业信心的恢复以及对防火墙内部Web 2.0形式的功能不断增长的需求。

Matter》的反应便是明证（请参阅参考资料）。内部IT项目耗时数月且投资巨夶而获得的好处却能够从Internet轻松获取，企业领导者常常因此感到气馁用户在Internet上体验到的搜索、协作和发布功能，远胜于许多企业的内部功能越来越多的应用程序正作为服务项目可以从Internet上获取，给企业提供了一个可供选择的IT源模型

在本文中，我将讨论在现有企业IT基础结構和各项操作上使用外部软件服务的影响并比较在使用整个公司广泛采用的任何业务线应用程序时，SaaS模型与S+S模型所面临的各种挑战我使用术语“软件服务”（software services）表示SaaS和S+S模型中的服务，因为我们可以将软件交付视为一个统一体无论它是创建的还是购买的，或者从另一方媔极端地说是通过Internet交付的全套服务（即SaaS）。内部软件加cloud服务的混合形式（即S+S）位于这个统一体的中间。图1说明了这个软件交付统一体在本文中， 

l  传统软件（Traditional software）是指安装在基础结构中专门供内部用户使用的应用程序

l  构建块服务(Building Block Services)提供开发人员在构建复合应用程序时可以使用的低级功能。这些服务存在于cloud中

l  附加服务（Attached services）与构建块服务相比，提供了更高级的功能应用程序利用附加服务来添加功能。

l  S+S是指使用附加服务的应用程序或通过构建块服务构建的应用程序

图1：软件交付统一体和软件服务分类（单击图片查看大图）

在考虑IT基础结构戓应用程序源模型时，了解业务对象非常重要例如，对成本效益的需求驱动了外包业务通过合同支付形式将现有成熟应用程序的交付荿本和风险转嫁给另一方。相反软件服务的采用满足了业务需求，如更有效的客户管理（就CRM来说）从业务经理的角度来说，SaaS似乎是一種两全其美的模型：以合理的成本（甚至免费）获取业务收益在IT资源方面不需要额外投资或预先投资。虽然企业是确定服务是否能很好哋解决业务问题的最佳场所但除非将IT纳入讨论范围，否则企业IT的许多更广泛问题（软件服务应用涉及的隐性成本）都将被忽视

软件服務：新的集成挑战

在采用软件服务时，服务交付和服务支持这一组挑战成为服务供应商的职责但是，在采用新模型时IT将面临额外的一組新挑战（图2）。

图2：软件服务消费增加新的挑战（单击图片查看大图）

这些新挑战是不可避免的不能对其熟视无睹。我们将会看到這可能成为直接或间接成本、资源问题以及遵从性问题。换句话说软件服务的采用是内部IT的一种混合采购/集成项目。集成 图2：需要从以丅三个广泛领域考虑软件服务消费带来的新挑战：

规范和法律责任也应该予以考虑

身份和访问管理是影响IT各个方面的长期问题，包括帮助台成本、用户生产力、数据安全等这也是企业IT应该比Internet提供更佳用户体验的领域，目前大多数企业仍有很多用户目录分析机构经常提箌，平均有30%的帮助台呼叫都是询问重置账户密码的问题

全套服务与相应外部目录的增加需要扩展供应和取回过程，即使这是一个人工过程例如，当某个员工辞去工作时许多组织尽力及时取回或禁用内部账号；外部应用程序或服务的暴露风险事关重大，因为企业防火墙無法阻止用户访问应用程序及其数据

Manager）都不能解决这个问题。AD是专有的其信任模型没有足够细粒度，元目录部署应用不广泛并且不能實时操作基于标准的一些东西，如联合服务器提供的一组功能特别适合与外部应用程序或服务集成。这是松散连接的可以实时操作洏不是按照进度表进行，从而简化了供应和取回过程联合信任关系是细粒度化的，允许消费组织只公开其子集目录（基于规则）以及屬性到“要求”的实时映射，减少了对内部目录更改的需求（参见图3；有关联合服务器和ADFS的详细信息，请参阅参考资料）

与SaaS相比，S+S应鼡程序可以使后端服务在防火墙内部运行这样单个企业或代理的身份就能够传递到cloud中的服务。身份集成是许多企业应用程序的一种共同功能因此后端服务可以与Active Directory或开箱即用的普通LDAP目录集成。

图3：联合服务器提供身份标识集成（单击图片查看大图）

授权和访问管理是需要栲虑的另一个方面许多应用程序针对不同用户提供不同的功能。例如开支应用程序允许管理员授权的金额达4,000美元，4,000美元以上的金额则需经主管批准当今，企业防火墙内部的许多应用程序都针对每个用户设置了许可权实际上，应用程序包含用户及其授权之间的映射关系然而，许多组织已开始从基于用户的授权转向基于角色的授权这样做的优势很明显：更低的管理成本，一致的基于角色授权透明嘚遵从性。

如果一个全套服务具有多级授权则有两种选项：手动将用户映射到授权级别以向组织中的人员分派任务；将内部基于角色的模型扩展到外部应用程序。前者常求助于帮助台这是采用全套服务的隐性成本。后者将内部角色映射到外部应用程序可以通过联合服務器完成；例如，Active Directory组的成员可以映射到外部应用程序使用的cookie中的名称/值对

构建块或附加服务（混合软件+服务）中的授权可以采用联合服務器模型，并且这么做确实能带来好处：完整性由服务供应商负责严格管理这有助于实现遵从性。更灵活的S+S模型意味着在对外部服务发絀请求之前可以由本地服务器进行授权进行本地控制和策略强制意味着组织可以更快地应对业务变化。它还简化了集成；企业可以对供應商应用程序on-premise部分的配置进行更改以适应其环境。

对身份和访问管理的影响总结

l  如果外部服务依赖于用户身份（对于SaaS非常可能对于S+S是鈳能的），则需要扩展供应和取回过程集成可以通过技术或手动过程完成，这两者都会影响成本

l  服务供应商用户账户策略需要根据您嘚内部策略进行评估（例如，密码复杂度、锁定等）

业务线应用程序不一定以岛屿形式存在，即使其来源于外部Payroll软件能很好地证明这┅点。Payroll服务供应商需要Raw数据（如员工名称、工资总额等）来处理月工资单在此示例中，从内部HR系统简单提取相关信息就可以提供数据顯然，通过电子邮件将XLS或CSV文件邮寄到payroll供应商不可能提供所需的安全/机密等级因此需要另一种形式的数据交换，人们期盼IT能够满足这一要求换句话说，IT面对企业应用程序集成(EAI)项目

从EAI角度来说，构建块和附加服务应该易于集成；毕竟作为本地应用程序的扩展，它们是专門为开发人员使用而设计的附加服务的一个示例是Exchange托管筛选服务（Exchange Hosted Services for Filtering）（有关Exchange托管服务的更多消息，请参阅参考资料）这种情况下的集荿分为两部分：

本文中的关注点是基础结构，我不会就EAI进行深入探讨但是，我们将从其他一些角度来讨论数据的基础结构问题：

l  防火墙規则和筛选器

要了解使用全套服务的防火墙问题我们需要调查哪些内部应用程序将与软件服务集成以及集成的形式。需要集成的内部应鼡程序是一个还是几个需要创建什么样的防火墙规则以允许发布和信息流?如果应用程序正在交换XML，那么这需要在防火墙处验证吗放火牆可以提供这种功能吗？数据需要与某种形式的工作流集成吗如果需要，该工作流IT公司如何找客户跨越内部/外部基础结构如果通过HTTP（唎如，SOAP）进行集成除创建规则之外，防火墙可能不会有什么问题

构建块和附加服务可能成为某种本地后端基础结构，这自然成为数据集成和安全的关注点某些SaaS供应商已认识到，在其数据存储在企业防火墙内时企业更愿意订阅因此，他们正在客户数据中心内部安装设備将其全套服务发展为S+S模型。

通过Internet交换加密数据最有效的方法是采用公共证书机构的证书如果证书安装在客户端上，则需要实施公共密钥基础结构（PKI）计划解决其所有问题，如证书生命周期管理和发布证书撤销列表这不是一个无足轻重的事情，一旦完成它将在基礎结构中启用其他功能，例如电子邮件签名和智能卡身份验证

当然，在S+S实现、加密和签名中使用本地后端基础结构可能更为简单（更少嘚端点）

数据的另一个角度是用户视图。不管这样做是否恰当但许多企业用户都希望继续使用他们熟悉的工具—Microsoft Office应用程序。新应用程序常常无法发挥其全部潜在功能因为企业用户坚持提取数据和使用Excel进行日常管理。此数据很少会回到应用程序许多独立软件供应商都宣布要将其应用程序客户端构建为Office商业应用程序(Office Business Application)，实质上是使用Office作为应用程序平台这通常会导致采用速度更快、培训开销更低，但却给IT帶来了部署和维护问题要考虑的要点：软件服务提供企业所需的所有功能吗，还是需要使用本地工具/系统抽取数据来执行操作/分析软件服务的采用会导致更多部门应用程序在Excel和Access中构建吗？

l  为了确定数据集成和ETL需求需要进行分析。

l  为了允许集成可能需要防火墙规则。

l  為了提供应用程序数据筛选功能（例如XML Schema验证），防火墙可能需要更新

l  为了支持身份验证、加密和签名要求，可能需要购买证书或实现PKI

从外部获取应用程序或服务时，操作集成问题有点不协调：毕竟作为消费者的主要好处在于，操作是供应商的职责但内部操作和过程在几个方面会受到外部应用程序或服务影响，最重要方面是帮助台和用户培训

许多消费者被效率低下和混乱的呼叫中心弄得沮丧不已。为了避免类似问题内部帮助台团队应该了解集成到IT操作的新应用程序和服务。企业用户依赖许多内部IT系统访问外部应用程序：网络、DNS、代理服务器支持这些服务是企业帮助台而不是服务供应商的职责。许多组织现在认识到简化业务支持过程的重要性例如，只需一个電话号码和内部网站点就可以将他们连接到适当的一线团队。

用户培训是引入任何新应用程序的重要方面无论其安装在哪里。全套服務的一个优势是供应商通常提供按需培训但是，企业对此类培训的控制力较弱质量低劣的培训会提高支持成本并降低企业生产力。作為服务的一部分引入升级（订阅全套服务的好处之一）是另一个潜在问题：如果企业在所有员工都得到培训之前没有能力延迟升级的实现则内部帮助台可能必须面对激增的电话求助。相关问题是全套服务的单个功能是否可以有选择地禁用：如果内部已经提供了该功能IT需偠确保用户都在使用该内部功能。

“应用程序对企业的重要性越大您需要考虑的相关事项就越多。作为全套服务交付的业务线应用程序昰一项重要的集成活动”

如果全套服务使用浏览器作为其客户端，则正常的兼容性涉及：浏览器版本和安全性设置以及安装的插件及其版本。对于传统应用程序企业可以决定何时更新到新版本，如果新版本要求最新的浏览器那么这一点至关重要。如果该应用程序是外部的则企业可能无法提供这种选择。

如果服务的客户端不是基于浏览器的内部IT将负责部署工作及相关事项(兼容性测试、部署规划、噺品展示等）。

如果服务是附加或构建块服务将需要在企业数据中心中部署后端基础结构和/或客户端。对于后端服务一般的非功能性挑战有：需要什么样的服务器、网络和存储容量才能满足负载？可以使用共享服务（如现有的SQL服务器或web服务器场）吗IT公司如何找客户提供弹性和灾难恢复能力？可以在多个数据中心运行吗答案取决于应用程序的本地组件而非cloud中的附加服务：换句话说，在很大程度上它可鉯像正常的后端部署一样进行处理

供应商运营/业务连续性

在选择、监控和评估服务供应商时，我们应将注意力完全集中在SLA的内容上重點考虑IT公司如何找客户实现SLA：SLA规定在灾难发生后的24小时内恢复服务，表面上看起来很不错；但是灾难定义和恢复形态是至关重要的。对於服务消费者来说灾难可能是应用程序记录的意外删除，但服务供应商可能对此有不同看法再举例来说，对于许多业务应用程序恢複应用程序数据是一个复杂的过程。例如在这些应用程序得到完善之前，恢复Exchange邮箱或消息、SharePoint站点或文档是一项重大挑战现在，这种挑戰出现在多租户（multitenant）的SaaS应用程序中即使可以进行细粒度恢复，但考虑到操作成本供应商业不会愿这么做。

一些架构师告诉我他们关紸的另一件事情是服务供应商完成业务后的风险，即IT公司如何找客户保护数据以防止泄漏到竞争者手中将应用程序代码根据协议交由第彡者保存起来是一个正确的处理方式，但这还不够就算企业消费者可以获得数据，但不安装说明文件或求助开发人员也很难在其数据中惢重新构建应用程序这方面的风险还没有一个完美的解决方案，这是一个信任问题如果出现最坏情况，供应商会正确加以应对相信怹们具有良好的业务和管理技能。

与任何SLA一样企业和IT团队应该评审报告执行情况，并调查在哪些方面SLA还没有被满足

l  需要对帮助台程序進行更新，以排除新应用程序的一线故障升级过程由服务供应商定义。

l  当依赖服务供应商获取升级支持时复查内部帮助台SLA以确保其依嘫可以得到满足。

验证对规范和法律责任的遵从性将对基础结构产生影响确保整个内部系统和外部服务业务过程的遵从性尤其具有挑战性。有关遵从性的潜在解决方案：如果应用程序或服务是向业界看齐的那么主要市场很可能遵从相关规范；一般性服务可能不会如此。即使遵从性成为服务的一个卖点企业的内部安全策略或区域性法律（如欧洲议会数据保护法）也可能与服务供应商策略相抵触。

企业无疑希望在任何时候都保留对其数据的所有权；合同中应该明确声明这一点此外，可以谨慎地检验数据能够按需提取

企业应该谨慎地评估供应商的隐私策略和使用术语，以确保其数据的专用性不得用于市场营销或销售给其他方，在全套服务接受广告支持的场所尤其重要隐私认证计划在确认供应商的可信赖性方面能够提供很好帮助；具有TRUSTe许可证的供应商具有公开的策略并经受独立审核，可确保遵从隐私保护准则

l  遵从性可能扩展到服务供应商，您IT公司如何找客户来证明遵从性呢

l  出具遵从性报告可能有一定成本。

表1：建议摘要（单击图爿查看大图）

针对消费者和小型企业的产品占据着当前的SaaS市场因为该细分市场不需要集成的交付模型。使用来自这些供应商的业务线应鼡程序对于任何企业都存在风险因为本文中讨论的集成点有许多无法解决。

应用程序对企业的重要性越大您需要考虑的相关事项就越哆。战术性应用程序的首要关注点是合同问题如数据所有权，与此相比作为全套服务交付的业务线应用程序需要大量的集成活动。图4嘚热图（heat map）中表示了这种关系

图4：考虑事项热图（单击图片查看大图）

当今，企业IT部门对于消费构建块或附加服务的体验和自信远远胜過完整的应用程序将它视为富应用程序（如Reuters 3000）或基础结构服务（如垃圾邮件过滤）的数据供给，就能很好地理解该模型

由于SaaS交付模型巳经成熟并且得到了更广泛采用，因此能迎合更多的企业要求（如集成）是很自然的事情企业为“源即服务”准备的功能范围将扩大。朂终将是软件+服务应用程序；on-premise软件和cloud服务的自然平衡

正如Gianpaolo Carraro和Fred Chong在其文章《SaaS:An Enterprise Perspective》中所述，SaaS和S+S是聪明的CIO可以用来为企业提供更多价值的传统工具IT经理应该了解SaaS和S+S的用途，而不是感到惶恐：这是带来业务收益的替代性源模型构建解决方案的另一种架构方法。

经过正确运用软件垺务将帮助改变企业对IT的认知。

l  Microsoft法规遵从性规划指南（虽然本指南关注的是内部IT但评估外部供应商时也很有用）

Services担任了5年资深顾问。Kevin在渶国公私部门领导了Enterprise和eCommerce基础结构的架构和设计包括针对12万用户组织的分布式Microsoft基础结构和针对120万教育领域用户的外部网应用程序平台。作為基础结构架构师他为企业客户提供建议和咨询，并出席各种国际活动

作为一名项目经理（Program Manager,简称PM）你必须对项目拥有宽泛的全部的管理职责。项目经理应该在财务技巧和客户打交道的技巧，领导技巧等方面做出努力要想在一个 项目中莋成功，则该项目经理必须愿意在本质上承担对该项目的无限责任以下的关于IT公司如何找客户成为一名成功的项目经理的建议是基于作鍺和该领域的最成功的一些人共 事的经验而提出的。

一个成功的项目经理应该具有的品质：

对所承担的项目的各个方面负全部责任

一个項目的所有方面都很关键。作为一名项目经理意识到所有的方面都需要你负责，这一点很重要如果有人告诉你，该项目的某些事情你鈈用操心千万别相信这样的话，那样的人不是木讷就是狡猾

花时间建立和促成一个具有凝聚力的管理团队。

这个方面经常被忽视而倳实上，交流、激励、解决冲突等等会对你的团队IT公司如何找客户协作和IT公司如何找客户将工作完成产生影响几年前，我曾提出这样的想法：如果你真正能够成 功地组建一个具有高度凝聚力的团队那么你每周大约只需工作一个小时。很明显这是很理想化的，而且在现實工作环境中不可能发生然而，在理想情况下你 可以有几个项目经理为你工作，他们是那样的自信和有动力那么你可以每周仅仅来┅次并且能够保证没有任何事情会出差错。仔细考虑一下这一点你应该会意识 到你IT公司如何找客户和你的团队一起工作会影响项目的底線。

和你的项目经理们建立强有力的联系

这一点和建立一个有凝聚力的团队关联性很大你有必要告诉你的团队你关心他们所遇到的问题，你也同样关心他们的成功一个建议是每周开一次非正式的会议。 在一个完全没有Powerpoint等现代化设备的房间里鼓励你的团队能够公开地讨論他们的问题所在并且讨论IT公司如何找客户解决这些问题。通过这种途径不仅建立 了团队精神，而且也建立了相互信任的关系比如你嘚项目经理们应该拥有你的宅电，并且在周末的时候如果有必要，他们可以毫不犹豫地给你打电话

101%的只关注你的项目

在一些公司和政府组织里，你会非常容易被一些和你的项目毫无关系的任务牵扯很多精力这是一个很大的错误。也许这听起来有些自私但是你必须始終将注意力 集中在那些你必须做以使你的项目能够成功的事情上。而且做那些和你负责的项目毫无干系的事情对你的职业的发展也不见得囿好处尽管你也许会很表面地认为你 的上司会欣赏你做的这些额外的工作。注意事实上这是消极的。

理解终端用户的优先级别

很多情況下当你作为项目经理时，你的客户项目经理并不是你的终端用户所以你必须确信你能够和使用你的项目或产品的终端用户取得直接聯系。当我曾做F- 117隐形战斗机项目时在没有最关键的三个人取得一致的情况下，做出任何主要的决定都是不可能的他们包括：客户项目經理，用户和项目经理本身我们有 这么一个安排，并且所有为我们工作的人员都能理解这个安排为了使这一点得以实现，我们做出了佷大的努力我们并不在一个地方，所以我们会在某地互相见面 来解决问题当然也有一部分工作是通过保密电话得以解决。

很多大型的項目都有与之相关的很繁重的软件内容选择和培养合适的软件管理人员非常的重要。最近几年在项目管理中，软件失败的情况层出不窮所以为你的 团队找一个优秀的软件管理人员是你明智决策的开始。记住：好的决策是需要决定什么是需要的而什么是最好的 在这一點上，很容易陷入这样的陷阱：客户不断地提出软件方面的要求事实上，如果你允许软件变得越大和越复杂, 你失败的可能性也会越高早些年，计算机的存储空间是有限并且昂贵的这也意味着软件在空间上或大小上有其边界。这真是很幸运的事情但是现在，我们有几 乎是无限的而且很廉价的存储空间这真是不幸。项目经理必须确信所有的规则被严格执行只有这样才能防止软件失去控制的情况出现。

为了你职业的发展可采取的措施：

起初你身处一个项目管理团队当然在这个团队里你并不是项目经理，你承担一项任务并且完成它伱从你所做的工作中获取经验，当然如果你幸运的话你会为自 信的人工作并且从他们那儿学到很多东西。其实最廉价的教育是这么一种形式：你为一个杰出的人工作而且你能够无须花很大力气就能学到很多东西你通过工作和 观察来学习。对我而言这一点非常重要和有意义。我通过观察学到了很多东西我曾供职于一些由一流项目经理管理的项目组织。尤其是该领域的两名大师级人物 就关注最重要的问題他们并不把正式的报表当作信息输入的唯一方式，他们组建了他们信任的一个团体当然这个团体中的成员也信任他们。他们的项目非常的成 功比如S-3A海盗航天飞机项目，该项目从签订合同到在舰队上服役仅仅用了5年时间在1975年，当我决定想成为一名项目经理时候我通过非正式的方 式告诉了Lockheed公司：我很想做项目管理这份工作并且如果有该方面的职位空缺的话，很希望能被考虑到在1976年的春天，我成为┅名项目经理

你能够做的一件事情是对你目前所从事的工作尽心尽责。在每一个项目管理团队都有大量的辛苦的工作，这些工作很乏菋也不令人激动，但是必须完成从这一 点上来说这些工作非常的重要。自愿地承担这些工作对于你增加你的经验和提升你的名誉是一條很好的途径如果你渴望在项目管理上能够成功，那么被人认为你并 不愿意做这些辛苦、乏味但也很重要的工作那将是最糟糕的事情呮要是项目上的任务就不应该拒绝。（正如前面所强调的如果说该项任务超出了项目范围，那就 没有必要去做了）这又回到了我们前面闡述的事实即项目经理必须毫无边界地愿意承担所有责任在四年的时间里，我负责洛克希德（Lockheed）、波音 （Boeing）、通用（General）三公司合作的动仂F-22高级战术战斗机项目我为三个CEO工作，他们都是卓越的人在项目开始的初期，他们 明确地告诉我我越少向他们请示，他们会认为我嘚工作做得越出色我的角色是将工作完成并且做出相关的决定。有几次不小心我将一些不该由他们来做决定的 事情让他们定夺，但是怹们的第一反应却是：“穆林（Mullin）,你自己能够解决”他们非常明确地知道他们雇佣项目经理是为了让其来承担所有的责任， 而不是让一夶堆不该由他们自己来处理的事情来打扰他们（事实上项目经理能够而且应该处理这些事情）现在，如果你确实需要他们的帮助那么凊况是两样的， 所以他们非常的伟大

培训并不意味着项目的成功。即使你拥有一大堆的证书和学历证明你仍然可能是一个糟糕的项目經理。然而获得项目管理的基本知识则非常重要。记住因为你 对项目承担无限责任，你必须知道财务管理战略规划，市场营销等等我曾经接受的最好的培训是斯坦福大学的执行主管人员培训项目。这是一个为期8周的课 程讲授成为一个成功的项目经理的关键技术。洳果有人在20世纪70年代晚些时候问我是否渴望负责Skunk Works我想我会说你在开玩笑吧！别拿我开心了！但是从1990年到1994年，我成为了Skunk Works的总裁在我的职業生涯中，我觉得自己是幸运的我曾从事过很好的工作并且通过项目管理的实践和观察学到了很多东西。

光环国际PMP转自PM圈子网