ERP 合約談判：中東北非 (MENA) 財務長省下 $850K

ERP 導入合約要能守住預算，結構本身就得到位：具體的交付物、指名的人員、與已驗收成果掛鉤的里程碑、設有上限的 Hypercare，以及受控的變更單 (change order)。這個案例研究說明，一家中型中東北非 (MENA) 製造商的財務長，如何在簽約前請人把工作說明書 (SOW) 逐項拆解、重寫合約，在不縮減範疇的前提下，於啟動前就避免了 $850,000 的支出。本文寫給即將簽署 ERP 或 SAP 導入合約的財務長、財務總監與採購負責人。請把文末的簽約前檢查清單，拿去對照您自己的提案。

財務長交給我一份 120 頁的提案。他說看起來很扎實，但總覺得哪裡不對勁。他說對了。

問題不在數字，而在結構。像「標準組態」和「測試支援」這類籠統的用語，完全沒有說明背後的工作內容。同樣的工作用不同名稱出現在不同章節。措辭模糊到足以為日後幾乎任何超支找到理由。專案就是這樣在開始之前就偏離了軌道。

我看得出他感覺到、卻說不上來的問題在哪裡。他清楚預算和目標。他的團隊很稱職，但從未審閱過這種規模的交付 SOW，而供應商已經在推進簽約了。

三週的工作之後，合約已經截然不同，而專案在啟動之前就少了 $850,000 的負擔。

$850K啟動前避免的支出

1. 範疇合理化刪減灌水的工時、移除重複的訓練與測試、測試週期由四輪減為兩輪加預備$340K
2. 角色與費率重新配置控管資深與資淺人員的比例，由內部人員負責文件與基礎測試$310K
3. 合約變更依交付物付款、費用上限、設有上限的 Hypercare、變更單須財務長簽核$200K

一家中型的工業製造與經銷商，業務橫跨多國，並設有集中式財務職能：包括離散製造、售後市場經銷、共享服務財務與集團採購。這個集團在五年內快速成長，並且已經選定 SAP。當時正處於供應商選定與導入之間，重大承諾即將定案的時刻。

我把 SOW 拆成六個類別：組態設定、資料移轉、整合、測試、訓練與 PMO。這樣拆開之後，缺口就很容易看出來。

1. 模糊的交付物。 「標準整合」沒有寫系統名稱、資料量或複雜度。組態設定只用工時描述，與業務流程沒有任何連結。「於工作坊中確認」散見整份文件，每一處都是日後的變更單。
2. 人力金字塔化 (resource pyramiding)。 提案中以資深日費率列出資深顧問的名字。合約一簽，資深人員往往消失，改由資淺人員以同樣的費率交付工作。我在幾乎每個專案都見過。沒有指名人員條款，就沒有任何保障。
3. 重複計費。 訓練在 UAT 計一次，在 Hypercare 又計一次。資料檢核在測試時計一次，切換時又計一次。知識轉移分散在功能組與 PMO 兩個工作流，被收了兩次錢。單獨看都是小小的重疊，加在一起就是嚴重的超支推手。
4. 固定費用的假象。 對外說是固定價格，但「固定」只有在每項假設都被鎖定時才成立。這些措辭讓表面數字維持穩定，卻為日後加收費用留了門。
5. 薄弱的里程碑。 付款綁在日曆日期上，例如「9 月前完成設計」，卻沒有定義何謂完成，沒有驗收標準，也無法對做到一半的工作扣住發票。
6. 預留工時。 「視需要使用」的緩衝項目，沒有任何理由說明。它們很快就被例行工作耗盡，最後以變更需求的形式回頭找上門。

還有兩個範疇細節也很突出。資料移轉完全算在供應商頭上，儘管客戶已經有內部工具。還有，測試被設定為四個完整週期，背後卻沒有任何缺陷率的假設。

這些節省來自三個面向：

面向	節省金額	做法
範疇合理化	$340,000	刪減灌水的組態設定工時；移除重複的訓練與測試；將測試由四個週期減為兩個週期加預備
角色與費率重新配置	$310,000	控管資深與資淺人員的比例；內部人員在指名人員的保障下接手文件與基礎測試
合約變更	$200,000	付款與交付物掛鉤；差旅與費用設上限並須事先核准；Hypercare 設定期限並以 KPI 作為結束條件；變更單由財務長簽核管控

善用客戶自己的工具與標準，供應商的資料移轉工作量減少了約三分之一；改採內部主導的模式，外部訓練工時減少了約一半。這些都沒有縮減範疇或功能。專案按原訂日期啟動，第一季沒有任何變更單。換作平常，到那個時點，財務長桌上早就會躺著好幾張了。

六項條款帶來了實際的差別：

1. 指名人員。 每位關鍵顧問都要指名。替換須經客戶核准，並調整費率。沒有這一條，提案中的人就不會是現場的人。
2. 以交付物為準的里程碑。 每個里程碑都以產出來定義：簽核的流程圖、核對完成的資料、完成的驗收測試。滿足標準才放款，而不是日期一到就付。
3. 變更單管理。 每項範疇變更都需要一份針對範疇、時程與成本的影響說明。新增工作的費率設有上限。財務長核准是強制的。變更單成了受控的例外，而不再是一種營收模式。
4. Hypercare 上限與結束條件。 限定為六週，結束條件由交易穩定度與 SLA 達成情形來界定，而不是由供應商自行判斷。延長須重新取得核准。
5. 差旅與費用上限。 超過設定門檻須事先核准。否則上線後的差旅就會變成一條沒有上限的科目。
6. 稽核權。 有權審閱計費紀錄，即使從未行使。它會改變行為，因為灌水的事一旦查得到，就比較不會發生。

