再论中台 ｜ DDP带来企业核心系统的革命
这几天有篇热文谈某大型制造业实施“中台”失败，再次引发企业是否有必要搞中台的讨论。👇
中台搞了2年，项目叫停，CIO被裁！本以为中台是道送分题，没想到是送命题！
被互联网公司包装出来的“中台”的概念，当然不能简单照搬到制造企业里去。
制造企业的数字化应用大多数是面向内部用户，用户数量限于企业人数，数字化转型的架构变化是基于核心系统，由内向外的解耦，面向用户提供用户体验更好（用户操作背后的流程整合）、界面更友好（像微信一样便于使用的移动应用）、数据更实时的IT应用产品。银行、保险等存在内控要求、注重内部的服务效率的行业，数字化架构的道理类似。
而互联网企业天生就是面向外部海量用户，用户场景丰富、多变，访问性能要求高，中台能力是由外向内沉淀而形成的，某种程度上说，互联网企业不存在传统意义的后台核心系统。零售、服务等需要直接面向顾客交互的行业，数字化转型路线类似于互联网公司。
“中台”来自于互联网公司，最早产生仅仅是一个技术概念，即因应互联网时代软件架构的变化，例如横向扩展、分布式计算、微服务架构等，把自身的多个互联网软件的共用组件提取出来，形成面向各个软件的“公共能力”服务，例如日志服务、监控服务、告警服务、统计服务、权限服务、认证服务等，采用微服务架构还会涉及服务注册发现、微服务配置、微服务网关等，再加上互联网平台之上共用的用户身份认证、DevOps平台等组件，落到企业级的软件“公共能力”平台建设上，技术人员起了个名词叫“技术中台”：
在提炼互联网软件的技术部分的公共组件服务后，人们开始提炼业务应用的公共组件作为服务，亦即所谓“业务中台”。“业务中台”所指范围并无明确的定义，它既包括前台应用程序的业务抽象性的服务，例如公共数据字典、数据转换等，也包括了具象性的业务组件，例如不同渠道的前台业务，都有商品管理、订单管理、会员管理等功能，那可以将这些公有的业务抽象到中台，为前台提供服务。
这样由前台向后形成的能力沉淀，不仅是软件架构的变化，而且必须匹配以相应的业务流程和组织变革，例如商品运营、会员运营、全渠道订单处理的跨渠道的业务组织整合。
从IT应用的角度，这些“中台业务”覆盖的功能传统本来属于 “核心系统”的范畴，例如：商品对应了零售商品系统、库存对应了ERP系统或者WMS系统、会员对应了CRM系统、订单对应了OMS系统等等。然而，基于传统技术架构的核心系统的业务处理模式是T+1，而互联网前台（例如电商）对信息实时性要求越来越高，因而，划分出中台另一个重要作用，是实现海量、实时的前台业务，和相对严格、时间周期长的后台记录系统之间的异步处理。
从用户的角度来看，前台系统面向的是外部互联网用户，对用户体验要求极高；而中后台面向的是内部员工。参考阅读：
制造业等企业一般不直接面对互联网外部用户，其传统的核心系统以功能领域以及信息实时层级来划分（参见旧文👇），包括了ERP、DMS、PLM、SCM、MES等，其中ERP是最核心、最重要的系统。
如果比较互联网公司或者电商零售公司的业务、数据的面向用户实时性的要求，制造业数字化的实时性表现在对设备的反应和控制上，这也是今天IoT和工业x.0成为制造业数字化重点的原因：
上图传统制造业应用构架存在两个显著问题：
一是ERP、PLM、MES、SCM等核心系统都是相对割裂，需要进行流程和数据的整合，例如一个生产管理人员，可能他需要在ERP里下达生产计划，同时又需要在供应链管理系统中去协调物料到料情况，还需要根据设备管理情况来调整产能计划；
二是制造业的传统核心系统更新换代一般都比较慢，有些系统架构较老，操作界面也不人性化。
如果按照今天流行的数字化产品的做法，我们可以以“生产管理人员”作为一个用户画像，设计他的用户旅程，根据他的数字化体验来设计数字化产品，这样的产品在前台将打破传统各个核心系统的功能限制。然而，核心系统作为企业流程的信息记录系统，例如，普通的研发工程师使用PLM以及设计工具，或者仓库管理员利用ERP来进行库存收发，必须服从质量控制标准以及业务合规要求，流程并不是随心所欲地随时在变动，所以核心系统仍是非常有必要的。
制造企业中台究竟符合什么样的标准，是由业务场景决定的，所以我在热文中评论：“没有业务需求的企业数字化架构改造，都是在瞎折腾”：
制造业、银行保险、能源交通等传统行业，“双模式IT”的特性会比互联网和电商公司的纯互联网化要强很多，相应的流程服务颗粒度也并不需要那么细，场景多变程度也没有那么多。所以这种IT模式下的数字化架构，需要从各个核心系统中集中提取、管理和处理的数据，建立数据平台，并在数据之上建立数字化平台，来支持多种前端数字化应用的创新，我们把这样的平台称为“数据和数字化平台”（DDP）。
企业级数据和数字化平台（DDP）并不完全等于互联网中台的概念，例如制造业的业务组件和服务的平台（假设我们把这个叫“业务中台”的话），并不一定要采用微服务架构，微服务架构对于企业业务和技术管理、以及人才能力的要求都非常高。
数字化落地的四个核心问题 | 自建决策，摩登架构，中台赋能和重塑人才
我认为中台概念本身没有问题，但是不同行业、企业对于中台的定位和架构都是不一样的，不能简单地把互联网公司的IT架构搬到传统企业，坦白说，在对企业架构的认识上，互联网公司的人缺乏对传统行业IT应用复杂度的敬畏，而传统企业在接受敏捷方法、数字化创新、以用户为中心的极致体验等方面又比较迟缓。所以，“中台”只能作为企业架构某个层级的概念存在，而并不是某个具体的软件或者解决方案。
中台概念炒热以来，确实造成很多误导；不少没有技术背景的人在按照自己的理解在望文生义解释，例如知识网红刘润先生也没搞清楚ERP和中台的关系👇，实际上，ERP不是中台，而是后台。
BCG提出的涵盖了核心系统、数据层、数字化层以及相应的基础设施、API管理、网络安全管理的数据和数字化平台的技术框架如下图：
基于DDP框架，我们可以思考如何企业数字化转型中，如何重新定位并改造ERP这类核心系统。按照Gartner基于“IT双模式”的系统分级法，核心系统和后台系统属于“system of record”，而中台则是“system of differentiation”：
从七、八年前云应用开始热起来时，“下一代ERP”（缩写为NextGen ERP）的概念就出现了，ERP从核心系统扩展到：
ERP内是企业无差异的业务流程（例如财务流程）
在ERP之外的持续扩展开发，构成企业差异性优势，这样的差异性创新的开发平台，就是企业级PaaS平台
大数据平台提供业务洞察服务，实时嵌入到业务流程中
以用户体验为中心的前端开发
接入外部成熟的云服务，即SaaS，例如费用报销云、用户体验调研云等
以上的各个层级都基于新一代的技术能力（云、DevOps、容器化、API等）
需要强调的是，“下一代ERP”因为架构现代化变革，实施方法也和传统ERP的瀑布式方法有所改进，例如经典的SAP ERP实施方法论ASAP就是典型的瀑布式方法，今天，ERP项目也开始采用敏捷方法。显然，如果ERP技术架构不改，光从方法也没法奢谈敏捷；而新一代技术出台，例如SAP S4 HANA和SAP云平台，方法也必须改了。
敏捷ERP实施方法的特征如下：
我们来看看企业核心系统的代表SAP ERP是怎样转型的。传统SAP ERP系统最受诟病的是：
用户界面不友好
内部高耦合
外部系统集成方式复杂
用户端应用迭代慢
今天，SAP S4 Hana时代的转变首先是从用户界面开始的：
从架构上，企业ERP、CRM等核心系统仍然可以用传统本地或私有控制云的方式部署，同时SAP也通过收购整合了各种SaaS（包括供应商管理、电商营销、费用报销、人才管理等等），而革命性的变化是SAP云平台（SCP），它定位于新一代的、云上的集成平台，集成各种SAP的内外部应用，同时可以作为一个开发平台，扩展、整合SAP在云下和云上的各种软件和服务的标准功能，面对用户开发个性化数字化产品。这和前文那张“围绕核心系统的企业数字化架构”图完全吻合。
以ERP功能定制和扩展为例，云平台上的应用扩展可以做到和本地化安装的ERP（即S4 Hana）的肩并肩扩展，在用户界面、应用逻辑和数据层实现无缝对接。SAP的产品发展和DDP定义框架是一致的，今天做好一个SAP项目，不再仅是需要传统的功能模块顾问和开发人员，DDP“架构师”的作用将越来越重要。
SAP云平台是个新兴事物，我对其充满了希望，过去三年来，我有多篇文章倡导对SAP云平台的重视（如下链接👇），这是彻底解放传统核心系统（所以今天SAP也把ERP成为“数字化核心”，digital core），向以用户为中心的数字化转型的最佳模式；如果硬要说企业架构里有“中台”的话，我认为云平台就是中台。
不过，核心系统向企业平台转化也面临诸多挑战，涵盖技术组件、快速开发以及应用服务的全套PaaS的市场一直不温不火。5年前，IBM第一代PaaS平台产品Bluemix上市时，我也有类似兴奋，不过，由于技术选型和商业模式等多种原因，IBM云平台这几年时运不济，命途多舛，今天，IBM终于又携RedHat让人重燃希望。IBM没有企业核心业务系统产品可能是它的PaaS发展限制原因之一，SAP从自己的企业核心业务系统S4和C4等产品出发，企业客户如果能够准确地审视自身数字化架构发展，云平台前途无量。
数字化转型，请关注