从两种典型的组织架构中台演进看中台困境

组织是个很大的问题，典型的组织架构就包括：直线职能型（U）、事业部型（M）、矩阵型、网络型、平台型，还不算各种组合和变体；如果结合经营模式，还需要了解大家常常提到的阿米巴经营模式以及海尔的自主经营体……

所以，肯定不是一篇文章就可以讲清楚的。

本文定位白话，我就还试着收敛回到中台的上下文上，聚焦到数字化团队组织的形态上，以中台化场景中最典型的两种数字化团队组织结构的中台建设演进推导为案例，试图从组织演进的视角来看看到底为什么中台的建设会碰到这么多问题？以及寻求破解之法。

直线职能型组织结构的中台推演

直线职能型组织有时候又被简称为职能型组织，是从直线型组织发展而来，也是大中型企业最常见的组织形式，大多数企业都采用这种组织结构形式。

在这种企业组织架构下，数字化团队最常见的形式就是业务团队（BT）与技术团队（IT）分离体系。

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

不过，随着企业业务的发展，IT系统也越来越多，自然就会出现越来越多“烟囱型”的系统，再加上整体架构的老化与腐化，技术团队的工作负担越来越重，对于业务团队的需求响应能力也逐渐降低，开始出现需求堵塞，需求排期问题日渐严重，业务团队不满情绪积累，技术团队则同样不堪重负，矛盾日益显现。

怎么办？

肯定会有人说，中台啊！中台不是就是解决烟囱问题的么，你想想，只要能将各个系统重复的能力抽取出来，沉淀成共享服务，大家一共享，一变都变。对于新需求前台直接拼拼凑凑，拖拖拽拽就能快速满足，简直不能更完美。

嗯，听起来也是这么个道理，说干就干，于是技术团队就开启了寄托着美好愿景的“中台改造”，因为是技术团队基于IT治理的需求驱动的，也就代表“中台改造”对于业务往往是透明的。

不过随后就发现，中台建着建着，之前提到的那些问题就开始一个接一个出现。

根本原因在于中台改造往往涉及到大量的工作量，难度也非常高，而由于其“业务透明性”，表面上并没有直接的业务价值。看不到业务价值就代表没有业务团队愿意为这些工作买单，甚至相反因为技术资源会被中台改造占用，对于业务的响应不升反降，业务团队怨声载道。

技术团队内也逐渐出现问题，随着架构复杂度急速上升，再加上中台改造出现了团队之间的服务交叉耦合，跨团队的沟通成本也急速增加。

看起来一切都在向着期望相反的方向加速进行，直到失控的边缘。

中台建设不是号称可以增加IT的响应力么，为什么会适得其反？是不是分离出一个独立的中台团队就会好些了呢？

中台技术团队应运而生，但不久我们就会发现，问题并没有被解决。

仍然是因为“业务透明性”，在没有新的资源支撑前提下，团队也自然无法扩张。只能将原来的团队进行重新切割，分为中台技术团队和前台技术团队（事实上，已经很少有企业有魄力能走到这一步）。

业务团队的压力和需求此时就会通过前台技术团队传导到中台技术团队。而中台团队则因为要同时支撑多条业务线多个APP，复杂度高，之前提到的需求拥堵、排期、冲突的问题仍然无法得到很好的解决，只是转移到了中台技术团队而已。

那是不是因为直线职能型组织天生就不适合做中台改造呢？

其实恰恰相反，从某种角度看，中台本质上就是一种Shared Service。Shared Service不是一个新概念，原本就是代表一种共享组织结构，由来已久，例如我们常常听到的共享财务中心。而直线职能型组织结构下的技术团队，本身就是一个IT Shared Service（IT共享中心），不但不是八字不合，反而非常的契合，那问题到底出在哪呢？

中台概念来自互联网，那我们就再来看看另一种在互联网企业更常见的组织结构，事业部（产品型）组织结构，是不是就可以在中台建设的过程中避免出现类似的问题？

事业部（产品型）组织结构的中台推演

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

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

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

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

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

怎么办？

能不能成立一个单独的组织来处理协同的问题，让产品型团队专注于自己各自前台产品的差异部分，通过组织的分层来解决产品型组织的问题呢？

中台团队又一次应运而生。

但区别于前台产品团队，此时的中台团队与直线职能型团队中的中台团队一样，仍是以一个偏职能型的内部共享技术团队存在的。（我在图例中用红框来代表产品型团队，用篮筐来代表职能型团队）

乍一看，这种“分层组织结构”解决了产品团队组织结构下的协同问题。

前台产品团队继续负责产品差异部分的独立开发，承载着企业的纵向“灵活性”；中台职能团队负责产品间的协同和通用部分的开发，承载着企业的横向“经济性”。理想情况下，通过分层组织结构，就可以通过不断调整前台产品团队与中台职能团队的组织边界，来调节企业在“经济性”与“灵活性”之间的动态平衡，一切看似完美……

但是，同样随着中台建设的推进，我们就会发现，之前出现在直线职能型组织中的中台团队所面临的问题（需求堵塞、排期、冲突、资源竞争、边界定义、团队冲突……），同样也会出现在这种事业部（产品型）组织架构的中台团队里，问题并没有得到解决……

究其原因其实也是一样的，中台团队因为不是直接服务于终端最终用户，而是通过服务前台产品团队间接服务终端用户。所以并没有直接的收入来源，需要从各个产品线抽取一定的资源（人+钱），组建中台团队，为前台团队服务，前台团队与中台团队的关系与直线职能型组织一样，仍是一种被服务与服务的关系，区别无非在于前台是产品型还是职能型团队而已，并无本质区别。

本文转载自健荐公众号。

原文链接：https://mp.weixin.qq.com/s/DxjRze7GmtIpOrC1FxdWAQ

创作场景

白话中台战略 -4：Platform as a Product(组织篇)（四）