图片来源@视觉中国

文 | 穆胜

与数字化转型一起火起来的，是“中台建设”。如今，在大多数实践者眼中，中台就是数字化转型标配，以至于，一个帮助企业建设中台的创业赛道异军突起。同样，喊出中台建设口号的企业不少，但真正建起来中台的，更是屈指可数。

但随着中台建设的火爆，有关“中台建设究竟成不成立”的争论也如影随形。就连被认为是中台建设典范的阿里，有段时间也传出了正在“拆中台”的消息。有人更是戏称：“大公司上中台，钱没了；小公司上中台，公司没了。”

本项研究将探讨数字化转型中的三个关键问题：一是Why，即是否应该建设中台？二是What，即应该建设什么样的中台？三是How，即如何建设中台？

01 数字化转型与中台建设

数字化转型是互联网浪潮发展到一定阶段的必然。沿着互联网商业的进程，数字化转型呼之欲出。整体来看，数字化转型一共分为三个大类：数字化营销、工业数字化和数字化管理，也有若干对应的同义词或延伸词（如表1）。我们对这些关键词的百度指数进行了加权统计，发现了数字化转型的三波浪潮（如图1）。

表1：数字化转型关键词

资料来源：穆胜咨询

图1：数字化转型浪潮热度趋势图  资料来源：穆胜咨询

备注：关键词热度参考百度指数加权计算，加权方式主要考虑了各个同义词/延伸词与中心词的关联度。

一波数字化转型浪潮是“数字化营销”，出现在2017年。互联网转型高潮属于需求侧的消费互联网领域，而数字化营销显然是焦点。

前一波数字化转型浪潮是“工业数字化”，出现在2015年。在流量红利消失之前，互联网转型率先映射到供给侧的产业互联网。其中，工业数字化是毫无疑问的C位。

第三波数字化转型浪潮是“管理数字化”，目前处于正在爬坡，预计会是在2022-2023年之间达到高点。前两个浪潮里，“数字化营销”和“工业数字化”两个趋势进一步倒逼出了企业内部的“数字化管理”。要将产业的供给用于满足用户需求，必须要有企业作为枢纽。如果两头都是数字化的，企业就不得不让自己的管理也走向数字化。过去，这个领域一直是由ERP（Enterprise Resource Planning）来承接，但ERP作为工业经济时代的产物，显然无法满足互联网与数字化时代的需求。

管理数字化的本质，是打通企业内部的“连接”从而提升效率。这可以通过两个方面来实现：

一是传统的连接，即建设“业务中台”，实现资源或能力的极度共享，这是最传统的效率来源。我曾举过一个简单的例子：糖醋排骨、鱼香肉丝、松鼠桂鱼这几道菜，都需要糖、醋、生抽、老抽、淀粉等调料做成的糖醋汁，于是，厨师就可以提前调制好，在做某道菜时直接加进去就行。

其实，传统企业也这么做，例如，将营销资源集中起来，建立一个营销体系作为业务中台供前台团队调用。但这种操作在节约成本的同时，也会导致资源或能力输送不到前线去，产出下降，速度也变慢。所以，传统企业会权衡利弊，选择是否建业务中台。

二是数字化的连接，即建设“数据中台”，让资源和能力在极度共享后形成数据汇集，并基于算法进行智能决策。互联网企业在资源和能力的共享上似乎没有太多顾虑，因为他们有数字化的解决方案。数据作为生产资料的价值已经无需多言，简单的数据汇集，就可以发现更多的效率提升空间。加上算法智能决策（算法也是自动进化的），这种效率优化空间实在太吸引人了。

其实，企业根本无法抵抗数字化转型趋势，某种程度上，其选择中台建设是“被卷入”的。可以说，有无中台决定了企业的未来，因为，有无之间的效率根本不是一个量级。

02 业务中台建设的本质

先谈谈业务中台。

业务中台，被形容成为前台打仗提供“弹药”支持。什么是“弹药”呢？一般的描述是，“弹药”是交付产品、服务或解决方案的中间件，既有实物形态，也有非实物形态。但这种说法并不全面，容易导致中台建设偏差。

业务中台实际上是后台的延伸，考虑后台主要是做“平台规则设计”和“资源池建设”两项任务，业务中台提供的弹药也应该是这两个方面。

一个被绝大多数人忽略的事实是，中台提供的弹药同时包括了“落地规则”和“输送资源”两个方面，根本就分不开，也没有必要分开。

