如何避免 SAP 導入專案的範圍蔓延

要避免 SAP 導入專案的範圍蔓延，就是讓每一項變更都清楚可見，而且核准的代價很高。把不在範圍內的項目，跟在範圍內的項目一樣仔細寫下來。每一項請求都要走變更控制，並評估對時程、成本與品質的影響。每一項追加都要求取捨。在高階主管的支持下設定範圍凍結日，並把同樣的紀律放進與系統整合商（SI）的合約。本指南寫給負責 S/4HANA 專案的專案總監、發起人與 PMO。請把下面的變更成本表與合約條款，用在您下一次的指導委員會簡報中。

多數 SAP 專案都會超支、超過期限，而範圍蔓延是最常見的原因。我合作過數十家 SAP 專案失控的企業，在超支反映到指導委員會報告之前，會先出現三個訊號。小變更不經影響評估就不斷堆疊。變更控制靠的是私人關係，而不是書面的權限。而發起人在咖啡桌上核准的事，專案團隊一週後才聽說。

有一位製藥客戶一開始有明確的 18 個月時程。三年後它仍在導入，成本已經翻倍。一家製造公司的 CIO 告訴我，他的團隊曾因為需求不斷變動，把花了數月組態好的整個模組報廢。範圍擴大到沒有人還認得出最初的計畫。

這些不是特例。這是 SAP 專案最常見的失敗方式。

它一開始很單純。某位業務負責人要求「只是小改一下」。接著又一個。「既然都在裡面了，順便……」這句話，毀掉的 SAP 導入專案比任何技術挑戰都多。

我合作過一家零售客戶，一開始很乾淨：核心財務與基本物料管理。六個月後，CMO 想要客戶分析。接著 COO 需要進階的倉儲功能。原本九個月的時程受到威脅。我頂了回去，兩項要求都駁回了。守住這個紀律，就是這份工作。

並非每一項變更都是範圍蔓延。有時您會發現設計中沒有人預期到的關鍵缺口。有時法規在專案中途改變。這些是合理的，而且它們會走一套流程，並伴隨時程與預算的調整。範圍蔓延則是憑空冒出來的，通常是在走廊上聊過之後。

有一位製造業客戶一開始有 10 份客製報表，最後變成 47 份，每一份都增加了設計、建置與測試的時間。光是報表工作流，就超支了 200%。

200%

範圍漂移使客製報表從 10 份增加到 47 份後，報表工作流的預算超支幅度

來源: 製造業客戶專案

警訊

以下是我留意的跡象，以及對每一項的因應方式：

警訊	根本原因	因應方式
「再加一件事」成了日常用語	範圍邊界不清	與業務負責人重設基準；落實正式的變更控制
業務負責人非正式地追加功能	不了解對下游的影響	每項請求都走影響評估；讓對方看到成本
時程延長，卻沒有正式的重新規劃	範圍悄悄擴張	設定範圍檢核點；經變更委員會簽核後重新規劃
文件與實際建置的內容不再相符	範圍處理流於非正式，沒有版本控管	每次核准變更，都同步更新規格與計畫
預算消耗速度超過進度	未記錄的變更造成隱藏的工作量	對照工作包追蹤工時；調查差異
團隊靠夜晚與週末加班追進度	範圍超出產能	升級到變更委員會；迫使做出範圍決定
業務、IT 與夥伴之間互相指責	範圍已經蔓延到失控	凍結範圍，進行根本原因檢討，重設基準

一切都相連

SAP 把一切都綁在一起。財務影響供應鏈。人資牽動薪資。銷售連到庫存。一項變更可能弄壞十件事。

有一位客戶在採購單流程中加了一個欄位。看起來微不足道。它卻弄壞了三個介面，並迫使各部門的報表重寫。另一位客戶要求對它的定價程序做「一點小變更」，結果需要把整個定價結構重新組態：三週的工作和 4 萬美元的顧問費，只為了一個小變更。

十年一遇的壓力

多數公司每 10 至 15 年才導入一次 SAP。每個部門都知道，往後十年都不會再有第二次機會。沒有人想聽到「第二階段」，因為在多數組織裡，那代表永遠不會發生。所以一切都被推進當前的專案，範圍清單就變成了願望清單。

Clean Core 帶來的改變

Clean Core 為客製化加上了技術上的煞車。在 S/4HANA Cloud Public Edition 上，無法修改核心：擴充功能透過已發布的 API，以 on-stack 或在 SAP BTP 上以 side-by-side 方式實現。在 Private Edition 與地端部署上，仍然可以修改，但 SAP 的指引視之為最後手段，因為每一次修改都會增加升級的工作。

有用的附帶效果是範圍紀律。一項要求「只是在標準的訂單到收款中加入這個核准步驟」，不再是隨口聊聊的組態，而是一個有自己的設計、建置與測試成本的擴充功能。在指導委員會之下設一個擴充功能審查會議，由一位有權核准或駁回的架構師主持，許多這類請求在進入基準之前就會停下來。沒有這個會議的地端部署專案，則會退回舊有的模式。我的 Clean Core 指南說明了如何設立。

