互联网大厂的“中台战略”剖析：进击的中台，组织的砺炼

中台战略作为近期大厂和品牌商竞相追逐的方向，背后反映出企业对于业绩增长进入相对瓶颈期的焦虑。

我们的观点：

（1）中台从来不单是技术的游戏，是企业战略、组织、方法论与技术的结合产物。

“中台是组织的外化，最终服务于商业模式”，脱离战略与组织维度的企业数字化转型往往事倍功半。

中台概念之所以被争相传播，与企业所面临的成长瓶颈期以及企业技术架构的发展阶段强相关。我们通过阿里中台转型的故事看到：自顶向下、切入正确的场景、产品化思维是中台战略不可或缺的要素。

（2）各互联网大厂的中台战略尽管围绕主营业务各有侧重，但无一例外希望：

尽可能实现数据打通业务共性得到充分的抽象沉淀前台业务创新迭代周期得到压缩以充分享受中台红利。

然而目前看除阿里中台相对成熟外，其余大厂中台布局道阻且长；长期视角下的互联网大厂更希望自家中台的逐步社会化，这也侧面推动了云服务市场的繁荣。而具备危机意识的品牌商也已拉开中台化的进程，但在组织变革层面的进展相较于互联网大厂要更难。

（3）我们对中台的前景坚信不疑。ERP在早期实施阶段与中台当前面临的问题如出一辙，但毫无疑问ERP的实施强力推动了企业信息化进程。

特别是在全渠道零售/服务领域，中台将在线上线下的数据、业务与供应链融合过程中大展拳脚。

对于企业，找到当前发展阶段最适合自己的组织与技术架构乃当务之急，克服盲目对中台追随的心态有助企业保持理性与健康发展，毕竟在高速行驶中更换发动机谈何容易。

开篇说：

我们认为中台之所以不能被正确和理性看待的原因尽管复杂，但并不难理解：脱离企业组织文化单独看中台，将把中台归类为技术系统的优化、归纳与升级，这将会对中台的功能定义以及落地实施的期望值造成较大的偏差。

我们认为中台≈战略与组织的外化形式，企业组织的健壮性与柔性、业务的成熟度、数据沉淀的规模以及看待中台的视角将很大程度决定企业中台建设的必要性及推进难度。

一、我们为什么关注中台：企业战略与组织的抽象与凝练

中台战略作为近期大厂和品牌商竞相追逐的方向，背后反映出企业对于业绩增长进入相对瓶颈期的焦虑。我们认为，中台不仅仅是技术架构的变革，而是一套“战略、组织、方法论、技术架构”多者协同的结果。

中台思想在早期更多以技术层面展现和解读，往往是因为技术层面是企业战略、组织、文化外化的最终结果，从中台实施的最终结果看毫无疑问要以技术架构作为落地手段。

因此，本文通过不同主线反映企业中台的成长与进化历程，以中台为切入口探讨中台与战略和组织之间的关联，并尝试归纳与总结中台未来的发展方向。

我们看到，中台的诞生并未偶然或无迹象，我们认为这与企业业务发展与人员规模的扩大密切相关，中台的诞生也或多或少反映管理层的意志（当然也承载了他们对企业的美好愿景）。

基于对中台的历史研究我们初步认为，阿里中台的发展轨迹已在业内具备代表性：阿里最初的业务以1688和淘宝为主，各自为政，面向客户以及业务对象均有较大差异。

淘宝初期主要面向C2C电商领域，全套系统围绕淘宝垂直的技术框架落地。随着业务的不断扩张，阿里成立天猫事业部主抓B2C电商，又形成了一套并列垂直的技术框架。

这种垂直式的、相互不连通的架构体系类似烟囱林立带来了诸多不足，如成本的重复投入和维护、数据之间打通复用的难度、几年之后推倒重建的风险等。

为了解决这些问题，阿里于2009年就已成立了共享业务事业部（Shared Service Center）与数据平台部，通过构建共享服务来沉淀和复用业务能力。

但由于成立初期业务话语权不强，共享服务体系的建设并不顺利。随着“聚划算”团购项目的启动，公司统一要求各系统的流量都需要通过聚划算，共享服务中心依托聚划算业务才得以大展手脚，逐步将集团核心的业务能力沉淀成为用户中心、商品中心、交易中心、评价中心、店铺中心等数十个共享服务。

共享业务事业部：地位曾尴尬到聚划算救场

资料来源：《企业IT架构的转型之道》

阿里共享业务事业部逐步成为有效的中台角色

料来源：《企业IT架构的转型之道》，阿里云官网

同时，阿里借鉴Supercell组织管理方式，强化中台战略转型也进一步放大了巨头在中台组织建设方面的前瞻性：在Supercell内部以小团队（cell）形式作战，小团队最多不超过7人，小团队对整个项目周期负责，从项目策划到研发再到向市场推广。

如果产品没有受到市场欢迎则迅速放弃产品，从中吸取经验后再进行新的尝试。这样的快速试错、不断创新的模式使得Supercell成为了一家年税前15亿美元的游戏公司，人均贡献收入达到4亿元/年。

阿里在参访Supercell后，于2015年提出“大中台，小前台”的组织和业务体制。因此，阿里中台革命也即共享服务中心发展壮大后的产物，共享服务中心作为阿里中台核心，聚焦各业务单元能力的构建，协助目前集团上百个前台业务的快速创新——中台登上阿里组织架构发展的历史舞台，连接了前台的变化与后台的不变。

Supercell的类中台管理方式示意（注：“中台”的概念并非来自Supercell）

资料来源：程序员小灰公众号

阿里“大中台，小前台”战略落地逐渐成型

资料来源：阿里云论坛

从上述阿里中台的历史演化以及中台源起可以看出，中台发挥的核心价值在于“共享复用，敏捷创新”。我们认为中台目前正处于一个探索中的“定义混乱期”，按照ThoughtWorks给出的参考定义，中台是企业级的能力复用平台。

之所以是“企业级”，是因为中台的规划牵扯企业战略与组织，需要企业自顶向下做顶层设计。而“能力复用”体现在通过敏捷响应机制的建立，通过将企业的共性能力（对应共性需求）进行抽象重组，打造为公共的系统能力，以接口、组件等形式共享给各业务使用，使得企业前台各业务线无需重新开发即能快速实现业务迭代创新。

