互联网大厂的“中台战略”到底是什么？

本文来自 微信公众号互联网与娱乐怪盗团。

我们的观点

1.中台从来不仅仅是技术游戏，更是企业战略、组织、方法论和技术的结合。中台是组织的外化，最终服务于商业模式，脱离战略和组织维度的企业数字化转型往往事半功倍。中台观念之所以竞相传播，与企业面临的成长瓶颈期和企业技术架构的发展阶段密切相关。通过阿里中台转型的故事，我们可以看到，中台战略不可或缺的要素是自上而下，切入正确的场景，产品化思维。

2、各互联网大厂的中台战略尽管围绕主营业务各有侧重，但无一例外希望(1)尽可能实现数据打通(2)业务共性得到充分的抽象沉淀(3)前台业务创新迭代周期得到压缩以充分享受中台红利，然而目前看除阿里中台相对成熟外，其余大厂中台布局道阻且长;长期视角下的互联网大厂更希望自家中台的逐步社会化，这也促进了云服务市场的繁荣。具有危机意识的品牌也开启了中台化的进程，但组织改革的进展比互联网大厂更难。

3、我们对中台的前景坚信不疑。ERP早期实施阶段与中台面临的问题相同，但毫无疑问ERP大力推进企业信息化进程。特别是在全渠道零售/服务领域，中台将在整合线上线下数据、业务和供应链的过程中展示实力。对于企业来说，在当前的发展阶段找到最合适的组织和技术结构是当务之急。克服盲目跟随中间平台的心态，有助于企业保持理性健康的发展。毕竟，在高速行驶中更换发动机并不容易。

开篇说

我们认为，虽然中间平台不能被正确和理性看待的原因很复杂，但不难理解：从企业组织文化的角度来看，中间平台将被归类为技术体系的优化、归纳和升级，这将对中间平台的功能定义和实施的期望产生很大的偏差。我们认为中台≈战略和组织的外化形式、企业组织的强度和灵活性、业务的成熟度、数据沉淀的规模和对中间平台的看法将在很大程度上决定企业中间平台建设的必要性和难度。

1、为什么我们关注中台：企业战略和组织的抽象和简洁

作为近期大厂商和品牌竞争的方向，中台战略反映了企业对业绩增长进入相对瓶颈期的焦虑。在我们看来，中台不仅仅是技术架构的变化，更是一套战略、组织、方法论、技术架构的结果。在早期阶段，中台思想更多地在技术层面上展示和解读，往往是因为技术层面是企业战略、组织和文化外化的最终结果。从中台实施的最终结果来看，技术架构无疑应该作为着陆手段。因此，本文通过不同的主线反映了企业中台的成长进化过程，探讨了中台与战略组织的关系，并试图总结和总结中台未来的发展方向。

我们可以看到，中国平台的诞生并不是偶然的或没有迹象的。我们认为，这与企业的业务发展和人员规模的扩大密切相关。中国平台的诞生或多或少反映了管理层的意愿（当然，它也承载着他们对企业的良好愿景）。基于对中国平台的历史研究，我们最初认为阿里（09988）中国平台的发展轨迹在行业中具有代表性：阿里最初的业务主要是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，康威定律表达的核心是承认，企业的技术结构与组织结构密切相关，组织结构是指责任和利益的分配结构和方式，责任和利益的划分明确，中间平台得到认可，存在感更加明确。因此，中台建设真正困难的部分是在战略指导下组织重建的深刻动刀，这通常是有意或无意地避免谈论（或没有意识到）。因此，中台建设真正困难的部分是在战略指导下组织重建的深刻动刀，这通常是有意或无意地避免谈论（或没有意识到）。具体细节：

（1）技术架构是公司核心业务和组织的抽象和沉淀。架构师实际上是一个解释管理复杂性的角色——不断抽象、简化和清晰复杂性的职业。在架构师的脑海（中间蓝图）中，公司应该是各种积木（业务单位）的抽象、组装和组合。

（2）平稳组织下的高效、充分的沟通是抽象、复杂业务、组装和组合业务公共部分的前提。对于一个系统模块（如支付、交易等），其呼叫次数和呼叫后评估是衡量其质量的标准。然后开发其工程师与其他部门和业务方的沟通次数与该技术模块的呼叫次数和呼叫时间相似。

这意味着在快速发展和迭代的技术时代，公司不竞争技术，而是竞争组织和文化的优势和力量。这种优势和力量使中台架构师能够在沟通、抽象和沉淀的动作中实现相对平稳、平稳的对接过程，最终实现中台建设和充分发挥效率的目的。

因此，必须提到的是，阿里的铁腕文化价值观被强烈绑定和评估 平台型多元化业务组合，正面推动了中台战略的实施。通过阿里巴巴中台建设，我们看到(1)高层制定并推动部门间数据开放和大中台、小前台战略实施(2)DT基础设施下的电子商务 金融 物流 本地生活 通过2B产品化接入阿里云并输出(Aliware Dataphin/Dataworks引擎 阿里云效平台)是阿里中台能够实现内外部复用的关键点。我们试图总结中台成长路径的核心要素：

(1)自上而下的一把手工程:企业管理者大力推进组织文化重构的勇气

虽然高层可能不会首先提出中台的初步试水，但我们认为中台的建设路径中涉及战略确立，组织变动与利益协调分配，仍然要通过自顶向下的驱动方式。没有高层强有力的长期推动，很难切动组织架构中的固有利益网，因而会导致中台的内部推广难度都大幅上升，很有可能最后因组织划分与职能分管等不可调和原因“中道崩殂”;同时大部分一线员工是很难站在一定的高度去做“看N年、做一年”的中台战略规划，特别是当中台与业务眼前的 KPI 难以达成平衡时，中台的工作开展会受业务的强力狙击。

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

 

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

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

