用模块化思维打造组织

如今远程办公已蔚然成风。通过模块化组织，实行远程办公的公司可以大幅降低协调成本。Spotify公司今年早些时候宣布，它将完全转向远程办公。Salesforce 公司则要求其员工每周只来办公室1 ～ 3天。去年秋天，苹果CEO蒂姆·库克（Tim Cook）表示，他相信，大家在疫情前的那种工作方式已经一去不复返了。他说：“有些事情在虚拟环境下其实也能做得很好。”中国最大的保险公司——平安保险——也将远程办公向前推进了一步：它开发出一套工具，可以让140万员工和保险经纪人远程工作。如今，它正在把同样的工具提供给其他金融服务公司使用。

上述公司有一个共同点：它们都在走向或已经实现了模块化建制。模块化组织的实施曾经困难重重，但如今已是遍地开花，这正是微服务和API（应用程序接口）的功劳。

模块化组织这个概念本身并不新鲜，但不同以往的是，今天我们有能力相对轻松地实现这种架构。API 可以将部门间的互动编写成固定规则，从而减少临时性的沟通，并将协作的复杂程度降至最低。于是，传统的业务流程——无论是财务、法律还是人力资源的相关流程——都可以转变成微服务。于是，原本铁板一块、高度互依的组织变成了模块化组织。

不过要注意，反过来也是同样的道理：微服务的短缺，可能会妨碍公司模块化架构的实现，并使其深陷复杂性的泥潭。这类组织除了号令其总部员工重返实地办公之外，别无他路可走。

我们的发现来自IMD 商学院的一个研究项目，该项目的目标是探明组织如何为未来做好准备。我们深度访谈了数十个富有前瞻性的组织，并建立了一个数据库，对40多个生态系统加以追踪。我们还根据公开信息，对公司进行了准备度方面的排名。我们的高管教育课程实际上也成为一座实验室，让我们有机会与高管们一起，检验各种假设。

组织复杂性要求不断协调

以需要仰仗他人参与的任务为例。某知名时装制造商的一位高管解释说，他们公司每次准备推出一款新品时，他都必须和总部通话简要汇报情况，之后再打电话给自己的团队分配任务。接着，每一位团队成员都要和自己的外部对接人（货运代理、零售店、广告代理商）沟通，并且自始至终都要让总部随时知晓每一个关键节点的最新进展。各种Excel 表格飞来飞去，一切都要手动完成——这可是在2020年初，就在全球疫情暴发之前。

这就是复杂性：一场纷纷攘攘的行动，任何事情都可能影响到其他所有一切。因此，在这样一家公司工作的管理者，为了协调和定战略，需要面对面地开很多会。

因为要横跨多个通信平台开会或交流——无论是Zoom还是Microsoft Teams、Slack抑或电子邮件——团队成员间的“连连看”很快就让人不堪重负。把整个组织的每一个点都连接起来，几乎不可能做到。正是这种组织复杂性，让公司无法充分优化远程办公。

解决之道是：采取模块化和分布式的组织设计。

微服务怎样驱动模块化组织

如果一个企业被分切成彼此独立的业务小组，就可以称其具有了模块化的组织结构。20世纪70年代末，麦肯锡公司（McKinsey）的汤姆·彼得斯（Tom Peters）宣称，我们应当抛弃矩阵式组织，因为他认为，这种组织发展太慢，无法跟上日新月异的商业环境。20世纪90年代，詹姆斯·摩尔（James Moore）讨论了新兴生态系统导致的竞争消亡。最近，加里·哈梅尔（Gary Hamel）宣称，为了实现更加灵活的组织方式，需要彻底淘汰科层制。这些有影响力的思想家都意识到了减少内部协调工作的重要性。

速度是一种优势。疫情奖励了那些把高昂的协作成本降至最低的公司。例如，全球最大的家电制造商之一、总部位于青岛的海尔集团，在新冠疫情暴发后的一个月内，就恢复了满负荷生产，这主要归功于该公司广泛使用了智能制造和远程办公解决方案。

但是，我们今天所见到的每一家迅猛发展的巨无霸企业，都一度经历过生死挣扎。它们如今的蓬勃发展，完全是因为它们进行了精简。这些公司咬紧牙关，推倒重来，才避免了在自身复杂性的重压下走向崩溃。

亚马逊公司（Amazon）1996年创立之初是只拥有一个应用的平台。它运营的网络服务器与一个后台数据库通信。随着时间的推移，这个单一应用平台发展成了一个由上百万行代码组成的庞大架构。由于看到亚马逊应用开发人员和硬件服务器团队间一直在你争我抢，CEO杰夫·贝索斯（Jeff Bezos）给开发人员下了指令，要求他们创建某种标准接口，用于计算资源的访问和分配。

贝索斯对降低协作复杂度的态度十分坚决。在他的新指令下，面对面会议和电子邮件都得到了大幅精简。取而代之的是将大型的功能系统——在这个例子里是IT——分解成小的服务模块，称为“微服务”。每项微服务通过API 与其他微服务交互。由于应用开发人员和IT 运营部门互相发送的请求在格式上保持了一致，日常协作也实现了自动化。

