中台看起来没有去年那么火了。

 

今年年初随着一些行业负面消息被传出，舆论对中台的态度开始呈现两极化。

 

正面的声音仍认为中台是大势所趋，是传统企业数字化转型的必然选择；反面的观点则认为中台就是炒概念，满足的是伪需求。

 

但多空之辩还不是中台领域最重要的议题，因为很多人至今还没真正搞明白中台究竟是什么？除了区块链，中台可能是近年来科技圈唯一一个所有人都在讨论，但大部分人却说不明白的风口。

 

然而这丝毫不影响中台的生命力，因为对于传统企业而言，它有可能是一座能帮助后者跨越鸿沟的桥。

 

互联网企业对传统企业降维打击已经不是新鲜事，多年来传统企业一直试图线上化却鲜有成功案例，最近宣布注销的飞凡网就是万达曾经祭出的杀手锏。经过不断试验后，传统企业终于明白，自己和互联网企业的差距不是线上能力，而是一条说不清道不明的鸿沟，而这条鸿沟曾经被冠以“互联网思维”。

 

但做过线上化尝试的传统企业都明白，自己真正缺的是互联网企业所谓的“扁平化”组织能力——可以随意地变形以应对外部环境变化、小步快跑式地推动创新、像履带一样不断有新业务接续企业发展诉求，一个词总结就是“灵活”。而这个“灵活”的组织能力，传统企业想学却无从学起。

 

中台的出现，貌似给出了一个解决方案。很快，大量传统企业便趋之若鹜，中台一朝成势。但实践过后，有些企业出现了不良反应，茅台、龙湖地产等被给予厚望的标杆案例纷纷折戟，众人才明白中台并非一个开箱即用的现成品，更不是一颗百试百灵的万能药，由此质疑之声甚嚣尘上。

 

但回到问题的本质，中台能火是因为暗合了传统企业的根本诉求——相比此前的干着急，中台最起码给出了一个解决方案。而现在问题的关键，是要搞明白中台是什么？中台到底有没有用？如果有用该怎么用？以及自己怎么配合才能实现“说明书”上写的疗效？

 

01

—

中台是个什么鬼？

 2018年下半年开始，腾讯、百度、京东、字节跳动、美团、滴滴等各大互联网巨头接连开启以建设中台为核心的组织变革，中台这一2015年由马云提出的概念，才于去年正式爆火。随后大量科技型创业公司也纷纷跟进，谈到未来战略言必及“中台”。 

但中台究竟是什么？虽然很多从业者近年来都在努力阐释，大量科普文章也都在说明，但大多太过抽象化和概念化，让人难以探知究竟，对于大部分非技术出身的人，更是云里雾里不知所谓。

 要想搞清当前这个定义不清、仍处混沌状态的中台，最好的办法还是要回到它的初始，看看阿里最早做中台的初衷以及中台在阿里内部的价值分别是怎样的？ 坊间流传最广的说法是，2014年马云考察了芬兰的游戏公司Supercell，发现对方不是按项目划分开发和运营团队，而是所有游戏团队共用开发，每个前端团队可以做到非常轻量化从而实现灵活机动。而这个共用的开发平台被称为“中台”。 受到启发，回国后马云开始在阿里内部普及中台理念，并于2015年正式提出中台战略，推动“大中台，小前台”的组织和业务架构变革。 最开始时，天猫只是淘宝事业部下面的一个部门，淘宝抽调了一拨人去支持天猫的产品开发和运营工作。由于天猫发展迅速，在阿里内部的战略意义越发重大，阿里很快就成立了一个与淘宝事业部平级的天猫事业部，但天猫的开发任务当时仍由淘宝的技术团队负责。

 可想而知，分家不分工肯定会出问题。淘宝有限的开发资源自觉不自觉地就会优先倾斜本事业部，因此天猫的很多产品开发需求就总得不到及时响应。但完全分成独立的两摊事，为天猫配齐完整的项目开发和运营团队阿里又觉得浪费，因为淘宝和天猫的产品架构很相似（都有用户管理、商品管理、交易管理、店铺管理、购物车等模块），两套开发团队重复造轮子没必要。 为此，2009年阿里决定成立共享业务事业部，并将其定位为与淘宝和天猫平级的事业部，由其支撑后二者相同的开发需求，并将开发出来的应用变成可被任意业务调用的服务。而这个共享业务事业部就是阿里双中台之一的业务中台的原型。 但就像阿里内网广为流传的这幅插图一样，往往事与愿违。  