例如，一家酒店集团的供应链部门作为业务中台提供的弹药，应该是供应链能力。供应链能力具体包括什么呢？看得见的是“资源”的构成，即整合供应商提供的设计、装修、供材、信息系统资源；看不见的则是“规则”的导向，包括供应商准入标准、甄选标准、服务标准等。“资源”只有进入“规则”的框架，才能成为可以被前台使用的弹药。

另一类情况里，“资源”和“规则”就是一回事。例如，金融机构的风控部门作为业务中台提供的弹药，应该是风控能力。他们看似常常都在说“这不行”“那不行”，但他们却是以自己的风控知识（模型）来对具体业务进行判断，他们的风控结论也会进入最终的产品里。他们提供了一种非实物形态的弹药，既是资源（知识），也是规则。

对于业务中台应该把资源池里的资源变成中间件，已经是不用争论的共识，在考核上，自然是关注资源经营的效能（Efficiency）；但对于其如何把平台规则变成中间件，尚且存在认知盲区，也没有明确的考核标准。

过去，很多人把规则设计相关的职能统一放到后台，认为后台设计的规则只要足够有弹性，自然就可以应对一线作战的复杂需求。实际上，这是不可能完成的任务，或者说，这种判断根本就是缺乏对于组织规律的认知。规则是死的，市场是活的，一定要有人基于基本规则去做不同应用场景的匹配。规则也应该有中间件，这也应该是业务中台的主要任务。其实，如果没有这一块职能，业务中台要想把后台传递过来的资源经营出好效能，是不可能实现的。

所以，我们既可以说业务中台应该对资源的效能负责，也可以说业务中台应该为平台的规则负责，这两者之间并不矛盾，而是高度统一的。在过去，大多企业所谓的“业务中台部门”似乎更强调自己在落地规则，而没有强调自己在经营资源。他们实际上是带着后台的脑子走到了业务中台，是“伪业务中台”。

我们甚至可以大胆地推断，大多所谓“业务中台”部门强调自己的主要职能是“落地规则“，本身也是因为这个职能难以考核。试想，如果业务中台要主张自己落地（坚守）了后台的规则，“一刀切”地当个规则的二传手，不是很容易吗？

我的建议是，把考核倒过来，从主要考核落地规则，到主要考核经营资源的效果。只有如此，他们才会以经营资源为前提，考虑如何弹性地适配规则，为前台找到经营空间。

进一步看，一个能够真正“落地好规则”和“经营好资源”的业务中台，应该拥有三项能力（如图2）：

• 连接能力——连接内外部合作者的能力，能够监管住合作者，让合作者交付有质量的服务，相当于盖木屋时取到合适木材。如供应链中台连接供应商的能力，再如生产部门连接设计部门的能力。

• 整合能力——基于自身对于某一领域的理解，将各种服务进行整合的能力，相当于把木材搭建成一个木屋的基本框架。如供应链中台设计各类流程和标准，让供应商能够各司其职，高效服务于生产。

• 交付能力——基于自身的基础能力，按照前台要求进行定制化交付的能力，相当于按照（前台）客户的要求对木屋进行一定的个性化。如供应链中台根据前台的特殊需求，给出弹性的服务。

图2：业务中台的三项能力要求  资料来源：穆胜咨询

03 数据中台建设的本质

无论以“落地规则”还是“输送资源”的形式输送弹药，本质上都是业务中台沉淀知识的外化。知识，在这个时代是以数据为表现形式的，以数据来呈现知识，也是最高效的方式。数据中台是业务中台高效运转的根本支撑。

当然，数据只是一个大概念，现在的时代，任何人都可以毫不费劲地高呼“数据就是一切”。但数据从哪里来？如何在“落地规则”和“输送资源”上发挥作用？

让我们先回到知识的概念。我认为，在数字化的时代，知识有三层：

• 指标（Indicator）——将看到的事实变成数字，进入一个绝对标准化的对话频道。例如，将人才的某项素质变成分值。

• 模型（Model）——连接数字，说明数字之间的关系。在程序设计的语言里，有点像函数（Function）或子程序。例如，按照素质模型的5项维度来计算人才素质的综合得分，这就是一个简单的模型。