1. 以明確的排除項目定義範圍。 把不在範圍內的項目，跟在範圍內的項目一樣仔細記錄，並對兩者都取得簽核。模糊的地方，就是爭論開始的地方。
2. 執行有後果的正式變更控制。 每項變更都需要對成本、時程與品質做影響評估，並讓核准者看得到。
3. 每次指導會議都傳達範圍邊界。 用簡單的紅、黃、綠燈號呈現範圍狀態。許多漂移只是誤解。
4. 撰寫範圍管理計畫。 說明變更如何評估、核准、升級與追蹤，讓每個工作流都以同樣的方式處理。我的 SAP 專案範圍範本提供了一個起始架構。
5. 以 MoSCoW 排定優先順序。 必須有（Must have）、應該有（Should have）、可以有（Could have）、這次不做（Won't have）。要極力讓「必須有」保持精簡。
6. 對每項決策做版本控管。 每項核准的變更都會更新基準。每項被駁回的變更，都附上理由記錄下來。
7. 要求取捨。 新需求進來，就得有別的東西出去。「必須有」一旦要付出代價，很快就變成「可有可無」。

有三個我用過的技巧，讓這些做法能夠落實。

簽核的紀律。 讓業務負責人簽署已核准的需求。在一個專案中，有一位業務負責人發誓他從未核准過某個特定的流程。我們拿出有他簽名的文件，爭論就結束了。簽名不是官僚作風。它讓同樣的爭論，不會在六個月後又重新開打。

讓連鎖效應看得見。 我為一位客戶做了一個示範，展示變更銷售訂單上的一個欄位，會影響 14 個領域，從報表、介面到安全角色。行為因此改變。教育只花幾個小時。不理解連鎖效應，則要花上好幾個月。

讓變更的成本看得見。 在設計階段做一項變更，可能花 5,000 美元。同樣的變更到了測試階段，可能要 5 萬美元。把這個簡單的圖表擺在大家面前，隨口提出的要求就會慢下來。

以下是美國市場 S/4HANA 專案的變更成本參考區間。它們會隨複雜度與夥伴而異。請把它們當成參照點，而不是報價。

階段	小型變更的典型成本	中型變更的典型成本
Explore（設計）	2,000 至 1 萬美元	1 萬至 3 萬美元
Realize 前期	5,000 至 2 萬美元	2 萬至 8 萬美元
Realize 中期（建置）	1.5 萬至 5 萬美元	5 萬至 20 萬美元
Realize 後期（測試）	3 萬至 10 萬美元	10 萬至 40 萬美元
Deploy 與上線切換	8 萬至 30 萬美元	30 萬至 100 萬美元以上
Hypercare（上線後）	15 萬至 50 萬美元	50 萬至 200 萬美元以上

這個模式，與數十年來的研究發現相符。NASA 的錯誤成本升高研究發現，一個在整合與測試階段才抓到的需求錯誤，修正成本是在需求階段抓到的 21 到 78 倍，一旦系統進入營運，更是高出許多。範圍治理的存在，就是為了讓變更留在這條曲線便宜的那一側。

重要的合約條款

含糊的合約會製造昂貴的問題。我看過一位客戶簽下的合約只寫了「導入 S/4HANA」。夥伴後來聲稱特定流程是需額外收費的附加項目，客戶最後付了兩倍的錢。下列條款可以防止這種情況：

條款	目的
含明確排除項目的範圍	限定固定價格涵蓋的內容，並消除附加項目的模糊地帶
常見變更的預先議定費率	在壓力來臨之前，鎖定報表、介面與組態變更的價格
顧問的延續性	避免新顧問重啟已定案的決策、擴大範圍
雙方的核准權限	避免資淺顧問承諾沒有人授權的功能
以里程碑計費	把付款與經簽核的交付成果掛鉤，而不是與經過的時間掛鉤
各項交付成果的驗收準則	在任何人爭論之前，先定義什麼叫「完成」
Clean Core 擴充功能條款	要求擴充功能使用已發布的 API 或 SAP BTP；可在第一次大型升級時省下重工

我關於 ERP 合約談判的筆記，說明了如何讓這些條款獲得同意。

變更控制委員會

變更委員會在成員對的時候才會有效。我組成的委員會有三種角色：一位在乎功能的業務決策者、一位在乎時程的專案經理，以及一位在乎預算的財務負責人。這樣的平衡，避免任何單一優先順序主導一切。

1. 01提出請求要有書面，不是在咖啡桌上口頭說說
2. 02影響評估在任何人核准之前，先評估時程、成本與品質
3. 03指明取捨有別的東西要拿掉，騰出空間
4. 04變更委員會決定業務、專案與財務都在場
5. 05更新基準被駁回的變更連同理由一併記錄

範圍只能透過委員會變動

委員會必須有真正的權限。在一個專案中，沒有經過它的核准，就不會發生任何範圍變更。一個都沒有。走廊上的口頭協議停止了。當業務副總裁試圖偷偷塞進新需求時，團隊有一份書面的核准權限矩陣可以指給他看。

