聊聊中台：我对中台的一些理解与思考

2021-11-23 07:48:00

编辑导语：对于中台的定义，可能大家听过很多个版本，但你对于中台能够真正理解到位，并为己所用吗？作者分享了一些关于中台的概念以及对于中台整体的认知，希望能够与大家达成一致，并总结了几个自己在工作的关键点，分享给你。

我自己做中台已经5年多了，打算近期对过去的一些业务发展和个人成长做些总结和复盘。

在此之前，先简单介绍一些关于中台的概念和我对中台整体的一些原则观点，便于读者能够对齐认知。

一、中台概念简介

1. 中台的定义

超级产品经理

以上是中台在百度百科的定义，读完之后，可以看出2个核心信息：

① 灵活、快速、避免重复建设、提升效率，这几个关键词合起来理解就是“高复用性使得降本提效”。

② 中台是前台和后台矛盾中演化而来的产物，是在业务感与技术性之间找到的平衡点。

这里，大家先记住“复用”这个词，这是中台最最本质的点。

2. 中台的小故事

接下里讲2个关于中台被广为人知、流传最广的小故事，让大家更加直观感受下啥叫中台。

故事1：游戏公司 Supercell

超级产品经理

故事的概要就是：

supercell这家游戏公司，成员少，但是却能很快诞生爆款产品。本质是因为他们公司在架构上，将游戏内核的很多能力、素材等抽象沉淀为公共能力，然后上游一个个小团队才可以敏捷低成本地去试错，快速找到市场用户需求。

然后，阿里巴巴高管团队就由此受到启发，开启了广为人知的“大中台小前端”组织改革。

2家公司都是真的，但是背后是否真的有这个故事，却不得而知了。

故事2：美军作战模式

超级产品经理

这个故事读起来更简单，就是美军作战形式，将前线人的灵活性与后方海陆空强大火力相结合，最大程度上发挥两者的优势。

其实我觉得可能不止是美军吧，大部分军队估计都应该是这个形式吧，毕竟后方火力成本很高，不可能每个前线都给配上。

以上2个小故事呢，不管真假，其实就是为了让大家大面感受下，中台的特征：灵活性、复用性，以及降本提效。

3. 五花八门的中台概念

接下来，普及一些中台概念。

看下图中的中台名字，你一定或多或少在哪个地方看到过、听到过。

超级产品经理

不过，很有意思，这些词语，还刚好被拼成了一套军队作战体系。

在这里，我们先不用管什么海陆空，还是武器基地指挥部，就关注一个核心：“无论是什么中台，其实都是围绕某种职能为核心，集中沉淀建设，形成对应领域内的可复用能力，然后服务于上游用户对象，以此达到降本提效目的”。

二、我对中台的理解

Ok，中台概念层面大家基本上已有了解。

那如果一家公司想要决策开始做中台，需要哪些方面的认知呢？

下面，我从几个维度做一些描述，也是我自己回顾中台实践以来梳理总结的经验，希望对大家产生参考意义。

PS：下边文中出现的中台，不特殊声明的话，都特指“业务中台”。

1. 业务中台的本质

超级产品经理

中台在做的事情步骤基本上都一样：

① 抽取业务共性，抽象沉淀；

② 中台架构设计、建设；

③ 改造老业务接入，驱动新业务接入。

抽象沉淀的有时候不一定是系统能力，可能是数据标准，可能是效率工具，总之只要是多业务共性或需要，就可以抽象沉淀为集中建设。

中台建设的架构目的有4个，取自钟华老师写的《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》一书，分别是降低复杂性、可重用性、敏捷性、统一数据。

业务接入，分老业务接入和新业务接入。如果是后置化的收敛建设，必然会有老业务改造接入，这是一个痛苦的过程（后续会专门讲解一篇关于商品底层改造联动全公司业务改造接入的案例），所以在中台建设过程中，一定要尽可能减少这个情况，或做到对上游较低的影响。

从自身经历中，获得了2点启示：第一是发现有苗头某个能力要多业务化时，就尽可能提前开始行动；第二是在系统架构上要留有一定的框架扩展性，有时候可能需要多花一点代价，不过拉长时间周期来看都是值得的。这两点的把握，都需要自己在日常实践中逐渐找到感觉。

2. 做中台的2个关键条件

