SAP 導入範本：逐階段指南

SAP Activate 為 S/4HANA 專案中幾乎每一項交付成果都提供了範本。您可以在 SAP Activate Roadmap Viewer 找到它們，在雲端專案中則位於 SAP Cloud ALM 內。找到它們很容易。難的是知道該認真對待哪些。

本指南寫給正在設定導入專案的專案經理、PMO 負責人與專案發起人。內容涵蓋我在每個階段都堅持要有的範本，為每一個範本提供可用的版面配置，並標出團隊在哪裡偷工減料。如果距離啟動會議只剩一週，先做範圍界定文件與利害關係人矩陣。下游的一切都倚賴這兩份。

在我參與過的製造、零售與金融服務業 ECC 與 S/4HANA 專案中，模式是一致的。遵循範本的團隊能更早抓到問題。把範本當成可有可無的書面作業的團隊，會在專案中途發現，每一項他們沒有寫下來的決策，都變成了範圍爭議。

這是我預期會看到簽核完成的範本組合，並註明每一份的負責人，以及它必須通過的時間點。

階段	範本	負責人	簽核須在以下之前完成
Prepare	專案範圍界定文件	專案經理（由發起人核准）	Explore 開始
Prepare	商業案例	CFO 或業務負責人	資金撥付
Prepare	利害關係人矩陣	專案經理	Explore 工作坊排定
Explore	需求與 Fit-Gap 表	解決方案架構師與流程負責人	Realize 開始
Realize	組態日誌	功能負責人	每一筆傳輸移入 QA
Realize	自訂開發登記表	開發負責人	任何物件開始開發
Realize	測試策略	測試經理	系統整合測試開始
Realize	資料遷移計畫	資料遷移負責人	第一次模擬載入
Deploy	切換上線計畫	切換上線經理	最後一次彩排
Deploy	上線準備度評估	專案總監（由發起人簽署）	Go/No-go 會議
Run	上線後密集支援模式	服務交付負責人	上線
Run	效能監控表	Basis 負責人	上線

Activate 有六個階段：Discover、Prepare、Explore、Realize、Deploy 與 Run。它結合了 SAP Best Practices 內容、引導式組態與敏捷交付方法。對多數客戶來說，Discover 發生在簽約之前，所以下面的範本從 Prepare 開始。

1. 01Discover通常在簽約之前
2. 02Prepare範圍界定文件、商業案例、利害關係人矩陣
3. 03Explore需求與 Fit-Gap 表
4. 04Realize組態日誌、開發登記表、測試策略、遷移計畫
5. 05Deploy切換上線計畫、上線準備度
6. 06Run上線後支援模式、效能監控

每份範本都在其關卡前完成簽核

階段順序不是可選的。我合作過一家零售商，試圖略過其中一部分，結果重做了三個月的工作。每一道品質關卡的存在都有它的理由。

調整範本時，請保留約 80% 的標準結構。只改動反映您自身情境的部分：產業要求、法規控制、區域特性。全部重寫就失去了意義。

2026 年工具方面的變化

Activate 的結構與先前相同。圍繞它的工具則有所變動。

1. SAP Cloud ALM 在雲端專案中存放範本。 它是 SAP 對 Solution Manager 的接班者，包含在 SAP Enterprise Support 與 RISE with SAP 等雲端訂閱中。範圍界定、需求、測試計畫與切換上線任務，都可以放在那裡，並在彼此之間保有可追溯性。Solution Manager 7.2 將在 2027 年底結束主流維護，部分功能的延伸維護則到 2030 年，所以現有的地端環境還有幾年的時間，而不是十年。
2. Joule 現在進入了方法論工具。 SAP 在 2025 年讓 Joule 可在 Activate Roadmap Viewer 與 SAP Cloud ALM 中使用，所以團隊可以請它提供任務指引，或從藍圖草擬內容。它加快初稿的速度。它不會取代簽署 Fit-Gap 的那個人。
3. Clean Core 現在是有分級的設計規則。 2025 年 8 月，SAP 以四個 Clean Core 等級取代了原本的三層延伸模型，從 A 到 D。Level A 只使用已釋出的 API，不論是在 SAP BTP 上，或是以 ABAP Cloud 在系統內。Level D 則完全不乾淨。Fit-Gap 範本需要一個欄位，記錄每個缺口最終會落在哪裡。
4. Public Edition 縮小了 Fit-Gap 的範圍。 SAP 現在把 S/4HANA Cloud Public Edition 行銷為 SAP Cloud ERP，以 SAP GROW 的名義銷售給中型企業。同樣的六個階段適用，只是文件較輕量，而且只允許使用已釋出 API 的延伸功能，所以「缺口」欄位可能的答案較少。

