编辑导读：如今，中台建设似乎已经成了企业的标配。但是，很多企业被中台的魅力所折服的时候，却没看到，这个“理想国”的表象下竟是“葬送场”。本文将从四个方面，围绕中台展开分析，为你揭开中台的“神秘面纱”。

中台不是一个IT产品，也不是一个“咨询+IT”产品，而应该是企业为自己定制的“高奢品”。

传说，2015年，阿里对标芬兰游戏企业Supercell建立了“中台”，无意中引领了一股互联网业界的潮流。

从2009年成立“共享事业部”，再到2015年启动“中台战略”，阿里一直是中台建设的坚定探路者与践行者，这也为其业务的快速发展带来了巨大好处。例如，阿里仅用1个半月就上线了团购平台（聚划算），而同类团购平台投入的研发资源可能是阿里的几十倍，准备时间可能是阿里的几倍。

互联网大厂迅速感知到中台的魅力，并在2018年末至2019年初密集推行中台战略。至今，中台建设似乎已经成为了标配。

但在中台如火如荼之际，我们依然可以听到不绝于耳的反对之声。不少从业者甚至感叹，中台在“理想国”的表象下是一个狰狞的“葬送场”。

一、什么是中台？

中台，作为平台型组织的一部分，是在前台作战单元和后台资源部门之间的组织模块。这些模块多半是传统组织中所谓的成本中心，它们负责把后台的资源整合成前台打仗所需的“中间件”，方便随需调用。

打一个通俗的比方：糖醋排骨、鱼香肉丝、松鼠桂鱼这几道菜，都需要糖、醋、生抽、老抽、淀粉等调料做成的糖醋汁，厨师可以提前调制好糖醋汁，在做某道菜时直接加进去就行。

其实，这背后有一个没有被大众熟知的概念——模块化（modularity），即把一个系统里紧密连接的两个部分进行“松散耦合（Loosely Coupled，也称退藕、解耦）”，减少模块间的关联，增强其独立性。

说通俗点，就是把一个整体做成乐高积木式的拼接结构。这样一来，某些频繁被使用的组织模块就成为了共用“中间件”，即中台（图1）。

其实，在20世纪60年代起，模块化的思路已经在产品设计、组织设计、企业间关系设计上流行了起来。

图1：业务中台的建设原理

资料来源：穆胜企业管理咨询事务所

这类部门在以前的金字塔组织中也存在。事实上，把不同业务条线的通用部分抽取出来形成独立部门来与前线部门做接口，几乎任何一个大型企业都实践过此类思路。而这样的思路下搭建的“平台型组织”和金字塔组织并没有任何区别，依然存在前台与中台之间的“部门墙”等大企业病，前台并不能顺利调用中台的支持。

但有意思的是，互联网企业的影响力太强了，当它们开始遵循这种组织设计基本原理时，这种运动就变成了潮流。于是，当下人人都在谈中台，这似乎又变成了一种创新。

笔者的观点是，从互联网的技术逻辑上去找中台建设的方向，绝对是一个进步。

模块化的原理是旧的，但互联网的技术是新的，在旧原理下做出新解决方案，是需要水平的。现在提到的技术中台、研发中台等概念，都是在做一种技术架构，并以这种架构来重新规划组织。因此，我们也没有必要强行去调整这个潮流中的概念，而是将其归纳为“业务中台”。

当然，互联网企业对于中台的信心不仅在于模块化实现的“退藕”，还在于利用IT技术实现的“全域数据化打通”，阿里称其为“数据中台”，业界称之“中台的中台”。当企业的各类资源都被数据化，且数据孤岛被连通到一个平台上，资源的供给、业务的需求、协作的界面等一目了然。

二、为什么要上中台

传统的组织设计，永远是在三个约束条件中求最优解的过程。