• 框架（Framework）——连接模型，说明模型之间的关系。在程序设计的语言里，有点像类库（Class Library）。一项“落地规则”或“输送资源”的赋能，一定是依靠综合知识的支撑，一定需要调用某个领域的若干模型。例如，要为前台经营单元输送人才，需要综合经营单元里角色的素质、经验、技能等级等模型，甚至要考虑人才的业绩产出节奏，再计算出候选人的适配程度，选出最合适的人。

数据，实际上是经过“指标”计量之后，在“框架”和“模型”里频繁计算后，得出有价值的资产。数据让规则适用更加明确，让资源分布更加清晰，从而大大提升了企业的各种效率。

数据中台的建设，我以前曾将其称为“全域数字化打通”。其实，数据中台应该称之为“业务中台的数据化”。我的意思是，如果没有业务中台的建立，强行建立数据中台是很难打通各类业务的。而业务如果不能打通，那么数字化可能就是隔靴搔痒：一是收集到的数据就不可能有太大价值；二是数据的结果也很难产生足够的业务影响。最终，数据中台可能有名无实。

数据中台的意义在于：一方面，它连接了需求侧的各种应用场景，各种用户需求被翻译为数字，便于企业最大程度进行消化；另一方面，它连接了供给侧的各大职能，研发、采购、生产、客户关系等职能一体化协同，高效回应用户需求。这种“连接力”的根本原因是，数字是最没有争议的沟通频道，与传统沟通方式相比，威力不是一个量级。

数据中台必然建立在IT架构上，但在这个方向上，尚且存在分歧。

传统的IT架构匹配的是传统的金字塔组织，企业在信息化的过程中，按照职能划分，建设了若干具有重复功能且缺乏连接的系统，被戏称为“重复造烟囱”。显然，将能够共享的能力建设成为统一的平台，才能适应平台型组织的趋势。

有的企业在寄希望于“微服务”这种模块化技术构架，这是不可取的。微服务依然是基于独立业务形成的“烟囱式解决方案”，不同之处只是在“烟囱”之间搭建了桥梁（通过标准协议进行访问），形成了一种松散耦合的效果。从数据层面来看，微服务的数据只能通过接口进行交互，无法在数据库层实现相互访问。

一个不容回避的事实是，构建系统如果不能从全局出发，而只是在各项业务上寻求局部最佳解决方案，必然是低效的。一方面，局部的最优方案大多并不是整体的最佳方案，而不断寻找最优方案的过程中增加的复杂性，将导致更大的系统复杂性；另一方面，如果业务无法连通，数据困死在烟囱内部，必然丧失整个系统可观的协同效应。

如果构建系统要从全局出发，组织上就不能分而治之，一定要有一个统管全局的数据中台部门。在此基础上，为了避免数据中台陷入“事后看数据”的误区，还应使其与业务中台紧密连接，形成一个协作闭环（如图3）：

首先，业务中台生产数据并传递给数据中台；

其次，数据中台处理数据，产生结论后（如各职能的最优决策建议），分享给业务中台；

再次，业务中台使用结论后，又产生了新的、数量更大、颗粒度更细的数据，给予了数据中台更多的“原料”。

最后，数据中台通过处理更多更优质的数据，产生了更高质量的结论，让业务中台更靠近用户的真实需求，并能产生更多更优质的数据。

图3：业务中台与数据中台的协作闭环

资料来源：穆胜咨询

这个闭环是无限循环的（Infinite Loop），每循环一圈，企业就能产生更大的竞争优势——供需的连接更加紧密。而这种竞争优势的集中体现，就是“数据资产”。更可怕的是，这种优势的增加是不可逆的。另外，这种竞争优势一旦超过一个阈值，企业的霸主地位就再也无法被撼动。其实，这才是若干清醒的企业疯狂追逐数字化的原因。

04 中台建设的组织原理

从组织的角度，中台被翻译为Middle Office；从IT设施架构的角度，中台也被翻译为Middle Platform。所以，不少人将业务中台理解为一个IT架构、工具或产品，例如，阿里打通淘宝和天猫的五彩石项目就被普遍理解为一个IT架构上的创新。

从IT角度建设数据中台的思路，应该说已经相对成熟，这得益于这个赛道近年来的蓬勃发展。我们发现，从云徙科技、奇点云等企业开始，帮助企业建立数据中台已经成为了一个颇有想象空间的生意，还获得了大量融资（图4-图5）。

图4：2017-2021年数据中台服务商融资笔数  资料来源：天眼查，穆胜咨询

备注：样本为天眼查中含“数据中台”标签企业

