什么样的企业适合中台？

今年“中台”一词异常火爆，据说在百度搜索指数已经超过了“数字化转型”。遗憾我这一向不愿意赶时髦的“老古董”前段时间才听别人提起，前几天陆续在朋友圈内发表了自己的看法，今天想写一篇文章系统地阐述我的观点。

做学术一定要严谨，既然要讨论这个问题，那前提是要弄清楚“中台”的准确概念内涵。我查了 IEC/ISO38505、GBT34960-2018（信息技术服务标准）等相关标准，并没有查到“中台”这个概念的定义。搜遍了百度，也没人给出确切的说法，都是各人根据自己对字面的理解去解释它。甚至有人说，中台就是前台和后台之间的那个台，颇有点像那首歌“啊，五环就是比四环多一环”的味道。

据说“中台”一词火爆的原因是因为马老师在 2018 年的某次演讲中提到了阿里的“中台战略”，既然是马老师让它火爆的，那我自然只能从阿里去找答案。我从网上找到钟华编著的《企业 IT 架构的转型之道——阿里巴巴的中台战略与架构实战》，书中写道 2015 年马老师带队考察了位于芬兰的 Supercell 公司，发现 Spercell 这家不到 200 人的公司却能快速开发出好的游戏作品。原因是他们把公共的通用的组件做了积累，每次创作新产品时无需重复写这些基础组件，这样开发速度大大提高。于是乎，回来后阿里暂时放慢了业务的脚步，正式实施中台战略。按照书中的说法，所谓“中台”就是从业务的视角看是企业业务能力的共享和复用，从技术的视角看是软件组件、数据服务组件的复用，以降低开发成本和提升效率。

提到阿里的“中台战略”不得不提阿里的电商业务演进路线。阿里成立之初的业务是阿里巴巴（B2B 模式），2003 年成立淘宝和支付宝，布局 C2C 及在线支付业务，2008 年成立天猫布局 B2C 业务，以及后来的聚划算团购业务。每一个新的业务模式的产生都是独立去建设一套系统去支撑，系统之间彼此都是割裂的，不仅建设成本和运营成本高，而且彼此之间的割裂不能充分共享资源如客户资源、产品资源、商家资源等。因此有必要把各个业务系统的公共资源抽取出来，构建一个中台，因此由最初的竖井式的架构就演变成如下图所示：

既然“中台”概念因阿里而起，那我们就姑且用阿里这个概念范围来展开讨论什么类型的企业或者行业适合“中台”？在企业 IT 一定是业务驱动，所以讨论是否适合的前提要从分析业务入手。我们先来看看阿里的业务。

按照国家统计局 2017 年发布的国民经济行业分类标准，阿里几大电商平台分属于互联网生产服务平台（6431）、互联网生活服务平台（6432）、互联网数据服务平台（6450）。按照《商业模式新生代》一书的作者对商业模式的定义，阿里的淘宝、阿里巴巴、天猫、聚划算属于典型的多边平台型商业模式，平台不参与交易，只提供撮合交易，通过提取佣金或者广告服务费盈利。

信息系统规划的方法有很多，如战略匹配模型（SAM）、企业系统规划法（BSP）、价值链分析法（VCA）、关键成功要素法（CSF）、企业架构（如 TOGAF）。下面我们选取价值链模型来分析阿里构建“中台”的必要性。首先我们根据迈克尔.波特的价值链模型找出阿里巴巴、淘宝、天猫、聚划算的价值链如下图

从价值链图上可以看出，四大业务板块第一阶价值链是完全相同的，如果公司规模小，可以组成一个公司分成四个事业部就可以。但阿里的每个业务板块都很大，所以有必要分拆。既然一阶完全相同，那么他们只能通过往下再分级去找到他们的差异点、相同点。为了简化起见，我只从“交易”这个价值链环节往下细分，二阶见下图：