• 灵活性——建立的组织结构能否应对市场的各类需求，这是企业生存的基础。
• 经济性——能否用最精简的人员和机构支持业务，因为人员和机构不仅会形成显性成本，还会产生大量隐性成本（内部交易成本）。
• 规范性——能否对扩张出去的分支机构进行有效管理，确保其路径规范、不踩红线、有效协同。绝大多数老板宁愿企业发展得慢一点，也不愿失控，因为风险太大。

一边是灵活性，另一边是经济性和规范性。两边永远处于矛盾的两级，追求一边就必然放弃另一边。所以，企业会陷入分拆与合并的循环：每当需要灵活性就会放权，为前台配置各类职能，让其以“独立团”的形式响应市场；每当需要经济性和规范性，就会收权，将前台里分散的职能抽取出来，合并为大职能部门，并由总部统一规范管理。

中台的建设显然是后一种情况。面对互联网时代变幻莫测的市场，企业不可能为诸多的小前台单独配置职能。以电商企业为例，当线上、线下、ToB、ToC业务团队都需要开发“订单功能”，此时就没有必要在每个业务里都单独开发一次，而是将其放到中台统一开发、大量复用。这样一方面更有经济性，另一方面为后来打通数据做好了铺垫。

另外，中台似乎也没有牺牲灵活性。当抽取出来的职能实现了“松散耦合”，就能够被前台随需调用。小前台在市场上无孔不入，灵活探测客户需求，而后调用强大中台的功能模块来实现交付，这是多么美好的画面！

除此之外，互联网时代为组织设计灵活性提出了新要求——体验感。互联网时代的信息透明，导致了产品之间竞争激烈，娇惯的用户对体验感的要求前所未有。以前企业把产品做到60分就行，现在必须做到90分，它们需要“灵活的深度交付”。

用战争来做个比喻：以前要攻克堡垒，组建一个“独立团”，配上冲锋枪、手雷、火箭筒就行；而现在的攻堡难度增加了，需要调用无人机、轰炸机、导弹等进行重度火力打击。从这个意义上说，中台建设就是构筑“重度火力”。

如此看来，一极是经济型和规范性，另一极变成了灵活性和体验感，但中台建设却几乎可以平衡矛盾，一次性解决所有的问题。企业为什么如此积极地建设中台，就不言自明了。

自2015年阿里开始实践中台以来，形成了两股实践潮流：一是互联网大厂纷纷入局，这种趋势在2018年末至2019年初间达到高峰，至今也未曾消退，当前甚至进入了中台细分的专业化阶段（图2）；二是专业服务商如雨后春笋般涌现，但在经历了2019年茅台等几个大单的折戟后（延期交付、项目亏损），中台的适用性受到挑战。

于是，业界对中台又爱又恨，众说纷纭。

图2：互联网大厂建设中台时间轴

资料来源：穆胜企业管理咨询事务所

注：红色字体代表官宣信息，黑色字体代表实际在建设中台的行动。

三、上中台的挑战

中台自然有诸多的好处，但建设中台却必须要通过三道“鬼门关”。

1. 建设成本

从前台抽取出业务的共性，再进行统一建设，看似原理简单，实则凶险无比。

中台毕竟远离一线，不可能100%了解业务需求，它们需要先与业务部门一起梳理需求，再抽取出共性建设公共模块，最后还要保证这个公共模块与前台业务的适配性。这个过程中需要投入大量的人力。有以中台作为服务内容的外包商反馈，项目耗费的人力多到夸张，人力成本是项目成本的大头。

更可怕的是，企业经过万般努力建设的中台却没有达到相应效果。大多数企业根本没有做知识萃取和沉淀，别说制度、SOP、工具、模型、Baseline，就连基本的业务逻辑都没有理顺，大量的知识都是留存在个体身上。换句话说，换了一个人，就是一套不同的做法。这样的情况下，中台部门不仅要先帮前台业务补课，还要建中台，其难度就可想而知了。

大多企业遇到的问题，并不是因为建设中台的逻辑存疑，而是因为中台没有建好。

俗话说，“举重才能若轻”，中台沉淀得越好，才能够应对各类需求，并在交付上实现超高的体验感。大多数企业没有相应的沉淀，前台调不出支持，好比打仗时大后方不给弹药补给。这时候你不应该讨论是否要建弹药库的问题，而应该想想平时做了什么，导致弹药库如此匮乏。

