SAP 導入範本：逐階段的 SAP Activate 範本組合

SAP Activate 範本是 SAP 為 S/4HANA 專案每個階段發布的導入範本與加速器，從 Prepare 階段的範圍界定文件到 Deploy 階段的切換計畫。您可以在 SAP Activate Roadmap Viewer 中找到它們，雲端專案也可以在 SAP Cloud ALM 中取得。

簡短的答案：您不需要全部範本。您需要的是十來份，每份都有具名的負責人與簽核時點，並且應保留 SAP 標準結構的約 80%。下表是我在親自主導或救回的 21 個 SAP 專案中堅持要求的一套範本。

找到範本很容易。難的是知道哪些要認真看待。

這是我要求完成簽核的一套 SAP 導入範本，列出負責人與每份範本必須通過的時點。

階段	範本	負責人	簽核期限
Prepare	專案範圍界定文件	專案經理（發起人核准）	Explore 開始前
Prepare	商業論證	CFO 或業務負責人	資金撥付前
Prepare	利害關係人矩陣	專案經理	Explore 工作坊排定前
Explore	需求與差異分析表	設計委員會（業務與 IT）	Realize 開始前
Realize	組態記錄	各模組功能負責人	每個傳輸請求進入 QA 前
Realize	客製開發登記表	開發負責人	任何物件開始開發前
Realize	測試策略	測試經理	系統整合測試開始前
Realize	資料移轉計畫	資料移轉負責人	第一次模擬匯入前
Deploy	切換計畫	切換經理	最終演練前
Deploy	上線就緒檢查清單	專案總監（發起人簽署）	Go/No-Go 會議前
Deploy	Hypercare 支援模式	服務交付負責人	上線前
Run	效能監控表	Basis 負責人	上線前

SAP Activate 有六個階段：Discover、Prepare、Explore、Realize、Deploy 與 Run。它結合了 SAP Best Practices 內容、方法論與引導式組態。Discover 是不做承諾的研究階段，因此對大多數客戶而言，它在合約簽訂前就結束了，下面的範本從 Prepare 開始。

1. 01Discover通常在合約簽訂前
2. 02Prepare範圍界定文件、商業論證、利害關係人矩陣
3. 03Explore需求與差異分析表
4. 04Realize組態記錄、開發登記表、測試策略、移轉計畫
5. 05Deploy切換計畫、上線就緒、Hypercare
6. 06Run效能監控

每份範本在對應關卡前完成簽核

在 Roadmap Viewer 中，每個路線圖分為階段、交付物與任務。範本以加速器的形式歸檔：操作指南、範例文件與檢查清單，連結在需要它們的任務下。您可以依階段、工作流或加速器篩選，這是取出某一階段 SAP Activate 交付物最快的方法。

調整範本時，保留約 80% 的標準結構。只改反映您自身情況的部分：產業需求、法規內控、地區特性。全部重寫，就失去使用範本的意義。

工具上的變化

階段結構沒有變。周邊的工具變了。

1. 在雲端專案中，範本位於 SAP Cloud ALM。 它提供給享有 SAP Enterprise Support 的客戶，並隨 RISE with SAP 等 SAP 雲端訂閱一併提供。Solution Manager 7.2 的主流維護到 2027 年底，部分功能的延長維護到 2030 年。
2. Joule 已進入方法論工具。 SAP 在 2025 年將 Joule 加入 Roadmap Viewer 與 SAP Cloud ALM，團隊可以請它提供任務指引或初稿。它無法取代在差異分析上簽名的人。
3. Clean Core 現在分級了。 2025 年 8 月，SAP 推出 A 到 D 四個 Clean Core 等級：A 級只使用已發布的 API，D 級則不屬於 Clean Core。您的差異分析表需要一欄，標明每個差異將落在哪個等級。

跳過這些基礎工作的專案，會在 Explore 與 Realize 階段付出代價。下面三份文件，是團隊為了更快進入組態而跳過的。

專案範圍界定文件

它界定專案包含什麼、不包含什麼。三個月後有人想追加範圍時（一定會有），它就是依據。

我期望看到的部分：

1. 名稱、發起人與專案經理。
2. 背景：現況與變革的理由。
3. 量化目標，例如「結帳週期從 14 天縮短到 5 天」。
4. 範圍內：依模組與流程列出（FI/CO、MM/SD 整合、資料移轉、UAT、上線）。
5. 範圍外：寫得和範圍內一樣明確（人力資源、舊報表移轉、非 ERP 介面）。
6. 假設與限制，例如發起人能出席每月的指導委員會，以及固定的上線日期。
7. 分階段時程，在 Explore 開始前由發起人與 PMO 簽核。

