SAP ECC 遷移至 S/4HANA：中東零售業案例研究

這是我最喜歡的案例研究。一家知名的中東時尚與消費品零售商，從 SAP ECC 6.0 遷移到 S/4HANA。它有約 18,000 名員工、橫跨七個國家的 1,200 多間門市，以及成長中的電子商務通路。它使用 ECC 已有多年，系統物件有 44% 經過客製。我們選擇了搭配選擇性重新設計的 brownfield 轉換。月結從原本拖進週末，變成中午前完成，客製程式碼則減少近一半。

如果您運行的是高度客製的 ECC 系統，並且在想究竟該帶多少東西往前走，這就是一個專案回答這個問題的方式。

客製是慢慢累積起來的，一次一個緊急修補。等到我們開始時，連小小的更新都帶有風險。整合很脆弱：財務上的一個小改動，就可能弄壞零售營運中的某個環節。業務端要的是彈性與速度，IT 卻整天忙著救火。雙方都承認，彼此的努力方向是背道而馳的。

我記得有一場會議，供應鏈團隊承認他們數十份「關鍵」報表幾乎已經沒人在用，說的時候不禁笑了出來。把它們砍掉，既務實，也有種莫名的解脫感。

ECC 主流維護結束是導火線。採用增強包（EHP）6 至 8 的 SAP ERP 6.0，主流維護將於 2027 年底結束（SAP News）。真正的動因更深。財務每個月結都要手動匯出資料。門市需要的庫存可視性，是夜間批次作業給不了的。IT 的大部分心力，都花在維持客製程式碼不倒。

SAP Readiness Check 證實了我們的猜測：這是一套高度客製的系統，前方有大量修正工作。Simplification Item List 顯示出，標準 S/4HANA 已經能做到過去客製 ECC 程式碼在做的哪些事。財務團隊發現，一些長年維護的客製報表如今已是多餘。那場會議上的如釋重負，一目了然。

單純的技術轉換只會把問題往前推。完全的 greenfield 重建，則會丟掉十年來運作良好的配置。搭配選擇性重新設計的 brownfield 是折衷的作法：保留穩固的，清理該清的，只重建壞掉的。我的 ECC 遷移至 S/4HANA 指南說明了如何權衡這幾條路。

單純轉換搭配選擇性重新設計的 Brownfield完全 Greenfield 重建

保留的配置單純轉換全部保留，連問題一併帶過去搭配選擇性重新設計的 Brownfield保留穩固的部分完全 Greenfield 重建全不保留，十年心血作廢

44% 的客製物件單純轉換原封不動帶過去搭配選擇性重新設計的 Brownfield逐一標記為淘汰、替換或改造完全 Greenfield 重建不帶過去

代表什麼單純轉換問題隨之搬到 S/4HANA搭配選擇性重新設計的 Brownfield該清的清，只重建壞掉的完全 Greenfield 重建每個運作中的流程都從零重建

挑戰	我們的做法
44% 的物件經過客製	業務與 IT 一起為每個物件標記：淘汰、替換或改造；每個階段設有品質關卡
脆弱的整合	迴歸測試計畫涵蓋 POS、WMS、財務、人資與供應商入口網站；點對點連線改為採用 SAP Integration Suite 的模式
資料品質	每個職能設資料管理員並訂定 SLA；每日追蹤缺陷；在 QA 之前完成資料清理
跨國採用	依角色編寫的作業指南、上線前後的現場走動輔導、與實際工作任務連結的訓練

大規模的客製程式碼

Readiness 的結果發揮了篩子的作用。業務與 IT 坐在一起，為每個物件標記。有些顯然是多餘的，像是沒人記得執行過的報表。有些則支撐著真正獨特的零售流程，需要審慎地重新設計。這逼著團隊做出決定，而不是往後拖。SAP Signavio 協助依最佳實務定義新流程，smartShift 負責自動化的程式碼掃描與低價值的修正，讓資深人員的時間留給重新設計。我的 Clean Core 指南說明了我現在如何分類客製程式碼。

整合

ECC 連接著銷售時點（POS）系統、倉儲管理系統（WMS）、財務、人資，以及數個供應商入口網站。我們為這些系統全部建立了迴歸測試計畫，並在每次重大配置變更之後都測試，而不是只在最後測。夜間批次作業在 S/4HANA 中必須跑得更快，否則倉庫的晨間報表就來不及產出。

資料品質

重複的供應商資料與過時的主檔資料，把測試拖得很長。解法是結構性的：每個職能指派一位資料管理員，並訂定處理時限的 SLA。如果資料在 QA 開始時還不乾淨，就退回給資料管理員。隨著切換臨近，我們端到端演練資料載入，並每日追蹤缺陷。這套簡單的例行作業，比任何花俏的儀表板都管用，至今仍讓我意外。我那篇談 SAP 資料遷移為何失敗的文章，說明了這種模式。

採用

訓練涵蓋 26,000 名員工。財務與零售營運的優先順序不同，這在早期的一場工作坊就浮現了，也改變了訓練的設計。接近上線、壓力升高時，我們採用依角色編寫的作業指南與現場走動輔導。一位門市主管後來說，那份兩頁的指南比任何全員大會都重要。我相信她。

以 SAP Activate 分階段交付。 核心財務與供應鏈先遷移，人資與供應商入口網站較後，因此支援團隊從未超載。每個環境只有一項任務。Sandbox 驗證路徑並鎖定範疇。開發環境強化傳輸。QA 以真實的業務量執行並調校作業。Pre-production 是一場真正的彩排。部署日期配合零售旺季與淡季安排。