2. 改革成本

大多数业务领导都会选择“做大势力范围”和“屏蔽上级监控”。前者意味着更大的权力范围和更多的预算拨付，后者意味着更大的决策空间。想当“藩王”是人性使然，如果控制在一定的范围内，危害不大。

而上中台意味着组织变革，显然与人性相悖。在企业内呼风唤雨的前台部门要将职能让出相当一部分放到中台，相当于“割地”；他们还需要将数据打通，使自己部门的业务全部可视化，相当于“戴上紧箍咒”。这种“削藩”的动作太大，只有一把手敢做，还必须是对企业有超强控制力的一把手。

典型的例子是阿里。2015 年末，在张勇提出“大中台、小前台”的组织战略后，阿里在 2016-2019 年内，进行过 19 次组织调整，当中涉及诸多高管换岗、部门合并，动静之大可想而知，这也为中台建设扫清了障碍。

但其他企业不见得如此幸运。据财经媒体36氪报道，在华南一个有几十人的CIO社群里，2019年由于中台项目失误而导致离职、调岗的高管就有十几个，他们无疑都倒在了前两道鬼门关下。

3. 改革后成本

这道“鬼门关”最让人绝望。建中台本来就是一种挑战，要面对的是前台的官僚主义，但当企业建设出一个大中台，又会面临中台更大的官僚主义。

2010年，海尔在改造倒三角组织结构时，将企业内的部门裂变为2000多个自主经营体（图3）。其中，一级经营体是研产销三大职能的若干小团队，而二级经营体也称“资源平台”，包括销售平台、研发平台、供应链平台等。除了没有当前这样极致的IT化要求外，二级经营体就是现在的中台。

图3：海尔三级自主经营体

资料来源：海尔，穆胜企业管理咨询事务所

原来的想法是由前台小团队来拉动平台资源，二级经营体被要求建立资源丰富、定价清晰的“资源超市”，与一级经营体签订市场化的服务协议。但这个层级本身就是各级资源的“管理者”，而且在内部是垄断的，要他们“听从前台指挥”，显然太难了。

典型的场景是，一个小地区的市场经营体虽然与国内销售平台这个二级经营体签订了服务协议，但其面对一个集团的“大部门”和“大领导（销售平台经营体体长）”，基本是没有话语权的。更让人无奈的是，当上游只有一个垄断的内部供应商，定价更是说不清。

大约十年前，中兴和华为也面临过相似的问题，它们提出“一线主战，专业主建”，将中台称为“XX体系”，同样带来了官僚主义。中兴通讯的一位中层称：“体系里都是大爷，要调动资源得使出十八般武艺。”

这些企业在碰壁之后，都开始寻找新的解决方案，下文会提到。但现在不少文章还在引用它们十年前的组织结构来支持中台建设的观点，这是错误的。

整体看来，建设中台的过程好像是从一个深坑掉入另一个，似乎真的不划算。

四、中台的未来

在上中台的潮流中，大量IT厂商一拥而上，资本也开始追逐此类项目，看起来，中台似乎变成了一门好生意。

从2015年开始，以中台名义获得融资的笔数一路走高，在2019年有明显跃升（图4、图5）。2020年3月，明略科技集团在E轮获得了3亿美元的融资，考虑到中国SaaS企业普遍估值较低的现状，这样的融资规模实在让人意外。

图4：2015—2020e中台服务商融资情况（2020年上半年融资13笔，推测全年26 笔）

资料来源：天眼查，穆胜企业管理咨询事务所

图5：主要的中台服务商融资（1000万元以上）时间轴

资料来源：天眼查，穆胜企业管理咨询事务所

这些企业最初的想法是，完成一个标杆项目后，中台的解决方案可以在简单修改后迁移到下一个项目。但这个想法显然太过天真，别说跨行业，就连一个行业内的两家企业，情况都大不相同。不同的商业模式、不同的业务流程、不同的组织结构、不同的人员素质……中台建设似乎天然就是无法模板化、标准化。

