怎么建设中台。业务中台和数据中台的组织、支撑技术和方法论

例举典型的需要建设中台的场景，供参考判断要不要建中台。建设中台需要考虑组织、技术支撑和方法论，往往还需要咨询服务的帮助，本文可以作为思考中台建设的大框架。

这是中台系列的第二篇。上一篇什么是中台，什么不是中台阐释清楚了中台的概念，这一篇说明什么情况下可以考虑建中台，如果要建要怎么建的问题。

要建设中台，首先要考虑要不要建设中台。话说的这么绕是因为现在有很多不明就理就想建中台的。这个问题先做个初略的判断。

要不要建设中台

1

对业务中台来说，比较符合的场景主要有：

• 业务系统研发团队至少大几十人以上（含外包的），需求多变化快，系统又涉及多个领域（比如做ERP、电商的），业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚，提高研发效率。

• 做相似行业的外包项目为主，业务规模也做的比较大的（一年有两位数的项目）。这时业务中台可以提升软件复用，降低定制化成本，提高研发效率。如果你做外包，每个项目都完全不一样，那中台也救不了你。

此外还有以下场景可能不需要建设完整的中台，但适合落地与中台相关的微服务技术的：

• 大规模互联网式在线系统，对稳定性和弹性要求高当前搞不定的。微服务或业务中台可以比较好的解决这些问题。

• 掉到IT竖井的坑里想爬出来的，通过项目外包做的系统无法管理和维护的。微服务或业务中台可以对系统的API、文档等进行有效管理，也能实现系统间的打通。

对数据中台来说，比较符合的场景主要是数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。如果这些数据产品和运营人员还在多个团队，那基本上数据中台没跑了。如果经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题，那基本上数据中台也没跑了。

并不是数据量大就需要建中台，主要还是看用数据的姿势是不是比较复杂，当前问题是不是比较多。对于这类符合的业务，数据中台能把层层数据直到最上层的指标梳理清楚，提升数据质量，从而提升运营效率。把数据理清楚了，往往还能降低数据存储和数据开发人员的成本。

除了上述判断，还有一条是同行对比。如果一个行业大家都有点跃跃欲试想弄中台，那领先者一定要想办法抢先（既然是领先者了，往往也符合上述标准），不然就可能被颠覆。跟随者要不要想办法抢先从而超越领先者呢？可能不好说吧，但如果领先者已经建了，跟随者一般得紧跟，否则真可能被甩开了。

如果根据上述逻辑觉得大致要考虑去搞一把中台的话，那请继续读本文以下内容，读完本文后续内容然后更具体的看看问题存不存在，条件是否具备。

要建设中台，需要考虑组织、支撑技术、方法论这三个方面，往往还需要咨询服务。

组织

2

中台作为一种有业务属性的共性能力，首先就需要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台，首先要看领导有没有魄力去整合建立一个中台组织。因为原来的平台部通常不懂业务，懂业务的人各自分散在前台业务部门，所以建立中台组织往往涉及人员、组织架构和部门职责的调整。正因为如此，中台的建设往往需要作为一把手工程才能成功。

中台组织关键要懂业务和承担业务职责。举个例子，一个大数据平台的建设运维团队不是一个中台组织。一个团队如果做了非常完善的中台产品（如开发了数据中台所需要的指标管理系统、数据仓库开发系统、数据质量管理系统等等），但只是把产品提供给业务方使用，这个团队仍然不能说是中台组织。只有当这个团队承担起指标体系的建设和管理、数据仓库的设计和实施、数据质量的保障等工作时，才可以说是中台组织。而要做到这一点，这个组织肯定是比较了解业务的，它的目标和考核也一定与业务有相关性（肯定不只是平台稳定性这样的非业务指标）。

中台组织的层次与中台的层次最好是对应的，BU级的中台组织最好直接向BU老大或分管的CXO汇报，企业的中台组织最好直接向CEO或分管的CXO汇报。

这里特别说明