SAP ERP ECC 6.0 升级至S/4 HANA 的IT 解决方案设计

2022-10-21李慧佳屈仁斌

中国管理信息化 2022年15期

李慧佳，屈仁斌

（株洲时代新材料科技股份有限公司，湖南株洲 412007）

0 引言

SAP S/4 HANA 是SAP Business Suite 4 SAP HANA 的简称，是SAP 公司推出的新一代商务套件，这款新产品完全构建于目前最先进的内存平台SAP HANA 上，从底层数据库到应用层各个模块都有革命性的创新。相较于传统的SAP ERP ECC 产品，S/4HANA 分别从系统架构、数据源、交互界面、系统功能等层面进行了精简、优化和更新，并与移动应用、云平台技术相融合，以适应移动和工业4.0 时代的企业运营。对于传统的SAP ERP ECC 系统企业用户而言，如何规避风险，并最大化应用和整合SAP 提供的最新业务解决方案及功能，将现有的ECC 系统顺利平稳地迁移至S/4 HANA 以实现数字化转型成了当前各ECC 系统企业用户必须面对和需要解决的问题。本文以本企业S/4 HANA 升级实际案例为背景，着重介绍一种基于系统转换的ERP ECC 6.0 系统技术性升级至S/4 HANA 1709 方案的实现。

1 三种升级方案概述

根据SAP 企业用户需求的不同，实现S/4 HANA转换升级的方法可分为三种，即全新实施、系统转换、布局转换。三种升级方案路径如图1 所示。

图1 三种S/4 HANA 升级方案

一是全新实施。通过部署S/4 HANA 系统，使系统功能与业务流程紧密切合，系统新功能应用程度最大化，但会初始化所有数据。

二是系统转换。该方法能将现有的SAP ERP ECC 6.0 版本技术性升级至S/4 HANA，新系统存储有历史数据以及开发配置，可保证企业业务流程和数据的延续性，避免重新实施。

三是布局转换。将分散式的ERP 系统通过升级的方式集中整合到一个S/4 HANA 系统中，可帮助企业实现信息共享、业务集中管控的目标。

结合项目组团队的专业调研和充分论证，还和企业四个“一”信息化战略目标，即“一套标准，一套流程，一套系统，一个团队”为根本点，企业最终选择了系统转换升级方案，将企业正在使用的SAP ERP ECC 6.0系统携带所有历史业务数据及开发配置升级至S/4 HANA 1709 版本。与其他两种方案相比，该方案技术复杂、难度系数大，风险高，但延续性好，历史数据可追溯性强。

3 系统转换升级方案的实现

以软件版本升级为节点，系统转换升级方案划分为软件升级前的准备阶段，以及升级后的实现阶段，各阶段包含的主要内容概览如图2 所示。

图2 升级方案阶段概览图

3.1 准备阶段

该阶段包含四个子阶段，主要对现有ERP 系统环境进行升级准备性检查，从底层数据库、ERP 系统版本、插件、周边系统接口、数据结构、代码等层面进行分析，明确系统升级对业务流程所产生的影响及风险点，检查系统升级的可行性，结合企业业务流程优化、主数据标准设计等运营管理需求，制订可行的转换路径策略以及计划。

一是系统准备阶段。技术上，S/4 HANA 对底层数据库表结构进行了简化与重构，传统ECC 系统数据库结构不再适用，需要企业采用内存处理速度更快的SAP HANA 数据库平台。另外，使用软件升级需要的其他硬件条件如前端服务器等对当前ECC 系统环境进行检查和评估，对系统转换不支持的硬件资源，如ABAP 和JAVA 双栈系统等，需做出相应调整以满足升级条件。业务上，了解熟悉S/4 HANA 系统的变化与新增功能，调研和评估业务优化流程，梳理主数据标准统一的管理需求，如S/4 HANA 新增的将客户、供应商合并成为一个主数据BP 等。

二是维护计划。运行维护计划的员工要拥有系统转换升级要用的文件，同时要检查当前ECC 环境相关的组件、第三方供应商插件以及业务功能与S/4 HANA 系统的兼容性。

