SAP Clean Core：5 大原則、A 至 D 級與治理

重點整理

SAP Clean Core 是指讓 S/4HANA 盡量貼近標準，擴充只透過已發布的介面建置，不是用 ABAP Cloud 在堆疊內實作，就是在 SAP BTP 上以並行方式實作
SAP 提出的 Clean Core 5 大原則是：流程、擴充性、資料、整合與營運
自 2025 年 8 月起，SAP 將擴充分為 A 至 D 四個等級；D 級（修改、隱含式增強、寫入 SAP 資料表）是最先要清除的技術債
Public Edition 只允許使用 ABAP Cloud，因此由系統強制落實 Clean Core；在 Private Edition 與地端部署中，這是一項治理決策
每一項 Clean Core 決策都應由業務與 IT 組成的設計治理委員會負責；以 ABAP 測試駕駛艙和 SAP Cloud ALM 中的 RISE with SAP Methodology 儀表板衡量進度
SAP ERP 6.0 EHP 6 至 8 的主流維護於 2027 年 12 月 31 日結束；選擇性的延長維護持續到 2030 年 12 月 31 日

Clean Core 對您的 ERP 代表什麼
SAP Clean Core 的 5 大原則
Clean Core 的 A 至 D 級
適用於 S/4HANA Cloud 的 ABAP Cloud 與 BTP 擴充性
Clean Core 治理：誰負責決策
Clean Core 與變革管理
Clean Core 遵循：如何衡量
我會從哪裡開始
Clean Core、RISE 與 AI：哪些是必要的，哪些不是
在 RISE with SAP 下，Clean Core 是強制的嗎？
ECC 我還能用多久？
Clean Core 對 AI 重要嗎？
常見問題

SAP Clean Core 是指在業務允許的範圍內，讓您的 S/4HANA 系統盡可能貼近 SAP 標準。您新增的任何內容，都透過 SAP 已發布並承諾維持穩定的介面來建置，因此升級不會讓它出問題。

簡單來說，Clean Core 是一套關於如何擴充與治理 SAP 的紀律。客製邏輯不是用 ABAP Cloud 放在堆疊內，就是放在 SAP BTP 上並行運作，而 SAP 會把每個擴充從 A 級（最乾淨）到 D 級（應該移除的修改）加以分級。回報是更快的升級：我看過企業用這種方式把升級時程縮短 40%。

如果您的系統充滿對 SAP 標準物件的修改，每次版本發布都會變成一個回歸測試專案。如果您的客製邏輯位於已發布的介面之後，升級就會變成例行維護。

我看過企業透過套用 Clean Core 原則，把升級時程縮短 40%。他們的做法是把客製化降到最低，並治理好保留下來的部分。

2024 年，一家歐洲消費品企業以一個在 SAP BTP 上、建置於核心之外的模組化 Fiori 應用程式，取代了原有的舊定價邏輯。這讓這部分邏輯的回歸測試完全消失。

Clean Core 對您的 ERP 代表什麼

Clean Core 的 ERP 仍然可以客製化。只是客製化必須使用 SAP 已發布並承諾維持穩定的介面。SAP 為此提供兩種方式：

堆疊內擴充，使用 ABAP Cloud。 擴充在 S/4HANA 內部執行，但只使用已發布的 API 與擴充點。
並行擴充，使用 SAP BTP。 擴充以獨立應用程式執行，透過 API 或事件與 S/4HANA 溝通。

SAP 將其做法描述為 BTP 優先，依使用案例選擇。依我的經驗，程式碼在哪裡執行，遠不如這個需求究竟需不需要程式碼來得重要。

髒核心對任何營運過 ECC 的人來說都很眼熟：被修改的標準程式、被直接寫入的 Z 資料表、讀取 SAP 內部結構的介面、沒人記錄過的隱含式增強。這些在建置當時都沒有錯。只是它們並不是為一個每一兩年就升級一次的系統而建置的。

我也在自己的 YouTube 頻道上用一支影片（英文）講解了這個主題。