跳過這項基礎工作的專案，會在 Explore 與 Realize 付出代價。

專案範圍界定範本

定義專案包含什麼、不包含什麼。當有人在三個月後想要增加範圍（一定會有人），這份文件就是參照點。SAP 專案章程位於它之上，載明治理的細節。

項目	內容
標題、發起人、PM	SAP S/4HANA Finance 導入；CFO；指名的資深 PM
背景	現況與推動變革的原因
目標	將結帳週期從 14 天縮短到 5 天；消除手動對帳
範圍內	FI/CO、MM/SD 整合、資料遷移、UAT、上線
範圍外	人資模組、舊報表遷移、ERP 以外的第三方整合
假設	高層發起人可出席每月的指導委員會（SteerCo）；測試資料在第 6 週前確定
限制	固定的上線日期；組態僅使用內部資源
交付成果	已設定完成的系統、測試計畫、切換上線計畫、訓練教材
時程	Prepare：第 1 至 4 週；Explore：第 5 至 10 週；Realize：第 11 至 26 週
核准	Explore 開始之前，需取得專案發起人與 PMO 的簽核

商業案例範本

以財務團隊讀得懂的格式，逐步走完成本效益分析。我有過客戶用這個結構，第一次送件就拿到專案核准，因為數字清楚、假設也寫了下來。

我堅持一條規則：將要執行這項工作的系統整合商，不應該撰寫這份文件。他們的誘因是開工。您的誘因是完工。我的 SAP 商業案例範本更深入地說明效益模型。

項目	內容
負責人與摘要	CFO 或專案總監；為何是現在、什麼會改變、什麼維持不變
問題陳述	具體的營運問題（結帳週期長度、手動權宜做法、系統老舊）
建議做法	Greenfield / Brownfield / 選擇性轉換，附範圍摘要
效益	量化：結帳週期縮短的天數、FTE 節省、錯誤率降低、稽核風險降低
成本與資金	導入、授權或訂閱、內部人力時間、應變預備金；預算來源
風險	前三大風險，附發生機率與影響
建議	繼續 / 有條件繼續 / 延後，並附理由

利害關係人識別矩陣

整理出受導入影響的每個人及其影響力層級。它讓您一眼看出誰需要每週更新，誰只需要在上線前先知會一聲。

利害關係人	角色	關注重點	影響力	參與方式
集團 CFO	高層發起人	專案 ROI、財務結帳改善	高	每月 SteerCo、每週書面更新
IT 總監	技術負責人	系統穩定性、整合、安全	高	每週專案委員會，Realize 期間每日
財務總監	關鍵流程負責人	FI/CO 設計、結帳流程	高	Explore 工作坊、UAT 簽核
廠長	受影響的使用者	MM/PP 流程變更	中	每月變革溝通、參與 UAT
終端使用者（AP/AR）	操作人員	交易層級的變更	低	訓練、上線後密集支援
內部稽核	治理	可追溯性、控制、法遵	中	在品質關卡審查文件

用同一份矩陣來規劃 Prepare 工作坊，依部門收集高階需求。請以您在 Explore 會用的格式為這些需求編號（REQ-001 等），這樣日後就不必重新編號，回溯到原始需求的軌跡也得以保留。

Explore 是導入成形的地方。這些範本會揭露 SAP 開箱即用的功能與業務所需之間的落差。

需求對應與 Fit-Gap 範本

需求對應依部門收集業務需求，並把每一項追溯到系統元件與測試案例。我看過公司跳過這一步，結果做出沒人使用的系統，因為建置依據的是顧問的假設，而不是業務說的話。

