搞中台要动组织架构，怎么动？

本系列的上一篇文章分享了*中台建设与组织架构调整*之间的关系，可能更加适用于互联网企业的敏捷型组织形态，传统企业内部各种组织架构纷繁复杂，因此没办法都在一篇文章中说清楚。本文的重点在于理清传统企业不同的组织架构形态应该如何调整，以及中台规划和实施阶段的关键人物。

如今，很多讨论中台的文章会集中在技术层面，比如微服务架构搭建、DevOps 以及云原生等。事实上，技术和方法论都是企业可以借助外力达到的，但组织架构调整只能亲力亲为。因此，本系列文章决定以“组织架构调整”为主题，探讨很少被认真谈起的中台战略下的架构调整之道。本文，InfoQ 独家采访了 ThoughtWorks 首席咨询师王健，他同时也是白话中台战略系列文章的作者，对这一领域有着深入理解和认知。

中台是一个战略，战略需要靠组织推动

为什么我当时选择将系列文章的标题定为《白话中台战略…》，因为中台是一个战略层面的问题，而战略的落地往往需要靠组织的调整来加速推动。——王健

在采访中，王健表示，中台是一个战略，战略则是企业为达成某项目标而确定的过程与方法，而战略的推进肯定与企业内部的组织和运作过程相关。谈到组织结构对系统设计的影响，很多人马上就会想到“康威定律”：任意一个软件都反映出制造它的团队的组织结构。简单来说，项目团队的优点和弱点都会反映到最终生成的系统中。

那么，大部分企业的组织模式有哪些特点？又是什么样的原因让企业需要通过建设中台来改变现状呢？

过往，王健接触了很多传统企业。在大型传统企业，IT 信息化部门可能存在了超过 20 年，一成不变的就是项目制的系统建设模式，除了造成“烟囱式”架构的系列弊端，也让 IT 信息化部门一直处于“业务支持“的职能位置，基本是“业务归业务，技术归技术”的状态。

在这个过程中，不知道有多少业务部门对信息部门的定位和存在的价值提出过质疑，很重要的原因是 IT 信息部门的人不懂业务，这个观点可能会引来很多 IT 信息中心人员的反驳，比如“系统的数据模型都是我们设计的，我们比业务部门更懂”等。

确实，企业内部的很多系统都是 IT 人员负责或者参与建设的，但这里的“懂业务”更多是指能对业务的下一步发展有自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有业务提出创新想法，而建设中台，尤其是业务中台，就是一个打破部门间壁垒的过程，因为只有了解业务，甚至比业务人员更加了解，才可以更好地抽离出不同业务板块中的共性需求，并更好地响应业务方的需求。

在采访中，王健表示，调整组织架构也需要与中台建设的不同阶段相对应。在中台的规划阶段，大多是 CIO 负责推动，或者是类似互联网公司 EA 团队的战略规划办、企业架构办等部门，这个阶段需要考虑中台建设的方向、蓝图、实际需求和解决哪些问题。

在中台的实践阶段，王健表示，数据中台和技术中台其实是传统企业最喜欢率先引入建设的，因为相对而言，传统企业内部对于技术和数据团队的划分相对明确，尤其是业务并不是非常繁杂的时候，技术团队和数据团队往往就是一个独立的、全面支持的角色，比如原来做数据平台的团队，现在就可以直接继续承担数据中台的建设，不需要做太多结构上的调整，毕竟不是非常影响业务，而业务中台则是一定要动组织的，这个过程涉及多条业务线的利益关系，这之间的屏障很难打破。照搬肯定不行，其他人调整是为了业务的横向扩展（例如做全球化），你的目的是为了纵向数据打通，这显然不可复制，还是得想清楚调整的目的是什么。

既然想清楚为什么要搭建中台，那么组织架构应该如何调整呢？在传统企业，如果只把中台嵌入单条产品线，一般问题不大，毕竟大家的利益是一致的，但如果有计划接入多条产品线，就需要一事一议了。

企业组织架构的不同形态

组织是个很大的问题，典型的组织架构就包括：直线职能型（U）、事业部型（M）、矩阵型、网络型、平台型，还不算各种组合和变体；如果结合经营模式，还有常常提到的阿米巴经营模式以及海尔的自主经营体……所以，肯定不是一篇文章就可以讲清楚的，王健曾在过往文章中以中台化场景中最典型的两种数字化团队组织结构的中台建设演进推导为案例，试图从组织演进的视角推断中台建设过程可能碰到的问题。

