企业数字化转型是「企业信息化」管理方式的升级换代；新时代的数字化实施工作和传统的信息化实施工作相比，议程重点正在发生变化。

首先，这个变化的大背景是企业软件技术的代际替换：

▲ 引自Gene Kim等著《The Devops Handbook》,有修改

在中国，前些年企业IT产业里突然产生了一个叫“去IOE”的概念。这个名词本来是说阿里技术构架的变化，即采用开放的、分布式的互联网架构。

这一变化反应了上表中从第二阶段向第三阶段的技术发展。它本身是个技术命题，并没有政治或商业含义，对IOE三家厂商贴标签也不尽准确。例如，IBM不仅是传统服务器供应商，也是“企业架构”和“开放技术”的开先河者和积极倡导者。

然而，部分服务器、企业软件厂商抓住这个概念进行炒作，对行业产生了一定程度的误导，除了阿里云等由互联网公司转型为云公司脱颖而出外，传统的服务器和企业应用公司大多并没有完成自身的转型，从而推进企业信息化升级。

在过去20年，企业应用架构的演化是个渐进的过程，从2000年左右开始，随着互联网的发展，就已经出现了所谓从C/S架构向B/S架构演化的趋势。

所谓从“三层架构”转向“多层架构”，将数据存取、数据抽象、业务逻辑、业务流程、用户访问等分层抽取出来，形成面向服务的架构（SOA，如上图所示），下图是典型的基于J2EE的应用架构示例。

然而，商业技术发展的规律是：出于理念接受速度、传统软件产品的在位优势等原因，软件公司商业模式以及企业应用发展在实践上，总是略微落后于技术发展；而当SOA的应用开始普及后，“微服务”等新一代技术概念又长江后浪推前浪了。

▲ 引自Gene Kim等著《The Devops Handbook》,有修改

近些年，越来越多的中国大型企业开始对集成的大型企业应用进行“解耦”，或称“去ERP化”。

所谓分久必合、合久必分，90年代中后期以ERP为代表的企业应用，其特点就是“大集成”，包括：

• 流程集成（例如销售、计划、制造、采购的供应链横向集成）；

• 职能集成（例如财务业务一体化）；

• 数据集成（一处输入、多处使用）等。

这反应了工业化组织的流程管理思想，同时也带来实施复杂、变化困难等一系列问题。这样功能复杂、结构严密的一个信息系统，技术架构上被称为“单体系统”（Monolith）。

当前，人们认识到商业环境越来越动态，即所谓“VUCA时代”。为了应对这样的环境，组织需要越来越灵活，组织形态分散，动态变化，跨组织开展业务和资源整合，运用“微服务”思想，从企业架构（Enterprise Architecture）出发，尽可能地将企业业务的数字化抽象的颗粒度变得更细小，生成更容易，更便于灵活组合和创新，这就是“去ERP化”的原理。

下图非常精辟地解释了“单体系统”拆分的三个角度：

技术变革也在推动管理者对商业组织模式的重新思考。

上一轮信息化革命带出了“业务流程再造”的组织变革话题，这一轮从信息化到数字化，业务的“技术解耦”和“组织解耦”是相辅相成的，移动、社交、人工智能和物联网让数字化用户在业务操作的前端可以被数字化赋能，而提供赋能的“平台”，被称为“中台组织”或者“平台化组织”。

中台的概念本来是从互联网公司、电商公司产生的，组织变革专家们又揉进了诸如现代军事的基于专业化细分的新组织方式（例如美军作战小组制），去层级化的“无经理组织”等概念，从管理理念上营造了数字化实施的企业环境。

另一个值得一提的技术变革动力是资本：资本推动下的企业应用软件向SaaS服务化转型，构成了企业内部应用解耦的外部动力。

如下图所示，大型SaaS商，如Salesforce, Adobe，Workday，ServiceNow等在过去5年股价飞涨。其中Adobe、Salesforce的市值高达1200亿美元左右，已经接近甚至超过了IBM、SAP、Oracle等传统IT厂商。

而这些传统IT厂商也正在倾尽全力、奋起直追，向SaaS转型。风起云涌的小型SaaS服务商也在用市值优势碾压传统软件商，无论是企业协作的通用软件Slack，Trello等，还是各种专业化应用。今天的企业软件领域，是否走SaaS路线，已经不是产品战略选择，而是2B软件企业的默认项了。

站在企业的角度，构建自己的数字化平台，应用合理的架构，一方面构造自有的企业服务，另一方面对接公有的SaaS服务，是企业数字化方向主流。