虽然是同级单位，但淘宝和天猫是强势的业务部门，共享平台事业部刚创立时根本没有话语权，往往就是前二者让其开发什么它就老老实实开发什么，根本没有能力主导共性服务的沉淀和设计，成为了夹在淘宝和天猫之间的小透明。 转机出现在2010年。随着团购的兴起，阿里创立了聚划算，不管是天猫的商品还是淘宝的商品，只要能登录聚划算销量就蹭蹭上涨，因此聚划算的资源位成为了众人争抢的香饽饽。此时阿里想出了一个主意——不论谁想接入聚划算，都得经过共享业务事业部。共享业务事业部的话语权一下子就被抬升了。 

 

靠着向聚划算借来的影响力，共享业务事业部开始能够主导项目的开发方向和进程，并逐渐沉淀为一个“厚平台”——既可以支撑前端业务的快速迭代，也可以支撑创新业务的低成本试错。

 

马云曾对外讲过，阿里历史上失败的产品要比现存的多得多。如果每个产品还按过去“后端+前端”一体化的开发思路，所要付出的成本早就把阿里拖垮了。

 

原本为同时支撑淘宝和天猫而创的共享业务事业部，后来为阿里整个集团搭建业务中台奠定了基础，最早的1688和后来并购的飞猪、优酷、饿了么、口碑等业务也纷纷借助共享服务体系顺滑地接入了阿里生态。

 

“阿里的共享服务体系中，每个服务中心都有近百人的技术开发团队，正是这个规模巨大中台团队支撑了阿里前台大量业务能灵活快速地根据市场环境做出变化。

 

但业务中台还不是阿里中台的全貌，阿里的双中台中还有一个数据中台，而数据中台的缘起则是另外一个故事。

 

2004年之前，阿里还只有B2B和淘宝两个业务，架构逻辑也相对简单，无非是上层应用+下层数据库，数据库的主要作用就是存储业务产生的数据。随着数据的积累，阿里希望能随时调用各个维度的数据进行分析计算并制成报表，从而支持业务端做决策。但传统数据库的主要作用是支撑业务系统，实现业务动作的顺畅执行，而大量调取数据会与业务系统争夺计算资源，为此阿里决定开发数据仓库。

 

相比数据库，数据仓库主要用于数据的汇聚和分析计算。但到了2008年前后，阿里每天产生的数据量已经达到了PB级别（1PB=1073741824MB)，传统的中心式数据库群组架构由于扩展性差，存在数据库彼此连通的上限，而且昂贵的高端存储设备为未来的数据存储带来了巨大的成本压力，因此已经无法支撑阿里的数据存储和处理需求，随即阿里开启了去IOE化（即去掉IBM的小型机、Oracle的数据库和EMC的存储设备），代之以分布式的数据存储架构。

 

但面对业务产生的海量数据，当时阿里内部也产生了分歧。由于当时所有人都不知道这些数据有什么用，因此一部分人主张把历史数据删了从而节省存储的成本；另一方则认为数据的未来价值巨大，虽然现在还不知道怎么用但仍应该保留。最后马云拍板，决定采用后一种方案。

 

为了把这些数据能存起来，还能顺畅的调用和分析计算，阿里决定启动一个5K飞天计划，即要打造一个能在5千台服务器上同时运行的分布式存储系统。与此同时，阿里内部也慢慢发现，把各个业务线数据打通能产生的价值似乎更大，于是在2012年张金银主持搭建了淘宝消费者信息库（TCIF），把淘宝、天猫、1688、高德等多个业务线的用户数据实现了全贯通。

 

