SAP 專案範疇範本：該定義什麼、該排除什麼

SAP 專案範疇範本，定義專案要交付什麼、刻意不交付什麼、每個部分由誰負責，以及範疇如何變更。下面的九個章節涵蓋這些。其中最重要的兩個，正是團隊會跳過的：明確的排除項目，以及資料移轉範疇。請在配置開始前填好範本，並由贊助者與流程負責人簽署。

有時團隊填完範疇範本就繼續往前。那一部分感覺很容易。幾週後，在設計或建置期間，有人指出某個流程「被假設在範疇內」。對話變得不舒服。沒有人寫下來。沒有人是故意漏掉的。這種事我看過太多次。開頭幾個沒被檢查的假設，會悄悄把專案推離軌道數週。

範疇文件的工作，不是記錄大家在會議室裡說了什麼。而是在配置把代價高昂、難以回頭的假設鎖死之前，強迫把事情釐清。

這是九個章節，以及每一章必須回答的問題。

1. 目標

為什麼要做這件事，完成時業務端會看到什麼？把每個目標連結到可量測的成果：把月結縮短三天、消除三個法人實體之間的人工對帳、所有工廠只有一份庫存視圖。模糊的目標會產生模糊的成功標準，而分歧會在使用者驗收測試（UAT）時浮現。

2. 範疇定義

模組、法人實體、工廠、國家、語言、整合與部署模式。要具體。「財務」不是範疇。「財務會計與管理會計（FI/CO），涵蓋阿拉伯聯合大公國法人實體在 S/4HANA Cloud Private Edition 上的應付帳款、應收帳款、總帳與成本中心會計」才是範疇。

3. 排除項目

這是多數範疇範本失敗的地方。如果某件事沒有寫成排除，就會有人假設它被納入。要逐項點名寫下的排除項目：

1. 延後到後續階段的國家或法人實體。
2. 目前維持原狀的舊系統整合。
3. 某個既定截止日期之前的歷史資料。
4. 移到上線後增強清單的報表。
5. 等待法務確認而延後的法規要求。

為每一項排除，寫明它移到哪個階段（如果有的話）。一份簽署過的排除項目，能把兩週的爭論變成一場簡短的對話。

4. 資料移轉範疇

一個一貫的盲點。以書面回答三個問題：

1. **哪些要移？**只移未結項目，還是也包括歷史？所有客戶與供應商，還是只移有在往來的？每個工廠的物料，還是只移首批上線法人實體的？
2. **截止規則是什麼？**未結採購、銷售與工單的基準日期，以及切換時進行中項目如何處理。
3. **哪些改為歸檔？**歷史資料的法定保存規定，以及舊系統要保持可讀取多久。

在這裡沒有記錄的假設，會在建置期間變成爭議。我的文章SAP 資料移轉為何失敗深入談到規劃。

5. 非功能性範疇

這些在規劃時會被丟掉，到了測試後期才變成阻礙浮現。請把它們納入範疇：

1. 可用性與維護時間窗口。在 RISE 下，請參照您合約中的可用性條款。
2. 尖峰負載下的效能，例如月結。
3. 稽核日誌：哪些交易，以及日誌保存多久。
4. 安全性與依角色的存取控制。
5. 報表延遲：即時、近即時，或每日。

它們不是功能。它們是系統必須滿足的限制。如果它們不在範疇內，就沒有人會為它們做設計。

6. 角色與職責

每條工作流都需要一位顧問負責人，以及一位有決策權的業務端對口，兩者都要指名。我最常看到的缺口是 UAT 的責任歸屬：誰能簽核某個流程已完成測試並被接受？請在建置開始前決定，不要等到上線前兩週。

7. 變更控管

不是「變更需要正式核准」。而是一套明確的流程：什麼會觸發變更請求、誰評估對時程與預算的影響、誰核准，以及記錄什麼。沒有它，「我們可以加這個嗎？」就會變成「我們以為那已經包含在內」，然後是一次沒有人規劃過的三週延期。

8. 擴充規則

客製開發如何核准。SAP 現在把擴充分類為從層級 A（僅限已釋出的 API）到層級 D（修改核心）（SAP News，2025 年 8 月）。在 GROW 下的 Public Edition 上，系統只允許已釋出的介面。在 RISE 下的 Private Edition 與地端環境，核心仍然可以被修改，所以範疇應該載明目標層級，以及由誰核准例外。我的 Clean Core 指南說明了這些層級。

9. 假設與限制

列出範疇背後的假設，這樣就有人必須去查證它們。然後是限制：固定了上線日期的法規期限、預算上限、只有兼職投入的人員，以及舊系統的汰除日期。

客製化是範疇蔓延中，最慢顯現的一種形式。一份核准的客製報表，變成五份。一個工作流程的例外，變成之後每一項請求的先例。

在核准任何事之前，先為每一項請求分類：

