1.1 企业信息系统发展历程
工商业的发展在过去三百年间不断的变 化与加速演进。从18世纪末的动力产生 (power generation)、二十世纪初的工 业化(Industrialization)、1970到2000年 的电子自动化(Electric Automation)、到 现在以数字化供应网络(Digital Supply Networks)为中心的第四次工业革命， 这些变化要求卓越企业不断创新以跟上 技术的更新，甚至引领产业的革新。通 过技术发展的历史，我们发现从打字机 进化到PC花了100年、从PC进化到智能 手机花了30年，而人机交互技术从概念 到落地仅花了几年时间，越来越快的技 术变革速度促使我们的业务系统必须能 够同样快速的响应这些变化。从早期的 业务流程管理系统，到数年前，机器人流程自动化技术（RPA）与ERP系统的融 合，提升业务效率，再到如今结合人工 智能技术的广泛应用，未来的企业信息 系统已经不仅仅只满足于日常事物的处 理，而需要我们的信息系统对业务的运 行具有感知、学习和预测能力，具备更 多的智能属性，帮助企业基于智能ERP 构建智慧企业。
截至2021年，我们可以看到，随着信息 技术的发展，今天的业务模式已经不同 于过去，如今企业信息化环境具有以下 鲜明特征：
数据越来越多样性
今天的数据已经呈现爆炸性的发展，过 去，我们的数据都以关系型数据的形式 存储在数据库、核心信息系统中，但 是，今天我们随时随地都在产生数据， 数据已经不只是发生在我们的核心数据 库、业务系统中，而是无时不刻在我们 的身边产生，例如我们的社交平台，我 们的移动终端设备，我们的互联网和协 作网络，以及我们的云端设备和各类联 网智能设备，这些都是新时代的数据来 源。如今，企业需要有从海量数据来源 中获取有价值信息的能力。
新兴技术快速更替
随着数字化的发展，技术的更新换代已 经越来越快速，短短几年间，云技术从 兴起到普及，机器人技术从简单的流程 自动化到今天探索如何实现人工智能、 机器自我学习，越来越多的新技术、新 名词出现在企业数字化转型的道路上。 很多技术在短短数年内已经普及，成为 企业数字化的核心技术，例如云、机器 人和数据可视化。目前这三类技术已经 成为成熟企业的标准配置。除此之外， 绝大部分获得爆发式增长的企业都选择 了一种或多种指数型技术，以树立自己 在行业内的领先地位，类似的指数型技 术，包括深度分析、认知计算、内存计 算、物联网、区块链等。现代企业的信 息化系统需要有能力借助新兴技术创造 新业务价值。
构建数字生态
现代企业需要的不仅仅是简单EDI、B2B 和应用系统之间的连接。他们需要全方 位的服务整合，构建企业数字生态，这 不仅有助于企业与客户和业务伙伴之间 建立密切联系，而且有助于提升企业与 客户和业务伙伴之间的协作效率。
与客户、合作伙伴、供应商的业务系统 和数据连接是建立企业数字生态的第一 步。端到端集成——数据传递、数据转 换和数据整合——才是最困难的部分。 这就是为什么数字生态整合战略在2021 年及以后对企业更加重要的原因。现 代企业的ERP系统作为企业的数字化核 心，必须有能力与数字生态内的合作伙 伴、供应商、业务系统进行高效协作。
1.2 企业数字化转型面临的挑战
数字化转型的概念已经提了很多年，有 人可能会说，数字转型始于计算机技术 本身的迅猛发展，但是为了更好的描 述这一波趋势，我们引用Gartner的定 义：“数字化转型是通过数字化技术改 变商业模式以增加收入和创造价值的机 会，是一个从传统业务模式向数字化业 务模式转型的过程。"。
在IT领域之外，数字化也正在成为主流。 例如，《经济学人》杂志专门刊登了一 期完整的文章（《经济学人》，2017年5 月6日）。“无论你是去跑步、看电视， 甚至只是坐在车流中，几乎每一项活动都会产生一个数字轨迹。同时，机器学 习等人工智能技术从数据中提取更多的 价值。算法可以预测飞机的喷气发动机 何时需要维修或某人何时面临疾病风险 等。”
其实，这种现象每天都反映在与我们与 客户的交流中。客户希望他们的信息系 统能够提供360°洞察力、用户体验管 理、提供洞察分析能力，以便根据数据 做出决策、为员工提供更好的员工体验 等。这些需求都促使了企业数字化转型 的推进，但是，在企业数字化转型过程 中，往往会遇到不同的挑战。
1.3 企业现代化核心信息系统的特点
为应对现代业务模式转变及如新冠疫 情等各种突发情形的挑战，当今企业 需要提高自身的灵活性、响应速度和 洞察力，以能够适应供应链和工作模式 的快速变化。为此，企业必须比以往更 多地利用数字化和自动化技术，在当今 充满不确定性的经济局势下保持稳定运 营。同时，随着数字化转型的开展，并 在数字化体验中加入人工智能和认知维 度后，技术、业务流程乃至整个企业都 将实现智能化。而随着智能化水平的提 高，企业将不断发展，逐渐转型成为智 慧企业。
现在，数字化智慧企业已成为全球企业 的一个差异化竞争优势，转型成为智慧 企业意味着企业必须为未来创新奠定坚 实的运营基础，这个坚实的基础就是具 有智能属性的ERP, 智能 ERP 系统利用算 法、数据集、分析功能、认知功能和辅 助用户界面在人员、流程和技术层面让 一些任务实现自动化，帮助执行预测、 追踪、学习、路由、管理、分析和报告 等工作。这种自动化可以为企业带来更 深入的洞察，帮助他们制定切实可行的 决策，进而提升业务绩效。
2.1 如何构建新时代智慧企业 – 动成长 企业Kinetic Enterprise
基于多年的ERP实施经验和帮助客户数 字化转型的经验，德勤提出了“动成长 企业”建设理念（ Kinetic Enterprise ）, 该理念为企业数字化转型提供指 引。“动成长企业”由四大部分组成， 以Clean ERP为核心理念， 结合智能应 用技术、向云平台部署模式迁移和开放 应用集成平台三大技术方向为基础，助 力客户向智慧企业转型。
2.1.1 兼容任何平台的Clean ERP (Clean ERP Anywhere)
智能企业的核心是一个"Clean ERP"系 统，Clean指的是低技术包袱的ERP系统 （Technical Debt）。ERP系统不应作为 一个应用开发平台，因为大量的自开发 会降低ERP系统本身的灵活性和敏捷性。 技术包袱包括不必要的自开发，创新应 用开发，过时的需求导致的开发等。
应坚持"Clean ERP"原则，将业务流程 标准化，将技术负担降低到最小。这样 ERP本身会易于版本更新，随时应用最 新的功能。同时标准化减少了平台依赖 性，ERP可以部署、迁移到任何平台， 无论是IaaS还是SaaS， 一个干净的ERP 都可以较小的代价平稳的迁移到新的技 术平台。而拥有大量技术包袱的ERP系 统就不具备良好的平台移植性，通常更 适合本地定制化部署。
此外，Clean ERP将结合平台优先的 建设理念，平台优先指通过核心系统 与创新平台双平台部署模式，赋予业 务创新价值。既保证了核心业务系统 的Clean,降低TCO, 赋予企业更多精力 在创新平台上投资，实现更多业务价 值。例如通过部署在云端的创新平台 进行应用开发，该应用可以便捷地调用 PaaS平台上的大数据、人工智能接口 并与核心“Clean ERP”进行集成，赋 予“Clean ERP”更多智能属性。
2.1.2 智慧互联
智能ERP应具有双平台部署模式，利用 云端PaaS平台构建创新业务平台，将敏 态业务、创新业务在创新平台中进行开 发，对核心ERP进行功能扩展，整合云 端的智能技术，例如大数据、物联网在 云端进行创新应用敏捷开发，在不增加 核心ERP技术包袱的同时，为Clean ERP 赋能。云端PaaS平台相较于核心ERP， 更有利于创新应用的开发，对各类开发 技术支持更广泛、更开放。
传统ERP由于标准功能有限，通常不能 满足所有业务需求，导致会存在大量自 开发应用和增强程序。这些自开发和增 强增加了ERP系统的技术包袱，增加了 平台移植难度， 使得ERP本身的版本更 新也变得更为复杂。
智能ERP将创新应用的开发、智能技术 的集成迁移到云平台，一个更适合敏态 业务、创新应用开发的平台。通过降低 ERP自身的技术包袱，使得ERP版本更 新更为轻松，企业可以始终使用ERP的 最新版本，享受最新的功能。同时ERP 也有更好的部署模式兼容性，可以更容 易的向云端迁移，因为通常SaaS版本的 ERP追求高度标准化的配置，只有最小 化技术包袱的ERP才可以兼容SaaS版本 ERP部署模式。
2.1.3 按需扩展
智能ERP应具备部署在云平台上的能 力，相较于传统的本地部署的模式，云 平台可以更低的拥有成本提供更高的可 靠性和按需扩展的能力。 如今商业环境 瞬息万变充满了不确定性，企业如何随 时应对突发的业务需峰值，又降低总体 的设备投入避免不必要的投资，云平台 就是最佳的部署选择。云平台提供多种 付费模式，同时将资本支出转为运营支 出，又可以降低企业对系统运维团队的 建设和投入，从而在满足业务扩张需求 的同时，保持一个降低的拥有成本。
2.1.4 兼容并蓄
“动成长企业”是多元化的，涵盖多个 维度。在数字化生态系统中，它与企业 不断发展的业务网络以及整个数据环境 紧密集成，从而覆盖结构化的关系数据 和非结构化的大数据，以及物联网，体 验数据等。所以智能ERP需要具备广泛 的集成能力，包括且不限于: 从应用到应 用(SAP 产品集成和非SAP产品集成)、从 应用到体验 (用户体验集成)、从应用到 传感器 (传感器/物联网设备集成)、从应 用到数据 (非结构化、社交、大数据集 成) 及从应用到云 (SaaS集成)，从业务伙 伴到客户（协作网络）。
通过统一的集成技术平台,创新边际（ Innovation Edge ），将Clean ERP与数 字生态系统内的其他信息源进行统一的 集成管理和开发，创造可复用的集成API 和业务场景，降低新流程的开发成本， 同时在集成过程中，应确保数据的一致 性和有效性。
2.2 基于SAP的智能ERP框架
在人们印象中，SAP的成长历程基本上 就是企业ERP的发展史，甚至在许多人 心中，SAP曾等同于ERP。事实亦然，近 一个世纪的时间，从最早的R/1到SAP第 4代ERP产品S/4HANA, SAP一直在用领先 时代的ERP产品和理念帮助无数企业更 好地管理与生产，为世界提供更好的产 品与服务。
随着数字化时代来临，云计算、大数 据、机器学习、人工智能等新技术层出 不穷，SAP也从未停止前进与改变的脚 步。SAP已经是业界少有的可提供完整 和最具创新的数字化转型软件的厂商之 一。利用这些技术和创新，中国企业正 在加速数字化创新，实现发展目标。
同时，SAP也是新兴技术的倡导者，SAP 业务技术平台，将物联网、机器学习、 商务分析、大数据、区块链、数据智 能这些面向未来的技术与能力贯穿在一 起，拥有先进的设计思维，并无缝集成 至云平台—用简单的方式，支撑企业快 速创新，扩展新商业模式。
2015年， SAP推出了SAP S/4HANA，这 是SAP最新一代的业务软件，也是基于 R/3后最重要的创新。其中，S代表简单 和套件，4代表第四代产品。S/4完全运 行在全新一代内存数据库SAP HANA上， 并进行了高度优化。S/4在R/3的基础上 进一步简化数据模型，重塑业务流程和 模型，并利用物联网、大数据、人工智 能等技术进行了一系列的创新，S/4真正 实现了Real Time实时的目标，将ERP系 统做到了Anytime, Anywhere。同时，结 合全新一代的UI技术SPA Fiori，可以为 用户提供更加友好和人性化的体验。
在“动成长企业”建设理念下，智能 ERP的建设为双平台模式，一方面是以 S/4HANA为核心的数字核心平台，并坚 持“Clean ERP"部署理念。另一平台模 式是以SAP云平台为基础，提供智能技 术和集成应用开发的数字化创新平台， 该平台提供ERP应用扩展，创新应用开 发和集成。
这个智能ERP框架，主要由三个组成部 分， 数字化核心应用（SAP智慧企业套 件），数字化创新平台（SAP业务技术 平台）和运行在数字化创新平台上的 SAP智能技术（ 物联网、人工智能、区 块链等）。
首先，智慧企业套件主要由S/4HANA作 为数字核心，结合其他LOB云端应用 （ 例如： C/4 HANA, IBP, SuccessFactor, SAP Concur, SAP Ariba等云端应用） ，S/4HANA可以与这些云端应用紧密结 合自动集成，帮助客户自动化日常业务 流程，并加强与其客户、供应商和员工 的互动。这些应用既能满足行业特定要 求，又能适应全球需求，可以满足不同 规模的企业应用。
其次，借助SAP智能技术指为企业注入 智慧属性，例如将人工智能，机器学习 等前沿技术引入业务流程，进行辅助 决策。
最后，借助SAP业务技术平台提供云上 创新功能的使用、扩展和应用研发、对 数据和流程进行整合等功能，为智慧企 业套件提供敏捷扩展，持续应用创新， 应用集成等基础支撑。
2.2.1 智慧企业套件
SAP智慧企业不仅是业务流程自动化， 而是一个愿景，包括SAP构想的企业未 来的业务模式、员工工作模式以及客户 体验。通过端到端的集成、结合深入 的行业专业知识、把商业智能融入产 品，SAP智慧企业为企业实现了端到端 重构大型流程、增强企业智能、实时连 接产业价值链、简化IT运营、基于云的 加速创新等五大数字化转型的能力。智慧企业套件主要有三大特征：
流程简化，提供简化业务流程的实时 处理平台；
流程智能化，在业务流程中，引入预 测分析、机器人自动化等智能应用；
愉快的用户体验，提供用户简洁、一 致性的界面体验。
智慧企业套件最终目的是将用户从低附 加值的重复性任务中解放出来，以释放 生产力、通过人工智能辅助决策让用户 更专心在价值创造领域。
SAP智慧企业套件以场景化方式为企业 落地从五大维度的数字化转型解决方 案，切实把人工智能等技术与企业的实 际业务流程结合起来。其包括一个数字 核心和四大业务场景。
其中的数字核心即为SAP S/4HANA， 这是适用于25个行业内所有组织的智 能ERP，其简化的架构将实时数据转 换为智能洞察，推动更智能、更快速 的决策。同时基于HANA内存实时数据 库，S/4HANA可在本地内存中处理海 量数据，能显著降低数据处理时间，支 持云部署、企业预置型部署和混合模式 部署。
除了以SAP S/4HANA为企业数字核 心之外，SAP还整合了新发布的SAP C/4HANA以及之前陆续收购的采购云 Ariba、费用云Concur、人力资源管理 云SuccessFactors等行业云应用，再 结合SAP技术应用平台（SAP Business Technology Platform）及其承载的SAP 智能技术，这些为SAP所提出的智慧企 业打造了五大维度的能力：提供一流的 客户体验并重构业务模式；实时管理行 业价值链，推动生产力的逐步改变；使 员工能够利用数字技术实现更多价值。
2.2.2 智能技术
SAP智能技术包括人工智能，机器学 习，物联网和数据分析技术。其中又以 人工智能和机器学习对企业数字化转型 影响最大。因为智慧企业的未来就是逐 步以人工智能替代重复性的手工工作， 解放生产力。
机器学习算法本身并不是什么新鲜事， 但它们最近变得非常重要，因为我们所 处的时代，技术已经足够强大，能够以 一种高效和经济的方式利用它们，数字 经济开始以来产生的大量数据现在可以 用来训练机器学习算法以产生高质量的 结果。
市面上关于数字化转型产品、技术和服 务种类繁多，特别是最近两年来人工 智能热度的蹿升，很多厂商都声称能 够提供以人工智能为核心的数字化转型 解决方案。但其中不少厂商，要么是 新进入企业级市场领域，仅以单点技术 取胜而缺乏已有生态的支持；要么就是 来自于传统企业级软件领域，但在云和 人工智能等新兴技术领域的投资力度不 够。SAP则在企业端到端的完整解决方 案中皆融入了人工智能技术。
SAP“智能技术”构建于SAP业务技术 平台之上（ SAP Business Technology Platform）。SAP业务技术平台能够将 智能技术嵌入客户的核心流程中，支持 客户利用自己的数据，发现模式、预测 成果并提供行动建议。对于想要进一步 加速创新的客户，SAP将提供行业创新 软件包和开放式创新服务，支持利用设 计思维方法，构建行业特定的全新业务 模式。
SAP人工智能服务可支持客户开发自己 的应用，新增了物体检测、图形化文 字识别及文本分类等智能服务。SAP Conversational AI能帮助企业开发智能聊 天机器人，提供强大的端到端工具包， 用于训练、开发和监控聊天机器人。
同时，智能技术被嵌入到SAP的所有应用程 序中：例如，在S/4HANA、SuccessFactors 和SAP云平台中嵌入人工智能以预测结 果、缺陷或异常，和由人工智能支持的 机器人自动化，通过整合机器人流程自 动化、机器学习和会话人工智能技术， 减少手动任务，主动响应客户需求，并 制定更明智的决策。
最后，SAP HANA数据库本身也是智能技 术的体现，利用内存计算，为应用提供 高性能海量数据的高速处理。目前SAP 智慧企业套件的所有产品，以及数字平 台本身都是构筑于SAP HANA内存数据库 之上的。
2.2.3 SAP业务技术平台
SAP Business Technology Platform (SAP BTP) 是面向智慧企业的平台。借助该 平台，客户能够集成和扩展所有 SAP 和 第三方的应用及数据资产，化数据为价 值，从而提升敏捷性，实现卓越的业务 价值，并推动持续创新。此平台提供了 物联网接口、人工智能接口等智能技术 的应用和ERP功能扩展、为企业提供了 创新应用开发的平台。
SAP业务技术平台可以为企业智能ERP增 加以下功能特性：
易扩展：借助SAP业务技术平台，可以 快速将新功能添加到现有云和本地部 署ERP应用程序中，以对标准业务流 程进行扩展来满足特殊的业务需求。 功能扩展可以用Java开发，node.js和 ABAP语言。对于ERP，在SAP业务技 术平台中部署现有ERP的扩展功能可 以让实现“保持核心干净"，即Clean ERP理念，减少数字化转型的技术包 袱。同时满足确切业务需求。坚持 Clean ERP理念，可以让S/4HANA实例 轻松升级到更新的版本，并比以前更 快地使用SAP的创新功能。
易访问: SAP业务技术平台可以连接 云上应用和企业本地应用，消除数据 孤岛，使数字访问简单、安全、可扩 展。SAP业务技术平台将用户使用体验 作为一种服务提供: 通过SAP Fiori、门 户、移动应用程序，无论底层后台连 接的是什么应用，用户都可以借助SAP 业务技术平台，体验SAP特有的、一致 的用户交互界面。
易开发: 在SAP业务技术平台上，可 以容易的开发和运行新的云应用，业 务服务和API以解决新的业务问题和 需求，更方便的与新客户和新业务集 成，创造更多的业务价值。同时，SAP 业务技术平台支持多种开发语言，应 用可以使用JAVA，node.js和ABAP语言 进行开发。
易集成: 在不中断核心业务流程的情 况下，通过各种数字化集成工具提供 愉快的用户体验，促进创新。SAP业 务技术平台为云上应用和混合架构应 用提供数据和业务流程集成服务。通 过SAP 业务技术平台，云上和云下的 业务应用可以无缝集成，同时，SAP 业务技术平台提供了预配置的集成内 容，方便集成部署(包括预先配置的集 成模式和集成规则，以支持跨混合架 构的端到端业务流程)。
2.2.4 以SAP S/4HANA打造下一代企业数字化核心
作为下一代的ERP软件，SAP S/4HANA 可以完全胜任智能企业数字化核心的 角色。企业应该秉持双平台建设模式（ 数字化核心平台和数字化创新平台）和 Clean ERP的建设理念，在云端部署自己 的S/4HANA，并充分利用SAP数字平台 针对智能技术对ERP进行应用扩展，赋 予ERP创新功能和能力。
基于S/4HANA构建的企业数字化核心， 可以让企业与员工及客户、商业网络、 物联网、大数据等实现互联，运行快 速、智能且紧密集成的业务流程，实现 最佳运营。因此，无论扩展到哪个行 业、扩张到世界哪个地方、企业规模如 何增长，SAP S/4HANA都能帮助企业在 各条业务线上快速实现价值。正如2019 年 IDC 对 300 家 SAP S/4HANA客户开 展的调查发现，大部分的客户都可以通 过部署S/4HANA获得收益： (Source： IDC Survey: Customers Are on the Move to SAP S/4HANA ) • 55% 的受访企业能够利用数据更高效 地进行分析、预测或模拟。
51% 的受访企业即将或已经显著缩短 处理和使用信息的时间。
48.3% 的受访企业表示他们能够或将 能够快速实施新产品或服务。
48.3% 的受访企业能够或将能够通过 数字化方法提升效率和成效并采用变 革性业务模式。
3.1 如何规划S/4HANA转换
3.1.1 S/4HANA 转换项目实施路线图
通常我们会将S/4HANA 转换定义成两个 阶段，9个主要步骤。
3.1.1.1 探索与发现阶段
首先是探索和发现阶段，通常我们也 会称之为Phase 0阶段。这个阶段可以 看作是一个SAP ERP向S/4HANA转换之前的准备阶段，对于大型复杂企业来 说，ERP系统至关重要，对每个用户都 有影响，所以，用户和管理层都会关心 从SAP ERP向S/4HANA转换后对自己的 影响有多大，是否会为自己带来业务收 益，整体项目的周期需要多久，是否有 风险，什么转换方法最适合自己等等问 题。在有明确答案前，就启动S/4转换项 目会对企业和业务造成风险，所以比较 稳妥的方式是在正式启动S/4HANA转换 项目之前，对S/4HANA迁移项目可以带 来的业务价值、方法、风险进行评估， 然后基于这些发现去规划后续的迁移项 目，这样既可以让管理层明确风险和收 益，也可以让业务使用者明白项目对自 己日常业务操作的影响。
探索和发现阶段包括四个主要步骤。
在系统分析过程中，我们主要利用一些 S/4HANA转换前的评估工具，对S/4转 换产生的影响进行评估， 目前比较常 用的工具包括SAP Readiness Check工 具，同时德勤也有自己的分析工具的德 勤SAP S/4HANA升级分析器( Deloitte Platform Analyzer )帮助客户简化分析过 程，更方便获取需要的信息。
通过相关系统分析工具，识别出现有 ERP系统如果进行S/4HANA转换，哪些 业务、程序、接口会受到影响，以及未 来系统应该如何规划，所以系统分析阶 段主要包括以下主要分析工作：
目前系统中运行的组件和S/4 的兼容性；
系统内使用的业务流程影响范围；
自开发代码和接口影响范围；
S/4HANA转换后的部署模式和Sizing数 据库容量管理评估；
用户使用界面影响 （ Fiori APP替换传 统SAP GUI ）。
3.1.1.1.2 价值评估
ERP作为企业的核心业务系统，通常应 该系统保持稳定，而S/4HANA转换又 是一个非常大的变革，为什么企业要做 出这个变革，这个变革到底能为业务带 来多大的价值，这个是大部分企业在确 立S/4HANA转换项目之前需要回答的问 题。所以在探索与发现阶段，我们需要 分析S/4HANA究竟能为企业带来什么价 值。
对于价值分析，我们通常会引入一些 工具，例如，SAP的流程发现报告（ Process Discovery for SAP S/4HANA Transformation ），德勤也有相关工 具可以帮助用户探索S/4HANA带来的价 值，例如德勤研发的企业价值地图和商 业价值分析工具集。
SAP商业情景推荐报告可以根据系统中 目前使用的业务流程使用情况，与行业 KPI进行比较，判断目前系统业务流程的 效能状态，同时，根据S/4HANA的优化 功能，提供优化建议。
在价值评估阶段，也可以使用德勤价值 分析工具对项目价值进行论证。德勤 将S/4HANA核心功能和企业核心发展 价值进行了匹配，用户可以容易的发现 S/4HANA可以为企业带来哪些价值驱 动。同时，基于德勤的一整套商业价值 发现工具集，用户可以对S/4HANA的商 业价值进行论证和分析，得到更详细的 价值分析报告。
3.1.1.1.3 POC验证
在评估阶段，如果需要对技术风险有 一个更准确的评估，可以考虑进行一 次POC转换测试，通过POC测试, 对SA ERP系统在转换到S/4HANA过程中可能 遇到的技术问题有一个更准确的评估。
通过运行SAP简化项检查报表 （Simplification Item Check），可以发 现的S/4HANA转换对业务的影响范围， 评估需要投入的人力和时间去修复这些 影响。
由于测试环境的差异，POC转换测试虽 然不会得到最终准确的停机窗口时间需 求，但是通过POC，我们可以对系统切 换需要的停机窗口的有一个大致的预估 了解，以便合理的安排切换计划。
同时，POC测试过程中，SAP ERP在测 试环境中被升级到S/4HANA后，可以利 用S/4HANA中的自开发代码评估工具 (ATC Check)运行更详细的自开发代码升 级影响评估，基于ATC检查结果，更加 合理的安排和规划自开发代码修正需要 的人力资源和时间。
最后，POC验证可以帮助发现系统中存 在的历史数据问题，数据一致性问题是 S/4转换项目面临的最大挑战，这些一致 性问题需要今早发现并且在升级前得到 解决，提前运行POC验证，可以帮助我 们提早发现问题，并提早在现有系统中 进行修复。
3.1.1.1.4 规划实施
基于探索与发现阶段的前三个步骤，我 们会对S/4HANA转换项目有了更加具体 的了解，可以根据探索阶段完成的工作 量评估、风险评估、价值评估和技术难 度评估来规划如何落地S/4HANA转换项 目。在规划实施阶段，主要完成以下工 作：
制定项目范围和目标 （是否需要考虑 可选的业务优化功能实现）制定项目 预算和实施周期；
制定S/4HANA转型项目的高阶计划；
确定S/4HANA部署方式。
3.1.1.2 探索与发现阶段
在完成探索与发现阶段，对S/4HANA 转型有了详细的了解后，企业可以针对 探索阶段明确的转型方式开展对应的 S/4HANA转型项目。对于一些SAP系统 相对简单，转换难度低风险小、同时 S/4HANA带来的价值和目标也已经明确 的情形，企业也可以选择跳过探索与发 现阶段，直接开展S/4HANA转型项目。 对于一个S/4HANA转型项目，通常会进 行多轮的升级和测试，以确保整个转换 过程得到充分验证，所有的配置、数据 和代码问题都已经得到解决，才能确保 上线切换的成功实现。是一个典型 的S/4HANA转换项目的系统蓝图，包括 沙盒系统的转换，开发系统转换以及开 发系统转换后的双线维护工作 （ 同步旧 版本ERP系统中依然进行中的变更需求 到S/4HANA升级后系统环境进行验证）, 测试系统转换以及多轮的模拟切换测试 和最终的上线切换。
通常我们可以将系统转型阶段中的工作 划分为五个主要步骤：
3.1.2 SAP S/4HANA
部署方式 企业想转型S/4HANA，通常用三种不 同方式，分别是原系统转换（原系统升 级），选择性转换(包括空壳转换和混合 部署两种方法)， 以及重新实施。
不同的企业需要根据自己的实际情况， 选择适合自己的转换策略，是不同 的转换路径的功能特点比较，每个企业 都应该按照自己的实际情况选择最适合 自己系统环境、业务需求的转换路径。
3.1.3 如何选择适合的部署方式
对于S/4HANA部署方式的选择，通常需 要结合企业的系统现状和业务需求进行 综合考虑，我们罗列了一些关键的考虑 因素。
现在的业务流程是否符合企业的长期策略？
系统内现有业务流程和功能是否符合业 务需求和企业的长期发展策略，对于不 符合的业务流程需要考虑是否需要重新 设计，系统流程重新设计的范围和多寡 会影响部署方式的选择。
您的企业是否可适应SAP的最佳实践？或者您的企业倾向保留原来的客 制化配置?
若企业希望通过实施SAP标准最佳实践 为企业带来快速收益，则建议选择重新 实施的策略。如果企业希望保护历史投 资，保留现有的大部分客制化配置，那 么则需要考虑原系统升级或者选择性转 换的方式
转换至SAP S/4HANA的项目是由IT部门所发起？或者这是由业务需求而发起的项目？
若这是由IT发起的项目，通常我们会建 议您选择用原系统升级的方式转换至 SAP S/4HANA，因为业务部门往往不 希望自己日常的业务受到太多影响，而 希望系统保持稳定。所以并不建议在 S/4HANA转换项目中引入太多的新功能 变化，可以先完成S/4HANA的基本功能 转换，然后在此基础之上进行渐进式的 改善来满足业务未来的优化需求。
您的ERP版本是否支持直接转换到SAP S/4HANA，而不需要先升级到某个过 渡版本。
若您的企业目前使用的系统是SAP ERP 6.0以上的任何版本(并且是Unicode系 统)，那么一步到位完成SAP ERP转换到 SAP S/4HANA应是可行的。如果目前 系统版本较低，无法满足直接升级到 S/4HANA, 例如，需要先升级到过渡版 本ECC 6.0， 或需要先进行Unicode转 换项目，以满足S/4HANA转换的技术要 求，那么这种情况下，如果依然坚持原 系统技术升级，那么可能需要先规划一 个过渡版本的前置升级项目。这种情况 下，通常我们会更建议用户采用选择性 转换的部署方式，以规避现有系统版本 对S/4HANA转换的限制，降低项目周期 和复杂度。
您的企业公司是否需要将历史交易数据保留在新的系统当中？
若您的企业希望将历史交易数据完全保 留在新的系统当中，则您应考虑选择用 原系统升级的方式完成SAP S/4HANA的 转换。若您不考虑用原系统升级的方式 进行转换，希望采用重新实施、选择性 实施的方式，那您需要考虑将历史数据 保留在额外的系统中备查或者采取其他 的历史数据保留解决方案。对于选择性 转换和重新实施的部署方式，如果希望 保留所有历史数据，那将需要额外增加 历史数据迁移和迁移后对数据进行校验 的工作，相应的项目复杂度和周期也会 提升。
系统和业务流程全面整合是否为您的首要目标？
S/4HANA转换项目的目标是否是希望对 现有业务和流程进行全面优化和整合， 如果企业对于业务流程改造的诉求非常 强烈，说明现有系统对业务和企业发展 的支持不理想，那么我们更倾向于建议 您选择用重新实施的方式达到全面系统 或流程整合的目标。将相关系统的业务 数据、业务流程重新设计并部署到全新 的S/4HANA系统中。
现有系统与外部系统(SAP和第三方系 统)接口的的数量多寡？
若现有系统与外部系统接口的数量较 多， 则意味着重新设计系统的复杂度 和成本会比较高，而保留历史投资，继 续沿用这些外部系统的接口往往是比较 经济的一个选择。这种情况，原系统升 级和选择性转化可以更好地保护历史投 资，复用现有的接口和自开发程序。
您的企业是否能接受长期的渐进式系统转换？
S/4HANA提供了大量新的业务功能， 但是这些功能很多都是可选的，并不是 强制使用，这也就意味着，在执行了 S/4HANA转换后，只有一些S/4HANA的 基础功能被激活了，而大量的增值功能 依然没有被启用，用户依然有选择权是 否需要通过S/4HANA转换项目一次性激 活所有S/4HANA创新业务功能，还是更 愿意分批次逐步激活创新功能以减少转 换成本。
若渐进式的系统转换符合您的企业文化 和价值，我们就建议您用原系统升级或 者选择性转换结合一连串创新的项目来 进行并完成SAP S/4HANA的转换，这种 方式将可以满足您的企业渐进式转换的 需求。若您希望通过一次项目，解决企 业所有的问题和需求，将S/4HANA的 所有创新功能一次性激活，那么我们会 建议您选择用重新实施的方式完成SAP S/4HANA的转换。
您的企业是否对项目其他特殊要求？
部分客户希望在S/4HANA转换项目中同 时完成组织架构和系统的拆分或合并， 又或者希望系统切换实践尽可能短，实 现类似"零停机"切换的目标等，这些额 外的需求都会影响部署方式的选择。
德勤基于部署方式决策要素绘制的决策路径图，基于不同的条件因素， 辅助用户选择正确的S/4HANA部署方 式。
3.2 准备S/4HANA迁移
在开始ERP 向S/4HANA转换之旅前，企 业可以先进行一些准备工作。既可以对 S/4HANA部署的可行性有一个了解，也 可以通过必要的准备工作，了解转换要 求的技术或业务前提条件。
3.2.1 就绪性检查(Readiness Check)
SAP S/4HANA就绪性检查是一个免费 的在线工具，可以帮助用户规划向SAP S/4HANA的转型，该工具自2017年6月 起提供，对于每个拥有有效SAP支持协 议的客户都是可以免费使用的。
通过该工具，您可以对S/4HANA转换 前，ERP系统需要做的准备工作有一个 概览性的了解，同时也介绍了S/4HANA 对现有业务的影响范围，以便评估 S/4HANA转换的工作量和复杂程度。
3.2.2 S/4HANA 流程发现
2021年，SAP发布了新一代S/4HANA 业务场景推荐工具：S/4HANA流程发 现工具 （Process Discovery for SAP S/4HANA Transformation），通过这个 免费的在线工具，您可以获悉S/4HANA 的哪些业务场景是和您的业务密切相 关，并且可以为业务效能提升带来帮 助。S/4HANA流程发现工具，可以帮助 用户回答以下问题：
为什么要从SAP ERP转换到 S/4HANA?
S/4HANA可以为我的企业带来什么 帮助，不同的业务线可以获得什么收 益？
哪些S/4HANA的创新功能是和我的业 务密切相相关的。
该工具类似就绪性检查，拥有有效SAP 支持协议的客户都是可以免费使用的。 通过从现有SAP ERP系统中抽取必要数 据并上传到该工具中进行分析比较， 生产报告。该报告将把现有SAP ERP系 统内的业务效能与行业KPI指标进行比 较，给出现有业务流程效能的分析，同 时结合S/4HANA的创新功能，给出业 务效能提升的建议。让您可以直观的了 解，S/4HANA可以为业务带来的价值。
S/4 流程发现工具首先会对SAP ERP内现 有业务流程运行效能进行分析:
在获得现有业务运行的KPI后，该工 具会结合S/4HANA创新功能给出建 议，S/4HANA将如何帮助企业提升业务 运行效能。
3.2.3 系统代码清理
基于构造"Clean ERP"的理念。建议在 开始S/4HANA转换项目前，通过SAP Solution Manager工具对现有SAP ERP内 的历史投资进行清理，降低系统技术包 袱，使得ERP具有Clean ERP的属性，同 时，也可以让S/4HANA转换过程变得更 加轻松, 同时也可以兼容向S/4HANA私有 云版本、公有云版本的转换。
现有系统内的技术包袱包括系统内非必 要的自开发程序、标准程序增强、自开 发报表和报表以及过时的业务需求。可 以借助SAP Solution Manager的自开发代 码生命周期管理功能（ CCLM: Custom Code Lifecycle Management ），收集这 些技术投资的使用频率，同时对系统内 不再使用的自开发代码和程序进行清理 和删除，如果系统中的自开发代码数量 越多，也就意味着S/4HANA转换过程中 要修复和测试的工作量越大，应该在开 发S/4HANA转换项目之前，就开始自开 发代码的清理工作，将不再被使用的自 开发代码从生产系统里删除，进而降低 系统转换的复杂度和工作量。
Solution Manager的CCLM功能收集的自 开发程序使用频率数据除了可以用来做 代码清理外，还可以作为代码迁移范围 的筛选条件，通过S/4HANA内置的ATC 代码检查工具（ ABAP Test Cockpit）对 S/4HANA系统技术升级过程中的代码迁 移范围进行筛选，排除不需要迁移的自 开发代码。
3.2.4 数据清理和归档
对于拥有大量历史数据的SAP ERP系 统，如果计划的S/4HANA的部署方式 是原系统转换，那么这个转换过程的复 杂度和需要的业务停机时间都会很久， 复杂度高是因为在升级前，需要对历史 数据进行核对，解决历史数据中不一 致的数据问题。而数据量越大，技术 升级的停机转换时间也会越久，需要 将ERP内的历史数据从传统模式迁移到 S/4HANA的创新业务模式中。所以在开 始S/4HANA转换项目之前，建议对系统 内的数据进行清理，对数据容量进行瘦 身，降低系统转换的复杂度。梳理系统 中最大的TOP表，以及增长速度最快的 表，分析数据增长的原因和可能的数据 清理和减少的手段。
技术表的清理
对于系统日志表、应用日志表、spool表 等技术相关的表，建议开启对应的日志 清理后台作业，定期对这些技术表进行 删除清理。
业务表的清理
业务表的增长可能是由于配置或现有流 程设计不合理导致，需要考虑是否可 以改变业务模式，以减少数据的产生规 模，如果短期不可能改变业务模式，那 么可以考虑对对应业务数据表进行归档 作业。
Solution Manager 数据容量管理功能
建议激活Solution Manager数据容量管理 功能 （ Data Volume Management）,该 功能可以从ERP抽取数据容量数据并进行 分析，同时给出数据容量减少建议，包 括如何避免产生大量某类数据对象和如 何归档某类数据对象。同时会给出初步 的归档效果分析，让我们对数据归档的 效果有一个预期。是一个DVM分析 报告的截取部分，对系统中的TOP表进 行了总结和并对数据归档后的容量进行了预估。
3.3 HANA转换技术实现
3.3.1 S/4HANA不同版本选择
S/4HANA 目前有三个主要版本，包括公 有云版本、私有云版本、预置型版本。 企业可以根据自己的实际需要选择适合 的版本进行部署。不同的S/4HANA版本 都具有统一的代码、统一的数据模型、 统一的用户体验。公有云版本和和私有 云版本都是基于SaaS服务的云ERP，预 置型版本是以软件包的形式交付给客 户，客户可以按照自己的需要，部署在 IaaS云供应商平台上，或者部署在自己 的本地机房中。
我们为准备通过新的实施方式和预定义的 内容来拥抱ERP未来的公司提供的战略选择 旨在提供创新和云价值，同时允许客户通过转换 其现有系统和/或接管配置和数据来保留其投资 适用于需要最大程度地控制ERP系统的 客户的创新型智能ERP，通常是在自己 的数据中心或与现有IaaS合作伙伴云端部署，可以降低设备的采购和维 护成本，同时还可以按照业务的发展 按需扩展资源，符合智慧企业对ERP可 扩展的要求，所以基于智慧ERP的建设 理念，德勤建议用户逐步将传统本地 机房部署的SAP向公有云S/4HANA、私 有云S/4HANA、部署在IaaS云平台上 的S/4HANA版本进行迁移。同时，应 尽可能坚持Clean ERP的原则，减少在 SAP S/4HANA上的非必要开发，确保 企业的数字化核心可以兼容不同版本的 S/4HANA，可以在不同环境中进行灵活 迁移和部署。
不同版本的S/4HANA在功能范围、使用限 制和运维管理上也存在一些区别，通常来 说公有云版本对软件的扩展性和代码的修 改具有严格限制，如果用户希望可以任意 定制、二次开发自己的ERP产品，建议选 择私有云版本和预置型版本。 如果企业目前已经使用了SAP ERP产品， 在考虑S/4HANA转型的部署方式时，如果 希望可以迁移到S/4HANA 公有云版本， 那么只有重新实施的部署方式可以选择， 目前并没有工具支持SAP ERP向公有云版 本S/4HANA的直接转换。如果计划使用 S/4HANA私有云版本或者在IaaS云上安装 S/4HANA预置型版本，那么系统转换和选 择性数据迁移都是可以选择的部署方式。
3.3.2 重新实施方式
当企业希望彻底重新设计自己的业务流 程和数据，以满足业务需求或者企业 长期发展的需要，并使得ERP满足智能 ERP的Clean属性，又或者企业想从传统 SAP ERP转换成S/4HANA公有云版本， 以降低总体拥有成本，降低运维复杂 度，那么重新实施是合适的S/4HANA部 署方式。
重新实施的部署方式让我们有机会重新梳 理业务需求，并且更急业务需求重新设计 系统，可以不受现有系统内的数据、流 程、配置和代码的限制，完全重新设计。
重新实施通常不考虑历史数据的迁移，只 会通过SAP数据导入工具对主数据和期初 数据进行导入, 这种方式不需要对历史数 据进行清理，降低了数据转换的工作量和 复杂度。历史数据如果需要可以依然保留 在原SAP ERP系统中进行查询。
目前重新实施可以使用的数据导入工具 包括SAP Migration Cockpit 和基于SAP Data Service的RDM工具 (Rapid Data Migration)，德勤也在现有SAP标准工具 的基础上进一步开发了D-DASH数据迁移 平台，在SAP RDM工具的基础上丰富了 更多的功能和内容，加速和简化S/4HANA 期初数据导入的效率。
3.3.3 系统转换方式
如果企业希望可以保留所有历史数据， 并且希望减少S/4HANA转换对业务产生 的影响，尽可能保留现有业务流程，那 么系统转换是建议的S/4HANA部署方 式，该方式支持将企业机房本地部署的 SAP ERP转换成S/4HANA， 同时也支持 将企业机房内本地部署的SAP ERP直接 迁移&转换到S/4HANA私有云版本。
系统转换的过程大致可以分为两个阶段：
第一个阶段为系统准备阶段，该阶段主 要为S/4HANA技术升级做准备，包括 检查组件兼容性，检查数据一致性，检 查系统配置问题，激活S/4HANA升级必 须要的配置（ 例如BP数据同步， 激活 MRP 区域等）。
第二个阶段为实现阶段，这个阶段SAP ERP正式开始转换工作，SAP 升级工具 SUM DMO会负责将SAP ERP版本进行 升级，同时完成数据库向HANA的迁移 和数据模型的转换。当升级工具完成技 术升级后，开发顾问需要对受升级影响 的代码和程序进行修复，业务模块顾问 需要在升级后的系统中开展配置和数据 的迁移调整。
S/4HANA的转换过程由SAP SUM DMO 工具完成，该工具可以在一次转换动作 中完成多个任务，包括：
软件版本升级到S/4HANA；
数据从其他数据库迁移到SAP HANA 数据库；
将SAP ERP数据模型和数据转换到 S/4HANA数据模型；
结合System Move选项，可以实现SAP 应用服务器的迁移 ，例如跨数据中心 迁移、 本地部署迁移到云上部署，本 地部署ERP向私有云S/4HANA转换。
3.3.4 选择性转换方式
当企业希望保留历史投资，沿用现有 ERP系统内的部分流程，但是又希望借 助S/4HANA转换的机会，激活部分新 业务功能、改造部分过时的业务流程， 又或者在S/4HANA转换的同时进行一些 组织单元进行拆分合并的工作， 那么 选择性转换的部署方式通常是比较好的 选择。
选择性转换通常只会像重新实施一样导 入主数据和未清数据，通常不建议导入 历史数据，因为部分或全面的历史数据 导入，需要数据导入规则的制定、导入 工具的调整，以及导入后数据的校验。 如果企业想在系统转换的同时保留全部 历史数据，建议优先采用系统转换的部 署方式，以降低迁移过程的复杂度。
选择性转换方式有两种实现方式：
3.3.4.1 空壳转换
如果现有ERP系统内大部分业务流程希 望保留，那么建议使用空壳转换的方式 实现。空壳系统即不含业务数据，只包 含业务配置和自开发代码的系统，然 后通过SAP SUM DMO对空壳系统进行 升级转换，该过程要比完整ERP系统的 S/4HANA升级难度低很多， 因为没有 历史数据，降低了数据转换部分的工作 量，减少了包括数据一致性修正，数据 迁移、数据转换和数据校验等工作。
在空壳系统升级到S/4HANA后，需要 在空壳系统中进行配置调整和代码修 复，同时可以实施一些新业务流程和 新功能。当功能测试通过后，下一步工 作就是数据导入工作，类似于重新实施 的场景，选择性转换通常只需要导入主 数据和未清数据，我们可以通过SAP标 准S/4HANA数据导入工具- SAP RDM和 SAP MC进行数据导入，也可以利用德勤 D-DASH S/4HANA数据导入平台进一步 加速和优化数据导入过程。
3.3.4.2 混合部署
如果当前ERP系统中仅小部分流程希望 得到保留，大部分的流程希望重新设计 和实施，那么空壳系统升级就不适合， 因为空壳升级后，大部分的流程和配置 都不是我们的目标流程，需要删除和修 改，这种情况下，混合部署模式是更好 的选择。
混合部署的方式是通过安装一套全新的 S/4HANA系统，并基于业务需求重新设 计大部分业务流程，仅通过手工重新配 置/传输的方式同步部分旧系统配置、 流程到新S/4HANA系统中去。旧系统 的配置和流程既可以手工重新配置到 S/4HANA系统中（ 通常需要有经验的顾 问进行操作）。也可以将旧版本ERP系 统先通过空壳转换到S/4HANA版本后， 再通过传输机制将需要保留的配置到同 步新安装的S/4HANA系统中去。
4.1 如何降低ERP 运营成本
4.1.1 传统IDC建设SAP的成本
基于传统IDC建设SAP的TCO首先要考虑 直接成本，其中资本性支出Capex主要 由硬件成本、网络成本、软件和服务成 本、基础设施成本组成，运营费用Opex 主要由人力成本和运维成本组成。除了 这些显性成本，还需要考虑规模成本和 风险成本等隐性成本，比如升级、迁 移、扩容等与IT规模相关的活动引发的 额外成本，再比如为了满足监管与合规 要求，防止数据丢失，提高系统可用性 同样需要大量成本投入。最后，传统IDC 的一次性资金投入，也是企业需要关注 的风险因素。各部分的成本进一步细分。
4.1.2 云上建设SAP的成本
与传统IDC不同，云上建设SAP的成本模 型包括云运行成本和一次性安装成本， 而最终目标结果——云上建设SAP的总 成本（TCO）为运行成本和一次性安装 成本的加和。
其中，运行成本等于云基础设施成本加 上云后的新增使用成本，每部分的详细 含义如下：
云基础设施成本
服务器/容器；存储；网络；数据库；中间件；许可证。
新增使用成本
数据传输；额外链接；监控收费；云上SAP开发；企业支撑。
成本模型中的另一部分——一次性安装 成本等于建设成本和迁移成本的加和， 每部分的详细含义如下：
建设成本
公有云网络连接；云安全工具；云监控和管理工具；云迁移工具；实施成本。
迁移成本
SAP云上管理组织；SAP迁移；运营模式变更；人才和技能提升。
4.1.3 SAP上云总体持有成本（TCO）分析
SAP上云的TCO本质上不是一个可以通 过完全量化的指标来衡量的工作，但通 过以下三个途径，CIO与CFO之间可以就 SAP上云的TCO进行融合了准确量化和可 信判断的分析。
1、使用云服务商所提供的TCO计算 器，如阿里云的TCO计算器（https:// tco.aliyun.com/），从服务器、存储、 交换机、带宽、人工等方面对现有服务 器集群进行TCO分析，并融合折旧年限 和软件成本、年化资金成本、容灾和迁 移扩容成本等影响因素。
2、为SAP支出设计3-5年的成本支出路 线图：基于第一性原则，拆分SAP建设 支出中占比最大的主要成本来源，将 其与云上产品进行一一对应，结合其支 出情况、折旧年限、规模复杂度等影响 因素，设计可供对比的长期成本支出 路线图，以确定核心支出是否能够受益 于云。
3、在进行SAP上云的TCO分析时，如 果可以说服CFO和COO参与到TCO和 ROI评估中，应当将新的财务计划与企 业发展战略联合，充分考虑到云计算按 需使用、按需付费、支出灵活的特点（ 特别是云服务支出入费用，企业级客 户通过长约获得优惠，比资产平摊费更 低），以及从Capex到Opex的转换等 方面的优势。
4、需要指出的是，并非所有的云服务 都能带来CFO们所期望的弹性和按使用 计费的特性，比如SaaS则一般是按用 户数来收费，并且需要签署长期服务协 议，很难达成随用随停的目的，通过 财务的手段实施上云战略层面的操作， 一个非常重要的工作是具备数据分析能 力，将来自上云的原始数据碎片整合成 有效的数据信息，融入公司战略中。
4.1.4 成本视角的SAP上云价值
前文所述，基于传统IDC建设SAP和SAP 上云的成本核算具有不同的计算方式， 但两者的区别不仅仅在于核算的方式。 在实践中，基于传统IDC建设SAP有诸多 成本方面的挑战：
基础设施资源的消耗是波动的、周期 性、或者完全没有规律的；
因为上面的原因，通常基础设施采购 量是实际需求的2-3倍，需要数周/数 月的时间进行采购。 结果就是，基础 设施的能力在大多数情况下都未得到 充分利用；
较高的固定成本导致总成本（TCO） 既包含资本支出（CAPEX），又包含 运营支出(OPEX)；
资源的提供需要很长的时间，必须由 特定的团队完成，造成额外的时间和 人力成本；
基础设施资源的采购是一个耗时的过 程，阻碍了业务快速创新，增加了创 新成本。
相对的，SAP上云从以下几个方面应 对挑战：
无需固定成本。企业只需要根据需求 支付必要的基础设施成本；
按使用量付费。企业根据基础设施资 源使用情况支付运营费用；
更快的创新。使用公共云服务商提供 的快速迭代的创新功能，降低创新成 本；
即时资源调配。云基础设施可以在数 秒/分钟内配置完毕，提高了业务相应 速度。
综上，企业在云上建设SAP，改变了 成本核算的模式（从CAPEX转化为 OPEX），避免了资源的浪费，同时加 快了业务创新
4.2 S/4HANA 云端架构
对于”动成长企业”来说，在部署设计 S/4HANA落地的技术架构的时候也应该 面向未来，设计一个能够支撑未来5-10 年乃至更久的架构，来支撑未来可以预 见及那些不可以预见的需求的变化，使 我们的系统能力可以随着企业的“成 长”而“成长”。
4.2.1 S/4HANA云端系统架构设计
一般公共云都会在基础设施中设计有大 量的冗余措施，以保证为用户提供承 诺的SLA（服务级别协议），例如阿里 云公共云的ECS（弹性计算服务）承诺 单实例可用性为99.975%，多可用区多 实例可用性99.995%，云盘可靠性达到 99.999999%，相较于线下传统的IDC一 般都会有更好的可用性保障，不过考虑 到SAP S/4HANA作为一个企业的核心系 统，为了保证足够的业务连续性，我们 还是建议您根据自身企业对于系统的连 续性要求，在云端设计更加符合您公司 的系统架构。
公共云厂商一般会在全球拥有多个数据中 心，以满足不同用户在系统架构设计过程 中的需求。以阿里云为例，当前阿里云在 全球拥有23个数据中心69个可用区（截 至2021年2月14日），并且借助于阿里 云的『全球一张网』，数据中心或者可用 区之间的网络可通过高速通道进行快速打 通。所以，您可以在云上快速部署例如： 同城高可用、同城灾备、异地灾备甚至跨 境灾备等多种系统架构。
无论是SAP系统，还是其他IT系统，企业 在规划业务系统的备份恢复、高可用及 容灾方案时，需要明确两个核心指标：
RPO（Recovery-Point-Objective）： 直译为目标恢复点。该指标定义业务 系统发生故障或灾难后进行数据恢复 时要求恢复到的时间点，即定义了可 以容忍的数据丢失量。IT系统的数据 对企业业务越重要，RPO 就要求越 小，RPO越高，对数据备份的频率要 求更高、对数据复制要求的实效性就 越强，对业务系统ECS实例计算性能、 云盘性能以及网络带宽的要求也越 高，系统压力也会越大，成本通常也 越高。SAP系统，尤其SAP ERP，SAP S/4HANA等生产系统一般为企业的 核心系统，RPO时间一般为零或接近 零。
RTO（Recovery-Time-Objective）： 直译为目标恢复时间。该指标定义业 务系统发生故障或灾难后，业务系统 的数据恢复到RPO定义的时间点并且 业务系统技术上重新上线可用所需的 时间。业务系统故障后，单位时间内 对企业业务造成的损失越大，RTO 就 要求越短。RTO时间越短，对业务系 统的可用性要求就更高，就需要采用 更自动化的方案确保系统在发生单点 故障（SPOF）时可用性不受到或仅 受到有限影响。SAP生产系统，企业 根据自身业务要求，RTO可能从从数 分钟到数天不等。RTO规划在分钟级 时，SAP系统需要做高可用规划。
RTO、RPO 一般由业务部门提出要求， 与 IT 部门共同商议，基于技术可行 性、对现有系统影响、成本等多方面综 合考量综合得出。RTO、RPO 标准的高 低与基础设施成本往往有线性关系。
企业客户可以参考国家和行业标准来 制定 RTO、RPO 目标。GB/T 20988- 2007标准是中国国家标准化管理委员 会制定的信息系统灾难恢复规范。
而RTO/RPO在企业不同阶段，要求也 会不断变化，所以不同阶段需要调整不 同的架构以适应新的更高的需求。
不同架构的S/4HANA在云端部署
单节点部署：
单节点部署可以利用阿里云的“宕机自动迁移”来保证整体系统的可用性， 宕机自动迁移属于阿里云ECS默认特 性，ECS实例的底层硬件意外崩溃的情 况下，阿里云通常会在一分钟内确认故 障是否不可逆并且实例是否无法修复， 并且在大约五分钟内自动重启实例实现 宕机迁移，因此相较于线下，在阿里云 上部署的S/4HANA即便是单节点部署， 当底层硬件发生故障时，S/4HANA还是 可以在较短时间内恢复并对外提供服务 （应用层面的重启需要用户手工介入或 者配置成开机自动启动）。宕机自动迁 移一般只针对ECS底层硬件故障进行保 护，操作系统或者应用层面的异常则需 要通过采用高可用部署方案进行保护。
高可用部署：
在阿里云上S/4HANA的高可用主要通过 SUSE HAE来实现，通过HAE判断某个 资源不可用以后自动切换到备节点，以 达到更高的系统可用性，整个原理与线 下部署的高可用类似。相较于阿里云的 宕机自动迁移，高可用部署可以从软件 层面提供更高的保护级别。对于生产环 境的S/4HANA在预算允许的情况下建议 采用高可用部署架构，来满足生产环境 更高的可用性。
容灾：
容灾一般包含数据容灾及应用容灾两个 方面。数据容灾在线下一般通过将关键 数据备份，数据以离线方式保存在异 地，以保证主节点在受到自然灾害或者 计算机病毒入侵时异地备份的完整性可 用性。应用容灾一般在数据容灾的基础 上在异地建立一套与主节点相当的备份 应用系统，整体设计除了保证数据复制 之外，还需要包含网络、主机、应用等 资源的可用性，以便再真正需要切换的 时候备节点能立即接管所有由主节点切 换过来的系统负载。整体硬件投入、网 络投入以及运维人员投入均比较大，并 且建议进行周期性演练。
S/4HANA作为企业的核心系统，设计一 套容灾环境是非常有必要的，但是一般 S/4HANA项目实施需要公司内部大量人 员参与，而容灾设计又同样是一个复杂 的项目，容灾项目与S/4HANA实施项目 并行实施对于企业内部技术人员的精力 占用比较大，建议通过云上部署来降低 容灾投入。
HANA数据库常见的容灾方案采用HANA 自带的System replication功能实现，容 灾的数据库服务器需要一直开启运行， 在云上结合云的弹性与灵活性灾备节点 可以通过采用更低配置的ECS实例优化 支出。S/4HANA容灾系统的应用服务器 配置完成后可以使用按量付费停机不收 费的方式进一步节省费用。在进行真正 灾备切换的时候可以通过临时升配网络 带宽、ECS实例配置即可快速接管主节 点的系统负载。
上述容灾方案并非唯一设计方案，例如通过阿里云用于备份HANA数据库的 HBR混合云备份服务的容灾备份功能， 同样可以实现异地容灾（RTO/RPO会 有所不同）。
4.2.2 S/4HANA云端部署地域和可用区的规划
“动成长企业”在每个发展阶段对于系 统的要求也不尽相同，因此在规划地域 和可用区时，需要考虑如下因素：
地理位置
推荐企业就近选择靠近目标用户的地 域，以便减少网络时延，提高用户使用 体验。中国大陆地区，不同地域的基础 设施，BGP网络品质，资源操作和配置 方法区别一般不大。
云产品能力
基础云产品（ECS实例，VPC网络，存 储，数据库服务等）在中国大陆地区不 同地域的能力基本相同，个别新成立 的地域和可用区可能略有差异。如果 部署的系统或解决方案需要特别的云 产品支持以实现必须的特性（如高可 用），则需提前确认对应的地域及可用 区是否有能力提供该类云资源。
资源价格
除云产品能力外，不同可用区的资源价 格可能有所差异，例如阿里云张家口 与乌兰察布数据中心由于整体运营成 本较低，所以部分产品的价格也相较 于其他的地域更优惠。
业务安全合规性要求
由于受到法律法规的要求，一些保存 有敏感数据的系统可能必须部署在 某个地理边界之内（如中国大陆），或 必须部署在符合一定等级保护的环境 （如等保四级区域）。
规划运行S/4HANA系统的地域和可用 区，除了要考虑上述介绍的地理位置， 云产品能力，资源价格，业务安全合规 性等因素之外，还需要考虑如下因素：
SAP认证ECS实例规格
阿里云不同地域和可用区提供的SAP 认证实例规格可能有所不同。
阿里云上初次规划SAP系统时，在确 认当前地域和可用区能够提供所需的 SAP认证实例规格的同时，也要考虑 该地域和可用区能否提供未来1～3年 SAP系统（尤其是SAP HANA数据库） 垂直扩展升变配所需的SAP认证ECS 实例规格。
SAP系统的网络时延、高可用以及容灾需求
网络时延（Network Latency）
一个典型的SAP系统具有三层架 构，分别是展示层（Presentation layer），应用服务器层（Application Server layer）以及数据库层 （Database layer）。
应用服务器层和数据库层之间要求 具有极低的网络时延，在阿里云上建 议部署在同一可用区内。
展示层是企业用户使用SAP图形化 客户端（SAP GUI或者NetWeaver Business Client等），或者Web浏览 器访问SAP系统的终端，根据企业用 户所处的不同的地理位置，除就近 选择地域和可用区之外，还需要考虑 使用合适的接入方式连接办公网络 到阿里云网络上。
是否使用SAP（SAP Cloud Platform）提供的PaaS服务，以及 SAP提供的其他SaaS服务
SAP PaaS云平台（SAP Cloud Platform）
SAP云平台（SAP Cloud Platform） 中国版于2019年9月正式落地阿里 云，并部署在阿里云华东2（上海） 地域。详情见SAP官网链接：https://
help.sap.com/viewer/65de297720 5c403bbc107264b8eccf4b/Cloud/ en-US/350356d1dc314d3199dca1 5bd2ab9b0e.html
SAP SaaS服务 – SAP各个SaaS服务在中国的数据 中心位置见SAP官网链接：https://
www.sap.com/sea/about/trustcenter/data-center.html
Data Center Locations -> Find your Data Center -> Search by Region -> Asia
如果您的SAP解决方案现在或者未来 需要集成或者使用SAP云平台提供的 PaaS服务，或者SAP提供的其他SaaS 服务，在选择阿里云地域时可以考虑 部署在临近SAP PaaS/SaaS服务所在 的地域，以获得相对较好的公网网络 延时，增强用户体验
4.2.3 S/4HANA云端网络接入规划
将S/4HANA部署在云上以后，一般都会 有比较多的网络接入方式可供选择，这 也大大降低了SAP项目前期投入，快速 推进项目进行。SAP实施的项目的范围 一般是随着项目推进逐渐覆盖，例如按 照业务板块覆盖，或者先标杆工厂后向 外展开（Roll-out）到其他工厂。在项目 启动第一时间，并不需要将网络接入覆 盖到所有地方，或者前期某些工厂办公 点涉及的最终用户人数比较有限，完全 可以采用成本较低、实施较快的接入方 式来完成。
阿里云针对不同的使用场景有不同的网 络产品来进行覆盖：
SAG智能接入网关 SAG智能接入网关是阿里云基于云原生 的SD-WAN解决方案，利用阿里云的网 络基础设施能力给客户提供快速接入组 网的能力。
SAG智能接入网关分为 硬件版、软件 版。
硬件版本为CPE设备形态，适用于站 点site-to-site接入，可以支持专线、宽 带、4G接入。
软件版分为VCPE镜像形态的用于站点 site-to-site接入，可以帮助打通没有硬件 部署环境的数据中心之间的网络（例如 阿里云与其他云厂商之间的网络链接） 以及APP形态，一般用于point-to-site接 入，例如移动端、办公电脑等，可以支 持主流的操作系统。
物理专线接入
阿里云数据中心也支持物理专线的接 入，用户需要自己联系运营商提供待接 入点的详细地址，实际进行工勘后确定 是否可以接入，整个周期根据不同状况 会耗费大概一个月左右的时间完成。一 般核心节点或其他有大量数据交互需求 的节点与阿里云采用专线接入方式。
VPN网关
阿里云也提供VPN网关的方式进行接 入，支持IPSecVPN与SSL VPN两种方 式。
以上几种场景在接入阿里云以后都可以 访问到云端的S/4HANA，并且借助阿 里云CEN，可以将接入的所有点之间打 通，形成一张以阿里云为中心的全互联 企业内网。企业可以根据自身情况选择 适合自己的接入方式完成接入阿里云以 及您的组网需求。
4.2.4 S/4HANA云端服务器配置的规划
S/4HANA只有部署在经过SAP认证过的 硬件上才能得到SAP的官方支持，全球 主要的几家云厂商均有通过SAP认证的 实例来部署S/4HANA，以阿里云为例， 阿里云截至白皮书发布日期可提供针对 于HANA从256GB到6TB的ECS实例来满 足S/4HANA的部署。
S/4HANA在线下部署与云上部署从硬件 配置的规划上的不同点
线下部署
一般来说，由于线下物理服务器的可扩 展性相对来说比较一般，硬件升级一般 会伴随着系统迁移或者硬件兼容性测 试，所以会需要较长的停机时间与人力 投入，因此企业在采购线下物理服务器 时会考虑采用满足较长一段时间内的硬 件配置。
云上部署
云上服务器的配置升级相较于物理服务 器有天然优势。公共云上整个服务器配 置升级过程都可以做到服务器重启即可 完成配置升级，例如阿里云的HANA ECS 实例可以平滑支持跨不同代CPU实例升 级、虚拟机到裸金属服务器的平滑升级 等。所以在云上的ECS实例配置的选择 与线下部署方式也有所不同。
以往企业IT人员在评估S/4HANA对于服 务器配置的需求，会考虑到未来可能的 S/4HANA系统使用范围、实施模块、 企业自身业务变化（例如业务量急剧上 升、企业并购、企业经营范围变大等） 多种因素而采购五年后可能才能使用到 的服务器配置，而且上述几个比较容易 变化的因素很难被准确预估，大部分时 候，所购买的服务器会因为不贴合实际 系统负载造成浪费或者硬件提前升级所 带来的额外支出。
S/4HANA的存储设计规划
一般来说一套S/4HANA系统中HANA数据 库的存储使用量较大，以往线下一体机 由于存储扩容相对来说较为复杂，因此 在配置初期就需要根据整个一体机生命 周期内可能会采用的所有的磁盘容量进 行一次性配置。磁盘的IOPS对于HANA 运行效率也会有较大影响，需要采用较 高性能的存储，整个投入也非常可观。
阿里云块存储支持在线扩容能力，因此 前期如果受限于项目预算，可以采用较 小的容量，未来需要的时候进行在线扩 容也将是一个不错的选择，另外考虑到 未来扩容以及性能上最优，建议前期部 署时在操作系统层使用LVM将多块云盘 合并成为一个VG，并在划分LV时使用 LVM条带化。
阿里云上块存储拥有在线扩容能力以 外，也可以对块存储的性能快速升级以 满足未来系统对于更高存储性能的需 求。
4.2.5 网络安全设计
网络安全设计首先要根据云上系统不同 的业务属性，划分为不同安全级别的多 个区域，进行网络隔离和访问控制。 根据访问需求，配置CEN路由策略， 对于云上业务的访问控制，通过VPC和 VBR，CCN的路由策略实现。网络ACL 作为补充。对于线下自有数据中心的业 务访问控制，通过VBR和VBR，CCN和 VBR，CCN间的路由策略实现。
4.3 云端业务集成服务
德勤的集成服务框架
德勤建议使用集成服务框架连接核心业 务（如S/4HANA）和创新业务（如SaaS 和第三方应用）。德勤的集成服务框架 已在全球客户中被充分利用和体验，用 以提供整体战略、目标愿景和成功路线图。它主要由商业体验、赋能服务、服 务和集成层、组织赋能四大部分组成， 其中后三者又组成了集成服务生态系 统。
商业体验。通过定制化的体验实现快 速创新，包括：
合作伙伴生态系统。通过集成服务框架不断积累和培养合作伙伴，相 互支撑与共生，形成合作伙伴生态 系统。
消费者体验。集成服务产生创新解 决方案，解决消费者痛点，提升相关 体验。
员工体验。集成服务产生创新解决方 案，解决员工工作中的痛点，提升相 关体验。
数字产品。集成服务形成创新数字 产品。
赋能服务。实现无缝和安全的集成 流，以赋能当前主流平台；实现自动 化和标准化，供重复使用。赋能服务 包含：
微服务参考体系结构。微服务是实现数字业务的方法，应该进行规模化 的治理。
运营管理。确定基于SOA的核心服务（发布者）和网关服务（用户），以便 正确的分离关注点和生命周期管理。
代理网关。通过分布式网关管理，提 供安全、限制和用户访问管理。
开发和管理平台。管理需要合适的平 台来支撑编排和大规模的（内部和外 部）开发人员参与。
服务和集成层。解锁和去中心化管理 底层平台和数据资产，并屏蔽后端系 统的复杂性和越来越多的端点。服务 和集成层包括：
服务编排。包含启用混合IT所需的事件、批处理、同步、异步等模式的编 排模式。
数据转换。支持当前主流和传统格式 （json/xml/ftp…）的丰富的数据映射、转换和过滤功能。
开放连接。支持所有底层资产（包括 平面文件、大型机、API、SAML）的通 用连接能力。
轻量级通信。
组织赋能。专注于构建组织内的集成 能力，包括：
运营模型。流程、治理、组织架构、 服务交付和集成服务支持。
人才。明确关键角色、技能和资源需求缺口，以满足未来的需求。
培训。技能差距分析和培训需求，持续教育以支持未来需求。
组织变更管理。变更管理过程，以满足不断变化的组织需求。
除此之外，在集成服务生态系统中还需 要包含安全、日志和分析功能，并在整个集成体系关注API的治理。
4.4 云端创新应用开发
4.4.1 创新应用开发理念与DevOps
市场快速变化导致需求变更更加频繁,响应周期要求更短,为了适应市场的快速变化,抓住瞬息万变的商业机会, 企业的业 务系统需要快速迭代不断试错。与位于后端固化核心业务流程的ERP相比, 中前端的应用尤其需要快速创新和敏捷响应, 这 就导致了业务场景越来越多,应用投产频率越来越高,传统的软件交付模式已经无法满足要求, 企业迫切需要新的理念,方法 和工具提高整个软件交付和迭代的效率, DevOps正是在此背景下应运而生。
DevOps不是某种软件或者工具或者某种 组织形式, 实际上它是一组过程,方法与系 统的总称,其目的是通过一系列自动化的 工具提高组织团队之间的沟通与协作效率, 从而能够更敏捷更稳定的交付软件,高效完成整个软件的生命周期管理. 一般来 说, DevOps会涉及到四个环节,即:
持续反馈: 需求以小批量形式在团队的 各个角色间顺畅流动，DevOps能够促 使在较短周期完成小粒度需求的频繁 交付，并且在这个过程中，各个角色密切协作。(双态运维联盟定义)
持续集成: 一种软件开发实践，即团 队开发成员经常集成他们的工作，通 过每个成员每天至少集成一次，也就 意味着每天可能会发生多次集成。每 次集成都通过自动化的构建（包括编 译，发布，自动化测试）来验证，从 而尽早地发现集成错误。
持续交付: 一系列的开发实践方法，用来确保让代码能够快速、安全的部署到产品环境中，它通过将每一次改动 都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和 服务能符合预期
持续部署: 通过借助基础架构编排、应用编排、PaaS平台等工具并将需求持 续自动部署到目标环境中，并借助红 绿部署、灰度发布等手段进一步降低部署到生产环境的变更风险，提升变 更成功率。
4.4.2 云原生时代的DevOps
相对于传统IT基础设施，云具有更加灵 活的调度策略，接近无限的资源、丰富 的服务供用户选择、使用，这些都极大 方便了软件的建设。而云原生开源生态 的建设，基本统一了软件部署和运维的 基本模式。更重要的是，云原生技术的 快速演进，技术复杂性不断下沉到云， 赋能开发者个体能力，不断提升了应用 开发效率。
首先是容器技术和 Kubernetes 服务编排 技术的结合，解决了应用部署自动化、 标准化、配置化问题。CNCF 打破了云上 平台的壁垒，使建设跨平台的应用成为 可能，成为事实上的云上应用开发平台 的标准，极大简化了多云部署。
一个完整开发流程涉及到很多步骤，而 环节越多，一次循环花费的时间越长， 效率就越低。微服务通过把巨石应用拆解为若干单功能的服务，减少了服务间的耦合性，让开发和部署更加便捷，可以有效降低开发周期，提高部署灵活 性。后台的运维平台的工作都是不可以 缺少的，只是通过技术让扩容、容错等 技术对开发人员透明，让效率更高。
4.4.3 云端DevOps解决方案
基于云端分布式PaaS平台打造一体化DevOps解决方案
方案功能描述
项目管理: 包括需求管理，项目任务拆分、迭代、风险管理。项目里程碑、 报表管理；
配置管理: 包括SCM配置管理、集成应用管理、代码变更管理、项目流程 管理；
持续集成: 对项目开发仓库地址进行代 码变更监控，实时进行代码构建，静 态扫描，单元测试用例执行，代码覆 盖率收集等集成；
环境管理: 测试环境资源高效管理、提 供项目测试环境一键申请、一键部署 功能UI自动化:实现WEB-UI自动化测 试，提供极低成本的在线脚本录制、 在线脚本调试和维护等功能；
接口自动化: 实现接口自动化测试功 能，支持http、hsf、dubbo等多种接 口自动化测试；
mock平台: 服务端mock，支 持http，https，edas（hsf） ，dubbo，sofaRpc等多种协议的 mock，包括银行报文的mock；
性能压测: 性能压测平台，集脚本、场景、压测、监控和报表展示为一体，是一个支持快速、低成本实施压测的平台；
集成自动化: 项目分支合并后，自动触发打包编译、集成环境部署、单元\接口\UI自动化测试用例执行的集成自动 化测试服务
用例+缺陷: 测试用例编辑维护，缺陷整个生命周期的管理，解决缺陷的跟 进问题
前端自动化: 前端JS动态代码自动化检测，多浏览器环境，多浏览器截图
4.4.4 DevOps的实施原则
要实施DevOps，需要遵循一些基本原 则，这些原则被简写为CAMS，即：
文化（Culture）：不同团队间需要更好的沟通，提高效率，加强协作，打破不同团队之间的鸿沟，实现流程 自动化。
自动化（Automation）：想要大型系统的协作过程流畅运行，就需要规 范化和流程化，让可以自动化的环节 实现自动化。同时在自动化过程中， 需要各种技术改造才能达到预期效果。
度量（Measurement）：度量首先 要解决数据准确性、完整性和及时性 问题，其次要建立正确的分析指标。 找到工作中存在的瓶颈和漏洞以及对 于危急情况的及时报警，及时对团队 工作和系统进行调整。注重工具的建 设，自动化的加速和各个环节优化， 最大可能发挥度量的作用。
共享（Sharing）：通过共享知识， 让每个人可以了解团队其他人的工 作，让每个人都明白工作的共同目 标，在知识层面达成一致，避免某个 人成为单点，提高团队的集体能力。
文化、自动化、度量和共享四个方面相 辅相成，独立而又相互联系，所以要落 实DevOps 时，要统一考虑。
4.5 云端智能技术应用
S/4HANA本身对于企业的价值在前面都已经有所说明。随着时代的发展，人工智能、机器学习、物联网（IoT）、区块链等新一代技术已经进入主流，IT部门思考新的技术如何结合这些技术为企业 带来价值已经变得更加重要。另外随着公共云厂商这些年的发展，这些看起来很”重”的技术，在公共云上的落地也 已经变得非常简单。
数字化转型并不是一蹴而就，而是一个持续性的过程，每个企业都需要在对自 身企业现状有充分了解的前提下，提早规划具体的转型行动。
大多数企业将数字化转型视为是一件相当复杂的事情，因为其牵涉的角色众 多，而在具体转型的道路上，已经远远不是一个信息系统的转变问题，而是整 个企业端到端的业务模式都需要发生变更。所以对于不同的用户会有不同的期 望，例如：企业的CEO希望借助新的业 务模式实现业务增长，CFO希望通过流 程自动化提高利润，CTO希望引入更有 效的新技术，而作为普通的员工普通员 工或许只关心能不能帮自己简化工作、 提高效率。
而智能型企业转型，意味着更多的新技 术将替代传统的业务操作模式，企业需 要做好迎接创新的准备，同时改变员工 的思维模式，从传统的重复性劳动中解 放出来，更多地投入到创造价值的活动 中去。
5.1 构建数字化生态系统
现代企业的数字化转型需要构建以智能ERP为核心的数字化生态系统，通过 S/4HANA和SAP业务技术平台构建双平 台架构ERP，在云端部署稳定、"Clean" 的S/4HANA数字化核心，同时借助SAP业务技术平台构筑企业创新平台，实现具有以下特色的现代化智能ERP：
云端部署ERP，降低TCO
简化ERP流程、追求Clean ERP，具备 敏捷属性，持续创新
将智能技术融入ERP业务流程，赋能ERP智慧属性 对于依然使用传统SAP部署模式的企业，向智能ERP转型也变得越来越迫切。企业应着手对现有系统进行分析， 发现现有SAP系统中非必要的历史技术 投资，并且制定对应的转型计划和未来 核心业务平台部署模式，逐步将传统 SAP ERP向以S/4HANA为核心的智能ERP 转型。
5.2 合作共赢的一站式服务
德勤于2015年与阿里云展开战略合作， 成为首家拥有阿里云专属服务团队的国 际咨询公司。2016年德勤与阿里云共同 成立了“德勤-阿里云管理创新实验室 (DAMI-Lab)”，着力打造企业转型创新 实践平台。经过多年的探索与实践，形 成了完整的数字化转型方法。
企业数字化转型是一项复杂的系统工程，不仅是IT和数字化技术的应用，更 重要的是商业模式、组织、流程、文化等根植于企业内部驱动力的变革。德勤与阿里云结合企业数字化转型的诉求与特点，根据企业“稳态（数字化核心平 台）”+“敏态（数字化创新平台）” 的双模业务帮助企业选择最佳IT服务和云运营模式。结合德勤丰富的SAP S/4HANA 实施经验和领先的行业洞察， 帮助企业通过智能技术构建智慧企业， 在战略、运营、人力资源管理、财税管理、技术应用等领域提升管理效能、数字化运营能力。
作为全球领先的企业级信息服务服务商，德勤在已有资源、服务能力与解决方案的基础上，将继续与阿里云继续保 持全域合作，在商业模式、人才支撑、 前沿云技术应用等领域不断探索，精益服务能力，同时结合德勤行业领先洞察与实践，与阿里云共同助力企业数字化转型的云端之旅，实现云上卓越，驱动各行各业数字化转型，从而驱动数字中国的实现。
（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）
