重新打造企业｜数字化导致信息流加快，组织结构应该如何重构？

上周，我们进入数字化战略框架的第4R“重新打造企业”的B部分：重新设计创新组织，通过案例讨论了三种模式：Finansbank的“快艇”模式，万事达的“登陆码头”模式，高盛的“内部变形”模式。

本周继续。昨天我们讨论了数字化转型的投资类型和资金机制，今天聊聊数字化转型打造敏捷组织。

在数字化时代，企业信息流从数年、数月加速到数周、数天，甚至达到秒级快速响应或实时响应，传统的组织结构无法按照职能(如营销、财务、工程、安全、交付、运营)来有效地组织人员。许多组织正在寻找新的方法来快速响应这些变化。本篇重点介绍信息流加速之后如何优化组织结构的最新趋势。

1 跨职能“微服务”团队

看过《星球大战》吗？一个经过交叉训练的、分布式决策的团队，能够朝着共同目标努力、对自己的使命负全责，面对变化的快速响应能力要远远强过单体式、单线程、顶级指挥和控制的组织。

为了转型成敏捷企业，技术组织将组织结构重组为跨职能的小型团队，使之具有端到端的责任，并控制所提供服务的整个生命周期。其结果，只要维护跨服务的信息交换标准，变更一项服务的执行并不会影响其他服务。

微服务理念可以应用于组织设计。因而，技术方面的许多通用规则、技术和陷阱同样也适用于微服务组织。

实施微服务团队的好处，也类似于微服务技术架构的好处。从职能组织到微服务结构的转变以及服务的解耦，使团队可以进行快速变更、或增加新的服务功能，而不会让整个系统发生故障。

而且，解耦组织会也分散风险。团队越独立，整个系统故障的风险就越分散。因此，潜在影响的范围减小了。

转型为微服务组织之前，传统的职能团队将自己重组为与业务价值流一致的、面向服务的跨职能团队。

面向服务的跨职能组织可以更好地响应用户需求，因为用户很少仅需要安全性、仅需要交付应用。相反，用户通常喜欢同时满足需求的服务，包括安全性、可靠性、质量等非功能性需求。

微服务团队是面向服务的组织的自然产物和演变结果，它具有基于能力的结构的所有优点，也能与价值流保持一致。同时，微服务团队的组织规模更小、组织独立性更大，能够提高交付和运营的速度。

你可以将微服务团队视为永久性“小型项目”。毕竟，组织需要项目的原因是克服组织结构的惯性、整合分散的技能、避免工作冲突、加强团队协作，以达成实现业务价值的目标。

微服务概念已经远远超越技术部门，整个组织都在朝着不断变化的微服务生态迈进。微服务可以相互通信，可以通过变形为新的微服务、或更新微服务来动态响应需求，并且比以往更快地合并、分解和退出。每一个微服务都是一个半独立的实体，将技术、人员和业务流程结合在一起。

面向微服务团队的组织变革，与组织所使用的技术密切相关。实际上，如果微服务团队受制于底层应用或基础设施，就无法创造太多业务价值。因此，现代组织将这样繁重的技术组件设计视为技术债(chnical debt)，并将应用和基础设施构解耦为容错微服务。

通常由企业架构(EA)团队安排技术变革小组负责人，并根据需要整合技术重组需要的其他专业和组织能力。

多数情况下，向新技术架构过渡是与云转型同时进行的，这能综合应对各种业务需求、不断变化的基础设施要求以及访问现有高级服务的需求。

如果执行正确，则由基础设施即代码(IaaC)、软件即服务(SaaS)等云理念实现的微服务，最终将使组织实现“IT圣杯”：自动可扩展性、自动化、一致性，并完全控制基础设施和软件配置的变更。

转型为微服务团队好处多多，但也不无缺点。最大的问题可能源于：要获得理想的效果，就需要变革整个运营模式。仅修改一个元素、或执行变革的顺序不正确，都可能导致不良后果。典型的陷阱包括：

微服务团队仍然需要协调、标准化和端到端策略，因此治理流程必需到位，但又不能制约生态系统。
由于微服务生命周期的快速变化，因此需要在确保底层服务技术与当前标准一致性的同时进行重构。
转型为微服务需要同步修改多个流程和治理，包括：动态服务组合生命周期管理，自动化，自我配置的服务消费模型，各组之间的复杂编排，较短的预算周期，变更的投资计划，不同的人员绩效管理，技能改进，内部指标和KPI重组，供应商变更管理方法。
变更微服务团队和微服务技术架构也需要变更交付和运营方法。