最终的成果是， 一个由软件程序员组成的小型团队现在可以独立地在亚马逊网站上推出某个附加功能，就好像小商家在脸书（Facebook）上做宣传活动那样。这些商家不用致电脸书客户服务部安排线上活动，一切都是自助服务，执行也是自动化的。

对于亚马逊的工程师来说，发布新产品和跨部门协调并没有太多相似之处。它更像组装乐高积木，对新产品的功能做混搭和匹配，以便适应不断变化的市场。这就是复杂问题简单化。

突破IT范畴拓展微服务

亚马逊公司正在对其各项职能的输入和输出加以标准化，从而将整个IT 基础设施转化为上万项微服务。这些微服务进而可以作为彼此独立、分散的模块存在，并与其他模块交互。

然而，微服务的概念不必局限于IT 范畴。经过多年实践，海尔公司把自己打造成了一个自我管理业务单元的群集。

海尔拥有约4，000 个小微企业。每一家小微的员工只有10 ～ 15名，他们拥有完全自主的经营权向其他小微提供产品和服务，乃至为终端消费者提供最终产品。这些小微并非由总部统一指挥，而是彼此独立地进行业务往来。

某些小微提供人力资源或产品设计等服务，另外一些则制造特定的零部件。其协作就像应用商店那样，通过位于云端的内部平台加以管理。因为每个团队都很小且彼此独立，局部的失误就不会造成全局性的破坏。

海尔的访问控制解决方案

由于这些小微之间的接口是高度标准化的，因此信息交换可以实现自动化。海尔为访问控制开发的解决方案，就是一个具体实例。

在员工众多的大型公司中， 不断有人入职、离职和流动，这就使得公司很难控制谁有权访问哪些企业应用。在微服务的框架下，海尔设计出了自适应身份治理（adaptiveidentity governance）的解决方案，把IT 员工从为业务用户授权和取消授权的重复手动作业中解放了出来。

与之前不同的是，HR人员可以在单一平台上追踪员工的所有访问权限，并且只需点一下开关，就能修改其访问权限。由于身份管理也集中在一个数据库中进行，海尔在维护成本方面节省了大量费用。单个部门也不再需要运营自己的管理平台。这种集中化是一个重要特色。为了实现微服务的高效，数据需要驻留在云端，而非放在本地服务器上。这样，数据就只会有一个“正确”版本。

使用外部创建的API

聪明的公司也会选择部署一些云端可以找到的、由外部开发的开源应用，而不是每次都自己做API。开放存储库的例子包括谷歌云API 和OpenStack。这些API 本质上属于为云基础设施提供公共服务的软件组件。

在建立了所有的内部微服务之后，海尔发现，利用他人开发的开放式API 更加方便，包括最初由金融行业设计的API。如今，由新加坡星展银行（DBS）开发的一款应用，正在为海尔产品分销商提供数字金融服务。这给了海尔销售和分销渠道更多支持，而星展银行也获得了更多生意。

平安公司也是金融API 技术的早期采用者之一，自2013 年起就一直在使用这一技术。起初，该公司的关注点是实时余额信息的自动检索。不过，平安循序渐进但步履坚定地从API的接收者变成了生产者。到2018 年为止，和星展银行的做法类似，平安的金融技术子公司壹账通已经开发出数百个接口。

从远程办公到业务增长

远程办公的紧迫性凸显出模块化组织的优势。我们的研究表明，善用微服务与API 的公司，不仅能够降低复杂性、减少手动协调工作，也更加适应员工分散在各地的非同步互动方式。

从流程的角度来看，管理者在设计远程优先型组织时，必须遵循下面这些关键原则。

构建云优先的运营 对于是否将公司的宝贵数据放上云端，高管们可能会心存犹豫，也有些人认为，云只是一种高效存储数据的工具。然而，云优先的运营奠定了模块化组织的基础设施。

实现关键业务流程的数字化 如今，几乎每家公司都在进行数字化转型，新冠疫情也毫无疑问地加速了这一进程，但无论如何，业务流程的数字化都是必要的。只有通过全面的数字化，公司才能将相互依存的业务分解为小块，从而高效创建微服务。

开发微服务之间的数字化接口 数据科学和机器学习等领域的顶尖人才招聘是焦点所在，然而API 接口的构建同样至关重要。API交流具有巨大价值，任何公司都无法承受无视这一点的代价。正如海尔的例子所示，一旦拥有了API 开发能力，你就可以深入利用其他现有的开源API。

超越IT范畴，发挥微服务的战略价值 微服务的真正威力在于降低整个组织的协调和沟通成本。要通过业务运营的广阔视角，超越IT职能的范畴。

复杂性与公司的规模和经营范围无关。亚马逊、苹果和谷歌都是庞大的组织，但其组织方式一点儿也不复杂。海尔是一家在全球大规模运营的成熟制造企业，但其组织结构也非常简单。平安集团也是由高度自治、相互依存的企业组合而成的。

这些模块化的企业中，每一家都利用多种多样的微服务创造了优势。这曾经是一种理想化的组织设计概念，如今却因为一场全球性危机的到来，而加速成为现实。