通往 SAP S/4HANA 之旅：迁移攻略
SAP S/4HANA 是 SAP 第四代智能 ERP 产品，这意味着 SAP 会持续在 SAP S/4HANA 上迭代更新和创新。SAP S/4HANA 也是 SAP 历史上被客户采用最快的产品。对于运行在 SAP ERP(SAP R/3 或 ECC）平台上的公司来说，一个非常好的选择是将其升级到 SAP S/4HANA 上。
一谈到「升级」，可能会产生误导，因为从 SAP Business Suite 到 SAP S/4HANA 不仅仅是技术升级， 它很可能是一个完全的迁移，一个完全的重构。大多数企业通过从一种技术迁移到另一种技术，以及实施变革来激发企业创新和新的工作流程与方式，从而实现数字化转型。
对许多公司来说，尤其是对于基于一套系统跨全球多个区域管理的公司来说，迁移至 SAP S/4HANA，这是一项很大的挑战。这些年来，考虑到许多 SAP 客户为实现 SAP Business Suite 所做的大量投资，他们必须保护自己过去既有的投资。我们的合理假设是，迁移到 SAP S/4HANA 和 SAP C/4HANA 是不可避免的。事实上，使用 Big Bang 的方法是昂贵的，耗时长，风险高，他们找不到一个好的理由或更好的商业案例来支持这种升级方式。
对于 SAP 既有客户来说，SAP S/4HANA 的功能比 SAP Business Suite 更丰富，应重点关注在如何运用 SAP S/4HANA、SAP C/4HANA 和 SAP HANA 技术加速创新，最大限度地提高 SAP 软件投资的回报和价值实现，而不是把 SAP HANA 仅仅作为数据库进行评估投资回报价值。我们需要在预算范围内按时实现必要的创新，并希望每个阶段都有正回报。下面我们列举了几个迁移要考虑的领域及方法:
01
使用 IaaS 减少 SAP 业务
应用的硬件及运维投入
近几年，企业级软件领域发生了一些根本性的变化，各种云基础设施提供商如谷歌、微软、亚马逊、阿里巴巴等支持 SAP 运行在其 IaaS 上，随用随付费、弹性负载，并行系统副本、实现高可用性或灾难恢复等服务优势已经成为运营商的主力军。对于那些需要满足不断发展的数据隐私遵从性的人来说，大多数云提供商现在提供了所谓的私有区域或私有云来管理这一点。结合 SAP HANA 2.0的云技术，SAP 应用程序和技术以 SaaS 模式可以更快、更容易地灵活部署在公共云或私有云上。在您的公司必须做的硬件更新替换甚至可能是一个数据中心升级改造时，您可能会考虑将您的应用程序运行在云端，以减少硬件和数据中心投资。通过 IaaS 提供的定价模型降低 SAP 应用程序运行的大部分成本。前期硬件投资通常比较低，硬件使用只在月末结账期间、在高峰业务量期间、在批处理作业期间通过弹性加载模型使用。
02
使用 SAP S/4HANA 或 SAP C/4HANA
作为「微服务」的分阶段迁移方法
大多数系统迁移是由行业和市场需求驱动，公司在销售、分销、制造、供应链以及财务方面的创新需求并不是同等紧迫的，可以按照创新需求定义分阶段的实现和部署迁移至 SAP S/4HANA 或 SAP C/4HANA，即仅迁移支持创新事项及紧迫程度所需的内容。分阶段迁移的关键点是分解整体，首先确定所需创新的完整列表，根据您业务的优先级对其进行排序后，再定义优先的业务需求，确定 SAP 迁移策略。
从中央财务系统 Central Finance+1业务领域开始：
分阶段迁移的思路就是从最需要创新的业务领域开始，创建一个具有独立关注点的「微服务」，作为迁移到 SAP S/4HANA 的一种业务方式。需要说明的是，这不是将 SAP ERP 作为一个整体转移到 SAP S/4HANA 的「技术性」迁移。从 Central Finance(中央财务系统）和一个主要的商业领域开始的设想和实践 ，不仅仅是一条技术迁移路线，可以作为第一步迁移到 SAP S/4HANA 的「敲门砖」。
大多数企业内部运营，不管是哪个行业，都将覆盖生产制造、采购内部供应链以及销售分销渠道的业务职能。企业的创新或「竞争力」在很大程度上属于上述三者中的任何一种。 SAP ERP(SAP R/3 或 ECC）作为成熟套装软件，提供了管理上述内容的所有功能。SAP Business Suite 中的 CRM、SRM、APO、EWM 等应用程序以及 SAP SuccessFactors、SAP Ariba 等其他云解决方案加以补充完善企业运营管理。
SAP R/3 时期已经从财务领域开始进行逐个业务领域的开发。因此，传统 ERP 关注的功能领域分解创新，自然将沿着这些业务领域进行分离。PP 制造与 SD 销售分销模块之间的接口是将制造材料(产成品）「移动」到「销售产品」中，并将其分配到不同的销售渠道或销售区域，它们之间的集成是通过设计内置的，最初是通过「过账任务」或「过账指令」异步实现的。这将给我们一个提示，说明哪些领域可以在 SAP S/4HANA 中作为一个微服务首先重新设计和实现。从现有的财务解决方案到新的「中央财务系统」的整合非常简单，因为这将以财务凭证为基础。企业已经实施的数据仓库 EDW、内部供应链如 EWM、TM、PLM 或 CRM 几乎不会受到影响。
用例1
财务变革先行，依托 Central Finance 分阶段进阶到 SAP S/4HANA
越来越迫切的集团管理驱动下，集团法定合规报告需要实时从操作系统查看明细的交易性事务数据；集团合并管报(MIS）的盈利能力分析、成本收入的实时明细数据，内部公司毛利率分析，转移定价等；集团税务管理需要汇编各分子公司数据，满足总体情况以及从各操作系统中查看到发票级别的监管要求，从而进行合规、统驭调节、退货管理以及信贷管控；集团运营资金管理，企业层面各运营实体的企业现金流的可见性以及银行限制风险敞口的可见性和控制；从集团视角查看跨法人实体的债务及债权人分析，中央信用额度、收款、争议管理以及付款等。实际上，很多集团公司的 ERP 可能拥有多个 ERP Instance，和其它各类异构系统，包括 SAP 及非 SAP。由于不同的业务需求驱动，如迁移期间组织架构重新变动，财务变革优先级最高，实体单位按时间轴逐个迁移，短期阶段性过渡，核心信息系统重新实施，系统统一整合，在整体向 SAP S/4HANA 迁移的过程中，Central Finance都可作为迁移的变通方案使用。
SAP Central Finance 是一个 SAP S/4HANA 系统的加挂配置(Side-Car)安装，借助一整套技术日志记录、复制、映射、数字化、过账、纠错、对账和回账，通过实时复制接收来自混合 SAP 或非 SAP ERP 分布式系统中带有业务「标签」的财务会计交易数据，SAP S/4HANA Central Finance 作为全球财务报告和处理中心，为集团企业提供了一个更简化的财务信息中心， 允许任何企业开始使用 SAP S/4HANA 财务创新，直到源系统终止服务。事实上，采用这种财务创新先行的全球客户案例已经有很多，如塔塔全球饮料公司全球财务管理信息系统报告需求，诺基亚过渡期间的重组，诺华、飞利浦、Engie 财务变革先行、分阶段转型避免业务中断等。
从技术架构上来看，采用 SAP Central Finance 不需要通过各种接口连接源系统，非 SAP 的报表系统，合并报表、计划系统等，可以一次性联接源系统。而且 Central Finance 可以(接近)实时读取行业项目级别的交易明细数据且可追溯，在同一个平台上集中数据治理和管理数据映射、监控，不会因为数据校验和对账形成存储的冗余数据。同时，它可能会减少将历史数据加载到新 SAP S/4HANA 系统中的需求。SAP Central Finance 整合了 SAP 及非 SAP 系统报告、合并、计划和税务等应用的单一数据源，拥有盈利能力、成本、收入的实时细颗粒度可见性。SAP S/4HANA Central Finance 系统架构如下：
有了集中化的财务数据，企业数据运营分析还来自其它非 SAP 的运营系统， 企业的数据仓库(BW)专注在解决跨系统所有数据的问题, 抽取并存储来自 SAP S/4HANA、SAP C/4HANA 以及其它运营系统数据。和之前不同的是， 通过智能分析云 SAP Analytics Cloud+ SAP HANA 进行分析，人们不再需要将数据移动到 Analytics 系统，始终可以从所拥有的系统读取数据，而只有结果集存储在分析平台中。
在 SAP S/4HANA 迁移过程中，由于数据格式和数据切片在 SAP Business Suite，SAP S/4HANA 以及其他任何非 SAP ERP 系统中都会有所不同，可能还有来自云端，IoT 等复杂数据，涉及到跨业务部门、跨系统和高优先级的端到端分析等更为复杂的数据，借助 SAP Data Hub 可以协调加工多用途的数据源，基于统一目的输出，并加载到 SAP HANA 或 Hadoop 上，有助于在系统 Landscape 发生变化时进行统一分析，建立企业级统一数据平台。
在 SAP S/4HANA 的演进过程中, SAP 提供标准集成/接口的服务，加强了对于 OData 标准及开发模型和方法论的推广，降低了异构系统集成的复杂性。SAP 提供了更多标准化的 API，基于标准的 API 服务及架构和 SAP NetWeaver 网关，将 SAP S/4HANA 扩展为封装的微服务逐步替代 SAP Business Suite 的模块。API 可以由 SAP Cloud Connector 或 SAP NetWeaver 作为集成提供集线器，SAP Fiori、基于 UI5 或其他通过消费标准的 API 实现统一门户，增强用户体验，实现用户交互及数据展现。
基于分阶段迁移的思路，我们再列举几个常见的用例。
用例2
假设销售和分销管理首先迁移到 SAP S/4HANA+SAP C/4HANA
您的 SAP Business Suite 解决方案将保持原样
销售和分销以及所有渠道应用程序、营销应用程序和销售支持应用程序可以分别在 SAP S/4HANA 和 SAP C/4HANA 上迁移/实现。
某些共享服务(如定价)也可能保留在您的 SAP Business Suite 解决方案中，后续被 SAP S/4HANA 和 SAP C/4HANA 的(微型)服务替代。
这些新的解决方案与您的 SAP 业务解决方案共享主数据，并通过服务调用(利用 SAP 网关或 SAP 云连接器)与其他模块(如制造)接口。尽量减少系统集成之间的返工 。
这种方法的另一个好处是，通过设计，新的业务模型可以将任务外包给销售和分销合作伙伴/平台或战略供应商。
以销售分销和供应商 CRM 合同发起(B2B 场景）为例：将 SAP Business Suite 的 SD 和 FICO「迁移」到 SAP S/4HANA，SAP C/4HANA 提供合同管理，这几个系统之间的「共享」主数据，注意定义哪个系统拥有哪个(或部分）主数据及何处需要对应的同步模型。
用例3
供应链优化变革先行，迁移到 SAP S/4HANA+SNP
越来越多的企业开始对外部供应链协同管理需求迫切，以场景供应网络规划SNP为例，保留 SAP Business Suite 做为主数据源头系统，将 SAP S/4HANA 的 SNP 和 SD 作为微服务，SAP S/4HANA Central Finance 作为财务微服务提供整个财务镜像。通过标准的API及更加深入的消息集成实现多系统及应用间的无缝交互，同云端的交互更是服务化的未来，将 SAP S/4HANA 企业数字化核心的能力逐步搭建起来。
在原有的 ERP 系统中，大部分企业需要维护他们自开发的个性化需求的插件来保持竞争性优势，同时需要把多年存储的数据发扬光大，得益于 SQL，几乎不需要做任何修改，可保留用户自定义部分及现存的用户接口UI，保证了从传统数据库平滑迁移到 SAP HANA。在 SAP S/4HANA 中，在90%的情况下，只需最小的工作量，基于 SAP HANA Extension Hub 即可将自定义部分重构为微服务。在 SAP S/4HANA 和 SAP Business Suite 中，它将通过 User Exits、Function Calls 或对 SAP HANA Extension Hub 的远程函数调用(微服务)来完成。当然我们要评估新旧系统之间的功能差异，你公司的自定义代码功能范围，要检查如何被 SAP S/4HANA 标准功能所替代。
值得注意的是，该迁移方法论同样适用于 non-SAP 的客户核心系统迁移，在 SAP S/4HANA 的分阶段实施过程中，务必重视完整的测试如 Cut-over Rehearsal， Dry Run，Parallel Run 才能降低迁移风险，最终消除成功迁移的阻碍因素，完成平滑迁移。最后，分阶段迁移实施的思想始于对企业业务创新需求的清晰理解，包括针对行业解决方案的分解，定义优先的业务需求，确定优先变革升级的业务模块，以性价比最高的方式获得业务创新的快速响应。
作者介绍
王晶
SAP高科技行业群售前总监
拥有超过17年 SAP 工作经验，主导参与过多个大型企业管理咨询及信息化实施的项目。在成本管理、财务分析、资金管理、全面预算管理、财务风险管理、财务共享服务中心架构设计及 SAP 项目系统实施方面具有丰富的管理及实施经验。
相关资源推荐