企业公共能力复用价值被逐步开发（但请注意中台不承担管理职能：人/事/钱，那是前台和后台的事情），满足快速变化的市场需求。中台也开始成为进入成熟期企业不可回避的思考维度之一。

中台的视角迁移：从惯常的管理维度到业务能力创新视角

我们看到，近年来中台的曝光频率走高也反映头部企业迈向稳定期过程中的成长焦虑。我们之所以关注中台发展，本质上就是在高速变化的社会环境下关注企业在组织与文化层面的转型创新。

根据伊查克·爱迪思《企业生命周期》，我们认为中台即为企业生命周期从“稳定期”继续降本提效的立足点，也可以理解为中台是帮助官僚化企业减轻“官僚期症状”的有效组织形式（请注意：只是减轻，不是避免）。

伊查克·爱迪思提出的企业生命周期，中台在企业‘成长阶段’后期发挥作用。

资料来源：hrmarket

阿里从原有传统应用架构转变为共享服务体系架构，经历了多个组织架构的变迁与调整，可以说阿里中台的成长就是阿里对其战略组织架构不断思考与升级的过程，公司战略与组织结构发生了复杂却必不可少的的变化。

钟华在《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》一书开篇提到：

“与任何公司一样，阿里巴巴组织架构的战略调整势必对公司现有组织架构、部门间的协作等各方面都将带来深远影响…假若没能很好地控制战略执行过程中带来的风险，对组织架构的动荡过大，都会给现有业务带来不小的损伤。”

我们认为阿里的中台战略之所以能够成功落地，得益于其以往对组织架构调整的能力与决心，对阿里价值观的高度一致，以及内部逐渐形成的“适应变化”的文化。

组织架构调整的难点在于让每个员工都快速了解并且认同其背后的战略意图，并快速适应新的组织架构，理解接纳接下来在新的组织架构下自己的角色，从而使得战略能够平滑迁移并最终落地，这需要一套机制和文化基础来保证。

二、中台的成长路径：自顶向下的战略与组织变革承接者

