如何正確啟動您的 SAP 導入專案

要正確啟動 SAP 導入，在任何人設定任何一個交易之前，先談定五件事。選定部署模式。簽署載明範疇與決策權的專案章程。指定會出席設計工作坊的業務負責人。及早開始資料與切換的工作。建立一份含有真正緩衝的時程。第一個月把這些做對，大多數代價高昂的失敗就不會發生。

我一直以為，只要系統設定正確，SAP 導入就會順利運作。藍圖、建置、測試、上線。這是我遵循多年的思維模型。

我在中東、東南亞與歐洲導入 ERP（包括 SAP）已經 25 年。即使團隊一步一步照著 SAP Activate 走，專案還是會出問題。這些問題幾乎從來不是技術性的。責任歸屬薄弱。沒有人查證的假設。太晚才開始的切換規劃。這些裂縫在一開始看起來無傷大雅。一旦蔓延開來，後期再多的努力，也補救不了早期只要看得見就能避免的問題。

SAP 導入是一項帶有軟體成分的業務變革專案。工作流包括流程設計、組態設定、資料移轉、整合、測試、訓練與變革管理。每一個都有自己的時程、風險與負責人。

把它當成組態設定作業的團隊，會對組態設定以外的一切投入不足。這是我看到最一貫造成上線困難的原因。

對於現在才啟動的專案，還有一個要先談定的工作流：部署模式。S/4HANA Cloud Public Edition（GROW with SAP）、Private Edition（RISE with SAP），或地端部署。這個選擇，決定了其他每一個工作流如何運作。

SAP Activate 是 SAP 的交付方法。它有六個階段，每個階段結束時都有品質關卡。以下是每個階段的用途，以及我絕不讓它出差錯的那件事。

階段	發生什麼	我確保做對的事
Discover	商業案例、高階範疇、部署模式	務實的成本與時程，而不是樂觀的版本
Prepare	治理、專案章程、團隊、風險登錄表、環境	有真正權限、指名的決策者
Explore	Fit-to-Standard 工作坊、落差決策、設計簽核	業務負責人在場，而不只有 IT
Realize	組態設定、開發、整合、系統測試	切換規劃已經在進行
Deploy	使用者驗收測試、資料載入、訓練、切換	至少一次完整彩排
Run	上線、Hypercare、移交支援	Hypercare 的人力編制，要撐過第一次月結

最常見的時程失敗，是 Explore 階段太慢。它會壓縮 Realize，而 Realize 又壓縮 Deploy。使用者驗收測試（UAT）被縮短，資料彩排被跳過，上線卻照常發生，因為日期早已公布。上線後的前 90 天，就要為此付出代價。

1. 01Explore 延遲Fit-to-Standard 與設計簽核延後
2. 02Realize 被壓縮建置與測試的時間變少
3. 03Deploy 被壓縮UAT、資料載入與訓練的時間變少
4. 04測試被砍UAT 被縮短，資料彩排被跳過
5. 05依公布日期上線因為日期已經公布

代價落在 Hypercare，也就是前 90 天

1. 沒有業務參與的設計簽核

Explore 會產出設計。它的品質，取決於簽核的流程負責人是否理解自己簽的是什麼。如果工作坊只有 IT 與顧問出席，設計在技術上可能是正確的，卻仍然讓將要使用它的人認不出來。UAT 於是變成了發現問題，而不是驗證。

一個簡單的測試：簽核三個月後，請一位流程負責人帶您走過上線後採購訂單會如何運作。如果他做不到，那次簽核就不是真的。

2. 只存在於紙面上的治理

沒有落實執行的治理，範疇會非正式地擴張，決策會被延後。好的治理，代表有指名的高階發起人、有明確決策權的指導委員會、能守住階段關卡的專案經理，以及有指名核准人的變更控制流程。

在我大多數的專案中，都是由 CFO 擔任專案的推動者（champion）。當各部門無法就某個流程達成共識時，她會做出最後決定。這避免了問題懸而未決時所造成的數週延誤。我寫的 SAP 指導委員會指南談到了如何設立。

3. 太晚才規劃切換

切換是整個專案在營運上最複雜的部分。在上線前幾週才開始擬定的計畫，不會經過彩排，會漏掉相依關係，也不會有真正的回復點。

在 Realize 階段就開始切換規劃。把順序記錄下來，至少進行一次完整彩排，並預先談定回復準則。在壓力下、由已經清醒二十小時的人、在沒有事先談定準則的情況下做出的切換決策，正是上線後災難的起點。

4. 整合測試被擠掉

老實說，我以前覺得測試只是清單上的一項任務。設定好系統，跑幾個測試案例，然後繼續往下走。後來我看到一個專案分崩離析，只因為沒有人檢查採購核准如何影響財務過帳。那一刻，改變了我看待 SAP 測試的方式。

單元測試證明的是單一交易自己能運作。上線後真正傷人的失敗，出現在完整流程橫跨各模組運行的時候。收貨被採購訂單狀態擋住。開票執行因為缺少科目決定而中止。要測試完整的流程鏈，包括訂單到收款與採購到付款，而且不要讓它們拖到 UAT 之前的最後幾週。

5. 低估資料移轉

來源資料幾乎總是比最初評估所顯示的更糟。看起來簡單的欄位對應，在載入時失敗。筆數統計包含了不活躍的資料。清理規則需要業務做決定，而這些都需要時間。

有一家製造業公司在移轉過程中發現了數千筆重複的客戶記錄，不得不把上線延後三週來修正。從一開始就要規劃額外的載入週期。我寫的為什麼 SAP 資料移轉會失敗一文有更詳細的說明。

6. 把變革管理當成選配