正在如火如荼开展、市场反响强烈的阿里“新零售赋能”，我认为实质就是SaaS的一种形式；而苏宁、美的、三一等领先的中国企业也在提供零售、制造业的SaaS服务，也许，这正是中国式的SaaS成长路径：大型SaaS不是从软件公司产生的，而是从实业公司中产生的。

不过，实业SaaS商如何避免和应用客户的利益冲突，是商业模式设计的本质问题，前述观点还需时间检验。

旧时代（前表所述的第一和第二阶段）的信息技术实施上，项目管理者的核心议题是三个方面。

在存储方面，近些年来亮点颇多：

如下如所示，战略决定企业流程，流程中的业务决策需要使用信息，而信息则由信息技术手段产生，这样的逻辑导致了业务流程管理的产生。从理论缘起就能看出，业务流程和信息技术密不可分。

业务流程祖师Michael Hammer本人其实是MIT的计算机专业教授，“BPR之父”达文波特（Davenport）教授在总结有关业务流程理论前就在IT公司CSC和咨询公司麦肯锡担任IT研究工作，后来又在埃森哲和安永等咨询公司担任顾问，德系SAP则得到发明了ARIS业务流程管理（BPM）理论及工具的Scheer教授的理论支撑。从BPR到BPM，到共享服务中心（SSC），再到今天的流程自动化（RPA），业务流程是传统信息技术实施的出发点。

商业上，企业应用软件和硬件业务脱离，出现了“软件包”的概念。企业的应用建设无外乎两个选择：自行开发或者选择套装软件，无论采用哪种方法，项目管理者都必须从用户需求的业务分析出发，定义功能范围（functional scope）。

如果自开发，这个过程是将详细业务分析转为系统功能定义；如果采用套装软件，则是需求和套件的功能比对。由于套件需要具有应用的普适性，使得传统大型企业应用软件最终形成了极其复杂、精密的单体系统；

除此之外，因为信息技术本身的限制，例如数据处理效率方面的OLAP和OLTP的区分，形成了功能系统区分（例如ERP、PDM、CRM、SCM的划分），应用层级分担（例如作业级系统、管理级系统、数据分析系统的划分）等，企业的各个业务间，被按照业务领域、时序性和时效性等原则，条块分割为各个应用系统，由此也产生了所谓“应用架构”这个名词。

项目管理者要尽可能穷尽用户需求，确定明确的、刚性的应用实施范围，设计不同软件系统的功能分担，并分步实现之，因而在这个阶段，瀑布式是主流软件工程方法。例如SAP的ASAP实施方法论，从软件开发生命周期管理（EDLP）的角度来看，就是一个典型的瀑布式方法。

传统上，信息系统实施最大的挑战还不是技术，而是变革管理。“上ERP是找死，不上ERP是等死”这样的口号，反应了信息系统实施过程中，需要达成人员理念认同，工作习惯改变，甚至是企业政治格局变化的艰难；人员必须服从于流程，从而被系统所控制。

总的来说，尽管项目管理者会采取理念宣传、奖励认可等各种形式，这个阶段IT实施的变革管理的方式是自上而下、命令的、革命式的，而非自下而上、自发的、人性化的。

而在新时代，上述技术实施过程的环节并不是不重要了，而是随着环境、手段的变化，管理者将更关注三个重点：

深入理解企业的业务环境、商业转型方向以及技术现状，着手于：

▲ 技术和数据架构的概念示例

数字化时代要有用户思维，企业级的业务和服务要以“产品”的方式向用户交付，企业应用系统要“消费化”（据此可以设想微信或钉钉对传统企业应用带来的冲击），既不断迎合创新，又合乎人性化的直觉应用，具体来说涉及到：

广义的敏捷（Agile）是企业运作模式的创新，就企业软件工程而言，是传统的瀑布式方式向螺旋迭代式转化的新一代软件交付模式。今天，在业务部门、IT开发部门（应用开发和应用维护）、IT运维（基础设施和运维）之间的协作、服务关系也在发生变化，企业技术管理者将关注于：

▲ BCG 2018 年 4 月 1 日推特

最近在思考这个问题的时候，有位SAP ERP顾问跟我讨论，是不是在新时代下，SAP顾问就没有用武之地了？

我说，恰恰相反，上一个时代无法逾越的企业软件巅峰SAP所形成的企业应用思维，在新时代将以新形式来发挥价值。某历史上重度应用SAP的大型零售企业，即使今天利用新一代数字化技术很大程度上“去ERP”化，从高管到CEO都承认SAP对于企业架构形成所起的重要作用。

某大型系统开发专家（Z兄，说的是你）对我说，他觉得SAP顾问和纯定制化开发出身的业务分析师相比，更具有企业数据和流程的体系化思维，更有“套路”。所以，当前SAP顾问的知识革新要点也就是前述的三点：架构、敏捷和设计。