获得大量且多维的数据后，阿里忽然发现，数据不仅能用来看，还能拿来做很多事，比如在阿里的广告业务中，替代过去纯人工的凭感觉投放策略，推出了依靠数据的自动化投放策略，广告系统会根据数据反馈决定哪些广告应该保留，哪些广告应该及时撤下。广告作为阿里的核心盈利业务，这一招直接帮助阿里把广告收入提升了数倍。

 

在广告业务上尝到甜头后，阿里在2015年成立了数据平台部，并同时创造了一个DT的概念用来替代沿用了几十年的IT。而这个数据平台部，就是阿里数据中台的雏形。

 

依靠数据中台，阿里现在实现了越来越多业务的自动化运营，甚至智能化决策，比如淘宝首页的千人千面、阿里小贷的秒级审批、诚信用户在退款退货时的先退款再退货等。“天猫双十一现在70%的GMV都是靠智能推荐实现的，如果还沿用过去人工的方式推荐，无论成本还是效率都是不可能实现的。

02

—

中台能否治传统企业的病？ 

 

经过7年沉淀，2015年12月7日，时任阿里巴巴集团CEO的张勇通过一封内部信正式提出了“中台”战略，一大批在阿里内部见证了中台建设过程的专家级高管纷纷于2016年出来创业，欲把中台做成一门大生意。但在此之前还是先要搞明白一件事，即阿里的中台是否具备普适性，外部的企业客户是否学得会？

 

要回答这个问题，还是得回答阿里双中台创立的初始，看看阿里当初面对的问题是否有普适性，才能判断中台这一解决方案是否具备通用性。

 

先说业务中台，其雏形共享业务事业部创立的缘由，是为了解决淘宝和天猫在开发资源争夺上的矛盾，貌似解决的只是阿里自家问题。

 

在20年前，中国的企业界尤其是大企业圈子里也闹腾过一段升级改造的浪潮，名为信息化升级。原因是随着企业规模不断扩大，业务越来越纷杂，过去手工记账的方式已经无法支撑企业进一步的发展，于是众企业纷纷从国外引进企业管理系统。

 

随着企业业务不断增多，子公司、分公司不断创立，多年来企业在内部部署的ERP、CRM、OA等管理系统越来越多。渐渐的，这些原本帮助企业提升效率的工具，反过来变成了阻碍企业继续发展的桎梏。

 

由于这些IT系统往往是自上而下部署实施的，而且传统企业的IT部门一般只负责评估需求和系统招投标，而没有能力对系统的设计做长远规划，因此就会出现重复造轮子的资源浪费现象。就像当年的淘宝和天猫，淘宝已经开发了购物车功能，到了天猫还得再开发一次。但这还只是过去系统部署方式的弊端之一。

 

另外，随着企业发展的深入，当集团公司想要横向推动某些业务动作时会发现，彼此隔绝的异构系统就像一个个烟囱，难以打通。“比如库存管理，企业内部的ERP系统里有，外部的电商平台商城、微商渠道系统等也有，但它们往往彼此难以互通，企业还是无法做统一的库存管理。

 

更要命的是，这些系统往往已经僵化，根本无法支撑企业在创新业务方面的低成本快速试错，企业只能重新造烟囱。但当今的商业大环境是，电商、微商、O2O、拼团、直播电商等商业场景不断涌现，如果不能快速抓住这些趋势性的渠道，一个企业很可能就会被竞争对手超越，甚至被时代抛弃，因此企业自身就必须能快速自我迭代。

 

“重复造轮子、部门或业务‘墙’、组织僵化三大弊病，导致传统企业无论是在过去的电商时代，还是当下的数字化经济时代，都有一种强烈的随时可能被颠覆的恐慌感。

 

而这三个问题也是阿里当年遇到的问题，所以才推动了共享业务事业部的成立，并逐渐演化出了业务中台的系统和组织架构，从而灵活快速地进行创新。

 

如果说业务中台消除的是传统企业因自身问题而产生的恐惧，那么数据中台则成功唤起了它们对未来的恐惧。

 