Fit-Gap 分析接著呈現標準 SAP 在哪裡滿足每項需求、在哪裡不能。這對我多數客戶來說，都是真正開眼界的一刻。我喜歡看團隊意識到自己可以使用標準功能、而不必付出昂貴自訂程式碼的那個瞬間。

我把兩者放在同一張表，並加上一欄記錄解決途徑。在 S/4HANA 上，每個缺口都需要一個明確的答案：標準組態、關鍵使用者延伸、系統內的開發人員延伸，或 SAP BTP 上的並行延伸。對 SAP 程式碼的傳統修改是成本最高的答案，應該需要有指名的核准人。

需求編號	需求	SAP 元件	Fit / Gap	解決途徑	測試參照
REQ-001	自動化月結傳票	FI-GL、期末結帳	Fit	設定週期性文件範本	TC-001
REQ-002	透過 Fiori 核准採購單	MM 採購、Fiori 核准應用程式	Gap（ECC 中沒有）	標準 S/4HANA 應用程式與工作流程組態	TC-003
REQ-003	公司間開立帳單自動化	SD 開立帳單、FI 整合	Gap	公司間開立帳單組態	TC-010
REQ-004	批次作業監控	Application Jobs 應用程式	Fit	標準應用程式	TC-015
REQ-005	供應商自助服務入口網站	SAP Ariba 或供應商入口網站	Gap	Ariba 整合	TC-020
REQ-006	符合 GDPR 的資料封存	ILM、資料封存	Gap	ILM 政策組態	TC-025
REQ-007	即時成本中心報表	CO、嵌入式分析或 SAC	Gap	嵌入式分析或 SAC 即時連線	TC-030
REQ-008	支援 500 位同時在線使用者	HANA 容量規劃	Gap（已測試 300 位）	容量規劃檢討與基礎架構升級	TC-035

這是建置階段。這些範本是每一項組態決策、每一項開發與每一項測試結果的稽核軌跡。

組態追蹤範本

記錄每一次系統變更：誰做的、為什麼做，以及放進了哪一筆傳輸。當日後有東西壞掉時，您用幾分鐘就能追到問題，而不是幾天。

1. 組態編號與模組：[例如 MM-CONF-001、MM]
2. IMG 路徑與組態物件：[例如資料表 T161、採購單文件類型]
3. 目的與受影響的業務流程
4. 設定人員與日期
5. 傳輸請求編號：[例如 DEVK900123]
6. 關鍵值：變更前後
7. 連結的測試案例
8. 驗證與核准狀態

自訂開發登記表

在任何人寫程式碼之前，每個自訂物件都要先有一列。我有一位客戶把自訂程式碼減少了 30%，因為登記表顯示了標準 SAP 完全可以勝任的地方。

開發編號	物件	說明	開發人員	工時（小時）	狀態	延伸類型
CD-001	Fiori 圖磚：成本中心總覽	供財務使用的即時 CO 報表圖磚	Fiori 開發人員	12	已完成	開發人員延伸
CD-002	公司間開立帳單報表	IC 對帳報表	ABAP 開發人員	20	進行中	開發人員延伸
CD-004	供應商付款狀態應用程式	供 AP 付款查詢使用的 Fiori 應用程式	BTP 開發人員	10	待 QA	BTP 上的並行延伸
CD-005	收貨通知	收貨過帳時觸發電子郵件	整合開發人員	24	已規劃	事件驅動，位於 BTP 上

測試策略範本

把所有測試計畫放在同一處：誰在何時、於哪個環境、依什麼標準測試什麼。

項目	內容
範圍	涵蓋範圍內各模組的功能、整合、回歸、效能與 UAT（滲透測試由資安團隊負責）
環境	DEV、QA、UAT（正式前環境）、供最終驗證的 staging
工具	測試管理使用 SAP Cloud ALM 或 Jira/Xray；自動化使用 Tricentis Tosca 或類似工具；效能使用 JMeter 或 LoadRunner
缺陷生命週期	新增、處理中、已解決、已驗證、已關閉；嚴重度與優先順序於分流時設定
結束標準	所有重大缺陷已關閉；已取得 UAT 簽核；回歸測試通過率至少 95%；效能基準達標