图5：2017-2021年头部数据中台服务商融资金额  资料来源：天眼查，穆胜咨询

备注：头部数据中台服务商指样本企业中单笔融资金额超过1亿RMB的服务商。

但我还是要强调，数据中台并不是一个成熟的IT产品，而应该是一个解决方案。数据中台的服务商应该拥有一个方法论，但这种方法论必须导入企业，基于企业所能够提取的数据，对数据进行加工，并对数据流转机制进行设计后，才能形成企业自己的数据中台。部分服务商号称自己有数据中台的成熟产品，这相当于兜售万能灵药，是相当不靠谱的。正是因为不少服务商的冒进，这个赛道由最初的高歌猛进，逐渐走向了泡沫刺破后的稳定。2021年度，无论从融资笔数还是从头部企业的融资额来看，数据中台赛道的热度都在回调。

进一步看，即使将数据中台理解为解决方案，也并没有触及本质，可能会导致企业在中台建设中迷失。无论是业务中台还是数据中台，说到底都是组织建设问题，IT系统是组织结构的一种呈现形式。

早在1967年，著名计算机科学家、程序设计师和黑客麦尔文·康威（Melvin Conway）就曾经提出过一个观点，后来被总结为“康威定律”——设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。这个定律中，最基础的一个观点就是——组织沟通方式会通过系统设计表达出来。

下面，我将尝试阐述穆胜咨询帮助企业建立业务中台的思路，再基于“业务-数据”的联动关系，引出数据中台的建设思路。

业务中台一定是要沉淀出可以“被共享的能力”，如果前台依靠自己的本地能力解决问题，那就与业务中台无关。而要实现能力的沉淀，业务中台部门应该有三层结构（如图6）：

• 基石层——联动后台的界面，确保了对后台资源和规则的感知。这个部分负责把后台提供的资源和规则初步转化为知识（即“框架化”和“模型化”）。同时，他们也要负责向后台反馈，这可能引发整个职能条线（后台→中台→前台）建设思路的变化。

• 夹心层——知识的应用层，确保了知识的弹性。这个部分在基石层提供知识后，通过应用场景的采集和分类，形成方向性的解决方案（这种方式也被称为“业务中台的碎片化”）。同时，他们也要负责基于反馈来修正方向性的解决方案。

• BP层——向前台派出的BP（Business Partner），确保了对于市场温度的感知。这些BP进入前台团队，与他们协同作战，在感知市场温度的前提下，确保解决方案能够定制化交付。同时，他们也要负责将市场的反馈向企业内部进行传递。

图6：业务中台的三层结构  资料来源：穆胜咨询

有一个说法是，业务中台应该专注于沉淀能力进行共享，因此应该与前台部门进行逻辑分离。这种说法有一定的道理，要提供被共享的能力，一定要从前台业务中抽象出模型和框架，就不能把太多的精力放到参与具体业务中。但如此一来，却容易造成业务中台不接地气。而上述的三层结构完美解决了这个问题，至少，在我们的咨询项目实践里，这种组织设计是比较受企业认可的。

数据中台的结构显然应该和业务中台有很大程度上的相似性，也应该是三层结构（如图7）：

• 基石层——基于企业全局构建IT系统（或者称DT系统），形成数字化的底层框架。同时，他们也要负责汇总反馈数据，修正底层框架。

• 夹心层——基于底层框架，形成次级框架和主要的模型，对接每类应用场景，以产品形式支撑每个方向的解决方案。同时，他们也要负责基于反馈来清洗数据，修正模型和框架。

• BP层——向业务中台派出的BP，这些BP进入业务中台团队，确保数据中台提供的产品实现服务化，即让商业智能（Business Intelligence）完美落地。同时，他们也要负责基于业务逻辑抓取数据。

图7：数据中台的三层结构  资料来源：穆胜咨询

直观上看，夹心层和BP层的建设应该是最难也是最亟需的。实践中，不少企业都对我们提出了此类要求。但他们几乎都忽略了，自己的基石层太过羸弱，根本无法支持夹心层和BP层。于是，他们推出的BP层几乎都无法融入派去的组织模块，他们的夹心层也会做出大量华而不实的“产品”，双中台的建设也会因此走向失败。

我们的项目经验揭示了两个中台建设规律：

其一，先有业务中台建设，再有数据中台建设。解决了业务中台，数据中台的建设事半功倍。