直线职能型组织结构

直线职能型组织又被简称为职能型组织，是从直线型组织发展而来，也是大中型企业最常见的组织形式，大多数企业都采用这种组织结构形式。在这种企业组织架构下，数字化团队最常见的形式就是前文提到的业务团队（BT）与研发团队（IT）分离的体系。

在这种组织架构下，业务团队因为更多承载了用户与业务的需求，往往更具话语权和主动权，也掌握着预算分配的主动权，研发团队更多情况下是从业务团队申请预算，负责 IT 系统设施的建设与运维，完成业务团队的需求。

随着企业的业务不断发展，IT 系统越来越多，自然就会出现越来越多“烟囱型”系统，再加上整体架构老化与腐化，研发团队的工作负担越来越重，对业务团队的需求响应能力也逐渐降低，开始出现需求堵塞，需求排期问题日渐严重，服务也不能真正成为可重用的组件。

这个时候，很多人可能就想到建设中台来解决问题，通过中台将各个系统中重复的能力抽取出来，沉淀成共享服务。然而，中台改造需要花费大量时间，难度非常高，短期内很难看到业务价值。即便是分离出中台研发团队和前台研发团队，也只是改变了需求的传导链路，业务团队的压力和需求通过前台研发团队传导到中台研发团队，问题并没有得到解决。

再来看下互联网公司内部普遍存在的另一种架构模式：事业部（产品型）组织结构。

事业部（产品型）组织结构

事业部组织结构是分级管理、分级核算、自负盈亏的一种形式，即一个公司按地区或按产品类别分成若干个事业部，从产品设计，成本核算 ，产品制造，一直到产品销售，均由事业部负责，实行单独核算，独立经营， 集团总部只保留人事决策，预算控制和监督大权，并通过利润等指标对事业部进行控制。

由于互联网企业的产品基因，往往是由一款产品做起来的，随着业务扩张，逐渐出现多条并行的产品线。互联网因为竞争激烈，往往讲究的就是一个快字，谁先占领了市场和用户，谁就占据了主动权。因为事业部组织架构相对直线职能型组织架构，更强调“纵向”的执行力和灵活性，自然成为大多数互联网企业默认的组织演进方向。

同样，如果只聚焦数字化团队的组织架构，事业部职能结构可以简单理解成产品型团队。从单一产品开始，多一个产品就多一个团队，团队之间就像产品一样有很强的独立性，例如大家熟知的阿里巴巴淘宝团队和天猫团队。

产品型团队的问题就在于产品之间是割裂的，缺少横向协同。

如上图所示，“烟囱产品”的问题已经非常明显：随着各产品线的独立快速发展，各个产品间的重复建设、技术栈混乱、设计混乱等问题日益突出。

此时，很多人也会想到通过建设中台来解决问题，通过中台来解决产品间协同和通用部分的开发，让前台产品团队负责差异部分开发。理想情况下，可以通过不断调整前台产品团队与中台职能团队的组织边界，来调节企业在“经济性”与“灵活性”之间的动态平衡。

但是，随着中台建设的推进，组织就会发现，之前出现在直线职能型组织中台团队所面临的问题（需求堵塞、排期、冲突、资源竞争、边界定义、团队冲突……），因为建设中台团队的矛盾都是一样的：费力，费时且短期没有收益。

所以，从这两种组织架构的推进过程可以看出，问题并不在原有的组织架构身上，而是在中台团队的建设和定位上，只要中台团队的建设过程是大致相仿的，这些问题就会存在。那么，如何解决呢？

中台可能的推进路径

要想让中台在企业内部顺利推进，那么在组织架构层面，无非要解决权力、金钱和人员的问题。

先从权力谈起，如果将中台看成一款产品，试想如果组织不做中台，什么类型的人最受不了？王健在采访中肯定的回答：是高层，至少在中台建设的初期是为了解决企业高层在战略和未来长远生存上的焦虑，这种焦虑来源于危机感，尤其是新零售这类直接面向 C 端消费者的领域，如果无法敏锐捕捉用户需求，无法快速响应用户需求，最终损失会直观反映到财务报表上，所以这类企业的公司高管最为焦虑，希望通过建设中台达到部分转型目的。

