撰稿丨千山
审校丨云昭
日前，阿里巴巴组织架构剧变一事引起各方关注。3月28日，张勇一纸《唯有自我变革，才能开创未来》的内部公开信，宣布阿里进入“化整为零”的独立上市时代。
按照“1+6+N”的改组计划，阿里巴巴集团作为阿里巴巴的上市公司主体不会改变，其下将设六大业务集团和多家业务公司，这些集团和公司未来可以独立融资甚至上市募股。
紧接着，3月30日，以“新的组织和治理结构”为主题，阿里巴巴举行电话会议。阿里巴巴集团董事会主席兼CEO张勇对于市场关切问题进行回应，“历史上，我们有很多通过生产关系的改革，来促进生产力发展的案例。就像12年前阿里巴巴将一个淘宝变成了三个，淘宝、天猫和一淘后期释放了巨大的生产力。”
图源：新浪微博
组织架构的大规模调整必然带动职能部门的变化。根据内部全员信，集团中后台将全面做轻、做薄，“多年以来积累的中后台能力，将有序进入到相关业务集团和公司，为前台业务发展继续发挥重要价值”。简言之，阿里巴巴一直以来构建的“大中台”能力会逐步被更强有力的前台吸收，以更敏捷的方式服务发展需求。
可以看到，“中台”这个因阿里巴巴而风靡一时的概念在这场变革中正在被消解。那么，近年来反复强调要建设“敏捷组织”的阿里巴巴为何要在此时放弃其“大中台”？潮水褪去后，“中台”到底价值如何？对企业而言，中台还有未来吗？
网友表示对中台去向的讨论
图源：脉脉
1、兴起，是为了敏捷
在没有中台的时代，项目需求稳定时，“前台”和“后台”两个部分已足以支撑。但随着经济发展，如何快速响应用户需求、如何避免重复造轮子成为了主要矛盾。
中台就是在这样的背景下应运而生。
2015年，阿里巴巴设立 “大中台、小前台” 战略。自此，“中台”这一概念开始进入大众视野。
彼时，“中台”还没有一个统一的概念，如何建设中台也是众说纷纭。
当时ThoughtWorks负责中台咨询业务的总负责人王健提出过一个相对清晰的定义：中台是“企业级能力复用平台”。中台建设根本上是为了“弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾，提供一个中间层来适配前台与后台的配速问题。”
这一解释很通俗易懂地点出了中台的运作机制和关键特征。
其一，敏捷。这是中台的本质目的。业务需求变化快，中台协调了敏态前台和稳态后台的平衡。中台的构建最终是为了提升快速响应力，赋能前台业务。
其二，解耦。随着业务发展，业务系统之间的交互通常会变得越来越复杂，甚至可能牵一发而动全身。中台通过把复杂的业务逻辑和技术细节封装，极大降低了业务单元之间的耦合度。
其三，复用。中台的核心价值就在于可复用性。一些公共的能力通过复用，大大提高了开发效率，避免了重复建设。
无论是业务中台、数据中台还是技术中台，实际上都是通过抽象出通用的服务能力，再以标准化的接口对外输出，从而实现业务单元间的协作创新。
这种全新的组织和技术架构战略很快掀起了风潮，阿里巴巴之后，腾讯、百度、小米、京东等一众互联网大厂也都开始进行自身的中台建设。
但就在中台战略执行得如火如荼之时，阿里开始了拆中台的行动。
2、拆中台，同样为了敏捷
不可否认，中台在过去很长一段时间里给阿里巴巴带来了期待中的价值。它不仅符合当时阿里发展的需求，解决了其业务规模迅速扩张带来的重复建设、资源浪费等问题，也孵化出了如盒马鲜生之类的现象级产品。
但实际上，“大中台+小前台”这样的模式在实际的应用场景中也逐渐暴露出其弊端。这个“看上去很美”的概念在现实的检验下并不如理想中那么理想。比如：
1、中台自身的存在可能导致组织结构的庞大化、复杂化，增加沟通的成本和维护的成本；
2、中台抽象出的标准化通用能力可能导致惯性和僵化，降低各业务单元的创新活力，失去针对具体业务场景的灵活性和个性化；
3、中台的能力封装更适宜搭建逻辑相对简单的应用，无法及时响应和满足多元化的业务需求和市场变化。
随着这些问题的暴露，阿里逐渐意识到：中台太厚的话，反而会成为前台快速发展的掣肘。于是，拆中台成为了阿里自然而然的选择。
2020年底，张勇在内网发文，直言对阿里中台的不满。在他看来，中台过于臃肿和僵化，阻碍了业务的快速发展和颠覆性创新。他要求把中台变薄，变得敏捷和快速，释放出更多的人力和资源去做前台的个性化改造。
当然，这只是开始。内外因的共同作用又加速了阿里“拆中台”的进程。
一方面，市场格局变幻莫测，拼多多、抖音、快手等新势力快速崛起，这些竞争对手往往有更贴近用户的产品形态和更灵活的创新迭代能力；另一方面，阿里的业务版图正在试图开辟新的疆域，寻找新兴业态，掌握未来发展先机。其业务板块的复杂化、多元化以及跨界融合的趋势前所未有地日趋明晰。在这样的诉求下，原有的中台战略已经不适用于阿里，甚至成为了制约其向上的瓶颈。
3、一切为了敏捷
近两年，张勇在内外部多次强调，敏捷组织是实现多业务多业态超大型企业高效治理的路径。
为了成为“敏捷组织”，阿里一直在探索有效的解决方案。“拆中台”就是策略之一。这里的“拆”并非是全然的否定或完全的放弃，而是根据外部环境变化和自身发展现状，对中台战略进行了调整。其实质是将庞大的共享中台事业部打散，下沉到各个业务单元，形成更轻量化更灵活的业务域中台。
就此，51CTO询问了苏宁易购供应链BU采购管理研发中心采购中台技术负责人胥磊。在他看来，“中台更多是对‘通用’业务能力的沉淀。要实现‘通用’，一般都有限定范围，在某个业务域、业态或者赛道通用，在这个范围内对能力‘组合’创新会得到事半功倍的效果。”
“既然（阿里）定位大中台，肯定是要把相关领域的相似业务能力进行扎口整合，‘范围’就会很大，需要更多考虑自身中台的一个系统定位，很难去适配多业态发展带来的的五花八门的特性需求。业务都被逼无奈围绕‘大中台’去发展，很难做到‘颠覆性创新’。按业务域拆成小中台，一方面沉淀各自业务域的能力，另一方面对个性化需求也能更快响应，毕竟拆分后和业务都绑一条绳上了，真正的一荣俱荣了。”
如今，阿里这样的“拆中台”既保留了中台本来的标准化能力，又增加了中台针对具体需求的灵活性。胥磊强调：“像‘盒马’这样现象级的产品已经证明了中台对业务能力沉淀的作用是不可否认的，但是前提是有个范围的限定，一个小而灵活的、和特定业务域契合的中台才是真正意义上的中台。”
4、没必要刻意追求中台
之前51CTO采访了作业帮首席算法专家、智能中台部负责人宋旸，提及中台本质时，他给出了一个易理解的答案：中台本质上是把通用的东西剥离、抽象出来，将统一的团队去维护。做中台出于两个目的，一个是成本上，如果每人都独立干的话，成本会成倍的增加。第二，将不同业务下的同样的问题进行归类，交给更专业的人来解决，会做得更好。
同时，宋旸也给出了他对于中台的看法：中台不适合小公司，也不太适用于大型公司。下面是他的解释——
是否上中台，个人觉得还是取决于公司的发展阶段和公司的整体目标。比如公司规模非常小的时候，一个公司可能也就干一件事，三五个人、十来个人，谈不上中台化。但实际上，它也是用中台的，因为业务/能力都需要外部采购，可以将外部公司理解成“中台”的角色，为它提供了这些服务，小公司本身则专注在做业务。当公司发展到一定程度，业务扩张了多条线，但人力并没有那么充裕，这时，上中台是比较合适的。因为，不太可能把在每条业务线都分别都把所有的工种都配全，这里面的确有一些通用的东西值得抽象出来。尤其孵化新业务的时候，有很多跟之前业务共通的部分，这些部分可以抽象出来，形成一个“中台”的部门，来支持多个业务的发展。这其实是一个自然的过程。成长为一家大型公司之后，中台其实不是特别适用，为什么呢？因为大公司的资源其实相对是比较充足的，更多追求的是业务本身的效果。虽说有通用的技术可以抽象，大家可以共用。但不同业务部门，对业务的优先级判断和指标效果要求是不一样的，对于中台部门，并不是一件容易取舍的事情。例如，业务方ABC，提出了三个要求，同时满足这三方的要求的可能性并不大。即便中台部门能满足这三方要求，但交付时间的进度上或者其他一些细节上又达不成一致。这时候中台又不得不为这几个部门分别拆分出一部分人力，去单独适配各自的诉求。这样虽说是中台，但实际上也在为不同的业务单独匹配部分人力来完成，离中台真正的目标就会存在一些差距。
总而言之，中台本身作为一种组织和技术架构策略，对于不同的企业，对于同一企业的不同发展阶段，没有对错之分，只有适用与否。归根结底，不必刻意追求，“好用”才是硬道理。
5、未至终章从来无关对错，只有合适与否
当企业发展到一定规模，必然会面临协同和效率的挑战。如果每条业务线、产品线都各自为营，自建技术、数据、财务、安全等能力，就会导致大量重复建设、数据孤岛，增加内部协同和创新的难度。中台的出现恰好为这一问题提供了解决路径，构建统一共享的平台，实现了内部能力的高效复用，提高了创新的速度和深度。
但是如果为了建设中台而建设中台，庞大的中台反而是作茧自缚，那就要考虑中台与企业发展契合与否了。正如胥磊所说，要判断业务场景是否适合中台，只要观察其是否束缚业务发展即可。
“阿里的盘子大，业务范围横跨电商，物流，云服务，本地生活，文娱等等，跨度很大，才出现一个‘大中台’的格局。而我们（苏宁）的采购中台只针对电商这个大领域下的多个业态 比如电器、母婴、商超等等，不存在跨域的问题，因此对整个供应链采购业务的支撑是没问题的。”
当整个互联网从增量经济转为存量经济时，置身其中的每个企业都在寻找新的增长点和竞争优势。在这个阶段，中台战略到底是增益还是负累，最终也是“如人饮水冷暖自知”。它不是万能钥匙，有鲜明的优势，也有固有的缺陷。一个企业在选择是否采用中台战略时，盲目随大流或是囫囵吞枣都不可取，根据自身发展现状，考虑用不用、怎么用，因时因地制宜，及时调整优化，才是长远之计。
参考链接：
http://www.citnews.com.cn/news/202303/157019.html