多數決策應該停留在委員會層級。只有真正的爭議才送到發起人那裡，這讓發起人保持投入，又不至於被淹沒。每兩週與各工作流負責人召開一次範圍檢討會議，並報告已提出、已核准與已駁回的請求數量。當大家在狀態報告中看到「本月範圍成長 15%」，行為就會改變。

有些變更是必要的。我有一位製藥客戶，在導入中途遇上新的 FDA 法規。這些必須納入。那不是範圍蔓延。那是現實。

當合理的變更出現時，請問兩個問題。能奏效的最小修正是什麼？以及，問提出要求的人：您願意拿掉什麼來騰出空間？當一項要求需要付出代價時，急迫感會迅速下降。

選項包括延長時程、增加預算、砍掉其他需求、增加人手，或是混合運用。無論選哪一種，都要記錄下來，並同時更新所有基準文件。過時的文件，會製造下一輪的範圍問題。

AI 現在能幫忙處理文書工作。像 Microsoft Copilot 這類助理，能把冗長的變更請求往來串，摘要成一份供委員會決策用的簡報，而 SAP Cloud ALM 讓需求、變更與測試保持連結，變更的影響因此更容易追溯。AI 可以顯示一項變更牽動 14 個領域。但它無法告訴 COO，她的要求意味著 CFO 的要求不會實現。那場對話，仍然是您的事。

我合作過的一家製造公司準時完成了 SAP 專案，這比應有的情況罕見得多。它很早就設定了範圍凍結日，在那之後的任何變更，都需要 CEO 親自核准。專案結案時預算還有剩，上線時也沒有人在週末加班。

另一位客戶採用代幣制度：每個部門在整個專案期間，各分到三枚變更代幣。想要變更嗎？花一枚代幣。大家會認真想什麼才重要，「必須有」的需求一旦要花有限的貨幣，就被重新考慮了。

兩種做法都不複雜。兩者都需要紀律與領導層支持。任何範圍流程的考驗，是 COO 帶著「只是小改一下」走進專案室的那一天。請為那一天而建。

SAP 專案中的範圍蔓延是什麼？

需求逐漸、不受控地增長，而時程、預算或資源卻沒有隨之調整。在 SAP 中，它通常從小幅追加開始：多一份報表、多一個欄位、「只是快速改一下工作流」。每一項看起來都無害。加在一起，就多出好幾個月。

合理的範圍變更會走一套流程，並伴隨時程與預算的調整。範圍蔓延則是非正式地出現，並繞過變更控制。

SAP 專案中範圍蔓延最常見的原因有哪些？

有三項不斷出現：最初的需求含糊，因此任何東西都能被論證為在範圍內；沒有正式的變更控制，因此各個層級都有變更溜進來；以及十年一遇的心態，每個部門都想在這個專案中解決多年來積累的問題。

SAP 的高度互連放大了這三項。一項變更就能弄壞十個相連的流程，如果業務負責人看不到這些連結，影響就會在測試時才浮現，那時的成本高出許多倍。

Clean Core 如何改變範圍蔓延的風險？

它加上了一道技術上的煞車。在 S/4HANA Cloud Public Edition 上無法修改核心，所以每個缺口都成為一個有自己設計、建置與測試成本的擴充功能。在 Private Edition 與地端部署上，修改是可行的，但會增加升級工作，所以 SAP 的指引不鼓勵這麼做。

一個由一位有權決定的架構師主持的擴充功能審查會議，能在許多請求進入基準之前就擋下來。沒有這個會議，地端部署專案就會漂回舊有的習慣。

範圍蔓延與「鍍金」（gold-plating）有什麼差別？

範圍蔓延來自業務端：超出已議定內容的要求。鍍金來自交付團隊：沒有人要求的複雜度。

以 SAP 的角度來說，鍍金是顧問在簡單路由就夠用的地方，建了精細的工作流邏輯。範圍蔓延則是 COO 在一個原本只規劃基本 MM 的專案進行到六個月時，要求進階倉儲功能。兩者都會墊高成本與時間，也都需要同樣的紀律。

要如何建構一套真正有效的變更控制流程？

三個要素。每項請求都附有對時程、預算與資源的影響評估。核准委員會裡，這三項各有一位在乎它的人，而不是只有會什麼都核准的業務負責人。而且每一項追加都需要取捨：有別的東西要拿掉。

光是最後這條規則，就能濾掉那些並非真正關鍵的要求。

能完全避免範圍蔓延嗎？

不能。在任何超過幾個月的專案中，業務條件會變動、法規會改變，設計也會發現缺口。

目標是控制，而不是根除。受控的變更走書面流程、經過影響評估，並更新基準。不受控的變更繞過流程，在測試或上線後，以沒有人規劃過的成本浮現。

在長期的 SAP 專案中，處理範圍凍結的最佳方式是什麼？

給它後果，並讓高階主管的支持清楚可見。我用過最有效的版本是：凍結日從第一天起就寫在專案章程裡，變更流程定義「凍結」在實務上的意思，發起人在日期到來之前，先在指導會議上公開加以強調。

當凍結之後的每一項變更都必須由 CEO 親自核准，清單就會變得非常短。