建设中台的前提在于公司的成型业务存在大量协同效应，以至于中台能够很好的提升业务抽象能力，从成型业务的共性切入作为突破口是中台切入的理想选择。中台是能力复用平台，协同效应的业务越多，中台的抽象和复用能力越强，越能够为前台业务提供价值。阿里做中台起源于淘宝和天猫，本质都是电商平台;滴滴做中台，是因为快车、专车、出租车、顺风车等业务围绕出行展开;头条做中台是因为所有APP的使命都围绕用户展开，用户增长是所有APP无法绕开的话题，因此锁定增长指标成为所有业务部门的重点...我们认为当公司存在如下三种问题的至少一种时可能并不适合搭建中台1)业务处于早期还不成熟、数据量有限，现有系统满足数据服务业务的要求2)企业人力不足，建设中台投入的人力物力财力资源无法满足3)成熟业务之间独立性/个性化强，中台抽象余地小。

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

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

中台产品化、产品思维在中台建设当中的重要性也被逐步体现出来。每家企业建设中台的目的均存在差异，包括不限于内部研发效能提升、资源与数据复用、零售全渠道打通、开放银行、多品牌、构建商业生态等。因此，中台所面临的前台业务随着企业业务组成的不同大相径庭，这容易诞生诸多问题——

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

2)外部矛盾，中台团队迫于压力极力满足前台的需求。因为中台的性质，中台团队需要同时面对多个不同的前台业务、前台团队。每一个前台团队都是甲方，在中台团队眼中地位近似，需要极力满足需求。而因前台团队为能获取更多的中台资源使用权，提需求争取更多中台资源成为前台团队习惯，导致中台团队的需求短时间剧增，但因为中台资源毕竟有限，自然而然会出现之前反复提到的需求爆炸、排期、冲突等问题，矛盾产生。

因此，中台的成长过程需要按照产品化(PaaP)的思路进行设计，将前台业务需求前置，提升需求响应和处理能力，形成中台模块的核心落地思路。我们认为，中台产品化可以借鉴思考如下几点1)中台作为产品，能否为前台客户解决实际问题体现自身价值、能否关注前台用户体验，通过清晰的用户定位和产品力吸引并驱动前台客户选择中台产品2)视同一类型的中台产品的合理内部竞争为常态，或同时对多个相似的中台产品进行孵化，通过赛马机制形成更加健壮的中台产品3)需要提供客户运营，客户售后等服务，保持中台产品稳定平滑更新，关注用户满意度以实现客户留存与转化。

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

资料来源：健荐公众号

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

资料来源：健荐公众号

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

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

从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、用户中心、触达平台六大能力，高效率以支持各条出行业务线的快速发展。

滴滴中台架构

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

那问题来了，腾讯（00700）、拼多多（PDD.US）、小米（01810）等其它大厂要不要做中台?我们认为这与企业发展阶段、组织性格以及对中台的战略认识相关。于腾讯，我们认为腾讯某种程度上跳过了集团内部的中台假设，直接以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年向亚马逊内部发布的指令开始：

1. All teams will henceforth expose their data and functionality through service interfaces.

2. Teams must communicate with each other through these interfaces.

3. 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.

4. Anyone who doesn't do this will be fired.

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

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

资料来源：各企业官网

1、我们的判断是中台将会在某些行业得到充分的普及和应用，特别是全渠道全终端背景下，线上线下业务暂时割裂的行业，如上文提到的消费领域的各大消费品牌乃至商业银行领域。渠道之间的不互通将导致企业重复造轮、数据割裂、业务反映迟缓;大量企业数据的堆积与冗余，纯靠手工或已有系统的处理逻辑将会越来越难以适应，在运营策略越来越倚重数据的今天，系统高效的处理与分析有助于提炼数据深层价值。

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

2、中台从私有化走向公有化(泛中台)的形式将会为品牌商和渠道商的发展插上新的翅膀。我们已经看到有赞、快手、抖音、B站、小红书等公司尽管平台属性差异较大，但已经被众多品牌商和经销商潜移默化的作为中台使用，有赞+快手+抖音+B站+小红书+微信OS构成的“虚拟化中台集成商”已经能够有效支撑大部分企业看似”模糊不清“的中台诉求。因此，众多品牌商/商家未必需要搭建自己的中台，上述公有化中台已经能够有效帮助这些企业实现业务的快速迭代。

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

3、在市场红利逐步放缓的前提下，中台将最终成为企业苦练内功过程中的抓手。进入稳定期的企业往往到了拼精细运营的时候了：大家都寄希望于中台来帮企业最大化内部能力复用，从而实现降本增效，在技术上的表现就是企业架构在从单层的应用拼接到两层甚至多层的平台化架构(平衡经济性和灵活性)的过程。但是，未必所有的企业拼精细运营都需要经历中台建设的步骤，中台也并不适用于公司的每个阶段，中台是为前端业务创新的不确定性服务的，企业前端场景鲜少发生变化或应用相对固定，可能就不需要中台;因此适合自己的业务架构和组织架构，以及随之构建的技术架构，就是最适合的伴随企业成长的架构。进化组织尽管大势所趋，但并非所有企业都要在中台火热的时点(盲目)追风，在此文结尾之时，我们仍然相信让企业产生平滑稳健运营和业绩效率的、具备敏捷/灵活的组织与架构，就是(当前时点)最适宜的组织与系统架构。

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