S/4HANA 移轉時程與專案計畫：依路徑說明

依我的經驗，從 SAP ECC 出發的 S/4HANA 移轉，Brownfield 轉換需要 12 至 18 個月，Greenfield 導入需要 18 至 24 個月。選擇性資料轉換需要 12 至 18 個月。專案計畫依循 SAP Activate 的六個階段，而最常超時的階段是客製程式碼。

簡短的答案：計畫從 SAP Readiness Check 開始，並把 30% 至 40% 的工作量留給資料。如果是 Brownfield，請規劃三次模擬轉換，並預期切換停機時間從一個週末到一週不等。

本文是我的 ECC 移轉至 S/4HANA 指南背後的時程與規劃細節，那篇指南涵蓋各條路徑與 ECC 的期限。如果您是全新導入 SAP，而不是從 ECC 移轉，我的 SAP 導入時程指南涵蓋這種情況，並列出各階段的工期。

路徑決定長度。我的原則：從其他系統移轉過來或需要定義新流程時，選 Greenfield。流程已定義且運作良好時選 Brownfield，部分領域的流程需要重新定義時選選擇性轉換。

以下是在我看過的計畫中，每條路徑需要多久，以及通常是什麼拉長了時程：

路徑	典型時程	計畫圍繞什麼建立	通常拉長時程的原因
Brownfield（系統轉換）	12 至 18 個月	用 Software Update Manager 轉換現有的 ECC 系統，然後反覆進行測試轉換	客製程式碼調整與業務夥伴轉換
Greenfield（全新導入）	18 至 24 個月	Fit-to-Standard 設計、建置與反覆的資料載入循環	Explore 工作坊變成冗長的需求清單，以及資料清理
選擇性資料轉換	12 至 18 個月	談定哪些公司代碼、單位與歷史資料要移轉，然後使用專門工具	資料範圍界定，以及對專業合作夥伴的依賴

行事曆和路徑一樣重要。強化套件 6 至 8 的 ECC，主流維護於 2027 年 12 月 31 日結束（SAP News）。這個月開始的 Brownfield，會在 2027 年 10 月到 2028 年 4 月之間上線，現在開始的 Greenfield 則會在 2028 年上線。

所以今天寫的大多數計畫，預算裡都需要一些延伸維護。一開始就把它放進去，不要等到第二年才變成意外。

RISE with SAP 是商業套裝方案，不是路徑。在 RISE 下進行的 Brownfield 或選擇性移轉，會落在 SAP Cloud ERP Private，這是 SAP 目前使用的名稱，很多人仍以 S/4HANA Cloud Private Edition 搜尋它。我提到的 GROW with SAP 6 至 9 個月與 RISE 9 至 18 個月，指的是全新導入，不是 ECC 移轉。

SAP Activate 是 SAP 用於 S/4HANA 的交付方法。它有六個階段：Discover、Prepare、Explore、Realize、Deploy 與 Run（SAP Activate）。

移轉使用相同的階段。改變的是每個階段裡的工作。

移轉專案計畫

1. 01

   Discover

   Readiness Check、路徑決策與商業論證。

2. 02

   Prepare

   計畫、治理、團隊與第一個沙箱。

3. 03

   Explore

   Fit-to-Standard 或差異設計，談定 WRICEF 清單。

4. 04

   Realize

   建置、客製程式碼、資料載入、測試轉換。

5. 05

   Deploy

   彩排、切換與上線。

6. 06

   Run

   上線後支援、穩定運作並停用 ECC。

以下是移轉時每個階段包含的工作，以及各路徑的差異：