時程要依實際情況訂定。依我的經驗，GROW 專案需要 6 到 9 個月，RISE 需要 9 到 18 個月，Brownfield 轉換需要 12 到 18 個月，Greenfield 需要 18 到 24 個月；我的 SAP 導入時程指南 依階段做了拆解。

商業論證範本

它以財務團隊看得懂的格式列出成本效益分析。我有客戶用這個結構第一次提交就獲得專案核准，因為數字清楚，假設也寫明了。

結構如下：

1. 負責人與摘要：為什麼是現在，什麼會變，什麼不變。
2. 問題陳述：結帳週期長度、手工替代做法、系統老舊程度。
3. 建議做法：Greenfield、Brownfield 或選擇性轉換，並附範圍摘要。
4. 量化效益：縮短的結帳天數、FTE 工時、錯誤率、稽核風險。
5. 成本與資金：導入、授權或訂閱、內部工時、預備金。
6. 前三大風險，及其機率與影響。
7. 建議：推進、有條件推進或延後。

我堅持一條原則：負責交付的系統整合商不應撰寫這份文件。他們的動機是開工。您的動機是完工。我的 SAP 商業論證範本 對效益模型談得更深入。

利害關係人矩陣

它列出受導入影響的每個人、他們的影響力，以及您如何與他們溝通。它告訴您誰需要每週更新，誰需要在上線前先打聲招呼。

為每個群體記錄角色、關注點、影響力與溝通方式。典型的組合是：擔任發起人的 CFO（每月指導委員會）、擔任技術負責人的 IT 主管、擔任關鍵流程負責人的財務主管、作為受影響使用者的廠長與應付／應收使用者，以及在品質關卡參與的內部稽核。

用同一份矩陣規劃 Prepare 階段蒐集高階需求的工作坊。現在就以 Explore 階段將使用的格式編號（REQ-001 等），這樣才能一路追溯到最初的需求。

Explore 階段透過對照 SAP Best Practices 的 Fit-to-Standard 工作坊確定設計。這也是 SAP 預算超支的地方，因為 WRICEF 數量（工作流程、報表、介面、轉換、強化與表單）在這裡增加。

不要讓階段順序走樣。2023 年在歐洲的一個零售專案中，客戶試圖跳過 Explore，結果在不完整的需求上開發了三個月。我的 SAP 導入成本拆解 說明了這類重工如何變成預算。

需求與差異分析表

需求對應把每項業務需求追溯到一個系統元件與一個測試案例。差異分析再顯示標準 SAP 在哪裡滿足需求，在哪裡不滿足。

我把兩者放在同一張表，並設一欄寫解決路徑。在 S/4HANA 上，每個差異都需要明確的答案：標準組態、關鍵使用者擴充、系統內的開發者擴充，或建置在 SAP BTP 上的並行擴充。

需求 ID	需求	SAP 元件	符合 / 差異	解決路徑	測試編號
REQ-001	月結分錄自動化	FI-GL 期末結帳	符合	循環傳票組態	TC-001
REQ-002	行動裝置上的採購單核准	MM 採購、Fiori 核准應用程式	S/4HANA 中符合	標準應用程式與工作流程組態	TC-003
REQ-003	公司間開票自動化	SD 開票、FI 整合	符合	公司間開票組態	TC-010
REQ-004	符合隱私規範的資料封存	Information Lifecycle Management	差異	ILM 原則組態	TC-025
REQ-005	即時成本中心報表	CO、嵌入式分析或 SAC	差異	嵌入式分析或 SAC 即時連線	TC-030
REQ-006	供應商自助入口網站	SAP Ariba 或供應商入口網站	差異	Ariba 整合	TC-020

省錢就省在這裡。2023 年歐洲一家製造企業從 ECC 移轉到 S/4HANA，差異分析工作坊讓計畫中的強化減少了 35%，節省金額達到六位數。

讓這張表發揮作用有兩條規則。廠商不能掌控範圍，因為他們標記為開發的每個差異，都是他們可以計費的工作。由業務與 IT 組成的設計委員會負責 Clean Core 決策，修改 SAP 程式碼需要有具名的核准人；我的 SAP Clean Core 策略 說明了各個等級。

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

組態記錄

它記錄每一項系統變更：誰改的、為什麼改、放在哪個傳輸請求裡。日後出了問題，您可以在幾分鐘而不是幾天內追出原因。

