SAP 導入時程規劃：各階段工期與該避開的 5 個錯誤

依我的經驗，SAP 導入在 GROW with SAP 上需要 6 到 9 個月，在 RISE with SAP 上需要 9 到 18 個月。從 SAP ECC 移出，棕地轉換或選擇性資料移轉需要 12 到 18 個月，綠地導入需要 18 到 24 個月。

簡單的回答：在 Explore 結束時鎖定日期，而不是在專案啟動時，並在供應商估算之外再加 15% 到 20% 的緩衝。資料工作要在 Discover 階段就開始，因為資料移轉占導入工作量的 30% 到 40%。每多延誤一個月，光是顧問費就至少是六位數。

這份指南是寫給正在擬定計畫或搶救計畫的專案總監與發起人。它談的是要多久，而不是怎麼做：每個階段做什麼、由誰來做，請參考我的 SAP 導入逐步指南。

2024 年在歐洲的一個製造業專案上，我遇到一位專案經理，他的 SAP 專案比計畫落後六個月。嚴格依照 SAP Activate 的階段重新調整後，他們用四個月完成了剩下的工作。

他的原話是：「有了清楚的階段和具體的交付成果，一切都不一樣了。我們一直很清楚下一步要做什麼。」

對 SAP 導入時程影響最大的，是部署模式的選擇。以下是我做規劃時的基準範圍：

起點與目標	一般工期	決定進度的因素
GROW with SAP（SAP Cloud ERP，公有版）	6 到 9 個月	只用標準流程；擴充建立在已發布的 API 上
RISE with SAP（SAP Cloud ERP Private）	9 到 18 個月	範圍、擴充數量、資料量
ECC 棕地轉換	12 到 18 個月	客製程式碼、簡化項目、測試
從 ECC 進行綠地導入	18 到 24 個月	流程再造、使用者承受的變革負擔
選擇性資料移轉	12 到 18 個月	資料範圍界定與專業工具

相較之下，一位審閱過數百個公有版專案的 SAP 產品專家認為，一般的上線時間是 五到七個月。SAP 在 2026 年初推出的 GROW Fast，目標是在固定範圍內用兩到四個月完成。我仍以 6 到 9 個月來規劃 GROW 專案，因為資料、決策和訓練需要的時間，軟體省不掉。

在 RISE 上，基礎架構由 SAP 營運，這會省下一部分 Prepare 階段的工作，但省不掉資料、測試和變革方面的工作。如何在棕地、綠地和選擇性之間做選擇，ECC 到 S/4HANA 移轉指南有說明。

SAP Concur 是差旅與費用管理產品，屬於獨立的雲端產品，有自己的專案。請把它當作獨立的工作流來規劃，並有自己與 S/4HANA 財務的整合，而不是放進 S/4HANA 的階段計畫裡。

預算和日期在哪裡失守

我看過最大的錯誤，是一開始沒有好好規劃。日期和預算在 Explore 階段超支：工作流程、報表、介面、資料轉換、強化功能與表單（WRICEF）清單不斷膨脹，掌控範圍的變成供應商，而不是客戶。

我的 SAP 導入成本拆解說明了這如何演變成 50% 的超支。守得住的時程有三個共同點：實際的緩衝、鎖定前經過驗證的假設，以及被當成硬性停止點的品質關卡。

大多數超時都出自五個錯誤。每一個都可以預見，每一個都有對策。

錯誤一：還沒弄清範圍就訂下截止日期

2023 年在波灣地區的一個零售專案上，客戶向董事會承諾九個月完成導入，沒有留任何緩衝。資料移轉比預期花了更久，結果錯過截止日期三個月，高階主管也對團隊失去信心。我直接告訴他們：那個時程太激進了。

對策：在 Explore 之後鎖定時程，而不是在專案啟動時，並且一開始就告訴董事會。在供應商估算之外再加 15% 到 20% 的緩衝。

錯誤二：把資料移轉當成可以晚點開始的工作流

大多數團隊太晚任命資料移轉負責人，投入的資源也不足。最初的資料評估幾乎總是低估問題，接著就是在系統已上線的壓力下進行三個月的清理。

對策：資料剖析要在 Discover 階段開始，而不是 Realize。在整合測試開始之前，於 Realize 階段完整跑一次模擬移轉。我的文章 SAP 資料移轉為什麼會失敗詳細說明了模擬移轉的週期。

錯誤三：在時程壓力下跳過品質關卡

Realize 和 Deploy 之間的關卡，是團隊最常跳過的一道，因為「先上線再說」的壓力在這裡達到最高。為了「守住時程」而跳過品質關卡，之後會造成更大的延誤。

對策：把可衡量的退出標準寫進專案章程，並由指導委員會執行。我在每個專案都把為期三天的月結演練當作就緒關卡。關卡設計的更多內容，請參考我的 SAP 品質關卡指南。