階段	移轉時要做什麼	各路徑的差異
Discover	SAP Readiness Check、路徑決策、商業論證，初步了解客製程式碼與資料	選擇性轉換需要在這裡先界定資料範圍
Prepare	計畫、治理、團隊、資料負責人、沙箱	Brownfield 進行第一次沙箱轉換；Greenfield 建立系統並排定工作坊時程
Explore	Fit-to-Standard 工作坊或差異設計，談定 WRICEF 清單，資料對應	Greenfield 在這裡花最多時間；Brownfield 逐一處理適用的簡化項目
Realize	建置、客製程式碼調整、資料載入循環、多輪測試	Brownfield 進行模擬轉換；Greenfield 進行載入循環，通常使用 Migration Cockpit
Deploy	彩排、切換、上線	停機時段取決於路徑、資料量與方法
Run	上線後支援、穩定運作	停用 ECC，並歸檔您保留的資料

WRICEF 代表工作流程、報表、介面、轉換、強化與表單。它是所有超出 SAP 標準、需要您自行建置的項目清單，也是最值得盯緊的數字。

在我主導或救回的 21 個 SAP 計畫中，最大的錯誤是在導入一開始沒有好好規劃。在 Prepare 階段，就要談定誰負責資料清理、淘汰哪些客製程式碼，以及每次測試轉換與演練在何時進行。這些日期會成為計畫的骨幹。

Brownfield：圍繞測試轉換規劃

Brownfield 計畫是圍繞轉換循環建立的。Software Update Manager 負責轉換系統，每一次測試執行都會告訴您正式轉換需要多久，以及哪些東西會出問題。

Brownfield 專案在切換前，我會規劃三次模擬轉換。每一次都應該在最近的正式環境複本上執行，這樣時間數據才有意義。最後一次應該和上線一模一樣：相同的順序、相同的人、相同的檢查。

SAP 為其停機時間最佳化方法提出的計畫也類似。它安排了一次沙箱執行、一次品質保證執行、一次在複製系統上的載入驗證，以及一次彩排（SAP Learning）。SAP 指出，技術上可以減少執行次數，但會增加風險。

Greenfield：圍繞設計與資料載入規劃

Greenfield 的時間都花在 Explore。Fit-to-Standard 工作坊決定您採用多少 SAP 標準，而每一個差距都會變成一個需要建置、測試與維護的 WRICEF 物件。

資料以載入循環的方式移轉，通常使用 SAP S/4HANA Migration Cockpit。請規劃數次完整的載入循環，每次之後都要有一次由業務單位簽核的調節。我的 Migration Cockpit 逐步指南涵蓋暫存表、移轉物件與載入流程。

選擇性轉換：圍繞資料範圍規劃

選擇性轉換的計畫從資料範圍開始。哪些公司代碼、事業單位與幾年的歷史資料要移轉，以及哪些流程要重新設計。

這個範圍決定了工具、專業合作夥伴與測試循環。太晚改變範圍，時程就會跟著移動。

依我的經驗，客製程式碼是最常超時的階段。它也是移轉中最常被遺忘的隱藏成本，我的 S/4HANA 移轉成本指南有詳細說明。

以下是我會依序盯緊的地方：

1. **客製程式碼。**團隊根據一份報表界定範圍，到了開始修正時才發現真正的規模。在一個計畫中，透過 smartShift 的分析，客製物件從 18,000 個減少到 3,200 個。先淘汰，再調整。
2. **評估遺漏的客製物件。**依我的經驗，SAP Readiness Check 遺漏的客製物件，正是日後造成傷害的那些。在把它的輸出當成您的範圍之前，先讀我的 SAP Readiness Check 指南。
3. **資料。**資料移轉占工作量的 30% 至 40%。資料清理沒有負責人時，就會太晚開始，接著壓縮測試循環。我的文章為什麼 SAP 資料移轉會失敗有更深入的說明。
4. **Explore。**預算在 Explore 階段被打破，因為 WRICEF 清單不斷增長。當範圍由廠商掌控時，廠商那邊沒有人有理由阻止它增長。
5. **為了省時間而刪減演練。**為了守住日期而取消的演練，在上線週末耗掉的時間，往往比它省下的更多。

我的看法：在 Explore 結束時鎖定上線日期，那時 WRICEF 清單與客製程式碼範圍都已明確。在啟動會議上訂下的日期，只是附上一份董事會簡報的猜測。

