去中台是个什么鬼

去中台？要不我去XXXXXXX

首先，你看到这个标题有没有懵圈？是不是有一种。。。

不过我现在告诉你，你没有看错。这篇文章是正儿八经的来谈“去”中台的。只不过这个“去”字，打着双引号！

你会不会在想小猪我是标题党？还是套路你？

 

我告诉你，都不是，正儿八经的和你好好谈一下“去”中台。

中台成长历史以及“去”中台的由来

• 2015年，阿里巴巴提出“大中台,小前台”概念；

• 2018年9月，腾讯宣布打造技术中台；

•  2018年11月，阿里将中台系统与阿里云合体；

• 2018年11月，美团宣布建立自身平台的数据中台；

• 2018年12月，京东决定在系统中增加中台；

• 2019年3月，字节跳动搭建“直播大中台；

• 2020年底，阿里突然被曝出打算“拆”中台。

一时之间，中小公司纷纷观望，疑惑颇多：阿里“拆台”，那我现在建的或者打算建的中台，是不是都没有意义了？

2020年底左右，阿里的张勇在阿里内网发布文章表示：他对目前阿里的中台并不满意，他直言道，现在阿里的业务发展太慢，要把中台变薄，变得敏捷和快速。

阿里“大中台，小前台”已成行业标配

大家都知道阿里的“all in移动”业界著名，张勇作为阿里一号位时他又提出了“大中台，小前台”战略。推行5年多之后，中台似乎已经成为行业标配，规模稍微大一点的公司都建设了自己的中台。

当初张勇提出中台战略是想打造：统一技术架构、产品支撑体系、数据共享平台、安全体系等等。把整个组织“横”过来，支撑上面多种多样的业务形态。

不可否认阿里的中台，在近5年的发展过程中，有力地支撑了业务的发展。在如此快速的发展之下，每年的双11，从感觉上来说，系统是越来越稳定。中台战略的成效是有目共睹的。

中台正值如火如荼时为什又要提出“去”中台呢的真正原因

在“大中台，小前台”战略之后，阿里又提出了“五新战略”，即：新零售、新制造、新金融、新技术、新能源。

以阿里现在的体量，它的战略已经不是停留在“小修小补”的阶段，它要解决的是企业持续增长的问题、第二曲线的问题，所以它要做的是颠覆性创新。

很有幸，小猪有幸结识了不少阿里的大中台业务模式下孵化成功的盒马里的几位高管，同时身边有不少来自于一些P&G、来伊份、良品铺子以及一些大型国际连锁百货的CIO们也陆续在2021年年中左右开始了“去”中台化进程。

于是小猪就“去”中台问题和他们做过长达几个月的深入了解与探讨，通过调研和总结小猪得到了这么一个包括三个关于“去”中台的点，如果企业内有这三个点中的任何一点那么“去”中台就势在必行。

哪三个点呢？

• 技术上的“去”中台-敏捷化、轻量化中台；

• 业务上的“去”中台-薄化中台；

• 管理上的“去”中台-去的是那些躺平者、“独霸者”；

技术上“去”中台去的是其内部过于臃肿的架构目的是“敏捷化、轻量化中台”

中台正当势头，怎么可能真的被去掉呢？

中台并不是不支持创新，正相反，在业界内中台孵化出了像“盒马鲜生”、“永辉生活”等这样的现象级产品，如果没有中台，不可能半年打造出一整套线上线下新零售系统。

准确的说，中台适合做“组合式创新”，没法做“颠覆式创新”。

为什么这么说呢？因为，组合式创新，是把现有几个能力进行组合，形成新的能力，它强调能力的标准化，这个恰恰是中台所擅长的。以“盒马鲜生”和“永辉生活”、“永辉深夜大食堂”为例，它复用了中台的商品、库存、用户、支付、AI、安全等多个服务能力，经过重新组合，形成了“零售新物种”。

而一旦当一套生态围绕着中台被打造出来后，这套中台在技术上会变得极为复杂，动辄几百万行代码。比如说笔者自己经历过3个大型中台的建设，最少的一个不含前端相关代码也要达到370万行代码。在这些代码内大量充斥着过度封装、无用封装、潜在致命性能问题甚至黑盒。