那么，这部分高层将会成为推进中台战略的关键人物，主要负责整个中台战略的规划，包括可能的组织架构调整。王健补充道：“中台建设的前期可能没有给业务带来多大帮助，反而制造了很多问题，如果没有 CIO、CTO 甚至 CEO，或者技术委员会、战略规划部门等的支持，很难进行，可能原来想做一个业务中台，后来因为无法撬动业务，数据也拿不到，最终的建设效果就会大打折扣，如果这时领导层没有驱动力帮助继续推进这件事情，这个中台推也不是，不推也不是，因此我认为中台建设是一个自上而下的驱动过程。”

其次是金钱，这主要涉及两个阶段的内容——建设之初和建成之后。换句话说，建中台的钱应该谁出；建成之后，尤其是业务方享受到中台的服务之后，这个钱应该怎么分配。

在很多传统企业，研发往往仅支持内部业务，是一个纯成本的部门，当然这肯定是为业务带来了价值，只是直观来看，这是一个不营收的部门。如果站在为业务赋能的角度，业务中台的钱显然需要业务部门出一部分，建成之后可能还需要从业务方分走部分利润。

但这条路很难走通，每条业务线都有自己的 OKR 或者 KPI，这件事情对各业务部门的考核可能没有直接帮助，甚至于在局部较短时间内是阻碍当年 KPI 达成的。

王健表示，试想一下，如果一家企业要推出一款产品，很少有上来就采用众筹模式，让用户预付款，这样会对产品产生很大的短期交付压力，也不利于产品的初始阶段研发。相反，现在很多企业推出的产品，前期都是免费的，先通过投资机构注资研发，快速推向市场获取用户反馈，再不断改进并适时考虑向用户增值收费。如果考虑让公司从战略投资层面出这个钱，那么公司肯定也是要考虑收支平衡问题，投资的目的是什么，需要多长时间可以带来收益，如何合理制定中台团队的 OKR 等。建成之后，一旦业务线全部接入中台，那么该业务的营收是否需要与中台团队按照一定比例划分，也是需要提前想清楚的。

最后是人员，中台的团队的人员组成以及业务团队的人员抽调问题。采访中，王健表示，一开始大多是从前台抽调，毕竟企业资源有限，不可能纯招一批人，这些人可能包含架构师等实力非常强的人，因为业务中台的建设者要比各垂直业务线更懂业务，不仅仅是懂技术就可以的，尤其是很多公司是产品型文化，可能还会配备产品经理，这可能与传统企业里面的项目经理有些类似，但要有很强的沟通和协调能力，需要跟所有业务线战斗，然后服务好所有业务方，但如果没处理好组织关系，业务方给到中台的人可能是自己不想用的，毕竟业务方通常不愿意为了一年后才可能用到的项目外流人才给中台团队。

如果组织解决了上述问题，那么可以让中台战略有一个良好的开端，但即便中台可以搭建起来，业务方又为什么要使用呢？

针对这个问题，王健提供了一条可行的路径：企业可以试图以某项业务为标杆业务，先让该业务顺利接入中台并正常运转，再考虑其他业务线的接入问题，最终达到让业务线主动拥有的程度，如果一开始就接入很多业务，中台团队可能也对需求应接不暇，产品的边界也很难逐一打磨。

结束语

建设中台绝非易事，企业一定要想清楚这是否是当下的必要措施。一旦决定通过中台解决现有问题，这种战略的调整，组织的调整，IT 架构的调整就会存在于整个过程。正如王健在《白话中台战略-4：Platform as a Product(组织篇)》中所言：凡事没有完美，没有完美的战略，没有完美的组织，也自然没有完美的 IT 架构，都是在持续地演进中。

嘉宾介绍：

王健 ，ThoughtWorks 首席咨询师， 十多年国内外大型企业软件设计开发，团队组织转型从业经验。一直保持着对技术的热爱，享受着编码的快乐，热衷于技术分享。目前专注在企业平台化转型、中台战略规划，微服务架构与实施，大型遗留系统服务化改造，敏捷精益转型，以及 DevOps 和持续交付等实践在大型企业中的推广与落地。

相关文章：

《中台禁区：为什么最关键的组织架构却鲜少人谈？》

《网易杭研中台实践：建中台有可行方法论吗？》