SAP 工作說明書：必須包含哪些內容

SAP 工作說明書（SOW）是一份合約文件，說明合作夥伴要交付什麼、投入多少工作量、由誰執行，以及可以如何變更。它必須涵蓋範圍、詳細的假設與排除項目、依階段與角色列出的工作量、附驗收準則的交付項目、具名人員，以及變更控制。

大多數 SOW 對範圍的描述還算足夠。客戶最常遺漏的是詳細的假設與排除項目，而這一節正好決定了您最後要付多少錢。

本文是我的如何選擇 SAP 導入合作夥伴指南的一部分。SOW 是這個流程的最後一步，在 SAP 合作夥伴 RFP 與簡報答詢之後。如果想看簽約前審查 SOW 的實際範例，請讀我的 ERP 合約談判案例研究。

一份好的 SAP SOW 讀起來就像這個計畫的操作手冊。您這一側的任何人打開它，都應該能回答三個問題：我們會得到什麼、它取決於什麼，以及有東西變動時會怎樣。

以下是它需要的章節，以及缺少某一節時會出什麼問題：

章節	應該寫什麼	寫得單薄時會怎樣
範圍	納入範圍的流程、模組、公司代碼、工廠、國家與使用者	每一場工作坊都會重新爭論到底包含了什麼
假設	價格所依賴的條件，每一項都附上不成立時的後果	合作夥伴提出您無法質疑的變更申請
排除項目	合作夥伴不做的事，以及改由誰來做	工作落在您與合作夥伴之間，沒有人負責
做法與階段	方法、階段計畫與品質關卡	沒有一個雙方同意的階段完成點
工作量	依階段與角色估算的工作量	您無法判斷消耗速度是否符合計畫
交付項目與驗收	具名的文件與產出、驗收準則、簽核期間	只完成一部分的工作也被付款
人員	具名的關鍵人員、角色、投入比例與替換規則	您在簡報答詢中見到的團隊，不是到現場的團隊
客戶責任	您的人員必須提供什麼，以及何時提供	您這一側造成的延誤，變成合作夥伴的變更申請
變更控制	變更如何提出、評估、計價與核准	變更申請變成第二條營收線
治理	指導委員會、報告、升級處理	問題很晚才浮現，那時代價已經很高

在請合作夥伴報價之前，先自己寫好範圍，讓合作夥伴報價的是您的範圍，而不是他們自己的。

這是客戶最常遺漏的一節。少了它，價格就建立在您這一側沒有人讀過或同意過的條件上。

假設是合作夥伴報價時所依據的條件。排除項目則是合作夥伴完全沒有報價的工作。兩者都必須具體到第三方能夠查核它們是否成立。

要寫下的假設類型

每一項假設都需要一個後果。「如果這項假設不成立，變更就透過變更控制並附上影響評估處理」，這句話讓假設從裝飾變成控制手段。

SAP SOW 應該涵蓋以下類別：

1. 組織範圍：價格涵蓋的公司代碼、工廠、銷售組織、國家與法人數量。
2. 流程範圍：具名列出納入範圍的業務流程，以及合作夥伴預期您採用的 SAP 標準流程。
3. WRICEF 數量：工作流程、報表、介面、轉換、增強功能與表單的數量，依複雜度區分。隨著這份清單增長，預算會在 Explore 階段被打破，所以基準數量應該寫進合約。
4. 資料：要移轉的資料物件、歷史資料量、模擬載入的次數，以及由誰清理資料。
5. 整合：具名列出每一個介面、另一端的系統，以及由誰修改那個系統。
6. 測試：測試循環的次數、由誰撰寫腳本、由誰執行，以及由誰修正缺陷。
7. 客戶的可投入時間：需要您哪些人員、投入多少時間，以及決策必須多快做出。
8. 環境與授權：由誰提供系統、工具與存取權限，以及在何時之前提供。
9. 地點與語言：團隊在哪裡工作、在岸與離岸的比例、差旅，以及文件與教育訓練使用的語言。
10. 教育訓練與上線後支援：教育訓練模式、受訓講師人數，以及上線後支援的期間與結束準則。

