对“中台”的理解

1、背景

今天偶然看到36氪之前发的一个文章：《中台，我信了你的邪》，但看这个题目，感觉对“中台”充满了敌意和不信任。我赶紧看了一下，文章太长了，讲了“中台”的由来，讲了茅台引入中台的风波，以及后面大家的反思种种。实际上，我觉得写这文章的人应该不是技术出身。我第一次深究这个概念，其实，大体一看就懂了，我是这么理解的：类似于手机app，有前台（前端）、有后台（后端）；现在为了支撑前端的多样化和多变性，引入一个逻辑层，叫中台，这就相当于在中间加了一层。然后，原文也提到国外游戏公司用的顺风顺水，阿里用的舒服得很，字节跳动也用着呢。为啥专门给别人建立中台的公司却举步维艰，不好做呢？

2、理解

乍看一下，有点被问懵了的赶脚，实际上就像做软件项目一样，你架构再牛逼，不符合用户需求也是白扯！即便是你符合了用户需求，没有把用户伺候满意了，也是白扯！这是出门做项目大家都深有体会的吧。

回到中台这个话题，我们从技术方面考虑前中后台，从行政管理层面、业务方面也可以有，甚至于从其他各个行业层面也是有的。但是细想不难发现一个问题，在原本结合密切的前后台中间插一脚，而且还要尽量做到复用、高效、独立等等，其实难度非常大了。尤其是大体量的公司，如果在建立之初没有想到中台的存在，前后台剥离、然后插入、适应节奏等等过程，一个不好，整个公司业务流程都无法运转。

实际上，中台的建立涉及原有前后端业务解耦的一个过程，将公司的整个运营进行模块化再包装，有的公司甚至可以借着中台建立的过程进行公司模块化重建。尤其对于业务领域比较集中的公司，建立中台的意义是非同一般的，打个比方：互联网公司。下图是来之知乎的，原文链接：https://www.zhihu.com/people/keeliu/activities

3、如何做好

但是既然有先例可以做，那就一定有办法可以做好。实际上在网上看了不少文章，有一些已经提出来了比较重要的观点，撇除本身技术因素不说，我大概总结了一下：

1、定位和场景相符。寻找合适的场景，将中台产品定位好，类似于软件的中间件一样，首先要明白前后接口和自己的功能，找到合适的场景才能发挥最大的功能。

2、客户支持和沟通。这个太重要了，做项目本质是满足客户要求，如果客户不支持，他总是可以找到不满意的地方！但是对于中台来说，一般的支持是不够的。因为中台的引入给客户方带来的风险和利益都是非常大的，它涉及到公司整体的运营模式，当然也包括建立之后用户是否可以适应中台的存在，都是风险点，以上这些对于客户都是巨大的挑战。所以，表面上看，我们只是多了一层面，事实上，这对于一个公司而言，是在做“心脏手术”，其重要性不言而喻。中台项目前中后必须保持密切的客户沟通，取得最高层的支持至关重要，还要帮助普通员工建立新的工作逻辑和破除原来的思想障碍，因为归根到底，在我们当前环境下，管理是对于人的管理，人员思想不统一，一旦跟客户产生不信任，项目就容易陷入困境。

3、优化和运维。中台一旦建立好了，更多问题会接踵而至，因为中台对接的是公司前后两大重要接口，是全公司的逻辑核心，这里面容易出问题的地方太多了，比如：

1、客户是否真正利用中台发挥了它应有的价值；

2、员工是否可以适应，是否足以支撑中台的运营；

3、多个前台接入后中台是否能够完全满足沟通的需要，会不会成为沟通的瓶颈；

4、对于中台有问题的地方如何做到及时更改和修复，等等。

尤其是作为第三方来做中台，项目交付之后，也不能松懈，后期的运维同样可能会消耗比较多的精力。这里最好单独签订运维合作合同。

4、中台的必要性

其实，虽然中台有存在的意义，但它一定不是普遍适应的，试想一下公司架构都会千差万别，业务逻辑更是五花八门了，哪有一种普适的模式能统一大众呢？中台的存在可以解决一些公司目前的问题，但是不能强推，即便客户要求建立中台，也必须要帮助客户理性分析公司状态，充分确定中台建立之后可以介入的业务以及工作范围，否则交付之后也会麻烦不断。有些公司有多个子公司、涉及行业比较杂散和运营模式各不相同，中台建立起来难度肯定非常大，而且，即使建立起来了，发挥的价值也可能远远低于预期。对于想要建立中台的公司来说，很重要的一点就是根据公司现状充分评估建立中台的重要性、风险性和实施难度。

不过，可以预见的是，如果公司建立之初就有中台的概念，这是非常好的，尤其是互联网公司，专注某一领域。事实上，对于创业者来说，认清现实，保持清醒头脑的同时，也要适当规划将来（虽然大家普遍想的太远，哈哈哈）。