三是简化项目检查。通过运行报表检查系统转换相关的简化项目，检查这些项目的一致性以及转换后的影响。对于检查结果为非一致的简化项目，通过报表返回的错误信息结合SAP 官方提供的SAP Note 解决方案进行解决。

四是自开发代码检查。对ECC 系统内自开发的代码和程序进行检查，梳理明确不适应S/4 HANA 新数据结构和应用功能的自开发程序，检查需要进行调整的开发对象、数据表等。对项目组来说，通过评估整体代码调整的工作体量和完成时间，有利于项目计划的制订和组织架构的建立。对于企业来说，通过检查分析自开发代码的使用频率及可用性，可梳理出废弃的代码。

3.2 实现阶段

根据准备阶段的检查及调整结果，完成软件版本的升级、数据转换、代码调整等内容。结合本企业S/4 HANA 升级的实际实现方案，将系统升级及数据迁移的主要路径介绍如下：

第一步，通过客户端拷贝（Client Copy）的方式，拷贝当前ECC 的生产系统，搭建一个包含当前所有程序（包括系统标准程序、配置及自开发程序），但无业务数据的ECC 系统SB1。

第二步，使用S/4 HANA 升级工具Software Update Manager（SUM）将SB1 系统由ECC 6.0 版本升级至S/4 HANA 版本。

第三步，在SB1 系统中完成差异配置及初步测试，包括S/4 HANA 新功能或需求的配置工作，废弃对象的清理工作，以及自开发代码调整。完成配置后，测试系统的可用性。

第四步，使用第三方数据迁移工具SNP 建立ECC与S/4 HANA 系统间的数据匹配映射关系，包含新旧数据表之间的对应关系，以及根据主数据标准规则对历史数据进行调整及清理等，完成历史数据整理工作。

第五步，并行开展周边信息系统版本的兼容性评估和接口调整工作。

第六步，拷贝SB1 系统作为沙盘系统，导入历史业务数据后，测试验证数据的质量以及升级后程序的有效性。根据测试问题清单在沙盘系统以及SB1 系统中同步调整配置和开发，以及SNP 工具中的数据映射关系，修正问题。

第七步，在沙盘系统中进行3 到4 轮大批量集成测试，包括全流程业务测试、周边系统接口测试等。根据测试问题清单调整修改配置、开发及接口程序，修正问题。重复步骤六、七直到系统和数据质量满足上线条件。

第八步，拷贝SB1 系统作为未来S/4 HANA 的生产系统，使用SNP 工具完成从现有ECC 生产系统到S/4 HANA 生产系统的业务数据迁移。数据验证完成后，完成系统正式切换。

4 风险分析

S/4 HANA 升级项目不仅仅是一个技术升级过程，更是一个优化业务流程、深化应用功能的过程。大多数企业并没有S/4 HANA 升级相关的项目经验，且目前市场上可供借鉴参考的实际案例也很少。因此，在整个项目过程中对潜在风险的管理、分析和把控尤为重要。结合本企业实际案例，升级项目过程中需着重关注以下几个风险点。

第一，数据质量。对历史业务数据进行迁移时，S/4 HANA 底层数据结构变化、新增功能、业务流程优化整合、主数据标准规则的变更等因素对数据清理过程会产生直接影响，数据转换和匹配的准确度决定了导入新系统的数据质量，也在一定程度决定了后期新系统大批量测试的复杂度和进度，需严格把控数据质量问题，降低项目因此而延期的风险。

第二，业务冲击。制订上线切换方案时，系统升级完成时间、生产系统宕机时间的预估准确性对企业前端业务运转产生直接影响。若生产系统宕机时间过长，则不利于企业运营的稳定。

第三，项目周期。主要表现为项目初期制订的计划对整体项目的工作体量和复杂度无法准确把握，存在项目实际周期延长的风险。

第四，项目管理。目前，市场上具备S/4 HANA 技术性升级经验的、成熟的乙方实施团队很少，企业项目成员对S/4 HANA 系统升级的知识储备不足，同时缺乏升级类项目的管理经验，大大增加了项目管理的难度。