我見過系統運作完美，使用者卻仍然緊抓著舊流程不放的專案。不是因為他們難搞，而是因為沒有人帶他們走過這個轉變。當變革管理被砍掉，變通做法在第一週就會出現，並且變成永久性的，支援工單的數量會好幾個月居高不下。

大量客製化也屬於同一類。我曾與一位客戶合作，他們客製化了系統超過 60%。他們後來很難升級，也失去了廠商的支援。

以上的基本原則沒有改變。今天啟動專案時，有三件事需要先談定。

部署模式要最先決定。 Public Edition 提供的客製化選項最少，系統由 SAP 營運。RISE 之下的 Private Edition 提供更多空間，基礎架構由 SAP 營運。地端部署給予最多的控制權，也帶來最多的責任。在 Discover 階段就決定。把它延後的專案，會把整個 Explore 階段都花在爭論這件事上。

Clean Core 屬於專案章程。 Public Edition 只允許透過已釋出的介面做擴充，所以在技術上強制執行 Clean Core。Private Edition 與地端部署則不會，所以它變成一項治理決策。SAP 現在把擴充分成 A 級（僅使用已釋出的 API）到 D 級（修改），如其 2025 年 8 月的 Clean Core 更新所述。要把目標等級與核准論壇寫進專案章程，否則合作夥伴會預設採用修改的做法。

AI 工具從第一天起就屬於方法的一部分。 Joule 可在 SAP Activate Roadmap Viewer 中使用。Joule for consultants 回答組態設定的問題，Joule for developers 則產生 ABAP Cloud 程式碼。它們能加快草擬與建置的工作。它們不會消除業務決策、資料工作或變革的投入。請問問您的合作夥伴，他們在哪些地方使用它們，以及這在計畫中如何呈現。

做法應該依據您的風險承受度、複雜度與變革的承受能力來決定。以下是常見的選項。

做法	意思	最適合
Big Bang（一次全面上線）	所有模組與實體一起上線	範疇標準的小型組織，且接受較高的上線風險
依模組分階段	先財務，再供應鏈，再人資	彼此相依性少的模組；讓團隊在各階段之間學習
依國家或實體分階段	範本先在一個實體上線，再逐步推廣	擁有全球範本的集團
Brownfield 轉換	把既有的 ECC 轉換為 S/4HANA	流程穩定、成熟的 ECC
Greenfield	全新的 S/4HANA 導入	非 SAP 的舊系統，或技術債沉重的 ECC
選擇性資料轉換	把選定的實體或資料，移入重新設計的系統	併購、業務切割（carve-out）、部分重複使用

我見過小型上線在不到六個月內完成。我也見過專案因為沒有及時做決策，而拖了兩年。如果您正在權衡首次導入與範本推廣，我寫的導入與推廣比較指南比較了兩者。

在第一個月、組態設定開始之前使用。每一項都有客戶端的負責人。

1. 高階發起人： 部署模式已決定並記錄，附上理由。
2. 專案總監： 專案章程已簽署，涵蓋範疇、明確的排除項目、成功準則、決策權與變更控制。口頭的範疇約定會蒸發。我寫的專案章程指南附有範本。
3. 業務主管： 每個領域都有一位指名的流程負責人，並且確實空出時間參加工作坊。
4. 解決方案架構師： 已談定 Clean Core 目標與擴充核准論壇。
5. 資料主管： 在 Prepare 階段就開始資料剖析，而不是等到設計簽核之後。
6. 切換主管： 在 Realize 階段指定，計畫中已排定彩排日期。
7. 測試經理： 已列出完整流程鏈的測試情境，包括從核准到財務過帳。
8. CFO： 時程已對照類似的專案檢驗，並為緩慢的 Explore 與額外的資料週期預留緩衝。假設一切順利的計畫，不算計畫。

什麼是 SAP 導入專案？

它是讓 SAP 軟體就位、用來運行企業營運的專案。涵蓋流程設計、組態設定、資料移轉、整合、測試、訓練與變革管理，通常以 SAP Activate 交付。工作量會因實體、國家與模組的數量，以及您現有資料的狀況而有極大差異。

SAP 導入有哪些階段？

SAP Activate 有六個階段：Discover、Prepare、Explore、Realize、Deploy 與 Run。Discover 訂定商業案例與範疇。Prepare 建立治理與團隊。Explore 進行 Fit-to-Standard 工作坊並確認設計。Realize 負責建置與測試。Deploy 涵蓋 UAT、資料載入、訓練與切換。Run 是上線與 Hypercare。每個階段結束時都有一道品質關卡。

SAP 導入需要多久？

取決於範疇，以及決策做得多快。我見過小型上線在不到六個月內完成，也見過專案因為沒有及時做決策而拖了兩年。造成超支最常見的原因，是緩慢的 Explore 階段，壓縮了之後的一切。

SAP 導入失敗最常見的原因是什麼？

設計在沒有真正業務參與的情況下簽核、治理沒有落實、太晚規劃切換、整合測試被壓縮、低估資料移轉，以及變革管理被砍掉。這六項通常在早期就看得到，而且在那個時間點修正的成本很低。

SAP 專案章程應該包含什麼？

與可衡量成果連結的目標、依模組、實體、國家與整合劃分的範疇、明確的排除項目、指名到人的決策權、治理與升級機制、成功準則、變更控制、重要里程碑與關鍵假設。對於雲端專案，還要加上部署模式與 Clean Core 做法。在組態設定開始之前，取得發起人與業務主管的簽署。

SAP 上線後的 Hypercare 是什麼？

Hypercare 是上線後的密集支援期，通常為 30 到 90 天。專案團隊與業務並肩工作，修正問題並穩定營運。人力編制至少要撐過一個完整的業務週期，包括第一次月結，因為許多問題就是在那時第一次浮現。