每筆記錄需要：

1. 組態 ID 與模組（例如 MM-CONF-001）。
2. 組態路徑與變更的物件。
3. 受影響的業務流程與變更原因。
4. 組態人員與時間。
5. 傳輸請求編號。
6. 關鍵值的變更前與變更後。
7. 連結的測試案例與核准狀態。

客製開發登記表

每個客製物件在任何人寫程式之前都要先登記一列：ID、說明、開發角色、工作量、狀態與擴充類型。Clean Core 就是靠擴充類型這一欄落實的。

2024 年在歐洲一家零售企業的 S/4HANA 導入中，這份登記表讓計畫中的客製程式碼減少了 30%。它顯示出標準 SAP 完全夠用的地方。

測試策略

它把所有測試集中在一處：誰測什麼、何時測、在哪個環境測、依什麼標準測。

1. 範圍：涵蓋範圍內模組的功能、整合、迴歸、效能測試與 UAT。
2. 環境：開發、QA、UAT 與預備正式環境。
3. 工具：在 SAP Cloud ALM 或現有工具中進行測試管理，並寫明自動化與效能測試工具。
4. 缺陷生命週期，嚴重度與優先順序在分類時確定。
5. 結束標準：所有重大缺陷關閉、UAT 簽核、迴歸通過率達到事先約定的水準。

SAP Activate 的 Realize 階段以整合測試與使用者驗收測試收尾。結束標準要在測試開始前寫好，而不是等結果出來再定。

資料移轉計畫

資料移轉是最容易讓您吃虧的工作流。計畫涵蓋範圍（業務夥伴、物料、未結項目、餘額）、來源系統、對應規則、工具（SAP S/4HANA 移轉駕駛艙）、模擬匯入、驗證與回復。

驗證是團隊最常低估的部分：在第一次模擬匯入前，就筆數、抽樣與餘額核對達成共識。

在 SAP Activate 中，Deploy 涵蓋正式環境建置、切換、上線與 Hypercare。這些範本把一個混亂的週末變成一次受控的行動。

SAP 切換計畫範本

切換計畫把停機時段依小時排定。每項任務都有負責人、開始時間與相依關係。凌晨 2 點不應有人站在那裡不知道下一步做什麼。

寫任務清單之前，先就四件事達成共識：時段（例如週五 22:00 到週六 06:00）、回復觸發條件、舊系統能多快重新啟用，以及證明新系統可用的冒煙測試。接著是順序：

步驟	任務	負責人	開始	狀態
1	凍結舊系統（停止過帳）	Basis	22:00	待執行
2	最終資料擷取與核對	資料移轉負責人	22:30	待執行
3	正式環境移轉匯入	資料移轉負責人	23:00	待執行
4	匯入剩餘傳輸請求	Basis	00:30	待執行
5	切換介面與網路路由	整合負責人	01:30	待執行
6	冒煙測試：FI 過帳、收貨、銷售訂單	QA 負責人	02:00	待執行
7	業務確認與 Go/No-Go	專案總監	03:00	待執行
8	對業務使用者開放系統	Basis	06:00	待執行

上線就緒檢查清單

它決定您是否真的可以切換。每一項都以是或否回答，並附佐證。

1. 功能：關鍵流程與跨模組情境已測試，未關閉的 P1 與 P2 缺陷已列出，關鍵使用者確認就緒。
2. 資料：主檔資料與交易資料已匯入並核對，核對報表已核准，舊系統凍結已確認。
3. 財務：每個公司代碼與實體的期末結帳組態均已測試。
4. 技術：切換計畫已核准，傳輸請求已進入正式環境，批次作業已排程，監控已設定。
5. 人員：教育訓練涵蓋情況，存取角色已驗證，Hypercare 團隊已到位。
6. 決策：重大風險與緩解措施，Go / No-Go / 有條件上線，依姓名、角色與日期核准。

財務這一項有它的道理。2024 年在 GCC 的一個零售專案中，上線審查在上線前兩天發現了全部 25 個實體的財務結帳組態問題；若沒發現，會引發六位數的補救成本。

我曾用這項評估在兩個專案上建議延後兩週。這正是它的用途。

Hypercare 支援模式

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

1. Hypercare 期間與涵蓋範圍，例如四週，延長服務時間。
2. 支援管道：事件佇列、聊天頻道與 P1 專用的電話會議橋接。
3. 支援層級：服務台、功能顧問，接著是 Basis 與開發。
4. 依嚴重度區分的回應與解決時間。
5. 結束標準：沒有未關閉的 P1 或 P2 問題，並已簽署移交給維運支援組織的文件。