所以，这更像是以总集成商的身份来做“深度咨询+IT解决方案”，需要堆人头来解决问题。而且，堆人头只能解决建设成本问题，无法解决改革和改革后的成本问题。由于缺乏可复制性，上不了规模，作为生意前景存疑。

2019 年初，阿里云智能事业群总裁行癫在内部战略会上提出，如果阿里云一味冲在前面做总集成商——客户的特性可能千差万别，总包就要做定制化方案和实施——会透支阿里云的品牌。

如果不做总集成商，IT厂商可能需要从SaaS走向PaaS，提供一个平台支持ISV（Independent Software Vendors，独立软件开发商）和客户的快速自主开发。国内不少企业认为，SaaS层面已经不能提供客户需要的获得感了，尤其是具备支付能力的大客户，迫切需要更深度的定制化。但这样的方式也需要巨大的投入，盈利性和易用性都必须有庞大客户规模的支撑。在当下国内IT厂商所处的阶段上，极有可能是个“深坑”。

这可能是大厂才玩得起的游戏。

2019年阿里云峰会上，行癫甚至表示“阿里云自己不做SaaS，让大家来做更好的SaaS”。显然，阿里云已经做好了“练好内功被集成”的准备。当前，阿里云提得更多的是“数据中台”而不是“业务中台”，业务千差万别，而数据中台的产品更容易标准化。数据中台实现的“全域数据打通”才是中台的威力所在，以这种方式推动“企业上云”尽管稍显缓慢，但也许更为可行。

综合来看，将中台作为一门生意对大多数IT厂商而言并不可靠。

从产品角度看，中台不是一个IT产品，也不是一个“咨询+IT”产品，而应该是企业为自己定制的“高奢品”。从企业角度看，中台不是一套组织架构，只是平台型组织模式（架构+机制）的一个战略要地。如果仅仅以建中台的视野来行动，是解决不了问题的。相当于你手臂的力气再大，也不可能把自己全身举起来。

以海尔为例，在意识到这类中台会产生更大的官僚主义后，海尔打造了由后台的财务、人力、战略等部门派出的多角色BP（Business Partner，业务伙伴）团队。

这些团队在内部被称为“三自”，他们能推动前台团队的自创业、自组织、自驱动。他们进入前台与其协同作战，并代表后台加速资源和机制的精准配置（图6）。BP团队在激励方案里将前台和中台关键节点的利益绑在一起，就实现了分配上的共同劣后。说俗点，钱在一起了，心就在一起了。

图6：两类中台组成的组织腰部

资料来源：穆胜企业管理咨询事务所

这类团队是前后台之间的连接器，笔者称之为平台型组织“真正的中台”。在中台的研究里，有人将笔者提到的这类中台冠以“组织中台”之名，笔者认为也是很贴切的。显而易见的是，没有组织中台，即使有了全域打通的数据中台，业务中台很难发挥出期待的作用。

企业经历千辛万苦建设业务中台和组织中台，走向平台型组织，背后应该老板“坚定的相信”和“汹涌的野心”。他们相信未来业务的扩展空间，相信变化的市场需要超强的组织柔性，更相信传统金字塔组织只能实现线性增长，平台型组织才能实现指数级增长。他们要做的不是一个单体企业，而是要打造一个行业生态，所以他们才会不遗余力地将企业打造为平台型组织，建设好生态的底层。若非如此，他们很难对于过程中的艰险视而不见。

说白了，要不要建中台，最终还是看老板是怎样的人。离开了这个原点，再多的分析也是白搭。

#专栏作家#

穆胜，微信公众号：穆胜事务所（ID：hrm-yun），人人都是产品经理专栏作家。知名管理学者，北京大学光华管理学院工商管理博士后，管理学博士，穆胜企业管理咨询事务所创始人，互联网商业模式和组织转型研究专家。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Pexles，基于CC0协议