SAP ERP ECC 6.0 升級至S/4 HANA 的IT 解決方案設計

李慧佳，屈仁斌

（株洲時代新材料科技股份有限公司，湖南 株洲 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 系統升級的知識儲備不足，同時缺乏升級類項目的管理經驗，大大增加了項目管理的難度。

5 結語

本文以本企業S/4 HANA 升級項目為背景，著重介紹了一種基于系統切換的技術性升級方案的實現，將當前企業在用的ECC 6.0 系統攜帶所有歷史業務數據及開發配置一次性升級至S/4 HANA，在此基礎上總結概括了升級項目潛在的主要風險點，為集團其他公司后續開展升級項目提供思路。