與業務一起測試。 財務與供應鏈主管以真實的期末結帳與促銷週期來測試，劇本是依業務實況而非系統邏輯來寫。夜間執行暴露了時序問題。我記得一位倉儲主管在歷經數週的挫折之後，第二次執行順利通過時露出了笑容。

切換演練。 每個任務都計時、精簡或合併。光是試運行，就省下了試算表永遠看不出來的好幾個小時。復原計畫印成一頁的講義，大家說，那份簡單的清單比任何儀表板更能減輕壓力。門市試點在更大範圍推行之前，先驗證了 POS 與 WMS 的穩定性。

Hypercare（上線後密集支援）。 IT 與業務共用一間作戰室、明確的 SLA，以及每日行動紀錄。週末班次輪替，支援交接精確到分鐘寫成腳本。人們通常記得數字。我記得最清楚的，是第一個平靜的夜晚。

財務結帳。 團隊說，月結現在在中午前就完成，以前會拖進週末。財務長最滿意的是，他拿到報表快多了。一位財務主管開玩笑說，這套系統終於「比咖啡機還快」。這樣的時刻所建立的信心，比任何簡報都多。

客製程式碼。 減少近一半，降低了長期的支援負擔，以及日後每次升級的迴歸風險。

報表與使用者體驗。 門市經理從舊的交易畫面，轉到 SAP Fiori 應用程式。訓練時間縮短，因為這些應用程式的運作方式符合人們的預期。一位經理形容它「令人耳目一新」。

整合。 POS、WMS 與財務的連線變得更穩定，夜間作業也提早完成。

並非每件事都同樣順利。有些團隊在已有更好報表的情況下，仍緊抓著舊報表不放。有些人覺得工作坊太長、演練太重複。回頭看，那些步驟正是安全網。

教訓	發生了什麼	下次我會怎麼做
及早對齊	在一場工作坊中，門市經理表示他們的報表需求與財務截然不同。這個問題及早浮現，我們得以調整；若拖到後面，就會在切換時爆開	在設計開始之前，安排有結構的對齊會議
第一天就開始程式碼審查	數個物件在接近上線時，被迫在壓力下重做	從啟動會議起，就做出淘汰、替換或改造的決定
讓資料成為業務的責任	重複的供應商資料拖慢了測試	第一週就指定各職能的資料管理員並訂定 SLA
演練的次數要比覺得必要的更多	一次試運行揭露了 POS 與 WMS 之間沒人預見的作業順序衝突	多排幾次演練；上線前的最後一次，應該讓人覺得無聊

如果同樣的專案今天才開始，會有三件事不同。處於這種處境的多數公司，現在會考慮 RISE with SAP 之下的 S/4HANA Cloud Private Edition，而不是留在地端。淘汰、替換或改造的決定，會對照 SAP 的 Clean Core 層級 A 至 D 來定調。變更與部署的追蹤會在 SAP Cloud ALM 中進行，因為 Solution Manager 7.2 的主流維護將於 2027 年底結束。資料管理員、演練、共用的作戰室與兩頁的指南，則會完全維持原樣。在人的面向上，請見我的 SAP 教育訓練策略指南。

企業為何要從 SAP ECC 遷移到 S/4HANA？

ECC 主流維護將於 2027 年結束，是導火線。更有力的理由在營運面：即時報表、更快的結帳，以及少花力氣維持客製程式碼與脆弱的整合。在這個案例中，業務端想要的是即時的零售分析與更短的月結。

SAP Readiness Check 在這個案例中顯示了什麼？

它證實 44% 的物件經過客製，其中許多已經多年沒被使用。這改變了客製程式碼工作的架構：先淘汰，盡可能以標準功能替換，只改造真正有業務價值的部分。Simplification Item List 也顯示出，有些報表在標準 S/4HANA 中已經是多餘的。

為何選擇搭配選擇性重新設計的 brownfield？

單純的技術轉換會把每個問題都帶過去，而完全的 greenfield 重建會丟掉十年來運作良好的配置。選擇性重新設計保留了穩固的部分，在標準功能能取代客製邏輯之處，使用 SAP Signavio 定義新流程，並只重建壞掉的部分。

資料清理拖得太晚會發生什麼事？

測試拖延、演練失敗、上線日期延後。在這個案例中，重複的供應商資料與過時的主檔資料，在測試中造成了數週的摩擦。解法是每個職能指派資料管理員並訂定 SLA，同時把資料清理當成專案健康度的指標來追蹤。

遷移期間如何處理整合？

先盤點每一條連線：POS、WMS、財務、人資與供應商入口網站。迴歸測試計畫涵蓋全部系統，每次重大配置變更後都執行測試，並由門市試點在更大範圍推行之前先驗證 POS 與 WMS 的穩定性。即便如此，一次試運行仍抓到了 POS 與 WMS 之間沒人預見的作業順序衝突。

S/4HANA 上線後，好的 Hypercare 是什麼樣子？

IT 與業務共用一間作戰室，有明確的 SLA、每日行動紀錄，問題快速關閉，而不是丟進待辦清單。依角色編寫的指南與現場走動輔導，比正式訓練更快減少支援來電。週末班次輪替，並把交接寫成腳本，避免團隊燒盡。