1）业务同属性但多样化，创新业务持续、高频

业务同属性：是指各个业务的大类属性应该是相同的，例如打车的各种模式专车、快车、顺风车都属于同属性，而外卖和酒旅就会相差很大。这里可能有童鞋会问，那同一家公司的外卖和酒旅就不需要做中台么？我觉得必要性很弱，可能两者之间会能有一些共享服务可以建设，例如用户账户体系和一些偏后端的基础建设，但是对业务中台来讲，就不会有抽象沉淀的价值。

多样化：多样化跟同属性不矛盾，就像专车、快车、顺风车是同属性下的不同形态，还例如B2C、C2C、B2B等多形态也是多样化。因为只有多样化，你的样本才会丰富，你才有抽象沉淀的必要性，否则形态很少，那其实也谈不上中台，更多像是定向支撑的业务后台。

创新业务持续、高频：如果存量的多样化是有限稳定的，你只适合一早就规划了中台，但对后置建设中台（后置是指收敛各个业务变为中台）确是不可能的。因为公司看到的收益是有限的，只是解决了存量问题，并且还要花费很大的组织调整成本。而只有让中台能够支撑源源不断的新业务，才能让边际成本逐渐降低，实现做中台整体的ROI最高。

2）中台是一种组织形式，涉及资源分布，以及协作问题，需要公司CEO、CTO决策并坚持

做中台，除了说业务形态要满足以上要求之外，还需要另外一个关键点，那就是需要公司一把手、二把手做决策。

因为中台架构，本身就是一种组织形式，把各个业务的支撑职能剥离一部分集中到统一的地方进行建设，所以核心还涉及到资源分布分配的问题。那自然，就会延伸出协作的问题，业务与中台的协作，必然没有业务内部协作来得那么得心应手。后边会提到的中台难点，也恰恰更多都是来自于这个问题。

3. 中台的发展定位

1）中台对公司是资产，不是资源

大部分时候，公司对把研发当做资源，尤其是中后台部门。但是我想说的是，中台是资产，并不单是资源。中台在做业务支撑的同时，更多需要做的是沉淀的事情。这些沉淀，可能是系统，可能是流程，可能是经验，可能是人，这些都不随着一个个项目消失，会变为公司重要的资产。

2）中台首要职责支撑业务，其次才是自身发展（应用>沉淀的思路）

中台要发展，要去沉淀资产，但是一定是在支撑好重要业务的前提下。皮之不存毛将焉附，只有提供给业务价值，才能有自身的价值和资源。中台在做系统设计时候，也需要考虑平衡，太过于前置和重的设计，都会产生错位投入，不能让资源实现ROI最大化。最好的做法，就是业务与中台交替演化，既要保持适当后置（观测小样本成熟度），也要保持前置（洞察业务，预测变化，做好设计预留）。

3）中台不能做所有的需求，有限的资源一定要发挥最大的价值

作为中台，时常要面对数以百计的业务需求。这些需求我们都能满足么？当然不是。中台资源一定是有限的，尽管可能中台规模很大，但你相对的业务需求也一定会更多。

所以，中台是做不完所有需求的，肯定需要对需求做取舍，常规的做法就是价值判断+阻断性判断。价值判断很好理解，就是做公司战略导向的、重要业务的重要项目，这样才能实现最大化的ROI。而阻断性判断，就是说当业务已接入中台的情况下，那怕业务不是非常重要，那中台也尽可能需要保证一些对业务有阻断性的能力支持，不让业务停滞。而其他的需求，能业务闭环的，尽量让业务自己闭环。

这样的原则，肯定会让一些业务感到“不平等”，但是这个可能就是一个天然矛盾，尤其是中台本身带宽较窄，不能有较大空间腾挪的时候。而解决这个矛盾，除了要保持良好的沟通之外，更多还需要靠一些对称机制将矛盾转移出去，后续会发文讲中台与业务的协作机制。

4）业务中台是业务部门，我们要具备做业务的思维

业务中台不是纯技术部门，也不是职能部门，而是业务部门，我们需要有较强的发展思维。我们的内外部环境，我们当前的主要矛盾，我们规划要去往哪里，这些都需要做业务的思维来给出答案。我自己从最早到现在，会将自己经历的业务划分为了4个发展阶段，后续文章会陆续展开来讲。