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

中台定义

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

中台分为三类：

一个是业务中台，他们多半是传统的成本中心，把后台的资源整合成前台打仗需要的“中间件”，方便被随需调用。典型的业务中台如字节跳动的直播中台、腾讯的技术中台等。“业务中台”也被称为“有形的中台”，因为他们是有实体部门存在的。

二是数据中台，这应该被称之为“业务中台的数据化”，其让资源和能力在极度共享后形成数据汇集，并基于算法进行智能决策，以支持业务中台和组织中台的运作。

三是组织中台，这是由财务、人力、战略等部门向前台派出的业务伙伴（Business Partner, BP）组成的团队。他们会进入前台的小团队，用专业视角与他们共同作战，同时也代表后台高效配置资源和政策。“组织中台”也被称为“无形的中台”，就是因为他们没有实体部门，像水一样，无孔不入地渗透到每个业务单元。

业务中台建设的本质

业务中台实际上是后台的延伸，从而实现资源或能力的极度共享，这是最传统的效率来源。考虑后台主要是做“平台规则设计”和“资源池建设”两项任务，业务中台提供的弹药也应该是这两个方面。

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

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

连接能力——连接内外部合作者的能力，能够监管住合作者，让合作者交付有质量的服务，相当于盖木屋时取到合适木材。

整合能力——基于自身对于某一领域的理解，将各种服务进行整合的能力，相当于把木材搭建成一个木屋的基本框架。

交付能力——基于自身的基础能力，按照前台要求进行定制化交付的能力，相当于按照（前台）客户的要求对木屋进行一定的个性化。

图1：业务中台的三项能力要求

数据中台建设的本质

如果没有业务中台的建立，强行建立数据中台是很难打通各类业务的。而业务如果不能打通，那么数字化可能就是隔靴搔痒：一是收集到的数据就不可能有太大价值；二是数据的结果也很难产生足够的业务影响。

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

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

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

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

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

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

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

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

这个闭环是无限循环的（infinite loop），每循环一圈，企业就能产生更大的竞争优势——供需的连接更加紧密。而这种竞争优势的集中体现，就是“数据资产”。

中台建设的组织原理

无论是业务中台还是数据中台，说到底都是组织建设问题，IT系统是组织结构的一种呈现形式。

业务中台一定是要沉淀出可以“被共享的能力”，要实现能力的沉淀，业务中台部门应该有三层结构（如图3）：

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

夹心层——知识的应用层，确保了知识的弹性。这个部分在基石层提供知识后，通过应用场景的采集和分类，形成方向性的解决方案。同时，他们也要负责基于反馈来修正方向性的解决方案。

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

图3：业务中台的三层结构

业务中台应该专注于沉淀能力进行共享，因此应该与前台部门进行逻辑分离。

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

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

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

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

图4：数据中台的三层结构

直观上看，夹心层和BP层的建设应该是最难也是最亟需的。实践中，不少企业都对我们提出了此类要求。但他们几乎都忽略了，自己的基石层太过羸弱，根本无法支持夹心层和BP层。

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

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

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

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

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