談判的更大範圍，可以參考我寫的 SAP 談判顧問與 SAP 授權談判，那兩篇談的是交易中軟體的那一端。

財務團隊常把 ERP 交付當成 IT 專案，預算一核准就退到一旁。超支就是這樣累積起來的。

合約是一份財務工具。里程碑決定現金流。人力條款決定成本。變更單流程決定風險曝險。如果財務在簽約前不審閱這些，就沒有任何具備商務經驗的人會審閱。

有三個缺口一再出現：

1. 固定費用的迷思。 財務長核准一個看起來有上限的數字，但如果假設留得模糊，範疇就沒有固定。供應商的工作坊正是範疇膨脹、並且被計費的地方。
2. 沒有為延誤的代價建立模型。 延誤增加的不只是多出幾週的顧問費：還有內部人員的時間，並且推遲效益的實現。大多數預算只規劃專案成本，卻從未為每一週的超支建立成本模型。
3. 缺乏商務能力的內部 PMO。 排程與報告有人做；商務上的反制卻沒有。供應商的專案經理懂得運用合約條款，客戶端若沒有同樣內行的人，就只能節節退讓。我的 SAP 預算為何超支指南說明了這種風險曝險通常在哪裡轉成成本。

如果這筆交易包含 RISE with SAP，就有兩份合約要讀：SAP 的訂閱合約（附有自己的服務說明），以及導入夥伴的 SOW。兩份都要用同樣的紀律檢視，並為訂閱費如何隨使用者人數在整個合約期間成長建立模型，而不是只看第一年。

簽約之前，請拿這份清單對照任何 ERP 導入提案：

1. SOW 是否依工作流（組態設定、資料、整合、測試、訓練、PMO）拆解，並列出各項的工作量？
2. 每一項整合是否都寫明系統、資料量與複雜度？
3. 每一項「於工作坊中確認」的假設，是否都已結案或明確排除？
4. 關鍵顧問是否已指名，並附有替換核准與費率調整的規定？
5. 每個付款里程碑是否都綁定一項交付物，並有驗收標準與客戶簽核？
6. 是否有變更單流程，包含影響說明、費率上限與財務長核准？
7. Hypercare 是否設有期限，並有客觀的結束條件？
8. 差旅與費用是否設有上限？您是否擁有對計費工時的稽核權？
9. 您自己的團隊做得來的工作（用內部工具做資料移轉、文件、基礎測試、訓練），是否已從供應商的範疇中移出？

財務長後來是這樣說的：「我第一次審閱提案時，覺得數字看起來合理。我漏看的，是範疇實際上有多模糊。等我們把它拆開之後，我才明白大部分風險都藏在小字裡。從財務的角度審視合約，讓我取得了一份我不知道自己原本缺少的掌控力。節省下來的錢很重要，但更大的收穫，是帶著清楚的認知、沒有意外地走進導入階段。」

他把成果向董事會報告。節省的金額是頭條。更重要的成果，是一份合約，以及一個公司從一開始就掌握得住的專案。

ERP 合約中的人力金字塔化是什麼？該如何防範？

就是在提案中以資深顧問和資深日費率報價，簽約後卻改由較資淺的人員交付。計費費率不變，品質卻不一樣。

解法是加入指名人員條款：每個關鍵角色都要指名，替換須經客戶核准，如果替補人員的費率較低，計費就要隨之調整。

ERP 計費里程碑該如何設計？

要與交付物掛鉤，而不是日期。「設計完成」不是里程碑。「財務與採購的流程圖已簽核、組態已審閱」才是。

為每個里程碑訂出驗收標準，客戶簽核後才付款。這讓您在交付不完整時有談判籌碼，也能擋下對部分完成的工作開出的發票。

ERP 導入合約中的固定費用陷阱是什麼？

固定費用要真正固定，簽約前必須鎖定每一項假設。像「於工作坊中確認」、「標準整合」或「依目前範疇」這類措辭，讓表面數字維持穩定，卻為日後的變更單打開了缺口。

簽約前先結清各項假設，明確列出排除事項，為變更單費率設上限，並逐行檢驗每一項固定費用的主張。

ERP 合約中該如何定義 Hypercare？

沒有期限的 Hypercare 會變成供應商的一條營收來源。請把它限定在明確的期間，通常是六到八週，並訂出客觀的結束條件，例如交易穩定度、SLA 達成情形與工單數量。任何延長都需要正式核准。

這樣 Hypercare 就成了一張有期限、移交條件明確的安全網。

財務長在簽署 ERP 導入合約前應該審閱什麼？

至少要看：里程碑如何定義、人員替換的保障、變更單規則、Hypercare 的範圍與結束條件、差旅與費用上限，以及排除清單。

除了條款之外，還要請人把 SOW 逐個工作流拆解，並拿工作量估算去對照您內部的產能。凡是您自己的員工能承接的文件、基礎測試或訓練，合約都應該反映出來。

為什麼即使是固定價格合約，ERP 變更單還是不斷出現？

因為固定價格合約很少鎖定每一項假設。提案是在高層次寫成的，缺口在工作坊中浮現，而每個缺口都變成一份在技術上超出範疇的變更需求。

這個模式可以預測：模糊的範疇，把它撐大的工作坊，把缺口變現的變更單。簽約前要求具體的範疇，並規定任何新工作開始之前，都要有影響分析與高階主管的核准。