聚焦到业务中台建设，其本质就是一个“组织转型项目”，具体包括了业务中台的流程、架构、考核、激励、知识管理等一系列子模块，这是企业走向数字化的前提。说白了，这类项目既是在帮助企业为各职能条线的运作补课，又是在帮助这些职能条线实现更大的赋能弹性。

其二，建设基石层、夹心层、BP层投入的项目时间应该是5：3：2。解决了基石层，夹心层和BP层的问题迎刃而解。

基石层建设的难度在于，大量职能条线基本都是凭“手感”在运作。他们既没有能力说清楚规则，更没有意愿说清楚规则。就前者来说，需要有理解和重塑业务的能力；就后者来说，需要有推动组织转型的能力，巧妙地撬动各个职能条线去改变的动机。

所以，无论从哪个角度说，企业的中台建设可能都需要外部咨询机构的赋能。但这种赋能绝非不是兜售“万能解药”那么简单。

05 组织和数字化转型的因果纠结

最后一个需要被解决的问题是——究竟是组织转型推动数字化转型，还是数字化转型推动组织转型？不少企业在两者之间纠结徘徊，其实大可不必。

一方面，如果组织不变，数字化转型必然事倍功半。

第一个理由是如果仅仅将数据中台作为一种IT工具，不可能打通部门墙。

数字化转型让各部门之间的数据形成连接，共享可视，而数据自动形成的决策也会相对中立，从而大大加强协同。但不要忘了，用数据的始终是人，如果没有组织转型，员工的责权利没有变，每个人都可以找到理由不使用数据，尤其是在数据中台尚未成熟时，这些理由更是可以信手拈来。

第二个理由是数字化转型着重依赖的IT部门不可能强大到撑起整个数字化转型。

当前，大量的企业自然是以CTO或CIO带领IT部门作为数字化转型的龙头。最开始，他们也是信心满满地投入战斗，但越推动就发现越尴尬。大量的业务部门连标准化都没有实现，如何进行数据化甚至数字化？但业务部门可不管这些，他们把IT部门当成万能的机器猫，要求他们无限“赋能”。可不是吗？我辅导的企业的某位业务大佬的话很有代表性——“数字化转型不就是让业务变得更好，给我们赋能的吗？”IT部门有苦难言，却又无言以对，只能被逼充当“产品经理”，但这相当于要他们在沙堆上建高楼，效果可想而知。

另一方面，如果没有数字化，组织转型也必然事倍功半，或者说，没有经过数字化转型加持的组织转型，可能会损失可观的转型红利。

当组织内的部门、团队、个人在一体化的数据中台上实现连接，此时的协作是最稳定而高效的。所以，当组织结构的改变带来业务模式和相应数据流转机制的改变，就应该通过数字化转型来固化和强化改革成果。而平台型组织的架构决定了，企业是以用户为中心，各组织模块并联协作的。这类组织模式需要信息以数字的方式进行高度共享，没有一体化的IT平台，根本无法达成这个要求，这必然需要数字化转型。

这里举个实际的例子。穆胜咨询辅导一家汽车模组制造企业转型平台型组织，当项目能看到雏形时，我们就建议他们重新评估数字化转型的重要性。因为，当前中后台已经明确了市场化的激励机制，即对赌之后的超额利润分享，如何让这种激励机制落地下去就是一个只有数字化才能解决的事。

随便举一个小问题吧。不同难度的项目，项目参与者应该有不同提成比例吧（与公司分享利润）？而项目难度又是由什么决定的呢？由设计难度、生产难度、供应链难度、客户稳定性等十几个因素决定。每个因素变了，项目的难度等级都可能变化。而项目难度变了，整个项目团队的规模就应该变化，项目团队规模变了，提成之后的利润分边（给每个人的）又会动态变化。市场的瞬息万变，只有通过数字化系统才能消化，否则，组织转型无法深入。

最后，我们需要戳穿一个一直争论不休的伪命题——中台建设究竟成不成立？

有人以大厂为标杆，一直关注大厂在“拆中台”还是“建中台”，并以此作为中台建设是否成立的论据。这种思维是狭隘的，陷入了非此即彼的误区，实际上还是没有理解组织和数字化转型之间的关系。

企业发展的阶段不同，面对的市场不同，有的企业在“建中台”，有的企业在“拆（旧的）中台”，但他们一定会“建（新的）中台”。业务中台和数据中台的逻辑是恒定的，不会消失。