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

文章图片

图7：数据中台的三层结构
资料来源：穆胜咨询
直观上看 ， 夹心层和BP层的建设应该是最难也是最亟需的 。 实践中 ， 不少企业都对我们提出了此类要求 。 但他们几乎都忽略了 ， 自己的基石层太过羸弱 ， 根本无法支持夹心层和BP层 。 于是 ， 他们推出的BP层几乎都无法融入派去的组织模块 ， 他们的夹心层也会做出大量华而不实的“产品” ， 双中台的建设也会因此走向失败 。
我们的项目经验揭示了两个中台建设规律：
其一 ， 先有业务中台建设 ， 再有数据中台建设 。 解决了业务中台 ， 数据中台的建设事半功倍 。
聚焦到业务中台建设 ， 其本质就是一个“组织转型项目” ， 具体包括了业务中台的流程、架构、考核、激励、知识管理等一系列子模块 ， 这是企业走向数字化的前提 。 说白了 ， 这类项目既是在帮助企业为各职能条线的运作补课 ， 又是在帮助这些职能条线实现更大的赋能弹性 。
其二 ， 建设基石层、夹心层、BP层投入的项目时间应该是5：3：2 。 解决了基石层 ， 夹心层和BP层的问题迎刃而解 。
基石层建设的难度在于 ， 大量职能条线基本都是凭“手感”在运作 。 他们既没有能力说清楚规则 ， 更没有意愿说清楚规则 。 就前者来说 ， 需要有理解和重塑业务的能力；就后者来说 ， 需要有推动组织转型的能力 ， 巧妙地撬动各个职能条线去改变的动机 。
所以 ， 无论从哪个角度说 ， 企业的中台建设可能都需要外部咨询机构的赋能 。 但这种赋能绝非不是兜售“万能解药”那么简单 。
05 组织和数字化转型的因果纠结 最后一个需要被解决的问题是——究竟是组织转型推动数字化转型 ， 还是数字化转型推动组织转型？不少企业在两者之间纠结徘徊 ， 其实大可不必 。
一方面 ， 如果组织不变 ， 数字化转型必然事倍功半 。
第一个理由是如果仅仅将数据中台作为一种IT工具 ， 不可能打通部门墙 。
数字化转型让各部门之间的数据形成连接 ， 共享可视 ， 而数据自动形成的决策也会相对中立 ， 从而大大加强协同 。 但不要忘了 ， 用数据的始终是人 ， 如果没有组织转型 ， 员工的责权利没有变 ， 每个人都可以找到理由不使用数据 ， 尤其是在数据中台尚未成熟时 ， 这些理由更是可以信手拈来 。
第二个理由是数字化转型着重依赖的IT部门不可能强大到撑起整个数字化转型 。
当前 ， 大量的企业自然是以CTO或CIO带领IT部门作为数字化转型的龙头 。 最开始 ， 他们也是信心满满地投入战斗 ， 但越推动就发现越尴尬 。 大量的业务部门连标准化都没有实现 ， 如何进行数据化甚至数字化？但业务部门可不管这些 ， 他们把IT部门当成万能的机器猫 ， 要求他们无限“赋能” 。 可不是吗？我辅导的企业的某位业务大佬的话很有代表性——“数字化转型不就是让业务变得更好 ， 给我们赋能的吗？”IT部门有苦难言 ， 却又无言以对 ， 只能被逼充当“产品经理” ， 但这相当于要他们在沙堆上建高楼 ， 效果可想而知 。