资源|中台建设：不只是IT工具，更是组织布局( 五 )

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

文章插图
下面，我将尝试阐述穆胜咨询帮助企业建立业务中台的思路，再基于“业务-数据”的联动关系，引出数据中台的建设思路。
业务中台一定是要沉淀出可以“被共享的能力”，如果前台依靠自己的本地能力解决问题，那就与业务中台无关。而要实现能力的沉淀，业务中台部门应该有三层结构（如图6）：

基石层——联动后台的界面，确保了对后台资源和规则的感知。这个部分负责把后台提供的资源和规则初步转化为知识（即“框架化”和“模型化”）。同时，他们也要负责向后台反馈，这可能引发整个职能条线（后台→中台→前台）建设思路的变化。
夹心层——知识的应用层，确保了知识的弹性。这个部分在基石层提供知识后，通过应用场景的采集和分类，形成方向性的解决方案（这种方式也被称为“业务中台的碎片化”）。同时，他们也要负责基于反馈来修正方向性的解决方案。
BP层——向前台派出的BP（Business Partner），确保了对于市场温度的感知。这些BP进入前台团队，与他们协同作战，在感知市场温度的前提下，确保解决方案能够定制化交付。同时，他们也要负责将市场的反馈向企业内部进行传递。

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

基石层——基于企业全局构建IT系统（或者称DT系统），形成数字化的底层框架。同时，他们也要负责汇总反馈数据，修正底层框架。
【资源|中台建设：不只是IT工具，更是组织布局】夹心层——基于底层框架，形成次级框架和主要的模型，对接每类应用场景，以产品形式支撑每个方向的解决方案。同时，他们也要负责基于反馈来清洗数据，修正模型和框架。
BP层——向业务中台派出的BP，这些BP进入业务中台团队，确保数据中台提供的产品实现服务化，即让商业智能（Business Intelligence）完美落地。同时，他们也要负责基于业务逻辑抓取数据。

文章插图
图7：数据中台的三层结构资料来源：穆胜咨询
直观上看，夹心层和BP层的建设应该是最难也是最亟需的。实践中，不少企业都对我们提出了此类要求。但他们几乎都忽略了，自己的基石层太过羸弱，根本无法支持夹心层和BP层。于是，他们推出的BP层几乎都无法融入派去的组织模块，他们的夹心层也会做出大量华而不实的“产品”，双中台的建设也会因此走向失败。
我们的项目经验揭示了两个中台建设规律：