WRICEF 基準數量對預算影響最大。SAP 自己的課程教材把 Explore 階段描述為 Fit-to-Standard 分析，核准的差異需求會被加入產品待辦清單，供 Realize 階段使用（SAP Learning）。每一項核准的差異都可能變成新的 WRICEF 工作量，所以您需要起始數量來衡量增長。

要寫下的排除項目類型

排除項目應該寫明改由誰來做這項工作。只寫「排除」而沒有負責人，就是一個等著在切換期間被發現的缺口。

以下是常見的類別：

1. 舊系統中的資料清理與補強，通常是客戶的工作。
2. 介面另一端的第三方系統與舊系統變更。
3. 軟體授權與訂閱，這些在您與 SAP 的合約中，不在 SOW 裡。
4. 基礎架構與代管，除非合作夥伴明確負責營運它們。
5. 終端使用者教育訓練的執行，合作夥伴只負責訓練您的講師時。
6. 組織變革管理，超出已列出內容的部分。
7. 安全性、角色與權限設計，如果由其他方負責。
8. 效能、滲透與回歸測試，在具名的測試循環之外。
9. 國家、實體或在地化版本，不在組織範圍內的部分。
10. 上線後支援期結束後的應用系統支援，這是另一份合約。

請和您的計畫總監把這兩份清單並排閱讀。任何兩份清單都沒出現的事項，就是變更申請的來源。

我對 SAP 導入建議的商務模式是按工時計價（T&M），並量化工作量。也就是把依階段與角色估算的工作量寫進合約，讓您每個月都能拿實際工作量來比對。

固定總價在董事會眼中看起來比較安全。實際上，價格只在每一項假設都成立時才是固定的，而 SAP 計畫到 Explore 結束時，大部分假設都已經接受過考驗。我對 SAP 導入成本的筆記說明了在什麼情況下，固定總價的階段仍然合理。

以下是兩種模式在 SOW 中的比較：

比較項目	固定總價	量化工作量的按工時計價
合約固定的是什麼	價格，在假設成立的前提下	費率，以及依階段與角色估算的工作量
風險落在哪裡	合作夥伴把它當作預備金算進價格	在您身上，但每個月都看得見
範圍變動時	每一項變更都變成一場談判	工作量變動，您能拿它與估算對照
您能追蹤什麼	里程碑與變更申請	依階段與角色的實際工作量與計畫對照
什麼在保護您	嚴謹的假設與排除項目	嚴謹的假設、排除項目與工作量報告

量化的工作量，讓按工時計價從一張空白支票變成受控的預算。請要求以階段對角色的表格、以人天為單位提出估算，並把每月依這張表格回報列為合約義務。

不要讓費率藏在工作量裡。請用我的 SAP 專案資源配置規劃指南，把角色組合與市場費率對照。

前期資深人天多、後期資淺人天多的計畫很常見。反過來的話，就需要一個解釋。

交付項目是一個附有完成定義的具名產出。「設計支援」不是交付項目。一份針對 Record to Report 流程、依約定準則審查並簽署的解決方案設計文件，才是。

把驗收綁定在品質關卡上

SAP Activate 分為六個階段：Discover、Prepare、Explore、Realize、Deploy 與 Run。SAP 說明每個階段結束後都有正式的品質關卡，在專案往下推進之前確認該階段的交付項目已經完成（SAP Learning）。

在 SOW 中運用這些關卡。列出每個關卡應完成的交付項目、驗收準則，以及您有幾天可以審查。把付款綁定在已驗收的交付項目上，而不是行事曆。

您這一側必須有人能判斷這些文件。這是我建議引進獨立顧問的三個時間點之一：簽約期間、設計階段，以及評估合作夥伴的交付項目。我的 SAP 合作夥伴與獨立顧問一文說明這兩種角色如何搭配運作。

指名人員，並查核他們

提案人員素質不佳，是讓我放棄一份投標的兩件事之一。另一件是合作夥伴無法說明架構與計畫。

