中小企业建立中台的条件

Posted 2022-04-15 hursing

2019年起不少中小企业跟风建立了中台，然而到2021年末就很少呼声了，从招聘网站的岗位数量上也可观察出来。中台的撤销，很大程度源于财务部的核算：建中台后支出剧增。如果业务收入未能如期增长，那么中台肯定在降本大战中首当其冲。
反观这波浪潮起伏，笔者总结出3个建中台的条件。注：本文仅讨论小中台，即人员由产品研发构成，不包括人资、财务、法务等职能。

1.业务线超过三个且多业务之间有足够的相似度

公司业务已经多元化，这是最大的前提。单一业务下也按职责来划分中台，那就徒具形式化了。而只有两三个业务或项目组的话，也还是各管各的好，沟通越少效率越高。多数资料都讲到，中台的作用之一是减少重复开发。所以如果重复性工作不够多，也是没有中台出场的机会的。
“减少重复开发”，反过来说，就是增加“重复利用”，这有3个层次：

1. 代码复用
2. 业务流程复用
3. 人员能力复用

中台最底层的意义是代码复用。能让程序员复制粘贴就完成的工作，业务逻辑肯定是大同小异的。而中台做的事就是比复制粘贴高级一些，设计出来的程序，通过改变配置就能给不同的业务用。需要改变的配置不应该很多，否则同样有学习和维护成本，通用性仍会降低。所以这也要求接入中台的业务间有一定的相似度，否则差异过大就没有复用的必要。例如游戏、电商、内容社区，三者之间的相似度就很小，中台难以同时完全支撑这些业务。
最上层的人员能力复用，体现在两方面：一是单个项目的工作量不饱和，需要对多项目服务来填补工时空缺；二是同种技能可以为不同业务服务，各业务的差别只是输入的信息不同。例如数据中台里，如果不同业务间的用户画像维度差不多，那么数据分析师也就能为多个业务产出分析报告。

2.有能力匹配的业务架构师和技术架构师

无论业务间在表面上多相似，还是需要人去抽象整合的。整合出来的，可以是一套代码或者是一个通用模式。
业务架构师可以简单理解为懂技术的产品经理，能增加对技术实现难度、灵活性等的考虑来制定需求。他们更擅长建模，而不是写代码。架构师区别于技术专家是在于解决问题时会同时关注非技术的参量，例如运维难度和成本。做业务架构的难点在于各种考虑因素的平衡，而不是某些参量的最大化。
总结得更简单点：中台的专家团队必须是擅长掌控大信息量的人。这群人最重要的画像标签是：沟通表达能力强、善于总结复盘、服务意识。

3.真正节省成本

中台成为一个组织，就会存在部门墙，增加沟通成本。中台和业务方都有自己的KPI，更高层要做好协调统一。否则双方各自为政，弄不好会成为内耗。具体例子如：某些东西要不要做，优先级和质量要求等。
沟通多就需要增加人力，人力多就需要加强管理，最终中台会变成一个纯支出的成本中心。这些成本需要按一定的财务规则核算分摊到各个业务。这个分摊到的费用，如果比业务方自己负责全部事务的花费还多，那就说明中台没有存在的价值。
再省心点说，如果业务的营收规模足够大，能覆盖中台附带的成本增量，那么短期的支出变大也值得，会对未来更多的业务拓展有所帮助。
在有中台之前，“复用思维”更多体现在通过知识分享机制来增进交流。如果这种机制已足够，那没必要成立中台。“大中台小前台”是使得这种机制难以执行，因为中台人员需要专注技术，前台人员需要专注业务，在团队运作上失去了交流的时间和空间条件。双方人员会在一定时间后到达瓶颈难以成长，增加了不稳定性。解决方案是轮岗，不过轮岗也是企业要付出的成本。