当传阿里也要拆中台后，背后的罪魁祸首“伪中台”终于浮出水面

编辑导语：这几年中台在国内一度很火爆，很多企业在自家开始搭建中台，但中台实际上并不适用于所有企业，没有评估好就进行搭建反而会适得其反；本文作者分享了关于现如今“伪中台”现象的出现，我们一起来了解一下。

中台成功路上的绊脚石——“伪中台”。

一、什么是伪中台？

正所谓树大招风，作为互联网圈内顶级流量话题的中台，最近又因为一篇阿里要开始拆中台了，重新走上了舆论的巅峰。

于是乎各家企业对于中台的看法又开始出现了反对的声音，大家都在谈论还要不要继续建设中台，一时间似乎中台变成了万恶之源。

但是我想说很多时候之所以感觉中台建设并没有达到预期的效果，是因为我们在企业内部建设的实际是伪中台。

什么叫做伪中台呢？

所谓伪中台的概念，只是学习了中台思想的部分，例如为了收口而将企业内部原各业务线对于该功能的内容全部集中到所谓的中台中。

但是这样的建设既没有实现通过中台服务中心不断优化，从而为各业务线提供更优质的服务，也没有实现其他业务线需要使用时的快速接入，只是为了集中而集中。

此时各业务线不仅要忍受由于需要兼顾各个业务线提出需求导致迭代缓慢的中台服务，还需要将原有业务内的调用重新迁移至中台中，所以业务线部门肯定是怨声载道，这就是伪中台。

二、中台有罪吗？

找到了中台被嫌弃的根本原因后，我们就着这个话题进行一点深入的探究，中台架构真的是那么不堪一击吗？

我们来看看反对中台建设提出的一个最核心的论据，认为中台建设会增加代码的实现成本，导致降低实现效率。

就像我在上次演讲中也说过，在中台之前也有很多企业内部复用形式，比如：

• 代码级复用：最原始的复制粘贴对应模块代码；
• 服务复用：将功能抽象为一个个服务；

这些复用的本质就是为了提高生产效率；但是随着技术发展到今天，我们已经进入到了一个生产力相对富裕的阶段；大家可以看到此时的互联网内部，已经没有那么多真正的用户需求需要去进行解决，各家的app同质化极度严重；此时我们缺少的不是开发能力，而真正缺少的是创意设计的能力。

那么如何才能让提高我们的创意方案设计效率呢？最简单的做法就是我们剥离掉通用模块的设计，例如注册登录、账户管理、权限管理等；从而将思路只集中在核心玩法的设计上，在设计完核心玩法后，直接照搬成熟的通用模块设计产物就完成了一个完整的方案设计。

此时我们该方案投入到市场中进行测试验证，测试的本质也就是进行核心玩法的测试，这样做就能让我们可以在极短的时间内快速进行上百种核心玩法的测试，同时成本极低。

这种复用模式就称之为场景级的复用，也就是我们不只局限于代码层面的复用，而是直接将一个业务场景完整解决方案进行复用。

而中台就是场景级复用的产品设计架构产物：

中台 = 能力复用 + 场景配套服务

也就是说所谓的中台化作用就是功能复用与相关支持系统同时接入，而不是复用A服务后，还要独自去接入数据中心，对接财务系统等。

在这还可以为大家解释下什么是架构？架构是研究产品内各个模块之间的联系，而互联网内新的设计概念的不断提出，本质是在由计算效率追求上升到上层的方案设计效率的追求。

原因很简单，因为底层计算资源不值钱了，人的劳动力值钱了，特别是产品设计，编写代码与后期维护代码的人员成本。

用通俗的一个公式来说中台这种架构出现的根本原因：

买10台服务器的钱 < 代码复用时间 < 思考方案的时间

所以论证下来，中台架构的本身是没有问题，而是我们要去学会识别伪中台。

三、如何识别伪中台？

所以要如何识别伪中台呢？

这里我为大家总结了三个最基本的中台指标，大家可以基于此进行中台价值评判。

指标1：模块复用率

本指标主要考核中台服务中心设计的实用性，也就是究竟有多少业务方使用了你中台的模块，越多越好，用的多说明你抽象的共性准，代表业务方确实有这个痛点。

指标2：服务中心定制化

本指标主要考核中台服务是否真正解决业务方的问题，也就是判断中台服务中心是否需要为第三方定制化。

本质上来说定制化越少越好，说明中台的抽象能力到位，如果我们定义出的服务中心推向业务方时，业务方提出了一大堆定制化的要求；这就说明我们在中台建设前，并没有将各个业务线的需求进行统一以及我们所抽象的服务中心并不能通用。（这里如何抽象业务可以看一下我的上篇文章 《经历多个中台项目后，我总结了一套中台实战框架》 ）

也就是说中台只提供工具，至于在你手里怎么发挥那是你的本事，但是这个工具必须要能适用不同的场景。

指标3：TTM（迭代时间）

本指标主要考核中台上线后，是否成功缩短了前台业务线的迭代周期，也就是说以往前台项目需要开发一个会员中心可能需要十个工作日；而接入中台的会员服务后，只需要一天就完成，这就代表中台为业务线缩短了迭代时间。

通过这三个指标达成的效果，我们就可以快速区分出这个中台到底是不是一个伪中台？此外大家还可以在这基础上结合自己的业务背景来去定义完整的中台KPI。

最后在多说两句：所谓的阿里拆中台，只是将原有内部的未在上述三个指标作出显出贡献的部分推翻迭代罢了，而本质的这种场景化复用思想肯定是不会拆除的。

#专栏作家#

三爷，微信公众号：三爷茶馆，人人都是产品经理专栏作家，2019年年度作者。《中台产品经理宝典》作者，原万达高级产品、MBA特约讲师、独立创业者，现叮咚买菜B端产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议。