基于阿里中台的建设案例我们认为，企业中台的成长路径就是在企业战略与组织博弈的同时开辟的：通过战略与组织的相互博弈与妥协(战略也需要在组织调整的反馈中动态调整），最终达成一致，使得中台的形态随之逐渐迭代，形成承接战略与组织的成熟形态，进而推动业务在未来商业模式的不断（小幅）迭代。

也即：战略通过组织体现，组织效能通过中台反映，业务逐渐通过中台（而不是原有体系）进行商业模式的更新。

中台的典型架构：业务是骨架，数据是血液，双中台相辅相成

资料来源：阿里2017、2018云栖大会

“康威定律”（Conway’s Law：一个产品或系统的设计（架构）受到其生产组织自身交流沟通结构的制约，Melven Conway，1967）也被援引成为表达中台成长原则与核心价值的重要评估方式。

康威定律表达的核心在于承认：企业的技术架构与组织架构紧密联系，组织架构就是对于责任和利益的分配结构和分配方式，责任和利益划分清晰了，中台被承认了，也就有更明确的存在感。

因此，中台建设真正困难的部分是战略指导下组织重构的深刻动刀，而这往往是大家有意无意避而不谈（或未意识到）的。

具体细化而言：

（1）技术架构是一家公司核心业务和组织的抽象和沉淀，架构师其实是一种解读管理复杂性的角色——不断将复杂性抽象化、简单化、清晰化的职业。在架构师的脑海（中台蓝图）里，一家公司应当就是各种积木（业务单元）的抽象、拼装和组合。

（2）组织顺畅下的高效充分沟通就是抽象复杂业务、拼装与组合业务公共部分的前提。对于一个系统模块（如支付、交易等），它的被调用次数和调用后评价就是衡量它好坏的标准。那么开发它的工程师与其他部门、业务方的沟通次数，就近似于这个技术模块的调用次数与调用时长。

这也就意味着：在高速发展、不断迭代的科技时代，公司竞争的不是技术，而是组织和文化的优越性与建壮性。这种优越性与健壮性使得中台架构师在沟通，抽象与沉淀的动作当中能够实现相对平稳顺畅的对接流程，最终实现中台建设与充分发挥效能的目的。

因此不得不提的是，阿里价值观强绑定与考核的铁腕文化+平台型多元业务组合，正面促成了中台战略的实施落地。

通过阿里巴巴的中台建设，我们看到：

高层制定并推动部门间数据打通以及“大中台、小前台”的战略执行DT基础设施下的电商+金融+物流+本地生活+文娱消费多板块协同通过2B产品化接入阿里云并对外输出（Aliware+Dataphin/Dataworks引擎+阿里云效平台）是阿里中台能够实现内外部复用的关键点。

我们尝试总结中台的成长路径中需要具备的核心要素：

1）自顶向下的一把手工程：组织文化重构的魄力需企业管理者的大力推进

尽管中台的初步试水未必由高层首先提出，但我们认为中台建设路径当中涉及战略确立，组织变动与利益协调分配，仍然要通过自顶向下的驱动方式。

没有高层强有力的长期推动，很难切动组织架构中的固有利益网，因而会导致中台的内部推广难度都大幅上升，很有可能最后因组织划分与职能分管等不可调和原因“中道崩殂。

同时大部分一线员工是很难站在一定的高度去做“看N年、做一年”的中台战略规划，特别是当中台与业务眼前的 KPI 难以达成平衡时，中台的工作开展会受业务的强力狙击。

2015年12月起，阿里正式从集团层面启动中台战略建设

来源：阿里云官网，阿里2015年12月内部信

2）在平台化的基础上，寻找到有效的业务组合与有效的业务推动场景

建设中台的前提在于公司的成型业务存在大量协同效应，以至于中台能够很好的提升业务抽象能力，从成型业务的共性切入作为突破口是中台切入的理想选择。中台是能力复用平台，协同效应的业务越多，中台的抽象和复用能力越强，越能够为前台业务提供价值。

阿里做中台起源于淘宝和天猫，本质都是电商平台；滴滴做中台，是因为快车、专车、出租车、顺风车等业务围绕出行展开；头条做中台是因为所有APP的使命都围绕用户展开，用户增长是所有APP无法绕开的话题，因此锁定增长指标成为所有业务部门的重点……

我们认为当公司存在如下三种问题的至少一种时可能并不适合搭建中台：

业务处于早期还不成熟、数据量有限，现有系统满足数据服务业务的要求；企业人力不足，建设中台投入的人力物力财力资源无法满足；成熟业务之间独立性/个性化强，中台抽象余地小。

烟囱（业务）林立的时候未必一定是搭建中台的成熟条件，要看业务之间的协同效应

3）Platform as a Product（PaaP）：用产品思维建设中台

中台产品化、产品思维在中台建设当中的重要性也被逐步体现出来。每家企业建设中台的目的均存在差异，包括不限于内部研发效能提升、资源与数据复用、零售全渠道打通、开放银行、多品牌、构建商业生态等。

因此，中台所面临的前台业务随着企业业务组成的不同大相径庭，这容易诞生诸多问题——

a. 内部矛盾

因中台建设的复杂性和长期性，导致无法满足前台团队的短期业务需求，中台压力大。业务方不满，认为没有得到（与原有support相比）相应的服务；中台团队背负着业务的持续施压，无法按照自己的节奏推进中台建设，导致中台内部矛盾频发。

b. 外部矛盾

中台团队迫于压力极力满足前台的需求。因为中台的性质，中台团队需要同时面对多个不同的前台业务、前台团队。每一个前台团队都是甲方，在中台团队眼中地位近似，需要极力满足需求。

而因前台团队为能获取更多的中台资源使用权，提需求争取更多中台资源成为前台团队习惯，导致中台团队的需求短时间剧增，但因为中台资源毕竟有限，自然而然会出现之前反复提到的需求爆炸、排期、冲突等问题，矛盾产生。

因此，中台的成长过程需要按照产品化（PaaP）的思路进行设计，将前台业务需求前置，提升需求响应和处理能力，形成中台模块的核心落地思路。

我们认为，中台产品化可以借鉴思考如下几点：

中台作为产品，能否为前台客户解决实际问题体现自身价值、能否关注前台用户体验，通过清晰的用户定位和产品力吸引并驱动前台客户选择中台产品；视同一类型的中台产品的合理内部竞争为常态，或同时对多个相似的中台产品进行孵化，通过赛马机制形成更加健壮的中台产品；需要提供客户运营，客户售后等服务，保持中台产品稳定平滑更新，关注用户满意度以实现客户留存与转化。

中台通过角色转换变为产品团队，形成（中台）产品对（前台）产品的服务形式

资料来源：健荐公众号

中台产品化过程中可能需要去思考的问题：围绕产品需求展开

资料来源：健荐公众号

三、如无必要，勿增实体：技术架构演变催生中台方法论与落地

基于上述分析，中台需要考虑组织、方法论与技术三个维度的事项。从技术架构的演变，可以看出除了组织外，技术成熟度的提升也侧面催生了中台方法论（以及背后思想）的诞生。

从SOA到ESB理念转型为微服务架构，最早可以追溯到从亚马逊早期提出的核心管理原则的转变——我们能够从贝佐斯铁腕管理方式对中台诞生的萌芽初窥门径。

2002年，Bezos突然向全公司发布了指令，核心内容表达为：全公司数据不得成为孤岛，IT项目组之间必须以接口（API）的形式进行合作。

这使得从2002年开始直到2006年API工程迁移完成之后， 亚马逊内部技术体系逐渐调整为SOA (service-oriented architecture，面向服务)架构，每个技术组和产品组之间都是service形式，都可进行互相调用。

之后Amazon不仅在技术架构上逐渐变成业内俗称的“微服务架构”，并且使得整个组织都变得API化，不断强化对外接口的能力，AWS也间接受益于此：亚马逊早期的系统能力是按照高峰期的需求配置的，美国人购物集中在圣诞节前，圣诞节后系统的利用率仅有30%左右，其余算力都进入闲置状态，内部建议将闲置的系统计算能力和存储空间出租。

这也是最早的云的概念，亚马逊通过早期管理思想的积淀与电商业务的不断打磨，也一步步摸到了云的入口。

众多国内企业早期的发展的技术架构更多采用ESB架构完成——ESB（Enterprise Service Bus）讲究企业技术架构的联通，其基于SOA，应用场景是在对已有应用的打通，比如企业ERP+CRM软件以及定制开发的软件，这些软件价格不菲，需要长期使用，轻易无法改动。

所以要尽量保留，通过SOA进行架构串联，是一种企业集中式服务治理的架构；久而久之，企业形成了“烟囱式”的技术服务基础设施，“烟囱式”的技术服务设施尽管对单一业务的逻辑闭环与系统支撑形成了良好的支持。

但对于企业整体系统而言并不利于延展和内部业务相互协同，原因有如下几个：

（1）功能重复开发和维护成本带来的浪费：原有业务的系统支撑模块无法复用到新的业务系统架构中，只能重新开发极其类似的系统支撑模块；

（2）打通企业“烟囱”间交互花费企业更大成本：ESB架构的大部分/彻底推翻，新的企业架构的建立所需花费的时间；

（3）ESB模式下数据流典型系统特征：仅支持数据的单向流动和单场景使用，业务与系统单线联动，业务优化仅限于局部改善，无法做彻底性改动（如果彻底改动，可能对企业业务整体带来重大影响如业务停摆等）；

ESB架构下不同环节系统林立，使得业务链无法模块化拆分

资料来源：《钟华：中台战略推动企业生产力&生产关系再变革》

因此随着企业规模逐渐庞大的过程，ESB架构的系统负载将会愈发提升，随着前台业务面向用户快速变化需求的力不从心，前台需要更加灵活和健壮的系统和组织架构的支撑以便完成后续的快速改进乃至业务迭代。

中台的微服务技术架构效率要高于ESB，ESB更多体现中心化思想，将企业所有细分业务链接到ESB总线以便更加适用于技术部门管理。相反，微服务架构强调的是“业务的彻底组件化及服务化”，原单个业务的支撑系统会被拆分为多个可以独立开发、设计、部署运行的（小型）应用。这些应用之间通过服务完成交互和集成。

组件表示的就是一个可以独立更换和升级的单元，例如PC中的CPU、内存、显卡、硬盘，独立且可以更换升级而对其他单元并不产生显著影响。我们把PC中的各硬件以服务的方式理解，则PC只需要维护主板（可以理解为微服务架构中的ESB总线）和一些必要的外部设备就可以。

CPU、内存、硬盘等都是以组件方式提供服务，例如PC需要调用CPU作为计算组件，只需知道CPU这个组件的访问接口（地址）即可。

从ESB到微服务架构：总线形式的中心化思想到服务模块化下的去中心化思想

资料来源：知乎@李运华、CSDN

从ESB到微服务的架构转型，本质是企业组织管理方式的转型。

企业技术架构从早期的传统IOE架构（每个应用彼此按烟囱式独立排列，唯一的共通点在于都与底层的数据库相连；每个应用都比较庞大，同时需要连接多个数据库；架构中的应用数量较少，应用与应用之间的关系简单），到传统中心化ESB架构（ESB总线瓶颈凸显），再到去中心化微服务形式的敏捷架构（业务扩展随叫随到）。

实际是业务不断延展和深化过程当中路径：从传统经济到数字经济，从关注产品功能到关注用户体验，⽤户逐渐成为商业战场的必争之地，为了快速响应用户的需求，平台化组织的对业务相应的需求迫在眉睫。不断快速响应、探索、挖掘、引导⽤户需求，才是企业得以⽣存和持续发展的关键因素。

ESB到微服务，架构的演变为中台提供了一种灵活的技术选型方案

资料来源：《腾讯云中台建设实践》

由于电商行业一直是我们关注的重点，我们可以藉由电商平台系统架构的变迁看到中台能力在电商领域的不断释放。

我们发现近年来，由中心化向去中心化的电商演进正在发生：中心化模式的价值主张就是平台方汇聚流量，提供并掌握用户购物的第一入口，商户通过这个入口获得流量销售商品，平台以此分成。

在行业快速发展期，商户可通过平台提供的入口获得有效且具规模的流量和运营能力，商户受益且依赖平台赋能；但随行业整体增速放缓，互联网巨头用户量趋稳，获客成本高企，中台能力接近稳定。

另一方面平台入驻商户不断增加，竞争白热化，僧多肉少的结果导致流量价格加剧，订单转化率接近瓶颈，倒逼各大平台开始注重深耕存量用户的价值，并利用中台能力稳定商户军心。

2016年阿里首次提出私域的概念，伴随淘系的内容化战略落地方向，倡导淘宝商家从“产品为王”到“内容为王”的转变。但淘系生态本质是流量获取和留存方，商家和品牌在淘内更多属于流量贡献者，虽然微淘界面鼓励商家与用户之间建立直接联系，淘宝内部私域流量仍没有得到很好的发展。

因此在私域流量在电商领域应用逐步大行其道的今天：

（1）品牌主建立自有电商的需求，品牌主努力构建自有电商渠道，不断脱离“古典电商”的磁场，加强数据跟踪与应用能力；

（2）用户要求电商体验的多样化：购物现很多新场景触点——语音、社群、酒旅、穿戴设备、AR/VR，前端更加丰富，在稳定底层商品和交易框架基础上，API化可有助于保障各场景的购物体验稳定；

（3） 品牌直接面对消费者（DTC）的诉求：品牌通过自有电商直接面对消费者（私域流量也为DTC创造了很多机会）。

在这三点的推动下，电商平台的技术框架的演化与思想也随着电商形态的进化而不断更替：

从一体电商方案（从搜索到交易往往是一家供应商提供，如Oracle , SAP，WordPress等）到内容和交易能力的定制分离方案（用户交互端依托主站、电商交易端依托三方服务商）再发展到通过以API为基础的无头电商（Headless E-commerce，三方服务商提供全部定制化/灵活化的电商服务）架构。

无头电商（注：国外流行概念，国内接纳时间并不长；其实中台是国内提出的概念，国外更愿意采用AWS对标所谓中台）通过前后端分离，允许开发人员在任何类型的框架中为产品和服务创建各种接触点。

由此，后端开发人员就可以灵活地创建和使用API以交付给任何类型的终端设备（屏幕）。无头电商的去中心化系统理念为私域电商和品牌电商的发展提供了技术和系统层面的方案：将品牌电商的前台展现和后台服务进行解耦的结果。后台以API的方式提供服务，前端展现层与后端分离。

电商去中心化伴随系统架构去中心化，中小玩家拥有了和BAT比肩的中台架构利用机会

随着微服务架构替代SOA/ESB成为业界主流，京东、苏宁已逐步从SOA/ESB切换至微服务架构有赞云、微盟云的IaaS层或选用阿里云与腾讯云等IaaS服务商，在其基础上进行二次封装

无头电商模式更加有效的适应多样化零售场景

资料来源：互联居公众号，CSDN

无头电商的优势：设计灵活，前后端分离，API服务导向

资料来源：互联居公众号，CSDN

在技术层面上，无头电商模式属于SaaS与PaaS之间的抽象层次，这与中台的抽象层次类似（最终会殊途同归）。

从国内角度看，有赞云提供的服务与这种抽象层次类似，通过大量API的封装与开放，开发者或者商家可以自己定制交易流程，比如增加适用于社交工具的促销环节与特定交易流程、线下门店与电商的库存、促销、交易、会员服务匹配。

同时在流程中的各个业务关键点输出扩展能力，让开发者可以去实现扩展能力，如价格计算，现在开发者可以改写价格计算逻辑，实现新的商品实际成交价格，选择赠品逻辑，可以通过调整不同的赠品实现买赠挑选的功能等等。

通过前端页面组件化，开发者可以定制自己的组件，修改原有组件的行为，以及其它复杂的定制。

资料来源：《有赞云白皮书》

有赞云将核心业务模块封装，并开放接口供开发者调用

资料来源：有赞Coder公众号

四、互联网大厂的中台战略：平台企业中台化，垂直企业平台化

阿里是互联网大厂中台战略的坚定推行者之一。我们基于上述分析认为，阿里中台的前身是2009年成立的“共享业务事业部”和“数据平台部”。

具体到《企业IT架构转型之道》中，作者钟华的表述采用“共享服务中心”（shared service center），并且“从原有传统应用架构转变为今天共享服务体系的架构，本质上是微服务架构建设的过程”——中台架构大概率会选型微服务架构，微服务架构既是一种有形架构，也是一套管理复杂系统的服务治理思路。

阿里自2015年提出“大中台小前台”战略（提出此战略的目的是在共享服务基础上进一步之后，组织架构和业务机制两个层面进一步将关系梳理清晰，拆掉部门之间隔墙）经过3年多的改造，中台已经实现公共业务和技术组件横向打穿，为阿里前台业务提供高效运转和迭代的支撑。

阿里大中台示意：业务数据化+数据业务化，前台灵活+双中台支撑

资料来源：阿里云论坛

2007年9月的阿里战略会至今看来，仍被视为一次阿里内部思想提炼的重要媒介。在阿里未来方向不清晰、内部组织割裂严重的形态下，这次战略会确立了“建设一个开放、协同、繁荣的电子商务生态系统”的战略方向并始终延续至今，下图也诠释了阿里生态系统的远景，这也为阿里打开了生态化的格局。

也确定了“客户&数据为重要价值，信息流+资金流+物流为关键数据资产”的生态系统贯穿核心；阿里的“奔月计划”（数据贯穿所有子公司的业务打通，后由王坚博士改名为“登月计划”，属于阿里云飞天计划前身）“五彩石项目”（淘宝与淘宝商城（现天猫）的数据打通）也基于此次战略会的结论，开始围绕公司数据体系的变革展开。

07年阿里战略会提出的阿里生态系统雏形

资料来源：曾鸣书院公众号

从战略、组织、前台、云等维度梳理阿里中台的成长历程

阿里巴巴组织架构变动的核心主题为前台灵活、持续增强2B能力、中台收敛

资料来源：搜狐、新浪、阿里云论坛

滋养前台业务成为阿里中台对前台的定位

资料来源：51CTO

我们可以看出在阿里中台布局中，企业中台主要由业务中台与数据中台组成。业务中台提供业务数字化基础上的重用服务，例如用户中心，订单中心等等之类的开箱即用可重用能力，为战场提供了空军支援能力。

数据中台基于业务中台服务提供过程当中的数据流通，收集数据并强化数据分析能力，帮助业务从数据中学习改进，调整方向，为战场提供了海军支援能力。

业务中台是基础，产生并应用数据，数据中台进行数据资产化和数据分析，指导业务前台进行业务迭代

。同时，阿里云建设的不断成熟也为中台云上化以及中台社会化的中台延伸战略（阿里于2018.11提出）提供了强大的算力和存储力。

阿里云提供IaaS及PaaS服务支撑中台技术实施

资料来源：阿里云官网-中台解决方案

字节跳动以基于算法的信息分发为主要商业模式。信息分发背后是字节跳动对业务端用户增长的深度理解和直接推动：我们试图从上文的组织/技术的视角切换到经济模型 + 业务发展的视角来分析字节中台，这种视角更有利于理解字节跳动中台“提升增长效率”的定位和目标。

我们以抖音为例，将抖音用户增长和变现效率用ROI来表示，并认为ROI由三个核心指标组成：

Live Time（用户使用总时长，可进一步拆分为DAU * AD Load * VV），ARPU（用户变现金额，包含广告、游戏、电商带来的CPC/CPS等）与ACP（单用户付费支付的成本）；虽然不对外显著宣称中台概念。但我们能够看到，为ROI贡献核心因子的三个部门（内容推荐、商业化以及UG）成为推动抖音DAU最核心的支撑。

我们看到抖音从18年初的5000万增长至19年底的近4亿，三大部门的贡献功不可没。

抖音DAU成长曲线：三中台部门贡献突出

截至2019年底抖音DAU突破4亿

资料来源：《2019抖音数据报告》

作为一家正在极力推动组织变革，优化组织效率的零售为主业的公司，京东的中台战略和建设规划为京东提供了有效的前进指引。我们认为通过建设中台，京东或将实现如下三个明显的边际价值改善：

1）降本增效

原有业务各自为政加大服务器保有量，导致算力明显冗余、造成资源浪费。搭建高效统一的存储和计算平台，通过提升服务器和计算单元的利用率节省服务器资源，从而减少京东现有IT设备的开销。

2）统一数据标签

目前京东的数据标签系统不健全，数据口径和标签维度差异大，导致千人千面、搜索推荐等高级应用的效果差。而阿里的高级应用省去小二大量的时间精力筛选单品，淘宝天猫的数据标签的种类是京东的2-3倍，配合相对成熟的大数据体系，阿里做到了对用户和商家行为的充分识别，并根据识别结果做大量高级应用。

中台帮助京东实现统一、标准、精细的数据标签，有助于京东各类高级搜索推荐应用的落地，进一步提升用户浏览和消费体验，更重要的是有望加强女性用户的拉新效果。

3）业务流程全面模块（组件）化

京东当前垂直业务纷繁复杂，资源复用需求极高。通过实现一系列灵活且稳定的组件、工具和平台，帮助前台业务实现快速、敏捷、高效的拓展和开发。

通过API和SDK化，帮助前台业务快速调用中台接口，仅需修改参数就可实现业务流程复用。同时针对特定前台业务，支持定制化快速开发。最终使得前台业务成为机动灵活强大的作战单位，对于市场变化实现迅速反应。

京东的中台推演：典型的中台样板

作为双边效应的平台型起家公司，滴滴的中台建设顺水推舟：滴滴业务辐射出租车、快车、专车、单车、代驾、国际化、汽车金融服务等，在各条业务线飞速发展的过程中也会存在着很多相同或者类似的业务需求。

如何通过技术的手段抽象、沉淀这些业务为通用、稳定基础能力，让各业务线专注于其个性化的部分，快速的推出适合市场的新产品，是滴滴业务中台核心价值的体现。

滴滴的业务复杂性

资料来源：《滴滴中台建设案例分享》

我们看到，滴滴中台的发展历程也围绕出行展开：从专业深度看，由于滴滴是多业务垂直化的架构，会有多个团队开发同样的架构，这就需要很多的工程师。每个团队都是用最快速的方式构建流程，所以技术很难做深。

这样一来，导致客户端的流畅度不高，后端不稳定，影响可扩展性。从人力资源角度考虑，工程师的薪资高，招聘大量工程师来做近似的架构，研发成本高昂。

在考虑所有业务本质都是出行，出行本质有协同效应的基础上，滴滴考虑全局打通，通过数据共享和模块复用实现业务充分协同，降低研发成本。目前滴滴业务中台已经构建了订单中心、计价中心、支付中心、passport、用户中心、触达平台六大能力，高效率以支持各条出行业务线的快速发展。

滴滴中台架构：

资料来源：《滴滴中台建设案例分享》

那问题来了，腾讯、拼多多、小米等其它大厂要不要做中台？

我们认为这与企业发展阶段、组织性格以及对中台的战略认识相关。于腾讯，我们认为腾讯某种程度上跳过了集团内部的中台假设，直接以CSIG和TEG事业群为组织基础设施，以腾讯云为技术基础设施开发了生态系；同时WXG提供的微信基础设施让我们认为微信在某种意义上为腾讯的中台建设提供了相关参考。

但总体看，腾讯内部对中台概念属于若即若离的态度（因为考虑了中台数据交换安全性等以及权限控制等因素），内部的能力治理工作也尽量避开中台概念，与阿里京东直接大刀阔斧提出中台战略并操刀组织切割的方式相比，体现了腾讯与阿里京东企业文化的显著差异。

930组织调整后，腾讯于2019年5月提出了内部开源协同的要求，从自下而上的业务驱动直接上升至集团战略。通过避开因中台战略而直接对组织架构动刀，意图用“开源协同”方式柔性化推动组织架构变动和中台布局。这种开源协同让“相同爱好、能力、高协同度”的业务集中资源复用开发，减少重复车轮。

2019年6月3日，腾讯副总裁姚星在腾讯内部技术社区码客上也写道：

“开源协同是目前腾讯研发体系升级很重要的一个方法，开源是手段，协同是结果。如何平衡‘去中心化’和‘重复造轮子’，开源协同是个很重要的方法，开源的目的是减少‘重复造轮子’，协同的目标是‘去中心化’，保持快速的响应”。

但虚拟组织的捆绑效应和KPI协调能否到位仍然存疑，且开源业务以及协同业务最终仍会回到各自KPI的视角下安身立命。

阿里和京东在组织层面直接进行调整，归中台组织还是归前台业务组织无非二选一，较少出现组织重复的问题，业务开展方向较为明确，执行力强。

930后腾讯新成立的技术委员会担当起开源协同大任

资料来源：100ec电商研究中心

而拼多多作为电商平台，连接着海量C端用户和B端商户，其长期的可持续发展需要基于自身的对外赋能出口来实现，通过不断“提升上游效率和下游体验”强化平台赋能的实践，从而提升赋能效率。

这种对外赋能的能力从长期看需要强大企业中台的支撑。我们认为拼多多中台的建设更多依赖于C2M模式的不断扩充。依托中台，拼多多可迅速实现大规模C2M服务的铺广。

拼多多需要把提供给工厂的能力模块化、系统化，并通过切分隔离的方式归纳至中台体系，采用共享服务的方式输出给直接对接前台的数据服务、营销服务和供应链服务三大平台，这些平台将帮助拼多多的前台业务更加稳固发展。

拼多多中台和阿里、头条等中台的差异在于，阿里中台是零售业态的孵化器、头条中台是信息流产品增长发动机的孵化器、而拼多多中台是产地品牌的孵化器。

相比阿里中台更多聚焦于不同零售业态所共通的能力，如营销中心、商品中心、用户中心、交易/支付中心和数据中心是阿里中台强项；头条中台更加强化产品全生命周期的能力，用户增长、产品技术和商业化变现三大板块是头条中台的核心抓手，所有前台产品都通过中台赋能后，核心产品环节（拉新、留存、变现）的优化将会更具效率。

拼多多中台除了电商基础环节的复用之外，我们认为将会更多强调产品品牌的孵化能力，通过涉足品牌从0到1的各个环节，拼多多中台从品牌创建、产品研发、生产制造、品牌营销和零售等模块均给予上游供应链支持，工厂和农产地的品牌建设和销路获取将通过拼多多C2M中台得到高效满足。

拼多多中台推演：能力聚焦于C2M工厂与产地的品牌孵化

小米中台建设任重道远。我们尝试抽象了小米的业务矩阵，发现目前小米业务独立性较强，手机研发与零售业务目前仍然贡献了60-70%的营收。

因此从业务角度看硬件研发始终是基本盘。因此首先需要完善的是小米的数据中台建设，并对三块不同业务分别建立业务中台。随着数据一体化的完善和集团数据中台建设完毕，各业务中台逐步成熟之后，才有可能建设统一的集团中台。

同时我们认为，小米中台也需要按需调整中台建设里程碑，毕竟未必一定要建成一体化的集团中台形式，多中台并存的形式针对独立业务的提效能力值得观察。

2018年 9 月，小米四个大业务被拆分成了十个小业务，其中包括互一到互四的四个互联网业务部，但各业务各自为政，特别是广告业务变现层面，各垂直部门打法大相径庭。

2019年初重组的互联网商业部收口所有互联网业务的广告与流量端，负责互联网商业化过程的运营、集团广告位的管控与优化以及广告等商业化变现的目标达成。

但目前看，仅仅将商业化部门抽离，只迈出了业务中台长征的第一步。同时，生态链孵化体系和线下零售体系的数字化进程还在加强中，数据体系持续完善+独立业务背景下数据打通的难度不低，使得建设统一数据中台的目标也刚刚拉开帷幕。

小米业务矩阵梳理：零售、MIUI服务、生态链&IoT服务三部分相对独立，业务中台抽象不易。

2019年Q1启动的小米数据中台建设值得期待

资料来源：MIDC2019

五、品牌商的中台：早期萌芽、初露锋芒，但刚需大潮难以阻挡

品牌做中台的逻辑即为零售全渠道（Omni-channel）背景下的举措。消费零售行业渠道品牌的前台一直有个更通俗的说法，叫“全渠道系统”——在门店、APP、电商平台、微信小程序、to B分销的全渠道销售时，共享一套会员、商品、订单、库存、营销、支付体系（我们认为这也是近年来所谓新零售模式想要去实现的目的）——共享这一套体系的基础是什么？

是线上线下业务逻辑的解耦（拆分核心能力并标准化）和资源（流量/渠道）的不断货币化（在满足内部的终端渠道需求基础上开放给外部中小客户）过程，本质即为中台建设。

渠道能力解耦与抽象：多场景保持一种体验，全零售流程对应一种中台方案

全渠道是零售行业发展的必然方向。未来线上线下零售渠道将逐步融合，并在共享同一套中后台的基础设施和供应链的前提下达到效率进一步提升。前端交易场景将呈现多样化的趋势，而中后端的数据、资金和履约系统将不断融合为一。

尽管传统的线下与线上 ERP当前都在尝试构建全渠道方案，但由于线上线下拥有不同的技术架构，彼此都很难实现方案统一。

同时，ERP 厂商不具备物流履约能力、支付和流量等，很难为客户提供整合方案。我们认为，中台解决方案的提出更有利于品牌全渠道管理和运营——全渠道的基础设施将重点打造统一的大中台系统，通过强大的中台能力实现大量商品和数据在各渠道的高效流通。

因而目前众多品牌商都在试水中台。安踏于2018年3月与百胜软件合作的全渠道中台项目正式启动实施：双方打造的全渠道中台系统，实现全局库存共享统一视图、全局订单链路统一视图等功能。

安踏中台服务层通过分布式服务框架服务于前端的应用，建立了商品中心、库存中心、订单中心、结算中心、营销中心、促销中心等六大核心中台服务，集中管理，统一视图，实现货品通、订单通、财务通、终端通等数字化建设。

安踏中台方案示意

资料来源：百胜软件

良品铺子于2019年6月与云徙科技合作开发中台，发起中台的原因主要源于零食行业需要SKU持续快速上新，加速产品研发并落地，及时响应客户需求。

目前良品铺子的产品多达1000多种，全渠道会员已突破7400万，覆盖了2000多家线下门店、天猫旗舰店、饿了么、微信小程序、自营app等50多个渠道，线上销售额占比超过40%。

未来将上线直播、拓展办公室的智能终端，将线下门店向购物中心、街边店转型，全力搭建全渠道布局。

良品铺子面临需要对外提升用户体验，对内提升企业经营效率的运营瓶颈，因此其中台建设有两个目标：

一是将不同渠道中的会员数据打通，构建用户画像，实现以用户为中心的精准营销。随着会员中台的升级，用户在良品铺子所有渠道的会员积分和权益都将打通，可以在任意一个渠道端实现通存通兑。同时推送形式和渠道将实现用户定制化推送内容。

二是在建设中台后更好地支持前端业务快速创新。通过中台搭建、沉淀的数据、模型，高效开发新应用、新功能，极大的减少工作量。例如开发“秒杀”应用，过去需要从零开始搭建，工作量极其庞大。

现在中台可将通用的积分、优惠券等模型复用，只需要在表面做一些简单的开发即可完成。

孩子王具备大型实体门店、线上PC端购物商城、移动端APP、小程序等用户触达渠道，同时配备育儿顾问为顾客提供商品及服务推介。

基于数字化商品系统与会员画像系统积累的初始数据，孩子王可以有效触达会员，可以在会员不到店的情况下满足其商品、知识需求，形成了线上场景的初始覆盖。

2016年开始孩子王加深了渠道数字化能力，通过后台数据的驱动，根据会员标签，商城首页呈现出不同内容。孩子王现在仍以门店作为与顾客最频繁的触点，也是最大的流量入口，通过门店APP化，尝试将线下流量转移至线上。

在此基础上，孩子王中台建设思路是将与用户接触的渠道称为前端系统，所有的前端系统只负责接触用户，与用户做交互。

对ERP系统进行了升级改造，将原来分散在200多个ERP系统内的用户系统，商品系统做成统一的用户系统，构建分层的分布式架构，拥有具备大量数据与应用逻辑的数据库。

逐步将传统零售里的用户、商家、卖家、评论、交易、促销线上化。根据所处领域不同，孩子王中台分为交易、营销工具、虚拟交易、售后、会员、商品、促销、库存、订单中心九大核心领域，覆盖线上交易、扫码购/店APP、云POS三大交易流程，以此支撑商城、数字化门店与虚拟商品三大业务板块与线下交易、统一支付、财务库存、KEC、外部交互等业务形成互动机制。

孩子王v4.0中台方案示意

资料来源：《2019.12孩子王中台架构演进之路》

招商银行2019年底也在总行信息技术部下设置了数据资产与平台研发中心，主要负责数据中台，深度挖掘分析数据，推动全行大数据的应用。

招行此次对于信息技术架构的调整很大程度强化了中台智能，将技术资源最大化配置在不同业务条线中，让技术、业务、产品最大化衔接，充分展示了按不同业务类型、客户群体重新配置研发资源，确保研发资源能够实时响应、最大化服务前台业务。

中台作为全行资源分配的“中介”，连接后台资源与前台业务，打造前中后台一体化。同时，中台承载全行不同业务条线的公共服务，减少运行中的重复工作，确保业务的高效率运转，更好地服务客户。

但我们看到，品牌商搭建中台前后无一例外牵扯到了部门组织架构的调整：

安踏在2019年7月进行的大规模组织架构调整，将23个品牌划分为三大品牌集群，利用各大中台的能力输出运营三大品牌集群。

招商银行于2019年底进行信息技术架构的重大变革，将原来的信息技术架构的 “一部三中心” 改为“一部六中心“ 。

“一部”是指总行一级部门信息技术部，“三中心”是指三个二级部门，数据中心、研发中心和测试中心。

此次改革后，招行撤销原研发中心，保留测试中心和数据中心，新设零售应用研发中心、批发应用研发中心、基础设施研发中心、与数据资产与平台研发中心。新设的四个中心分别针对零售业务、对公业务、硬件及软件基础设施以及数据化转型。

良品铺子于2015年进行组织架构调整，将组织架构简化为三层：市场经营层、资源能力层与规划策略层，形成较为扁平的组织架构，以提高决策效率。

此外公司在2016年内部试推行小组制经营，将分公司管理层级取消，直接建立总部和最小经营单元的联接，建立了敏捷的响应机制。

孩子王在2014年起对组织结构进行了平台化与去层级化的大幅改造，打破部门之间的边界，总部职能部门围绕“顾客研究、顾客支持、顾客经营”三个板块划分。

同时，公司建立专门的一级职能部门：会员中心，通过会员研究、会员互动、会员营销三个模块与会员进行价值交互……

尽管伴随组织架构调整的背后一定会引起利益的博弈与冲突，但今天的中台就如十年前的ERP变革的故事重演——上线与运营过程的组织与技术阵痛期将持续多年，但运转顺畅后带来的效率转化将是无中台状态下难以比拟的。

从零售商/生活服务商角度，设置中台能够更加有效掌控与利用全渠道。随着苏宁的业务复杂度逐步提升，苏宁认为强有力的中台能力是实现业务支撑的必经之路。因此2019年苏宁在集团层面提出建设大中台的方向。

如果说互联网大厂的中台更多服务于线上业务，则苏宁中台与孩子王中台的搭建逻辑近乎一致：线上线下业务需要中台的共同滋养，我们认为苏宁中台与孩子王中台对于企业的价值近乎类似——用户多端触点的一致性服务，即从POS端、PC端、移动端、线下垂直门店端等统一地为用户提供服务。

（1）中台为前台线下业务提供服务接口，使得前台线下业务与线上业务获取一致的研发和应用资源；

（2）中台帮助前台业务提供标准化（共性）方案，前台业务在地推、门店运营支持、远程支持等层面提升效率，同时中台和集团中台的融合打通使得线上线下营销节奏、货源共享、现金流转、品牌输出、加盟商/三方商家线上培训等层面保持一致输出；

（3）中台通过集团中台的数据共享和数据应用，赋能相关前台业务，协同指导线下门店的品类、品牌、价格、日常运营等经营思路，提升线下门店经营效果。

苏宁中台的推演：帮助自身业务与合作（加盟）伙伴更好的开店卖货

集团中台建设完成之后有机会成为苏宁线上线下的数据连接器，真正提升线下门店的体验性，提升门店资产价值。

线下门店对顾客最大价值在于对特定品类商品的直观体验，但我们也在思考，线上购物环节的高效便利对线下的反哺和赋能到底体现在哪些层面。

目前我们所看到的“线下扫码下单线上配送”“线上下单门店提货”“线上下单就近门店（前置仓化）配送”“线下购物送电商购物优惠券/礼包”等线上线下联动的购物方式一定程度上都属于“鸡肋”，并未对顾客关注的核心环节“价格、品质、服务”有实质性的提升作用。中台在回答线上线下联动问题上的潜力仍在被各品牌商挖掘中。

苏宁目前已具备了成熟的电商实力，我们认为苏宁手握线上线下用户的消费数据，在数据开发和应用层面有很大的拓展空间。

同阿里类似，苏宁目前正在建设“基于统一数据体系的规划、组织和应用”的数据中台，意即全部业务无论数据采集、清洗、存储、调用、应用、决策均采用同一套数据中台体系，一改往常数据孤岛、隔离、不一致等数据应用痛点。

六、中台的未来：效率为本，价值为先

中台的未来是什么？

结合上文的分析，我们看到了中台在不断被各行业的各类组织所接纳并采用，对中台的认知与理解在业内也逐步开始从单一技术视角深化到高层认识+组织文化+实施方法论+技术等多视角并行。

以史为鉴，我们仍然从重温贝佐斯2002年向亚马逊内部发布的指令开始：

All teams will henceforth expose their data and functionality through service interfaces.Teams must communicate with each other through these interfaces.All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.Anyone who doesn’t do this will be fired.

这四道指令如破墙的铁锤打破了亚马逊内部组织与数据体系的隔阂，并强迫企业养成了API化的企业内部技术架构，极大提升了企业的透明度。中台的建设就是在打破公司组织与组织之间、系统与系统之间、数据与数据之间的藩篱。中台建设也侧面促进组织透明化程度与合作协同的深度。

赋能、适度透明、强调/考评价值观的企业组织文化可能是中台建设的先决条件

资料来源：各企业官网

我们的判断是中台将会在某些行业得到充分的普及和应用，特别是全渠道全终端背景下，线上线下业务暂时割裂的行业，如上文提到的消费领域的各大消费品牌乃至商业银行领域。

渠道之间的不互通将导致企业重复造轮、数据割裂、业务反映迟缓；大量企业数据的堆积与冗余，纯靠手工或已有系统的处理逻辑将会越来越难以适应，在运营策略越来越倚重数据的今天，系统高效的处理与分析有助于提炼数据深层价值。

通过解耦-开放-赋能，阿里在全渠道/新商业的数字基础设施层面臻于完善

中台从私有化走向公有化（泛中台）的形式将会为品牌商和渠道商的发展插上新的翅膀。我们已经看到有赞、快手、抖音、B站、小红书等公司尽管平台属性差异较大。

但已经被众多品牌商和经销商潜移默化的作为中台使用，有赞+快手+抖音+B站+小红书+微信OS构成的“虚拟化中台集成商”已经能够有效支撑大部分企业看似”模糊不清“的中台诉求。

因此，众多品牌商/商家未必需要搭建自己的中台，上述公有化中台已经能够有效帮助这些企业实现业务的快速迭代。

如果换一种视角将抖音快手有赞等当作公有化中台，抽象行业的共性需求呢

在市场红利逐步放缓的前提下，中台将最终成为企业苦练内功过程中的抓手。

进入稳定期的企业往往到了拼精细运营的时候了：大家都寄希望于中台来帮企业最大化内部能力复用，从而实现降本增效，在技术上的表现就是企业架构在从单层的应用拼接到两层甚至多层的平台化架构（平衡经济性和灵活性）的过程。

但是，未必所有的企业拼精细运营都需要经历中台建设的步骤，中台也并不适用于公司的每个阶段，中台是为前端业务创新的不确定性服务的，企业前端场景鲜少发生变化或应用相对固定，可能就不需要中台。

因此适合自己的业务架构和组织架构，以及随之构建的技术架构，就是最适合的伴随企业成长的架构。进化组织尽管大势所趋，但并非所有企业都要在中台火热的时点（盲目）追风。

在此文结尾之时，我们仍然相信让企业产生平滑稳健运营和业绩效率的、具备敏捷/灵活的组织与架构，就是（当前时点）最适宜的组织与系统架构。

证明自身价值的历程往往是漫长且艰苦的，而价值得到证明的一刻，就是企业中台战略拨云见日之时。

这一切，当然都是命运石之门的选择。