我看過的切換停機時間從一個週末到一週不等。資料量、轉換方法、同時上線的實體與介面數量，以及業務單位驗證的速度，都會影響它。

針對 Brownfield，SAP 在 Software Update Manager 中提供停機時間最佳化轉換方法。它把部分資料轉換與移轉移到系統運作期間進行，正式環境照常運作。

這些時間不是白來的。SAP 列出額外的測試執行、更複雜的規劃、停機前凍結客製化設定與開發，以及一位受過此方法訓練的專家。

所以在選擇技術方法之前，先談定業務單位能接受的停機時間。然後在模擬轉換中驗證它，而不是在上線週末。切換要避開月結與旺季。

計畫的好壞取決於背後的假設。以下是我會在任何人簽約之前提出的問題：

1. 計畫假設的是哪一條路徑，我們的 Readiness Check 結果中有什麼支持這個選擇？
2. 經過使用分析後，範圍內有多少客製物件，又有多少會被淘汰？
3. 誰負責資料清理，從哪個階段開始？
4. 規劃了幾次模擬轉換或載入循環，使用什麼資料？
5. 計畫假設多少停機時間，由哪一次測試執行來驗證？
6. 日期何時鎖定，如果 WRICEF 清單在 Explore 階段增長，日期會怎樣？

請合作夥伴提供與您類似計畫的參考案例，以及他們的高階設計。如果答案很籠統，沒有針對您的業務，請把它當成警訊。

這一季就執行 SAP Readiness Check。在任何人承諾上線日期之前，把客製程式碼與資料的發現交給財務長與計畫總監。

接著從您能接受的切換時段往回推，建立計畫。Brownfield 要有三次模擬轉換，其他路徑則安排所需的載入循環。想先檢驗路徑本身，可以試試我的 Greenfield 與 Brownfield 移轉評估。

我協助企業建立並壓力測試像這樣的移轉計畫。如果您想要獨立的觀點，歡迎與我聯絡。

S/4HANA 移轉需要多久？

依我的經驗，從 ECC 進行 Brownfield 轉換需要 12 至 18 個月，Greenfield 導入需要 18 至 24 個月，選擇性資料轉換需要 12 至 18 個月。客製程式碼是最常超時的階段，而資料移轉占工作量的 30% 至 40%。

S/4HANA 移轉專案計畫有哪些階段？

計畫依循 SAP Activate：Discover、Prepare、Explore、Realize、Deploy 與 Run。在移轉中，Discover 包含 Readiness Check 與路徑決策，Realize 包含客製程式碼、資料載入與測試轉換，Deploy 包含彩排與切換。

S/4HANA Brownfield 移轉需要幾次模擬轉換？

Brownfield 專案在切換前，我會規劃三次模擬轉換。針對停機時間最佳化方法，SAP 安排了一次沙箱執行、一次品質保證執行、一次載入驗證與一次彩排，並表示減少執行次數會增加風險。

S/4HANA 切換停機時間有多長？

我看過的切換停機時間從一個週末到一週不等。它取決於資料量、轉換方法，以及有多少實體與介面同時上線。SAP 的停機時間最佳化轉換把部分工作移到系統運作期間，但需要更多測試執行與規劃。

我們能在 2027 年 ECC 支援結束前完成 S/4HANA 移轉嗎？

強化套件 6 至 8 的 ECC，主流維護於 2027 年 12 月 31 日結束。2026 年 10 月開始的 Brownfield，會在 2027 年 10 月到 2028 年 4 月之間上線，Greenfield 則在 2028 年。現在開始的大多數計畫，都應該為一些延伸維護編列預算。

什麼最容易延誤 S/4HANA 移轉專案？

依我的經驗，最常超時的是客製程式碼，其次是太晚開始的資料清理，以及在 Explore 階段不斷增長的 WRICEF 清單。這些問題大多源自計畫一開始沒有好好規劃。