錯誤四：在上線前兩個月訓練使用者

2024 年在波灣地區的一個零售專案上，客戶在上線前兩個月就訓練了所有使用者。到了上線當天，大多數人已經忘了系統怎麼用。我們在每個工作站都放了操作指引，並把現場支援人力加倍。

對策：把訓練安排在上線前兩到三週，並由關鍵使用者擔任講師，因為人們會向自己信任的同事學習。我的 SAP 員工訓練策略文章有完整的做法。

錯誤五：把上線排在業務高峰期

Hershey 在 1999 年 7 月讓以 SAP R/3、Siebel 和 Manugistics 組成的系統上線，比計畫晚了三個月，正好撞上萬聖節訂貨季。該公司的 CEO 告訴分析師，這些問題會讓 Hershey 無法交付 價值 1 億美元的萬聖節訂單。

對策：為每個受影響的事業單位標出高峰週期，包括月底與季底結帳。即使要延後六週，也要選在業務量低的時段上線。延後可以追回，旺季上線失敗卻無法挽回。

SAP Activate 有六個階段，無論雲端或地端部署，它們都是所有 S/4HANA 計畫的骨架。以下工期是單一專案做規劃時的起點，不是承諾。

1. 1Discover2 到 4 週。退出條件：簽署範圍與成功標準
2. 2Prepare3 到 6 週。退出條件：章程核准，資源書面承諾
3. 3Explore4 到 8 週。退出條件：差異決策有負責人，時程鎖定
4. 4Realize8 到 16 週。退出條件：模擬移轉通過，整合測試結案
5. 5Deploy2 到 4 週。退出條件：UAT 簽核、月結演練、上線決策
6. 6Run4 到 8 週的上線後支援。退出條件：缺陷低於門檻，支援移交簽核

這是我每次做規劃時的起點階段表：

階段	一般工期	主要工作	進入下一階段前的退出關卡
Discover	2 到 4 週	商業論證、範圍、部署方式選擇（公有雲、私有雲或地端部署）	簽署範圍與可衡量的成功標準
Prepare	3 到 6 週	團隊到職、治理、系統環境、基準計畫、風險登錄表	章程核准，每個模組有指定的決策者，資源有書面承諾
Explore	4 到 8 週	Fit-to-Standard 工作坊、差異紀錄、WRICEF 清單	差異決策連同負責人一起記錄；時程鎖定
Realize	8 到 16 週	設定、開發、單元與整合測試、模擬移轉	模擬移轉通過；整合測試結案
Deploy	2 到 4 週	使用者驗收測試、切換演練、終端使用者訓練、最終資料載入	UAT 簽核、月結演練通過、上線決策
Run	4 到 8 週的上線後支援	現場支援、每日問題分流、移交給維運支援	未結缺陷低於約定門檻；支援移交簽核

時間實際花在哪裡

Discover 常被趕工。團隊還沒弄清範圍就訂下截止日期，也略過可衡量的成功標準，例如「把月結縮短三天」。

在地端部署中，技術上的延誤從 Prepare 就開始了，因為基礎架構由客戶和合作夥伴建置。資源承諾要白紙黑字。口頭答應的時間說不見就不見。

Explore 階段的紀錄很重要。如果當初沒有把決策和負責人寫下來，六個月後就沒人記得退貨為什麼要那樣處理。

Realize 是最長的階段，也是大多數超時發生的地方，原因通常是 Explore 產出了一份過於樂觀的差異清單。您的第一次模擬移轉一定會失敗，而您需要它在測試中失敗，而不是在正式環境。

Deploy 需要一份切換計畫，寫明確切的步驟、時間和負責人。「移轉資料」不算一個步驟。

2023 年在美國的一個醫療保健專案上，客戶比計畫落後三個月，面臨 200 萬美元的預算超支。我們用 SAP Activate 的 Fit-to-Standard 工作坊重新調整。團隊找出了 28 個可以零客製化運作的流程。

他們專案經理的原話是：「我們浪費了好幾個月，去設計 SAP 早就做好的東西。」六週內，他們就回到原定時程。

2024 年在歐洲的一個零售專案上，客戶發現自己 70% 的需求都能由 SAP 標準流程滿足。在親眼看到系統實際運作之前，它一直在規劃大量客製化。

Clean Core 讓這一點更加明顯。在公有版上，標準流程是唯一的選擇，擴充放在 SAP BTP 或已發布的 API 上。在私有版和地端部署上仍然可以修改，但當每個差異都需要一個附帶成本的擴充決策時，關於客製化的討論就會變得更坦白。

每個產業都會帶來自己的拖累。以下範圍涵蓋完整的多廠區 S/4HANA 企業級專案，所以比 9 到 18 個月的單次 RISE 部署更長：

