建设|中台建设：不只是IT工具，更是组织布局工具|中台|组织|资源|业务|转型

与数字化转型一起火起来的，是“中台建设” 。如今，在大多数实践者眼中，中台就是数字化转型标配，以至于，一个帮助企业建设中台的创业赛道异军突起。同样，喊出中台建设口号的企业不少，但真正建起来中台的，更是屈指可数。
但随着中台建设的火爆，有关“中台建设究竟成不成立”的争论也如影随形。就连被认为是中台建设典范的阿里，有段时间也传出了正在“拆中台”的消息。有人更是戏称：“大公司上中台，钱没了；小公司上中台，公司没了。 ”
本项研究将探讨数字化转型中的三个关键问题：一是Why ，即是否应该建设中台？二是What ，即应该建设什么样的中台？三是How ，即如何建设中台？
01 数字化转型与中台建设数字化转型是互联网浪潮发展到一定阶段的必然。沿着互联网商业的进程，数字化转型呼之欲出。整体来看，数字化转型一共分为三个大类：数字化营销、工业数字化和数字化管理，也有若干对应的同义词或延伸词（如表1）。我们对这些关键词的百度指数进行了加权统计，发现了数字化转型的三波浪潮（如图1）。
表1：数字化转型关键词

文章图片

资料来源：穆胜咨询

文章图片

图1：数字化转型浪潮热度趋势图
资料来源：穆胜咨询
备注：关键词热度参考百度指数加权计算，加权方式主要考虑了各个同义词/延伸词与中心词的关联度。
一波数字化转型浪潮是“数字化营销” ，出现在2017年。互联网转型高潮属于需求侧的消费互联网领域，而数字化营销显然是焦点。
前一波数字化转型浪潮是“工业数字化” ，出现在2015年。在流量红利消失之前，互联网转型率先映射到供给侧的产业互联网。其中，工业数字化是毫无疑问的C位。
第三波数字化转型浪潮是“管理数字化” ，目前处于正在爬坡，预计会是在2022-2023年之间达到高点。前两个浪潮里， “数字化营销”和“工业数字化”两个趋势进一步倒逼出了企业内部的“数字化管理” 。要将产业的供给用于满足用户需求，必须要有企业作为枢纽。如果两头都是数字化的，企业就不得不让自己的管理也走向数字化。过去，这个领域一直是由ERP（Enterprise Resource Planning）来承接，但ERP作为工业经济时代的产物，显然无法满足互联网与数字化时代的需求。

文章图片

管理数字化的本质，是打通企业内部的“连接”从而提升效率。这可以通过两个方面来实现：
一是传统的连接，即建设“业务中台” ，实现资源或能力的极度共享，这是最传统的效率来源。我曾举过一个简单的例子：糖醋排骨、鱼香肉丝、松鼠桂鱼这几道菜，都需要糖、醋、生抽、老抽、淀粉等调料做成的糖醋汁，于是，厨师就可以提前调制好，在做某道菜时直接加进去就行。
其实，传统企业也这么做，例如，将营销资源集中起来，建立一个营销体系作为业务中台供前台团队调用。但这种操作在节约成本的同时，也会导致资源或能力输送不到前线去，产出下降，速度也变慢。所以，传统企业会权衡利弊，选择是否建业务中台。
二是数字化的连接，即建设“数据中台” ，让资源和能力在极度共享后形成数据汇集，并基于算法进行智能决策。互联网企业在资源和能力的共享上似乎没有太多顾虑，因为他们有数字化的解决方案。数据作为生产资料的价值已经无需多言，简单的数据汇集，就可以发现更多的效率提升空间。加上算法智能决策（算法也是自动进化的），这种效率优化空间实在太吸引人了。
其实，企业根本无法抵抗数字化转型趋势，某种程度上，其选择中台建设是“被卷入”的。可以说，有无中台决定了企业的未来，因为，有无之间的效率根本不是一个量级。
02 业务中台建设的本质【建设|中台建设：不只是IT工具，更是组织布局】先谈谈业务中台。
业务中台，被形容成为前台打仗提供“弹药”支持。什么是“弹药”呢？一般的描述是， “弹药”是交付产品、服务或解决方案的中间件，既有实物形态，也有非实物形态。但这种说法并不全面，容易导致中台建设偏差。
业务中台实际上是后台的延伸，考虑后台主要是做“平台规则设计”和“资源池建设”两项任务，业务中台提供的弹药也应该是这两个方面。
一个被绝大多数人忽略的事实是，中台提供的弹药同时包括了“落地规则”和“输送资源”两个方面，根本就分不开，也没有必要分开。
例如，一家酒店集团的供应链部门作为业务中台提供的弹药，应该是供应链能力。供应链能力具体包括什么呢？看得见的是“资源”的构成，即整合供应商提供的设计、装修、供材、信息系统资源；看不见的则是“规则”的导向，包括供应商准入标准、甄选标准、服务标准等。 “资源”只有进入“规则”的框架，才能成为可以被前台使用的弹药。
另一类情况里， “资源”和“规则”就是一回事。例如，金融机构的风控部门作为业务中台提供的弹药，应该是风控能力。他们看似常常都在说“这不行”“那不行” ，但他们却是以自己的风控知识（模型）来对具体业务进行判断，他们的风控结论也会进入最终的产品里。他们提供了一种非实物形态的弹药，既是资源（知识），也是规则。
对于业务中台应该把资源池里的资源变成中间件，已经是不用争论的共识，在考核上，自然是关注资源经营的效能（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平台，根本无法达成这个要求，这必然需要数字化转型。
这里举个实际的例子。穆胜咨询辅导一家汽车模组制造企业转型平台型组织，当项目能看到雏形时，我们就建议他们重新评估数字化转型的重要性。因为，当前中后台已经明确了市场化的激励机制，即对赌之后的超额利润分享，如何让这种激励机制落地下去就是一个只有数字化才能解决的事。
随便举一个小问题吧。不同难度的项目，项目参与者应该有不同提成比例吧（与公司分享利润）？而项目难度又是由什么决定的呢？由设计难度、生产难度、供应链难度、客户稳定性等十几个因素决定。每个因素变了，项目的难度等级都可能变化。而项目难度变了，整个项目团队的规模就应该变化，项目团队规模变了，提成之后的利润分边（给每个人的）又会动态变化。市场的瞬息万变，只有通过数字化系统才能消化，否则，组织转型无法深入。
最后，我们需要戳穿一个一直争论不休的伪命题——中台建设究竟成不成立？
有人以大厂为标杆，一直关注大厂在“拆中台”还是“建中台” ，并以此作为中台建设是否成立的论据。这种思维是狭隘的，陷入了非此即彼的误区，实际上还是没有理解组织和数字化转型之间的关系。
企业发展的阶段不同，面对的市场不同，有的企业在“建中台” ，有的企业在“拆（旧的）中台” ，但他们一定会“建（新的）中台” 。业务中台和数据中台的逻辑是恒定的，不会消失。