Run 是對上線系統的支援與管理。大多數團隊太早放下的範本，是監控效能的那一份。

效能監控表

它每天追蹤系統健康狀況，讓您在使用者抱怨之前發現變慢。2024 年在歐洲一個金融服務專案中，它在 Hypercare 第 3 週發現了一個資料庫問題，否則系統會在月結期間當機。

我追蹤的指標，每項都設目標、警示門檻與負責人：

1. 對話回應時間（第 95 百分位）：目標低於 1 秒，2 秒警示，Basis。
2. 背景作業：100% 依排程完成，任何失敗即警示，維運負責人。
3. 資料庫查詢時間：目標低於 200 ms，500 ms 警示，資料庫管理員。
4. 介面錯誤率：低於 1%，2% 警示，整合負責人。
5. 月結作業執行時間：在約定時段內，超出基準 30% 警示，財務營運。

SAP Activate 在各階段路線圖中內建品質關卡，每個階段都有檢查點。我的 SAP 品質關卡 指南談了如何設定；這裡說明為什麼關卡必須有約束力。

在每個關卡訂出通過與不通過的標準。「95% 的迴歸測試通過。」「所有 FI 整合情境都是綠燈。」有了這樣的標準，當業務單位不顧品質也要依日期上線時，您才能守住底線。

2024 年在歐洲的一個製造專案中，整合測試通過率只有 74% 時，品質關卡讓我們停了下來。我們守住了，修正了問題，兩週後上線。上線後第一個月的支援工單只有同類專案通常水準的一半。

高階主管簽核也不應流於形式；上面提到的 GCC 零售財務結帳問題，正是在那次審查中發現的。發起人一通電話就能推翻的關卡，稱不上關卡。在需要之前，就寫明誰有權豁免它。

圍繞這些範本的完整流程，請參閱我的 SAP 導入逐步指南。

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

哪裡可以下載 SAP Activate 範本？

在 me.sap.com/roadmapviewer 的 SAP Activate Roadmap Viewer。開啟與您的部署方式對應的路線圖，再依階段或加速器篩選，就能看到每項任務的範本、指南與檢查清單。

在雲端專案中，同樣的內容也可在 SAP Cloud ALM 中使用，任務與交付物可以依專案追蹤。

SAP Activate 每個階段的交付物是什麼？

Prepare 交付範圍、計畫、治理與商業論證。Explore 交付 Fit-to-Standard 結果、需求與差異待辦清單，以及解決方案設計。Realize 交付完成組態並經過測試的系統，包括整合測試與使用者驗收測試。

Deploy 交付切換、上線與 Hypercare。Run 涵蓋對上線系統的支援與改善。

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

Prepare。範圍界定文件、商業論證與利害關係人矩陣決定了之後的每一個決策，而它們也正是團隊為了更快進入組態而跳過的。

Explore 緊隨其後，因為差異分析表決定 WRICEF 數量，而預算正是在那裡超支的。

可以客製 SAP Activate 範本嗎？

可以。保留約 80% 的標準結構，只改您特有的部分：製藥業的驗證規則、公部門採購、SOX 內控。這些修改要在 Prepare 開始時完成，而不是在 Deploy。

不要透過客製拿掉階段順序、品質關卡或上線就緒評估。

SAP 切換計畫範本應該包含什麼？

一份針對停機時段、附時間安排的任務清單，每項任務都有負責人、開始時間與相依關係。在任務清單之前，先就時段、回復觸發條件、重新啟用舊系統所需時間與冒煙測試達成共識。

在切換開始前，約定由誰在什麼時間點之前做回復決定。凌晨 4 點在沒有約定標準的情況下做出的回復決定，正是上線後問題的開端。

SAP 上線就緒檢查清單包含哪些內容？

功能、資料、財務、技術與人員的就緒情況，每項都以是或否回答並附佐證，再加上一份記錄姓名與日期的 Go / No-Go 決定。

上線前測試每個實體的期末結帳組態。這是最有可能讓您免於六位數補救成本的檢查。

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

適用。差別主要在 Explore。Brownfield 轉換會沿用現有組態，因此差異分析聚焦於必須改變的內容，以及哪些客製程式碼現在可以由標準 S/4HANA 取代；Greenfield 專案則從 SAP Best Practices 起步。

切換計畫也不同，因為系統轉換依循的技術順序與 Greenfield 的資料匯入不同。