从上图可以看出，他们在交易环节有很多相同点，也有很多差异点。因为平台撮合的交易对象不一样，导致了这种差异性。比如阿里巴巴的 B2B 交易模式，在客户管理这个环节，双方注册后都需要审核，对商家的审核和对购买方的审核不同。对商家的审核提交的资料更多，还需要保证金，因此很多环节是线下完成，很难完全通过线上完成，阿里的商家审核基本上是外包给第三方做。而淘宝的 C2C 模式，对消费者的审核几乎不需要资料，全自动在线上完成。

既然有很多业务上的相同点，那是否可以业务共享？如客户的共性部分的管理可以设立客户共享中心来管理？因为历史的原因，各板块成立的先后时间不一样，所以阿里一开始并不是业务共享（现在业务是否共享不得而知）。但即使板块成立的时间一样，是否一定要共享呢？是否共享要考虑的基本要素：一、是否带来规模经济，二、是否带来便利性。如果不能带来规模经济不要共享，如果共享后更麻烦，会带来管理成本的增加，降低效率也不要共享。显然，阿里这几个板块的规模足够大，业务的标准化程度足够高，是符合业务共享的条件的。

业务不能成立共享中心的情况下，技术组件是否可以共享呢？同样也要考虑这两个基本原则，一、规模经济，二、便利性。如果共享的组件足够多，那把公共的组件抽取出来，单独组建一个所谓的“中台”确实是很有规模经济的。另外，因为拆分带来的额外的管理成本一定要低于拆分前的重复开发的成本，不能增加管理的复杂度，所以拆分的原则一定是和具体业务解耦。很显然，阿里的技术平台是符合这个原则的。

上面我分析了线上零售行业的特点，下面我分析传统的石油天然气行业特点，整个产业链简单抽象如下图所示：

我们先看下游的城市燃气公司的价值链如下图：

从价值链图上可以看出，几种业务有很多相同点，有的燃气公司规模很大，会把采购、配送业务共享出来单独成立一个公司，为了挖掘客户价值，会单独成立客户部门或者公司。因此，从系统设计的角度来讲，采购和物流、客户管理最容易会成为全公司的“中台”，来支撑不同的业务板块的个性化业务拓展。尤其是 C 端客户的价值挖掘，由于城市燃气属于共用事业，受国家价格管制，盈利空间有限，在资本市场上的想象空间有限，因此如何在这一块加大数字化转型（业务转型）成为各大燃气公司战略布局的要点。在技术上就有必要统一客户资源管理和客户价值的挖掘。

我们再来看最近成立的国家油气管网公司价值链如下图：

从上图可以看出，因为国家管网业务单一，系统之间的关系是横向关系，不存在多个业务板块需要共享的业务。也许有人会问，财务共享不也是共享业务吗？首先在阿里对“中台”的定义只是业务信息系统，不包括管理信息系统。其次，财务共享是纵向共享，即把各个子公司、分公司的财务服务工作集中起来。从信息系统的角度来讲，不存在每个系统里都有财务模块，需要把每个系统的财务功能抽取出来共享。

我们再来分析一下家电行业的典型的架构图如下（为了简化就不分析其业务价值链）

在渠道层和生产、采购、库存之间要增加一个所谓“中台”的主要原因是，家电行业都是多渠道销售，既有经销商线下门店销售、也有自己的线上、线下渠道，为了把多个渠道的资源共享起来所以构建了中台（有点和阿里相似）。按理说，这些资源直接共享在 ERP 里不行吗？这是因为历史的原因，很多家电厂商选择的都是 SAP、Oracle 等产品，在功能上不支持这些资源的共享，另外在技术上因为传统的 ERP 软件处理并发能力较弱，所以需要有一个缓冲层，把库存、产品、客户等信息同步到中台，前端直接访问中台，中台再和后台采用异步消息机制来减轻对 ERP 系统的压力。如果直接自己开发 ERP 系统，那么在设计时完全可以省掉这个“中台”。

纵上所述，一般多业务板块的企业适合“中台”，面向 C 端消费者业务的企业适合“中台”，面向 2B 业务的企业不太需要“中台”。总之，采用什么样的系统架构一定要从业务分析角度出发，完全取决于业务需求。学会科学系统的分析方法很重要，不要一味追求时髦！