你知道数据中台，但你不知道它和ERP、数据仓库背后的关系
中台概念着实火了一把，继去年购买了“数据中台”的百度搜索指数后，昨天我又购买了“业务中台”的百度指数，可能是由于刚刚购买，全量数据还没有统计汇总出来，所以当我们在百度指数中，搜索业务中台的时候，目前只有 4 月 6 日的数据。
即便如此，我们依旧能从这张图能清晰地看出，中台、数据中台的热度在 2019 年 5 月份开始崛起，在年底达到顶峰，已经持续超越了数字化转型的关注度。
在本篇文章，我不去重复中台的各种概念和定义：中台是企业级能力复用平台。
从另外一个角度，历经了企业 BPR，ERP 实施等传统项目，再到现在的云计算、大数据、等数字化项目，在一个从业二十年的 IT 老兵的眼中，中台的崛起可能不仅是“能力复用”，它所代表的意义是更丰富和巨大的。
在我的认知中，“中台”这个概念的火爆不是昙花一现，更不是机缘巧合，它是中国企业信息化发展的必由之路，是本土企业信息化历史上的一个里程碑，它有以下两个代表性：
1、“中台”是国人自主提出并孵化成一个市场的原创概念
从 1999 年靠写程序挣了人生第一笔工资开始，我所接触到的所有的 IT 领域的概念，基本上全都是“舶来品”，中国的企业信息化市场的关键概念，包括大数据、云计算、移动互联网、Web、J2EE、EAI、SOA、ESB、ERP、商务智能、数据仓库等无一例外，都是从海外由咨询公司或者大型厂商引入的，而中国的企业信息化历程就是由这一个个关键概念牵引着前进的。
理论指导实践，好的理论能够统一愿景，领导行业的方向。好的概念能够让行业统一认知，形成共识，从而更快的规模化发展，比如云计算、大数据、ERP 这些概念，教育了众多企业的高管，构建起了中国数字化的基石。
在我的记忆里，中台是第一个由国人自己提出，持续被关注，不断走高成为现象级企业信息化领域的概念。
同时，通过行业的不断讨论和迭代，“中台”这个概念，已经像云计算、大数据一样，逐渐成为了一个独特的市场领域，众多的中台创业公司不断涌现，国内企业都在思考并且实践如何建设中台，巨大的市场需求正在形成。
虽然到目前为止，中台的概念在中国以外的市场落地的案例还不多，但是作为国人自主提出，并且已经孵化成一个市场的原创概念，中台这两个字，已经创建了太多的第一，这两个字足以在中国的信息化历史上画上闪亮的一笔。
2、“中台”代表着本土企业数字化转型理论的一个丰碑
在中台以前，中国的企业信息化领域出的书大部分都是偏实操和工具类的书籍，而介绍企业级架构、方法论的原创书籍不多。
对比美国的IT界，很多软件大拿非常擅长总结抽象理论体系，比如敏捷、演进式架构、微服务这些体系就是 Martin Fowler 和 Neal Ford 这样的软件巨匠提出并升华到企业架构级别的。
所以，中台概念的崛起，绝对是中国企业信息化领域的一个里程碑式的事件，它对于企业信息化已经带来并且还在持续带来巨大的推动作用。
当我回顾这个里程碑事件的时候，我隐约感觉到了一个模糊的关联，这些关联随着思考不断的深入，随着与同行们不断的碰撞越来越清晰，中台的本质是什么，它的发展将何去何从？
中台的崛起是从“服务化”到“去 ERP 化”
10 年前，阿里掀起了一场声势浩大的“去 IOE”活动，其本意是，在阿里巴巴的 IT 架构中，去掉 IBM 的小型机、Oracle 数据库、EMC 存储设备，代之以自研或在开源软件基础上开发的系统。
站在技术的视角看“去 IOE 化”的过程，就是将原来的中心化的、封闭的 Oracle 商业数据库软件替换为去中心化的、开放的开源数据库软件，将原来封闭的 IBM 的主机、EMC 的高端存储设备替换为以 X86 为代表的云化硬件设备。
对应到典型 IT 架构的层次，去 IOE 化都是在企业的基础架构层面，包括应用基础架构的工作，也就是从 IaaS 到 PaaS，而应用层并没有太大变化。
但是，当我们看中台的概念的时候，我们发现，中台要解决是两个方面的问题：业务中台和数据中台。业务中台通过抽象，封装可复用的逻辑，提升企业的响应力，而数据中台通过打通企业的数据，构建自学习服务的数据能力，让企业更智慧，一个是应用层， 一个是数据层，也就对应到 Application 和 Data。
行业里普遍比较认同中台的构建就是业务数据化，数据业务化，也就是围绕微服务架构的过程。
但是如果我们把业务中台和数据中台与过去二十年的信息化历程关联到一起，我们会发现中台的建设可以分为两个阶段，第一个阶段是“服务化”，第二个阶段是“去 ERP 化”，而最终对于企业来讲追求的是用新的数字化技术去替换遗留的 ERP 系统的过程。
企业中台实施第一个阶段：服务化
目前很多企业所实施的中台，主要的工作是将遗留的后台系统，比如 ERP/MES/CRM 的公共部分进行拆解复用，形成类似于交易中心、用户中心，订单中心这样的微服务集合供前台调用，从而保证逻辑的一致性同时更快的响应前台的变化。
这个阶段，中台以“通用能力服务化”为核心。如下图所示，左边是业务中台，业务中台将后台的通用业务能力，比如用户接口、订单接口、支付接口等统一抽象成微服务提供给多个业务前台使用，从而保证前台业务数据化的过程的标准化、统一化，提升了业务数据化的一致性和准确性，同时也加快了前台的响应速度。
右边是数据中台，数据中台从后台获取全域数据，并且通过结合人工智能的算法技术挖掘产生业务洞察，并提供唯一的数据查询和统计服务给到业务前台和业务中台，从而驱动业务朝智能化转型，优化现有业务同时转型和创新业务。
整个这个过程，都是业务响应需求的发展，进行微服务改造的过程。下面我们以一个最典型的订单服务为例来仔细剖析这个过程，从而阐述业务中台和数据中台的关系以及他们的业务价值。
下图是一个典型的电商订单服务的流程，用户在某电商自营 APP 下一个产品订单，这个应用负责把订单数据保存到数据库里。
随着这个企业的发展，该电商企业拓展了多个渠道，构建了其他的 APP，提供给用户使用。
于是，用户下订单就有了两个方法，分别在不同的应用里，比如自营 APP 和微信小程序，这样最典型的两个渠道。而真实的情况可能是一个电商企业会有非常多的渠道，有自营的，还有代运营的，还有线下的 POS 系统，还有合作伙伴通过 API 接入的，多个应用会同时创建订单。
这样的情况下就会出现多个应用都会创建订单。
这样带来的问题很明显：
- 用户体验不佳，一个用户不能看到在不同渠道的订单。
- 数据一致性差，订单数据分散在不同的应用系统中，数据不一致，同步复杂。
- 维护困难，当一个订单逻辑发生了变化，所有的应用逻辑都要重写，带来的很大的维护工作量，响应慢。
在这种情况下，如何解决这些问题呢？
为了解决订单数据一致性的问题，一般会在 OrderDB_1 和 OrderDB_2 之间做同步更新，从而保证用户能看到自己的全部订单。
为了能够掌握全局的销量情况，企业会构建数据仓库系统，将不同系统的数据都通过 ETL 的方式抽取到数据仓库中进行分析，这就是 OLAP 的过程。但是由于数据量比较大，处理过程复杂，往往 OLAP 都是 T+1 以上的响应速度，也就意味着，比如企业要想看所有渠道的销量分析报表，只能看到一天以前的，而不能看实时的数据，如下图所示。
上图的橘黄色箭头表示在线交易处理流程，是生成数据的过程，而绿色箭头表示在线分析处理流程，是抽取处理分析的过程。
这是典型的数据仓库和商业智能的场景，而这样的数据利用的问题也是很明显的：
- 数据分析不实时，不能够实时出报表。
- 数据仓库往往都是单体架构，受限于数据的处理计算能力，扩展能力不强，往往只能分析一个阶段的数据。
- 响应慢，ETL 的过程依赖于预设的分析主题设计，当要分析的数据结构发生变化时需要重新设计抽取逻辑，导致响应慢。
以上是现在很多企业现存的典型的应用和数据利用场景，在这个基础之上，业务部门提出了更高的需求，比如如何能够实现精准营销，如何能够实现动态的价格？
这就是数据中台和双中台的典型用例和业务价值所在，下面我们用三个典型场景用例来阐述中台服务化的价值。
下图是典型的数据中台的业务场景：精准营销。
利用分布式的数据架构替换传统的数据仓库，将 ETL 的过程更换成 ELT 的过程，结合批流一体的架构，保证数据的全面覆盖，源数据抽取，实时数据和历史数据并存。
在这个基础上，数据中台借助机器学习等算法能力，构建精准营销模型，能够供前台业务应用直接调用，而不需要做成报表以可视化的形式提供给业务人员，业务人员根据自己的经验在去做手工的用户运营。当用户在访问商品清单的时候，根据用户画像、产品销量等全域数据，实时生成最新的产品推荐，通过数据中台的 API 推荐给用户。
这是一个典型的数据智能化的过程，通过数据中台整合了企业相关应用系统的全域数据，通过分布式存储和计算能力，结合人工智能技术和算法，为业务系统提供直接可调用的实时数据和智能服务。
业务中台的典型场景用例：订单生成
实现智能化，是所有的企业希望达到的目标，但是智能化对于数据的质量要求很高，而多个分别创建订单服务，导致的问题很明显，而且随着前台应用系统的不断增多，业务数据化的过程越来越复杂，导致数据与真实的业务出现了很多的不一致和偏差。
同时，随着业务变化的速度越来越快，同时维护多个订单服务的工作量很大，响应速度越来越慢，这就要求对于所有的订单服务进行抽象、复用和包装，这就是业务中台出现的原因。
如下图是最简单的业务中台的服务，也就是订单中心的服务，所有的前台应用当需要创建订单的时候，统一调用业务中台的订单服务，由这个服务统一生成产品订单，从而保证了订单逻辑的一致性和维护的高响应性。
双中台的典型场景用例：动态价格
数据中台不仅为前台应用直接提供调用服务，并且也能够为业务中台提供数据和智能的服务。
下图是典型的双中台协作的场景用例：动态价格。
这个场景在很多需要实时计算动态价格的业务中存在，比如机票预订和滴滴打车的下单服务中，每一个订单的价格都是实时根据当前的数据计算生成的。
如上图所示，业务中台统一为不同的应用提供订单生成服务，而在生成订单的过程中，需要根据不同用户的情况，动态计算一个价格。这种情况下，业务中台就需要调用数据中台中的动态价格计算模型。
这个模型从分布式数据网格（Data Mesh）中获取产品、用户等历史数据，同时获取实时的订单数据，最终计算出最优的价格，返回给业务中台的订单服务。
而这个动态价格的智能服务可以同时被业务中台和其他业务前台所调用，所以，数据中台是同时为业务中台和业务前台提供数据和智能服务的。
部分企业目前所实施的中台，都是和以上三个业务用例类似的场景，就是将一些共有业务流程做服务化改造，从而变成可以被前台快速调用的业务服务，提升业务的响应力，让业务更智慧。
当我们看双中台服务化的过程时，不可避免地要面对很多已经有了后台系统，特别是已经有了套装 ERP 软件的情况。这个时候，我们要解决的就不仅仅是服务化几个核心能力的问题，而是以 ERP 为代表的遗留企业架构和以中台为代表的新兴企业架构的博弈问题了，这时候，中台的实施就进入了第二个阶段。
企业中台实施的第二个阶段：“去 ERP 化”
十几年前，我作为早期做 BPR（业务流程再造）和 ERP（企业资源管理系统）的顾问，经历了原来以进销存为核心、系统分散数据不拉通的蛮荒阶段。那时候的企业对于 ERP 的追捧，就和现在追捧中台一样。
当时要解决的问题是将企业的流程梳理清晰，做到资源的集约化管理，从本质上讲也是解决流程复用、业务能力化的问题，只不过那时的技术实践方法是套装软件，通过 Oracle EBS 或者 SAP ECC 这样的商业闭源软件，开箱配置后使用，用国外成熟标准化的流程来驱动企业的业务。
曾几何时，ERP 是企业现代化管理制度的代表，上了 ERP 表示企业流程优化、资源集约化的成功，但是经过了十几年的发展，原来的 ERP 系统已经不足以满足当今企业的诉求，主要原因如下：
套装 ERP 软件的弊端
- 商业软件，响应慢大部分的 ERP 系统是商业软件，是按照 License 来授权的，企业只有使用权，这就导致当企业的业务发生变化的时候，需要找到原厂进行重新配置或者新开发，响应比较慢。
- 封闭架构，不开放套装 ERP 软件是封闭架构，技术不开放，导致企业无法对它进行大的功能上的扩展，只能像打补丁一样，构建一些外挂，而且效果往往都很不好。
- 单体架构，弹性不够过去的套装 ERP 软件一般都是巨型单体架构，天生的弹性不够，不能够满足持续增长的性能需求。
- 昂贵的升级和维护成本套装 ERP 软件的升级和维护成本一般来说都很贵，导致有的的企业抱怨，不上 ERP 会死，但是上了 ERP，费用太高，负担很重。
过去，企业使用套装 ERP 的核心原因是需要复制和遵循 ERP 软件里内置的那些业务流程，在某种角度上讲，过去 ERP 系统的实施其实是“买流程送软件”。
但是，中国的企业已经建立了适应中国市场特色的组织结构和业务流程体系，而且互联网的快速普及，导致原来静态，标准化的业务流程已经不足以支撑企业的快速响应。
这种情况下，一些领先的企业对于 ERP 这样的核心业务系统的价值诉求从原来的固化流程到了快速响应前台市场变化的新阶段。
而与此同时，ERP 这样的以流程为核心的组织形式也转向平台化的组织形式，而这也是中台的核心理念。
企业组织结构从流程式协作走向平台式协作
ERP 的实施过程中，会制定很多的流程、岗位、职责，从而让多个部门能够在统一的流程下有机的协作起来，我把这种组织形式叫流程式协作，如下图所示：
这样的好处是，在预设好的业务流程、分工职责下，不同的部门做各自的事情。比如研发部门就关注产品的先进性，采购部门就关注采购的低成本，生产部门就关注产品的高质量，我们默认为只要各个部门按照制定的流程和 KPI 协作，就可以实现企业的业务战略。
但是，我们会发现，这个图是从企业内部视角来看的，并不是从客户价值视角来看的，天然把企业分成了外部和内部。
而随着互联网的出现，外部竞争格局越来越复杂，企业需要围绕客户价值来组织经营，一些领先的企业倡导，所有组织单元和业务部门都要产生客户价值。
但是 ERP 时代的流程式协作就在客户价值之间构建了一堵无法逾越的墙，因为研发部门只关注技术的先进性，不关注客户是否买单，而采购部门只关注低成本，不关注技术的先进性。每一个流程节点和业务部门重点关注的是给自己设定的 KPI，而不是客户价值，导致局部利益大于全局利益。
如何打破这堵墙？
这不是一个简单的事情，从原有的遗留系统，特别是 ERP 这样的套装软件中区解耦业务流程，做服务化改造本身是一个很复杂的工作，并且在改造的过程中，牵一发而动全身，很多企业会发现，最终的结果就是会将原来的单体 ERP 系统拆解成为分布式的，去中心化的 ERP 微服务集合，我称这个阶段为“去 ERP 化”阶段。
中台建设对于一些已经有 ERP 系统的企业来说，就是“去 ERP 化”，将中心化的单体 ERP 系统拆解成分布式、微服务架构的开放平台，而不仅仅是“能力复用平台”。
在这样的业务开放平台的基础上，能够打破企业内外部的边界，让所有的业务部门从后端走向前端，通过中台支撑敏捷前台，创造客户价值，我们把这样的协作形式称为“中台时代的平台式协作”。
ERP 系统的典型场景是流程的复用，定义业务流程模板，然后把一套业务流程尽可能的复制到不同的业务领域和客户需求上，从而实现资源调度的集约化，是典型的计划型经济的思路，强调标准化和资源的复用节约。
而在 VUCA 的市场环境下，企业面临的是客户越来越多样化，个性化的需求，越来越强调以客户为中心去动态的组织资源为客户提供服务。
这就要求后台业务系统能够更加灵活的支撑前台不断变化，个性化的客户需求，这和 ERP 系统的核心理念及本质是相违背的。
这种情况下，原来的 ERP 系统必须要将以流程为独立单元的模块拆解为以客户价值为独立单元的模块。
同时，这样的转变也带来一个巨大的挑战，就是如何给员工打绩效。
原来 ERP 时代的员工绩效比较直接清晰，就是将业务流程绩效分解到每一个岗位，比如完成率、审批率等。
但是，当转变成以客户为核心的时候，如何度量绩效呢？
企业希望每一个业务节点，所有的参与方都可以对齐到客户价值，用产生的客户价值来度量贡献，这样能够更直接的激励员工。
这是一个很好的愿景，但是实现起来是困难的，那就是对于一些后端赋能型的业务单元，如何将它们关联到直接的客户价值上，这里就需要利用全域的数据分析、建模，通过敏感性分析等算法技术来实时计算，这也就是数据中台所需要提供的能力。
总的来讲，对于那些拥有 ERP 系统的企业来讲，中台实施的深水区必然涉及到要重构原有 ERP 系统，因为传统 ERP 和中台的核心理念是冲突的，所以我用“去 ERP 化”作为企业中台实施第二个阶段的名称，不意味着一定是要抛弃 ERP 软件，而表示要将传统的以资源计划为核心，以集约化为目的的业务系统转型为以客户为中心的业务中台。
“去 ERP 化”的过程一般会分为两个步骤，由于篇幅原因，这里我们简单介绍一下：
一、将相对比较独立的真正的企业后台，比如财务，人力资源这些模块保留在后台 ERP 系统，其他的业务模块基本上都会从单体架构变成分布式的微服务架构，如下图所示：
这个拆解重构的过程，最重要的一个标准就是将原来的 ERP 流程拆解出可独立提供业务价值的微服务。
在这个阶段，我们认为，偏后端的 ERP 模块，比如财务、人力资源，还是会保留的，拆解的目的不是为了微服务而微服务，是为了能够对齐和提供客户价值。
二、一切应用云化，应用与数据分离。
在第一步的基础上，我们展望未来，会发现有一个趋势：最终，一个个的单体架构的后端系统都会随着云计算、大数据处理技术的发展，变成一个个的可独立运行的微服务。
企业的后台系统会被分解成一个个的分布式的微服务架构，能够被管理、被编排、被治理，每一个微服务有自己基于云的数据存储，物理上是分布式的。
小结
我用下面这张图来概括中台发展的三个阶段，最终我们发现，对于那些已经有 ERP 系统的企业来讲，中台的建设本质就是利用微服务架构构建开放业务平台来替换闭源单体架构的 ERP 系统的过程。
中台的构建过程是企业转型的过程，是企业从流程为核心走向以客户为核心的转型，是企业从以人的经验驱动走向数据智能驱动的转型。
中台概念的崛起和落地代表了中国部分领先企业逐渐走入了企业管理体系的无人区，已经没有以前的西方先进管理经验可以照搬，需要的是快速试错和高速响应的能力。
而这一切，也许要从“去 ERP 化”开始，让我们和过去的 ERP 说一声“珍重”。