阿里最初对数据价值的理解也仅限于数据报表，并对是否删除海量历史数据出现过分歧。但时至今日我们都知道，数据是企业最宝贵的资产，而数据的价值也远远不止于“看”这么简单。阿里的实践告诉所有人，其每年只需要数百人的小二运营团队，就能支撑其数万亿元的生意。

 

对应到传统企业，它们过去对数据的理解就是那些IT系统产生的副产品，数据价值最多是可以做成报表供领导阅览。“现在绝大多数的企业对数据价值的理解仍停留在数字财务报表的程度。

 

而这些数据大多跟随各自的应用被封锁在不同的烟囱里，彼此并不流通，而且各系统对数据的定义也不一致，即使流通也很难统一使用，因此除了财务数据外，很多企业会选择定期清除历史数据，以降低存储的成本。

 

而阿里顺手开启的DT时代又让这些传统企业很恐慌，急吼吼地想要推动自身的数字化转型，就像20多年前的信息化转型一样。

 

面对相似的问题，阿里用了12年时间摸索出了目前相对终极的解决方案，即业务中台和数据中台，理论上外部的企业客户可以套用现成的方案而不必再走弯路。但中台毕竟是阿里当前的组织和业务架构才能匹配的，而传统企业的状况和12年前的阿里一样，因此这供给与需求之间的落差，就成为了中台创业者的机会所在。

 

而中台创业企业要想帮助传统企业客户成功地部署中台，肯定不是只提供一套软件产品那么简单，其它的包括业务的梳理、数字资源的盘点、数据的打通、甚至人才的培养和中台使用理念的培训等都应该是包含在解决方案当中的。

 

“中台相对于前端应用，具体哪些能力模型该由中台负责开发，哪些业务实现该由应用端自主开发，应用的共性与个性的分辨；以及中台区别于传统IT系统相对固化的特性，其需要自我驱动不断升级进化，这其中持续运营的方法论等，也都需要中台创业企业给出成熟的解决方案。

 

03

—

如何驾驭中台？

“把客户预期调的太高，对方幻想中台无所不能。”这是谈到中台失败案例时，几乎所有被访对象都提到的一点。

 

早已对阿里组织能力和业务创新能力艳羡不已的传统企业，眼看阿里开出药方后，很大一部分直接把中台当成了万能灵药，认为部署了中台自己就能立马获得阿里一样的组织和创新能力。但中台不是万能药，没有起死回生的功效。

 

中台的作用就是帮助企业实现核心能力的复用和核心资源的共享，从而支撑更低成本的创新试错。比如一个创新业务系统开发任务，通过调用中台的服务就能实现90%的功能，剩下只有10%需要重新开发，那这个创新的时间成本和资源消耗自然就大大降低了。

 

“平时我们也经常会向老板强调中台不是万能的，如果某项能力我们之前就缺失，中台也帮不了我们。

 

但要实现“复用和共享”，也没那么简单。中台是要把散落在企业内的所有IT资源和数据资源集中起来，这不仅是一件技术层面的事情，更牵涉整个组织变动和企业战略。

 

“中台不是一个产品或IT开项目，而是一种理念，或一种方法论。”这听起来貌似很抽象，但他指明了企业要想拥有中台，不是部署一套软件系统那么简单。

 

首先是咨询，帮助企业做数据中台的顶层设计与规划。这一步可以由数据中台厂商来做也可以由外部的咨询公司来做。这个过程不仅是要了解客户的需要，同时也是一个教育客户的过程，要让客户明白中台是什么，以及能起到什么作用，把客户的认知和现实拉平。同时要摸清楚用户究竟有多少数据，并告诉用户用这些数据能做什么事情，基于这些事情能做哪些规划。

 

第一步至关重要，因为中台厂商需要在初始期就和客户达成一系列共识，而这些共识能否达成直接决定了中台项目的成败。“比如中台不可能是一两年建成的，它是一个长期工程，阿里也是花了十几年才逐步建成的，而且中台的价值是逐步显现的，越往后价值越大。

 

但这里就出现了一个矛盾，即中台厂商很难说服客户，中台部署前两年产生的价值有限，3-5年价值才会逐步显现，5年之后价值会指数级爆发，“用户基本都是期望年初部署，年底就能看到效果。

 