不要以为是大厂就没有这些情况，事实上越是大厂这种情况还越严重。因此当这样的东西经过3年，4年，5年发展下来，它实际上成了一座名符其实的“屎山”了。

而业务迭代在追求快速的同时也不断的加大、加重了“屎山”，“重”到新来的人或者不是这一模块的专门负责开发的人员在出了问题时都不能快速找到相关的问题、快速的修正问题。

我们都知道中国式互联网、新零售的速度意味着什么。99.99%的系统可用性这已经属于行业标准规范了，一些更大的“厂子”甚至要追求99.999%的系统可用性。这是因为“时间”就是金钱。比如说笔者曾经就业的一家国际连锁大超市，业务因为系统性能问题中断40分钟累计损失就达：760万。

所以出了问题快速可以找到问题，譬如说5分钟定位问题、15~30分钟解决问题成为了零售IT的关键以及核心竞争力。都是人，不可能不出问题。关键在于出了问题你要能够快速解决。而如果是一座400万、600万行的代码的且是一座“屎山”，有不少模块出了问题时还只能找到专职的那个开发来解决，更甚至有不少在出现问题时一查代码发觉封装过深、或者在封装时没有考虑复杂的生产运行环境而现在要改动变成了牵一发而动全身时，此时企业除了忍受一次又一次的出问题的同时更要忍受每次出问题没个3天、4天甚至一周才能解决得了的“气”。

所以，“去”中台在技术上我们提的是敏捷化、轻量化这个中台。去除掉那些无意义的封装，使得几十人上百人的团队人人都可以在出问题时上手解决线上问题、人人都可以随时接手另一个人写得的代码成为了当下迫切的需求。

笔者小猪自身就亲身碰到过10几次类似的问题，比如说小猪有一次碰到了一个问题为：门店数*SKU数*订单种类时，如果单店SKU数超过20万个就在手持PDA上查不出当天的要货单。经过一排查，原来是最最底层的代码在设计时根本没有考虑过一家店真的会有20万个SKU，而只考虑到一家店充其量只有6000个SKU。这个点是没错，全家、罗森等一些小店单店SKU500-600已经了不得了，上千SKU更是不多。可是这个系统现在是用在如一些“会员店”的场景时，这个代码就完蛋了。关键是设计者还把这一部分代码封成了jar包，这在出问题时还要打电话给到“原厂”，然后能不能及时修得好还得看原厂当天的心情和脸色、还得哄着原厂。。。。。。

因此笔者也经常会在一个中台上线后坚持用半年到10个月时间去除中台中那些无意义的、重复制造的“轮子”。使得整个中台更轻量、更透明，以便于在出现任何情况下团队中的普通开发都可以随意接手。

所以，技术上去中台去的正是这些“黑盒”。

业务上的“去”中台其实是“薄化中台”

早在2019年湖畔大学分享时，张勇就表示，如果一个企业奔着中台做中台，就是死。这是他当时就发出的一个关于中台方向的信号，也为如今的“拆中台”埋下了伏笔。

但仔细分析张勇的话，可以发现里面包含了两个信息点，一个是“阿里业务发展太慢”，另外一个则是“中台需要变薄”。

阿里业务发展太慢，其实是指阿里近期投资和发展的业务方向上，中台本身高复用性的特质无法发挥彻底。这提醒我们，中台的建设过程中一定要留意成本控制问题，无节制的中台扩张是不可取的。

而变“薄”，则是另外一个关键信息。

上面我曾经提到过当初张勇提出中台战略是想打造：统一技术架构、产品支撑体系、数据共享平台、安全体系等等。把整个组织“横”过来，支撑上面多种多样的业务形态。，但是，颠覆式创新，是从根上做创新，它要打烂前台、中台、后台，颠覆现有模式和能力。比如智能制造颠覆传统制造、智能手机颠覆传统手机，你没法在现有生产线上去创造，只有打破原有模式。所以，中台不支持颠覆式创新，这是中台的基因所决定的。因此当企业如阿里、腾迅这种大厂，发生了在多个领域同时发力时，此时你不能仅仅依靠一个中台来解决你全行业的需求了。因此中台变“薄”，其实是为了清晰中台的边界，把真正抽象化的底层运作框架和逻辑提取出来同时还能大幅度降低成本，并且保证一定范围内的成果可知性。也就是说，费了这么大力气做出来的中台，拆台是不可能拆台的，毕竟那么好用。但是要轻量化，要把中台改造成更加适应企业对于全行业发展的形态。而这一点，恰好是我们很多中小企业在发展中台的时候，可以参考借鉴的。