Your S/4HANA Migration Is Already Broken without Clean Core (Here's Why)18 min

SAP Clean Core 的 5 大原則

SAP 以五項指導原則來架構 Clean Core。以下是 SAP 對每項原則的定義，以及我最先查看的地方：

原則	SAP 的意思	我最先檢查什麼
流程	盡可能貼近 SAP 標準流程	哪些流程變體只是因為「我們一向都這樣做」而存在
擴充性	透過已發布的 API 與核心解耦的擴充，並治理要採用哪一種選項	有多少客製程式碼、其中多少有在使用、分別位於哪個等級
資料	在既定治理模式下保持乾淨、合規的資料	重複與不完整的主檔資料，沒人說得清楚的客製欄位
整合	以受支援技術建置的標準化、安全連線	直接讀取資料表的點對點介面
營運	讓其他四項得以維持的治理、人員、流程與工具	誰核准擴充，又是什麼在阻止下一次修改

多數團隊從擴充性開始，也止於擴充性，因為它最容易衡量。依我的經驗，流程與資料造成的延誤更多。客製程式碼通常只是症狀，背後的流程才是原因。

Clean Core 的 A 至 D 級

2025 年 8 月，SAP 以 Clean Core 等級概念取代了先前的三層擴充性模型。每個擴充都依其建置方式、與核心的解耦程度，以及能否安全通過升級來評級。如果您讀到的舊版 SAP 資料還在談「層級」，取而代之的就是這套概念。

Clean Core 的 A 至 D 級升級風險從 A 級到 D 級逐級升高。並非所有內容都要達到 A 級，但 D 級是最先要清除的技術債。

A 級B 級C 級D 級

使用什麼A 級僅限公開發布的穩定介面B 級也使用 SAP 的傳統 APIC 級SAP 內部物件D 級修改、寫入 SAP 資料表、隱含式增強

升級風險A 級最低，有穩定性契約保障B 級整體而言升級穩定C 級每次升級都需檢查D 級最高

需要決定什麼A 級所有新開發的預設選擇B 級接受，並記錄理由C 級附理由接受，每次升級重新檢查D 級最先移除，或移到 B 級或 C 級

來源: SAP Clean Core 等級概念，SAP News，2025 年 8 月

A 級只使用附有穩定性契約的公開發布介面，以 SAP Build、ABAP Cloud 或 BTP 建置。B 級還會使用 SAP 的傳統 API。C 級會觸及 SAP 內部物件，SAP 計畫為這些物件提供變更日誌，協助規劃升級。

D 級是修改、寫入 SAP 資料表、隱含式增強，以及其他 SAP 不建議的技術。這比過去「乾淨或不乾淨」的爭論更有用，因為它讓您能為每個物件設定目標。在升級前把 D 級物件移到 B 級或 C 級，本身就是實實在在的風險降低。

適用於 S/4HANA Cloud 的 ABAP Cloud 與 BTP 擴充性

ABAP Cloud 是 SAP 為雲端設計的 ABAP 開發模型。開發人員使用「ABAP for Cloud Development」語言版本，只能以已發布的物件、公開 API 與擴充點為基礎進行開發。它最早出現在 SAP BTP ABAP 環境中，如今所有 S/4HANA 版本都能使用（SAP ABAP Cloud FAQ）。

S/4HANA Cloud 提供三條擴充途徑。關鍵使用者擴充涵蓋簡單的欄位、邏輯與 UI 變更，不必動到 SAP 程式碼。以 ABAP Cloud 進行的開發人員擴充處理緊密耦合的邏輯，而 SAP BTP 上的並行擴充則處理所有應該保持解耦的內容。

您有多少選擇，取決於所用的版本：

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition 與地端部署
ABAP 開發	僅限 ABAP Cloud，自 2208 版起對新客戶強制要求	自 2022 年起建議使用 ABAP Cloud；仍允許傳統 ABAP
修改 SAP 程式碼	不可能	可以，但屬於 D 級
關鍵使用者擴充與 BTP 並行擴充	可用	可用
由誰強制落實 Clean Core	系統	您的治理

我給 Private Edition 客戶的原則是：凡是新開發的內容，都當成 Public Edition 來處理。傳統 ABAP 是允許的，但您今天新增的每一個傳統物件，都是下次升級時必須有人出面辯護的決定。

Clean Core 治理：誰負責決策

Clean Core 決策應由業務與 IT 共同組成的設計治理委員會負責。只交給 IT，凡是技術上可行的都會核准。只交給業務，他們會要求恢復舊流程。

我會這樣安排：

指定成員。 每個主要領域的業務流程負責人，加上解決方案架構師與首席開發人員。業務負責人判斷需求是否真實，IT 決定如何建置。
在開始建置前，先就優先順序達成共識。 先用標準流程，其次是關鍵使用者擴充，再來是以 ABAP Cloud 或 BTP 達成的 A 級。B 級或 C 級需要書面理由，D 級需要退場計畫。
每個擴充申請都必須附上負責人與業務理由。 沒有負責人，就不建置。決策與所接受的等級記錄在同一份登記冊中。
在傳輸之前設置技術關卡。 定期執行 ABAP 測試駕駛艙的 Clean Core 檢查，在新的 D 級程式碼進入正式環境前將其攔下。
每次升級前都檢視登記冊。 淘汰已經沒人使用的內容，並把現在可以提升等級的內容移上去。

過去在那張會議桌上問的是「為什麼這個不能放在 BTP 上？」如今我會問「為什麼這個不能做到 A 級？」如果做不到，下一個問題就是您接受哪個等級，以及原因是什麼。

我看到最大的 Clean Core 錯誤，是試圖讓 SAP 像 Oracle 一樣運作。請採用 SAP 的標準流程，而不是用客製程式碼重建另一套系統的邏輯。如果您還在兩者之間做選擇，我在 SAP 與 Oracle 比較中做了對照。

Clean Core 與變革管理

Clean Core 首先是變革管理問題，其次才是技術問題。每個客製物件之所以存在，都是因為有人提出要求。要移除它，就得說服那個人標準流程已經夠用。

當業務單位看到新流程實際運作，而不是看一張介紹它的簡報時，這種溝通會順利得多。當您去檢驗「流程很獨特」這個說法時，溝通也會更順利，因為它往往並不獨特（見下文第 4 步與第 5 步）。

技能和工具同樣重要。沒有用過 ABAP Cloud 或 BTP 的 ABAP 團隊，在學習期間會拖慢整個計畫。我合作過的一家製造企業，在 S/4HANA 專案啟動前舉辦了為期三個月的內部 BTP 計畫，回報是建置階段的意外明顯減少。

Clean Core 遵循：如何衡量

Clean Core 遵循是指您的系統在 5 大原則上有多少比例符合 SAP 的標準。沒有數字就無法管理，而 SAP 提供了三個取得這些數字的地方。

ABAP 測試駕駛艙。 SAP 用於程式碼層級檢查的工具。它會顯示哪些客製物件使用了未發布的物件、修改或直接存取資料表。
SAP Readiness Check。 它包含在您的維護合約中，能在您做出承諾之前，顯示移轉到 S/4HANA 會影響哪些內容。
RISE with SAP Methodology 儀表板，又稱 Clean Core 儀表板。 它在 SAP Cloud ALM 中執行。其系統檢視會檢查您的 S/4HANA 版本、確認資料收集工具已啟用，並在升級前檢視擴充；其營運檢視則追蹤營運 KPI。

我每個月會放在設計治理委員會面前的數字很簡單。每個等級各有多少客製物件，D 級是否在減少？有多少例外尚未結案，每一個是否都有負責人？

跳過 Clean Core 的團隊並沒有省下這些工作。他們只是把工作延後，而它會以卡住的升級和沒人看得懂的客製程式碼回頭找上門。

我會從哪裡開始

如果您請我下個月評估您的系統，我會依照以下順序進行。

弄清楚哪些有在用。 執行 SAP Readiness Check，並收集客製程式碼的使用資料。在一個計畫中，藉由 smartShift 的分析，我們把 18,000 個客製物件縮減到 3,200 個，因為其餘大部分根本沒有被使用。
將剩下的物件分為 A 至 D 級。 程式碼部分使用 ABAP 測試駕駛艙。如果您使用的是 RISE，之後就由 Clean Core 儀表板追蹤。
逐一物件做決定。 淘汰它、移到已發布的介面、在 BTP 上重建，或保留並記錄理由。從每天都在執行的程式碼開始，因為某個區域團隊一年只用兩次的報表可以晚點再處理。
讓業務單位一起參與。 我合作過的一位財務主管，直到經過 45 分鐘的實際操作說明後，才真正理解新的 Fiori 應用程式。那次說明在 UAT 階段省下了兩週的來回溝通。
挑戰「我們的流程不一樣」。 2023 年，在一家歐洲工業企業的業務團隊工作坊中，所謂「獨特」的流程有 80% 原來是多餘的舊行政作業。拿掉這些變通做法後，標準 SAP 改善了他們的客戶體驗。
及早開始資料工作。 我在 2024 年合作的一家波斯灣地區（GCC）零售客戶，有超過 15,000 個客製欄位需要整理。依我的經驗，資料移轉占導入工作量的 30% 至 40%，我的 SAP 導入成本指南說明了這部分會落在預算的哪裡。
在上線前確立治理。 成立上文所述的設計治理委員會，並讓它成為新擴充的唯一管道。

Clean Core、RISE 與 AI：哪些是必要的，哪些不是

幾乎每次談到這個主題，都會出現三個問題。

在 RISE with SAP 下，Clean Core 是強制的嗎？

並不是一體適用的規定。在 Public Edition 中由系統強制落實，而在 Private Edition 與地端部署中，您仍然可以修改核心。

在後者，Clean Core 是一種治理選擇，SAP 透過 RISE methodology 儀表板加以追蹤。如果系統整合商告訴您這是合約要求，請他們把條款拿給您看。

ECC 我還能用多久？

對於增強套件 6 至 8 上的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束。選擇性的延長維護需額外付費，持續到 2030 年 12 月 31 日。

之後，SAP ERP, private edition, transition option 涵蓋 2031 至 2033 年。它只適用於在 2030 年底前已移到 SAP HANA 上的 SAP ERP, private edition 的大型系統。

請把 2033 年當作例外途徑，而不是規劃日期。我的 ECC 到 S/4HANA 移轉指南介紹了途徑的選擇。

Clean Core 對 AI 重要嗎？

重要。維持 SAP 標準有助於 AI 與 Joule 發揮得更好，而經過大量修改的流程正是它們最難導入的地方。

SAP 的 AI 功能，包括 Joule，都建置在其標準流程與資料模型之上。Joule for developers 會依據已發布的 API 產生 ABAP Cloud 程式碼。關於雲端、AI 與 Clean Core 如何搭配，我在 ERP 現代化中有說明。

跳過 Clean Core 的團隊並沒有省下這些工作。他們只是把工作延後，而它會以卡住的升級、馬拉松式的回歸測試和沒人看得懂的客製程式碼回頭找上門。

在簽署 S/4HANA 或 RISE 合約之前，請您的系統整合商把現有客製程式碼分為 A 至 D 級。如果他們拿不出來，這就能讓您對他們的估算有所判斷。預約通話，我們可以一起看看您的狀況。

常見問題

SAP 中的 Clean Core 是什麼？

Clean Core 是指讓 S/4HANA 貼近 SAP 標準，擴充只透過 SAP 已發布並承諾維持穩定的介面建置。擴充不是用 ABAP Cloud 在堆疊內執行，就是在 SAP BTP 上並行執行。目標是讓升級不會破壞您的客製邏輯。

SAP Clean Core 的 5 大原則是什麼？

SAP 提出的 Clean Core 五項指導原則是流程、擴充性、資料、整合與營運。流程貼近標準，擴充使用已發布的 API，資料在治理模式下保持乾淨。整合使用受支援的技術，營運則涵蓋讓其他四項得以維持的治理、人員與工具。

SAP Clean Core 的 A、B、C、D 級是什麼？

自 2025 年 8 月起，SAP 將擴充分為四個等級。A 級只使用公開發布的穩定介面，B 級也使用傳統 SAP API，C 級會存取 SAP 內部物件。D 級涵蓋修改、寫入 SAP 資料表與隱含式增強，升級風險最高。

RISE with SAP 是否強制要求 Clean Core？

並不是一體適用的規定。S/4HANA Cloud Public Edition 只允許 ABAP Cloud 與已發布的介面，因此在技術上強制落實 Clean Core。在 Private Edition 中您仍然可以修改核心，因此 Clean Core 是一項治理決策，SAP 透過 RISE with SAP Methodology 儀表板加以追蹤。

什麼是 ABAP Cloud？

ABAP Cloud 是 SAP 為雲端設計的 ABAP 開發模型。它只允許已發布的物件、公開 API 與擴充點，讓客製程式碼在升級時保持穩定。自 2208 版起，它在 S/4HANA Cloud Public Edition 中對新客戶是強制要求，並自 2022 年起在 Private Edition 與地端部署中建議使用。

如何衡量 Clean Core？

使用 ABAP 測試駕駛艙進行程式碼層級檢查，並將客製物件分為 A 至 D 級。RISE 客戶可以在 SAP Cloud ALM 的 RISE with SAP Methodology 儀表板（又稱 Clean Core 儀表板）中追蹤採用情況。我追蹤的是每個等級的物件數量、D 級的趨勢，以及有負責人的未結案例外數量。

誰應該負責 SAP Clean Core 治理？

每一項 Clean Core 決策都應由業務與 IT 共同組成的設計治理委員會負責。業務流程負責人判斷需求是否真實，IT 決定如何建置以及採用哪個等級。每個例外都連同負責人一起記錄，並在每次升級前檢視。

SAP ECC 的支援何時結束？

對於增強套件 6 至 8 上的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束，選擇性的延長維護需額外付費，持續到 2030 年 12 月 31 日。SAP ERP, private edition, transition option 持續到 2033 年，但僅適用於在 2030 年底前已移到 SAP HANA 上的 SAP ERP, private edition 的合格大型系統。