为此，在给企业部署中台的同时，为企业做1-2个亮点应用，让企业能看到中台效果反馈。

 

第二步是规划，对数据中台顶层设计做详细设计，确定实施模块、里程碑、实施优先级及行动路线。相当于把顶层设计落地成可执行的详细规划，确定每一步怎么走。

 

但第二步完成也才只是一个开始，空有一套数据中台系统企业是不会用的。

 

第三步是建设，要对客户企业的数据进行归集、清洗、加工、建模，而这一步就是我们普遍理解的软件部署阶段。数据中台厂商需要把自己的标准化产品（软件系统）部署到企业，并根据企业的需求做一定的修改和个性化定制。而这个部署实施的环节可以由中台厂商自己做，也可以交由外部合作的项目落地实施的企业来做。

 

数据中台的产品包含数据归集、数据离线开发、数据实时开发，数据资产管理、数据质量检测、数据科学平台、数据开放平台等模块。

 

 

而这一步就是中台厂商实现商业价值的环节，即通过标准化产品获取溢价。很多厂商寄希望于通过做大量项目，从而沉淀出一套标准化产品是不现实的，因为行业不同，同行业内的企业之间差距也很大，想要抽象出标准化产品，必须通过行业专家来实现顶层设计。

 

这一步虽然看似简单，但这个过程反而是最难推进的。因为企业内部各部门会从各自利益出发，往往会拒绝交出自己手中的数据，“即使数据在他们手里发挥不了什么价值，他们也不知道怎么用，但他们也不愿意交出来。”

 

这个时候就要看前期的共识达成环节，有没有和客户明确表达中台是个一把手工程，需要靠一把手强力推进。“项目开始阶段，企业一把手都会开动员大会。我们的经验是，如果高管都能到齐，而且一把手明确下达命令让各部门配合，并要求各部门交出一个提交各自数据的时间表，这样的项目往往能较顺利推进；而那些只是口头说说让各部门积极配合，却没有实质性任务安排的，甚至于高管都到不齐的项目，往往很难推进下去。

 

第四步要帮助企业搭建全域数据共享能力中心，从而为上层的数据应用提供数据支持，将数据资产转化为数据价值，比如通过智能营销、决策指挥、精准预测等场景应用，实现数据驱动业务。

 

“基于场景开发的应用，才是客户能直观看到的价值。但很多企业会把场景应用理解为数据中台，在一开始就让数据中台厂商开发某些专项应用，这是把过程搞反了。，“如果按客户的要求来，后期会出现一些预想不到的问题，最终很可能把数据中台开发做成了一个个独立应用的烟囱，完全背离初衷。”

 

第五步是帮助企业建立中台运营能力，因为中台不像传统的应用软件，部署完直接用就行，而是个需要持续迭代的工程，而这就是中台和传统的ERP等企业管理系统最大的区别。

 

传统的ERP管理系统，只是把用户过去既有的业务流程固化到系统内，整体的扩展性比较差，未来一旦有新业务出现需要在系统中开发新能力时，原有的系统往往很难支持，这也是为什么企业需要不断建新的系统，开发出一大堆烟囱。

 

但中台的最大优势就是它是活的，它本身就需要不断成长，不断自主开发出更多的能力、引入更多的数据维度、研发更新的算法模型等，提前储备新业务可能需要的技术能力。

 

这个逻辑和传统的开发模式是不一样的。过去的开发模式是，业务端先提出一个需求，然后产品经理根据需求设计产品原型，再依次推动UI设计、前端开发、后端开发等。但中台模式是，中台本身要自带资源，业务部门的需求一旦出现，中台要能提供大部分的现成能力，业务部门只需求做服务组合和个性化扩展的开发工作，就能把新业务系统的初始版上线。

 

而中台想要有这样自生长的能力，就需要客户企业学会中台持续运营的方法论。在组织层面，负责中台的技术部门也不再是传统的为业务部门提供支持的职能性部门，而要提升为与业务部门同等重要的核心部门，因为中台不仅能支撑业务快速创新，甚至于能自生长出一些新业务。