SOW 應該指名解決方案架構師、計畫經理，以及每一位功能與技術負責人。寫明他們的投入比例、您面試替補人選的權利，以及每一次人員替換都需經您核准。ERP 合約談判案例研究呈現了具名人員條款的實際運用。

請查核認證，而不是單憑履歷就相信。SAP 透過 Credly 發放認證徽章，並支援即時驗證（SAP Learning）。依照 SAP 的認證維持流程，持有人如果錯過強制評量，認證就會失效（SAP Learning）。

這項條款比看起來更重要。我曾經在計畫進行中更換合作夥伴，起因是那家合作夥伴提供不了優質的資源。我的在專案中途更換 SAP 合作夥伴指南說明在走到那一步之前要先確保哪些事情。

變更控制是單薄的 SOW 變貴的地方。如果假設很含糊，幾乎任何事都能被說成是變更。

一份可行的變更控制章節需要以下要素：

1. 觸發條件：只有在假設失效、排除項目被納入範圍，或您提出新需求時，才算變更。
2. 影響評估：在工作開始之前，以書面列出範圍、依角色的工作量、時程與成本。
3. 費率表：變更依合約費率計價，除非另有約定，否則不加收急件費用。
4. 核准層級：您這一側誰能核准多少金額以內的變更，超過一定門檻則由 CFO 核准。
5. 紀錄：每一項變更，不論核准或否決，都連同累計總額向指導委員會報告。
6. 與基準的連結：新的 WRICEF 物件要以假設中的數量為基準衡量。

合作夥伴會提出合理的變更。SAP 計畫總會發現簽約時沒有人知道的事情。目標是讓每一項變更在任何人花錢之前，都看得見、有計價，也經過核准。

在我主導或救回的 21 個 SAP 計畫中，我看到最大的錯誤是一開始沒有好好規劃。SOW 是這項規劃產生約束力的地方，花在它上面的時間，和有爭議的變更申請相比便宜得多。

具體的下一步：拿出您手上的 SOW，把每一項假設與排除項目列在一頁上。在每一項旁邊，寫下如果它不成立會怎樣，以及由誰付錢。如果您填不出這一欄，這份 SOW 就還不能簽。

如果您想在簽約前取得對 SAP 工作說明書的獨立審閱，我會在簽約階段協助客戶處理這件事。您可以在這裡與我聯絡。

SAP 工作說明書應該包含什麼？

範圍、詳細的假設、排除項目、做法與階段、依階段與角色估算的工作量、附驗收準則的交付項目、具名人員、客戶責任、變更控制與治理。最常寫得單薄的是假設與排除項目，而這正是決定最終成本的部分。

SAP SOW 中的假設和排除項目有什麼不同？

假設是合作夥伴報價時所依據的條件，例如公司代碼或 WRICEF 物件的數量。排除項目是合作夥伴完全沒有報價的工作，例如舊系統的資料清理。每一項假設都應該寫明不成立時會怎樣，每一項排除項目都應該寫明改由誰來做。

SAP 導入採用固定總價還是按工時計價比較好？

我建議按工時計價並量化工作量：把依階段與角色估算的工作量寫進合約，並每月追蹤。固定總價只在每一項假設都成立時才站得住腳，而 SAP 計畫在 Explore 階段就會考驗大部分假設。

如何為 SAP 交付項目定義驗收準則？

為每一項交付項目命名、描述完成的樣子，並為您的團隊設定審查期間。把它們綁定在每個階段結束時的 SAP Activate 品質關卡上，並且只在交付項目驗收後才付款。

SAP SOW 應該指名顧問嗎？

應該，針對關鍵角色：解決方案架構師、計畫經理，以及功能與技術負責人。加上他們的投入比例、您面試替補人選的權利，以及任何人員替換都需經您核准。透過 Credly 上的 SAP 徽章查證認證，而不是依賴履歷。

SAP 工作說明書應該由誰撰寫？

由合作夥伴起草，但範圍與假設應該來自您。在進入市場詢價之前先寫好您的範圍，並在簽約前請一位與合作夥伴無關的獨立人士審查假設、排除項目與交付項目。