產業	規劃範圍	拉長工期的因素
製造業	14 到 20 個月	BOM 與途程品質、MRP 調校、QM 需求
零售與消費品	12 到 18 個月	POS 整合、主檔資料量、旺季時段
製藥	16 到 22 個月	GxP 驗證、批次追溯、序號化
公用事業	15 到 20 個月	設備管理、計費費率結構、GIS 與 SCADA 整合
公部門	18 到 24 個月	基金會計、採購法規、核准負擔、資料落地要求
汽車	16 到 22 個月	及時化供應鏈、工程變更控管
航太與國防	20 到 26 個月	政府報告、計畫會計、安全供應鏈
石油與天然氣	18 到 24 個月	合資會計、資產密集型營運
金融服務	14 到 20 個月	依職責分離設計角色、法規驗證

AI 工具能改變什麼，不能改變什麼

SAP Joule for Consultants 於 2025 年正式推出。它能根據 SAP 自己的知識庫（包括 SAP Notes）回答設定問題，並解釋 ABAP 程式碼。SAP Build Code 自 2024 年 3 月起正式推出，透過 Joule 在 SAP BTP 上產生 Java 和 JavaScript 擴充程式碼。

兩者都能幫助個別的顧問和開發人員。但兩者都無法改變工作坊、決策、資料清理和使用者驗收所需的時間。規劃時可以把它們納入，但在您自己的團隊實際量測出效果之前，不要從計畫裡砍掉好幾週。

以下是我會放進每週專案會議議程的風險。任何一項若拖到每月的指導委員會再處理，都會讓日期移動。

1. 後期範圍變更。 在 Explore 結束時鎖定範圍。之後每項變更都要由變更控管委員會核准，並附上對時程和預算的影響。
2. 資料品質。 大多數企業在規劃階段略過了資料評估。資料品質差，是模擬移轉失敗最一致的原因。
3. 資源瓶頸。 請部門主管以書面承諾具體的人選和日期。為每個關鍵角色培養一位備援。
4. 決策延宕。 範圍上的歧見要在 48 小時內往上呈報。不要讓決策排隊等每月的檢討會。
5. 變革管理太晚。 在 Prepare 階段就開始和終端使用者溝通，而不是上線前兩週。

工具方面，SAP Cloud ALM 是 SAP 用於導入管理的平台。SAP Solution Manager 7.2 的主流維護將於 2027 年底結束，部分功能的延長維護到 2030 年。SAP Best Practices Explorer 已於 2023 年停用，其流程內容現在放在 SAP Signavio Process Navigator 中。

本指南是我的SAP 導入指南的一部分，該指南彙整了從商業論證到上線的所有主題。

SAP S/4HANA 導入要多久？

依我的經驗，GROW with SAP（公有版）需要 6 到 9 個月，RISE with SAP（私有版）需要 9 到 18 個月。從 ECC 移轉，棕地轉換或選擇性資料移轉需要 12 到 18 個月，綠地導入需要 18 到 24 個月。

SAP Activate 每個階段要多久？

作為規劃起點：Discover 2 到 4 週、Prepare 3 到 6 週、Explore 4 到 8 週、Realize 8 到 16 週、Deploy 2 到 4 週，Run 則是 4 到 8 週的上線後支援。在較大的專案上，Realize 拉長得最多。

RISE with SAP 對時程有什麼影響？

RISE 把基礎架構的責任交給 SAP，這會省下一部分 Prepare 階段的工作。但它不會縮短資料移轉、測試、訓練或決策的時間，而大部分的時間正是花在這些地方。如果 Clean Core 紀律能在客製開發開始之前就擋下來，就能縮短 Realize。

SAP 導入時程應該保留多少緩衝？

在供應商估算之外再加 15% 到 20% 的緩衝。在 Explore 結束、範圍和差異都清楚時鎖定日期，並在專案啟動前就告訴董事會。

如何縮短 SAP 導入時程？

徹底執行 Fit-to-Standard，因為每避免一項客製化都能省下好幾週。在 Discover 階段就開始資料清理，業務人員要全職投入，而不是兼職借調。在 Realize 期間而不是之後準備切換計畫。

SAP 導入應該選擇大爆炸式還是分階段？

大爆炸式是一次全部上線。整體較快，風險也較高，適合範圍較小或變革管理能力強的組織。分階段則依模組、廠區或事業單位逐步進行，風險較低、時間較長，適合大型多實體集團。

SAP 專案延誤最常見的原因是什麼？

失控的變更請求、意料之外的資料品質問題、變革管理太晚、第三方整合失敗、專案中途流失關鍵人員，以及指導委員會決策緩慢。最讓大多數團隊意外的是資料品質。大家都以為舊系統的資料是乾淨的，但它幾乎從來都不是。

SAP 上線後的支援期（Hypercare）要多久？

規劃四到八週的上線後支援：現場支援、每日問題分流和效能監控。之後，系統移交給應用系統支援團隊或內部的卓越中心。