類別	判斷標準	該怎麼做
必要	沒有它，流程在法規上或營運上都無法運作	核准，採用升級安全、成本最低的擴充方式
重要，但不致命	能提升效率，但不是致命問題	只有在有明確的成本效益論證時才核准
不必要	一種偏好，或是舊系統做法的複製	質疑它，然後拒絕或延後

多數不必要的客製化，是因為有人不想改變自己的工作方式，而不是因為 SAP 無法支援該流程。而且建置成本只是開始。每一個客製物件，在它存在期間，都會增加測試、教育訓練、文件與升級的工作。

**設定變更凍結。**挑一個日期，通常是在上線前四到六週，在此之後，該版本不再接受新的請求。之後的一切，都進入上線後的待辦清單。這個凍結需要指導委員會的簽署作為後盾。只由專案經理宣布的日期，在部門主管第一次施壓時就會被推翻。

1. 01提出請求什麼算變更，事先就已定義
2. 02分類必要、重要或不必要
3. 03評估影響時程與預算，由指定的評估人員負責
4. 04決定由指定的核准人員核准、拒絕或延後
5. 05範疇版本化新的版本編號，以及變更內容清單

變更凍結之後，新的請求進入上線後待辦清單

分析是範疇討論最容易變得激烈的地方。每個人都想要報表，卻沒有人說要幾份。

在設計階段議定一份固定的報表清單。問人們需要什麼，而不是他們可能想要什麼。把每份報表標示為 SAP 標準輸出或客製開發，並讓這份清單與其餘範疇一起簽署。標準報表的成本只是客製報表的一小部分。同時辨識每份報表的資料來源；一份從三個系統取資料的報表，就是一項整合需求。如果儀表板與規劃也在範疇內，我的 SAP Analytics Cloud 指南說明了該先敲定什麼。

錯誤	造成什麼	如何避免
目標無法量測	UAT 時對「能運作」的意義產生爭議	一開始就設定可量測的成果
排除項目沒有寫下來	未經核准就吸收了工作	逐項列出不在範疇內的事項
資料移轉範疇含糊	資料量錯誤、切換延後、返工	定義哪些要移、截止規則與歸檔
缺少非功能性需求	上線時出現稽核與效能問題	把可用性、效能、日誌與安全性納入範疇
沒有指定的 UAT 負責人	測試拖延，沒有人能簽核	指名有權限的個人
沒有變更控管	非正式的追加、測試被壓縮	把變更流程寫進範疇
沒有簽核	之後範疇被質疑，卻沒有人負責	由贊助者與流程負責人簽署
分析留待之後	上線前兩週才出現報表請求	在設計階段議定報表清單
部署模式或擴充規則懸而未決	爭論一路延燒到建置階段	在範疇簽署前，把兩者都決定下來

在每個 SAP Activate 階段關卡，以及每次核准變更之後，都要檢視範疇，並附上版本編號與變更內容清單。範疇應以引用的方式放進專案章程，讓兩份文件講的是同一個故事。

SAP 專案範疇範本應該包含什麼？

九個章節：附可量測成果的目標、範疇定義（模組、法人實體、國家、整合、部署模式）、明確的排除項目、資料移轉範疇、非功能性需求、指名的角色、變更控管、擴充規則，以及假設與限制。排除項目是最常缺少的章節。

如何防止 SAP 專案中的範疇蔓延？

明確寫下排除項目，讓每一項變更都經過正式請求，附上影響評估與指定的核准人員；核准前先分類客製化，並在上線前四到六週設定經簽署的變更凍結。目的不是拒絕所有變更。而是讓變更被看見、被評估、被授權。

SAP 專案中的資料移轉範疇是什麼？

它定義哪些資料要移進 SAP，以及依據什麼規則：哪些物件（客戶、供應商、物料、未結訂單、歷史）、截止日期，以及哪些改為歸檔而不是移轉。它決定工作量與時程，也決定舊系統必須保持可存取多久。

SAP 專案中的非功能性範疇是什麼？

指系統必須滿足的限制，而不是它所支援的流程：可用性、尖峰負載下的效能、稽核日誌、安全性與存取控制，以及報表延遲。它們常被排除在範疇之外，然後在測試時才被發現。在受法規管理的產業，稽核日誌是法律義務。

範疇中該如何處理客製化？

把每一項請求分類為必要、重要或不必要。對每一項核准的客製化，記錄需求、為什麼標準 SAP 無法滿足、工作量、對測試的影響、維護成本與擴充方式。在 Private Edition 與地端環境，載明目標 Clean Core 層級，以及由誰核准例外。

SAP 專案範疇應該在何時檢視？

在每個 SAP Activate 階段關卡、每次核准的變更請求之後，以及每當預算、資源或時程改變時。把每個版本都保留下來，附上日期、版本編號與變更摘要。當之後範疇被質疑時，這份歷史會保護團隊。