管理上的“去”中台-去的是那些躺平者、“独霸者”

如何理解管理上的“去”中台化呢？笔者也亲身经历过这么一个案例。也是在一家超大型国际连锁超市数字化转型时，当企业的零售数字化中台发展成熟后，这个中台的技术团队组织内出现了20%左右的“躺平者”甚至是“霸权者”，他们一个是别有用心二者是“贪图安逸”的思路在作怪。我举两个例子大家就知道了。

例一、一个查询商品条码API开发需要6个月时间，花费230万

 

 你没看错，是真事。其实我们当时需要在新购置的智能手持POS机上可以查询一下来自中台商品的bar code，因此需要中台在网关层暴露一个可以传入商品ID然后显示一下商品的bar code的Restful API而己。换了你或者你手下的团队开发这么一个东西：1天调研、2天开发、2天测试，5天已经算多了。而我们当时由于中台1.0版掌握在这么一个“霸权、独权”团队，因为他们掌握了中台、因为中台复杂先后经历了小5年的开发，所以外部人员轻易插入不进去。同时这个团队中又有不少来自于一些国外大厂的“外包”，他们都是按“人头费”收费的。所以就有了这个API开发6个月、收费230万。。。哦。。。顺便说一下，230万是欧元！

例二、利用中台的复杂性出现了个别精英开发想“躺平”的现象

这也是真事，当一个中台运行了4年5年后。上层的领导对于中台涉及到的业务范围也越来越大、接入各种渠道也越来越频繁、越来越依靠中台。而团队内的一些元老级开发居功自傲，刻意延长工时想躺平。明明一个需求可以在11天内完成，他非要拖上个1个月完成；明明手里有空余的开发资源，他就是一个月只接一个CR。而当我们出面协调时，他就拿中台复杂外部轻易介入不了因此“我不干了，你能拿我怎么样”来要挟团队、要挟公公司，甚至不告诉你“超级管理员”密码。

 

对于这样的人，一些迫于业务压力的团队或者公司也只能忍气吞生，但久而久之就形成了“劣币驱良币”，“霉币大量污染好的币”的情况了。

因此，一旦出现了这样的人员团队管理上也是坚持需要”去除”的。法宝正是第一点技术上“去”中台的：透明化。唯有透明了、消除了黑盒、敏捷化轻量化了中台才可以为第三点，管理上的“去”中台夯实基础。

所以到此这三点“去”中台形成了一个完整的企业IT团队管理“闭环”，只有把这三点贯穿起来才能让中台形成长久、持续的生产力和战斗力。这三点也构成了一个IT团队建设的不断、周期性的“内循环”过程以使得团队始终保持着良性血液的循环和动力。

写在末尾

因此我们至此终于知道了“去”中台，去的不是中台这个东西本身。中台正当势头。有人说中台不行了，连阿里都要放弃它了，其实不然。不是中台不行，而是场景变了，中台在提升组织效率、进行组合式创新等方面还是非常优秀的。许多大型企业面临的也是这方面的问题，所以中台依然适用。但是BAT、TMD们更多面临的是颠覆式创新、释放组织创造力等深层次的问题。而放在零售行业、电子行业、IOT领域甚至是制作业来看中台的演进，中台将越来越薄、越来越轻、越来越敏捷。这是中台发展的一个必然趋势。跟小猪一直提倡的“中台碎片化”理念其实是不谋而合的，中台会越来越碎、越来越轻。这也正是云原生、微服务的本质。

所以我们一定不要“人云亦云”，看问题要看本质、去了解它的前后背景。当然，一旦企业出现了上述三个问题中任何一个点时，你需要考虑一下我说的“去”中台化了。同时小猪本身也正带领着一支“精干”的中台团队，正不断的在对中台技术团队进行提效今年也正当是“内循环3.0版提效”开始，小猪在此也在不断的告诫自己：如果我的团队出现了上述这三个问题中的任意一点，我会坚定不移的“去”中台化。如果要是是我自己出现了这样的问题，那么小猪也一定。。。。。。坚定的就把自己给“去”了。