文章图片

图5：2017-2021年头部数据中台服务商融资金额
资料来源：天眼查 ， 穆胜咨询
备注：头部数据中台服务商指样本企业中单笔融资金额超过1亿RMB的服务商 。
但我还是要强调 ， 数据中台并不是一个成熟的IT产品 ， 而应该是一个解决方案 。 数据中台的服务商应该拥有一个方法论 ， 但这种方法论必须导入企业 ， 基于企业所能够提取的数据 ， 对数据进行加工 ， 并对数据流转机制进行设计后 ， 才能形成企业自己的数据中台 。 部分服务商号称自己有数据中台的成熟产品 ， 这相当于兜售万能灵药 ， 是相当不靠谱的 。 正是因为不少服务商的冒进 ， 这个赛道由最初的高歌猛进 ， 逐渐走向了泡沫刺破后的稳定 。 2021年度 ， 无论从融资笔数还是从头部企业的融资额来看 ， 数据中台赛道的热度都在回调 。
进一步看 ， 即使将数据中台理解为解决方案 ， 也并没有触及本质 ， 可能会导致企业在中台建设中迷失 。 无论是业务中台还是数据中台 ， 说到底都是组织建设问题 ， IT系统是组织结构的一种呈现形式 。
早在1967年 ， 著名计算机科学家、程序设计师和黑客麦尔文·康威（Melvin Conway）就曾经提出过一个观点 ， 后来被总结为“康威定律”——设计系统的组织 ， 其产生的设计等同于组织之内、组织之间的沟通结构 。 这个定律中 ， 最基础的一个观点就是——组织沟通方式会通过系统设计表达出来 。

文章图片

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

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

文章图片

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