資料遷移規劃範本

資料遷移是最可能讓您吃虧的工作範疇。這份範本把它拆解成步驟，讓資料品質問題在切換上線之前，而不是之中，就暴露出來。資料遷移失敗模式這篇文章說明了跳過它時會出什麼問題。

項目	內容
範圍	客戶主檔、供應商主檔、未結項目、物料主檔、庫存餘額、成本中心階層
來源系統	ECC 6.0 EHP 7（主要）；舊有人資系統（員工成本中心指派）
目標系統	S/4HANA（目前版本）
對應與規則	客戶與供應商轉為 Business Partner；成本中心轉入新階層；移除無效的銀行資料；合併重複資料
遷移工具	SAP S/4HANA Migration Cockpit（主要）；自訂物件使用 Migration Object Modeler；前置處理使用腳本
載入策略	在 QA 做模擬載入；差異遷移與對帳；正式環境切換上線
驗證方式	來源到目標的筆數核對；10% 隨機抽樣；餘額對帳報表
回退計畫	切換前備份；舊系統待命 48 小時

Deploy 階段就是您上線的時候。這些範本把混亂的週末，變成受管理的事件。

切換上線規劃範本

逐小時規劃停機時段。每一項任務、每一位負責人、每個開始時間。您的團隊不該在凌晨 2 點站在原地，不知道下一步該做什麼。

在寫任務清單之前，先同意四件事：時段（例如週五 22:00 到週六 06:00）、回退觸發條件、舊系統能多快重新啟用，以及證明新系統運作正常的冒煙測試。接著是任務順序：

步驟	說明	負責人	開始時間	狀態
1	凍結 ECC 系統（不得過帳）	Basis	22:00	待處理
2	最終資料擷取與對帳	資料遷移負責人	22:30	待處理
3	執行正式環境遷移載入	DBA	23:00	待處理
4	將剩餘的傳輸匯入正式環境	Basis	00:30	待處理
5	DNS 與負載平衡器切換到 S/4HANA	網路	01:30	待處理
6	冒煙測試：FI 過帳、收貨、銷售訂單	QA 負責人	02:00	待處理
7	業務確認與 Go/No-go 決策	專案總監	03:00	待處理
8	開放系統給業務使用者	Basis	06:00	待處理

上線準備度評估

決定您是否真的準備好切換。我有過客戶根據這份評估延後上線，事後他們還感謝我。

領域	檢查項目（每項以是或否回答，並附證據）
功能面	關鍵流程已測試；跨模組情境已完成；列出未結的 P1/P2 缺陷；關鍵使用者確認已準備好
資料	主檔資料載入完成；交易資料已驗證；對帳報表已核准；舊系統凍結已確認
技術	切換上線計畫已核准；傳輸已在正式環境；批次作業已排程；監控已設定
人員	訓練涵蓋率 %；存取角色已驗證；上線後支援團隊已就位；支援計畫已溝通
決策	列出重大風險與緩解措施；Go / No-go / 有條件通過；由姓名、職位與日期核准

上線之後，工作的形態改變了。這些範本帶著系統與團隊度過上線後密集支援，進入穩態。

上線後支援範本

整理您在上線後如何處理問題。沒有它，每個問題都會變成 P1。

項目	內容
密集支援期間	上線後第 1 至 4 週：24/7 全天候覆蓋
支援管道	ServiceNow 事件佇列（主要）；專用聊天頻道；P1 問題使用電話會議橋接
支援層級	1：服務台（密碼、導覽、已知問題）；2：功能顧問（流程詢問、小幅組態）；3：Basis 與開發（系統錯誤、效能、介面）
SLA（回應 / 解決）	重大 15 分鐘 / 2 小時；高 30 分鐘 / 4 小時；中 4 小時 / 1 天；低 1 天 / 3 天
監控	SAP Cloud ALM 或 Solution Manager；每日檢視錯誤日誌
結束標準	無未結的 P1/P2 問題；所有事件皆已記錄；最終交接簽核

效能監控範本

它讓您逐日觀察系統健康狀況，在使用者抱怨之前發現變慢。我最近就這樣協助一家公司抓出一個資料庫問題，否則它會在月結期間讓系統當機。

指標	目標	工具	警示門檻	負責人
對話回應時間（第 95 百分位）	低於 1 秒	ST03 / SAP Cloud ALM	2 秒	Basis 團隊
背景作業完成率	依排程 100%	SM37 / Application Jobs	任何失敗的作業	營運負責人
資料庫查詢時間	低於 200ms	SAP HANA cockpit	500ms	DBA
系統可用性	高於 99.5%	SAP Cloud ALM	低於 99%	基礎架構
介面錯誤率	低於 1%	SAP Integration Suite 監控	2%	中介軟體負責人
登入成功率	高於 98%	安全稽核日誌	低於 95%	資安負責人
月結作業執行時間	在約定的時段內	作業排程器	超出基準 30% 以上	財務營運

品質關卡能阻止某個階段的問題，變成下一個階段昂貴的重工。我的 SAP 品質關卡指南說明了如何設置。以下是它們為何重要。

上線前的高層簽核不該只是橡皮圖章。在我參與的一個專案中，CEO 在上線審查時抓出一個大問題，否則它會打亂財務團隊的工作。

在每道關卡設定通過／未通過的標準。「95% 的回歸測試必須通過。」「所有 FI 整合情境皆為綠燈。」像這樣的標準，讓您在業務不顧品質、堅持要在某個日期上線時，有可站得住腳的依據來守住防線。

在我的一個專案中，當整合測試只通過 75% 時，品質關卡擋下了我們。我們先修好問題，而不是急著往前衝。這為客戶省下上線後約 €100,000 的緊急修復費用。

發起人一通電話就能推翻的關卡，就不是關卡。請在需要之前，先寫下誰有權豁免。

什麼是 SAP Activate 方法論？

SAP Activate 是 SAP 針對 S/4HANA 與其他雲端產品的導入方法論。它分為六個階段（Discover、Prepare、Explore、Realize、Deploy、Run），結合 SAP Best Practices 內容、引導式組態與敏捷交付。

各種部署情境的任務清單與交付成果範本，都發布在 SAP Activate Roadmap Viewer 中。

SAP Activate 的哪個階段擁有最重要的範本？

Prepare。範圍界定文件、商業案例與利害關係人矩陣，為後續的每一項決策奠定基礎，而它們正是團隊為了更快進入組態而跳過的。這個捷徑是 Realize 階段範圍爭議最常見的原因。

Explore 排第二。Fit-Gap 與需求對應文件中的缺口，會在數個月後以 UAT 缺陷的形式浮現，到那時修正的成本，遠高於在 Explore 第 3 週時的成本。

可以客製化 SAP Activate 範本嗎？

可以。保留約 80% 的標準結構，只改動您情境特有的部分：製藥驗證、公部門採購規則、SOX 控制。請在 Prepare 開始時加入這些，而不是在 Deploy。

不要客製化品質關卡的結構、階段順序，或必備的文件（範圍界定文件、商業案例、上線準備度評估）。

SAP Activate 範本同時適用於 Greenfield 與 Brownfield 嗎？

適用。主要差異在 Explore。Brownfield 轉換會沿用現有的組態，所以 Fit-Gap 著重在哪些必須改變、標準 S/4HANA 現在可以取代哪些自訂程式碼，以及轉換前需要哪些資料清理。Greenfield 專案則從 SAP Best Practices 出發，確認哪些標準流程適用。

切換上線計畫也不同。Brownfield 系統轉換遵循的順序，與包含完整資料遷移的 Greenfield 上線不同。

切換上線計畫應該多詳細？

至少逐小時，停機時段還要更緊密。每項任務都需要開始時間、負責人與相依項目。

請在切換開始之前，先同意回退的標準：哪些條件會觸發回到舊系統、由誰做這個決定，以及在幾點之前。凌晨 4 點在沒有事先約定標準的情況下做出的回退決定，正是上線後災難的起點。