SAP 專案救援：挽救偏離軌道的計畫

SAP 專案救援，是讓一個偏離軌道的移轉或導入停下來，找出它真實的狀況，並根據這個真相重新規劃。成敗取決於第一週：評估專案狀態、審查設計，並評估系統中實際部署了什麼。

簡短的答案：如果這三項檢查彼此一致，也與計畫一致，這個計畫需要的是推一把，而不是救援。如果彼此不一致，在現行計畫上再投入多少心力都修不好，您需要一次正式的救援，並設定新的基準。

本文討論的是這個診斷，以及之後的工作。它是我的 ECC 移轉至 S/4HANA 指南的其中一篇延伸文章，那篇指南涵蓋路徑、時程與期限。這裡的問題更聚焦：您的計畫出了問題，現在該怎麼辦？

大多數延誤的計畫並不需要救援。它們需要的是更快做出決策、讓一位關鍵使用者騰出時間，或是要求廠商守住日期。這是推一把。

救援則不同。徵兆來自我在第一週執行的同樣三項檢查，而訊號很簡單：狀態、設計與已部署的內容，彼此之間或與計畫之間不一致。

以下是我會視為需要救援的幾種模式：

1. **狀態是綠燈，系統不是。**報告說大部分建置已經完成，但測試系統連一個基本的訂單到收款流程都跑不起來。
2. **設計已簽核，建置卻不理它。**設定是根據工作坊筆記做的，而不是根據核准的設計。
3. **計畫有上線日期，卻沒有人能解釋怎麼走到那裡。**測試、資料載入與切換演練都沒有實際可行的時段。
4. **範圍只增不減。**在 Explore 階段結束很久之後，WRICEF 清單（報表、介面、轉換、強化、表單與工作流程）仍在增長。

其中任何一項，都可以靠推一把來解決。同時出現兩項以上，通常就不行了。

第一週是用來找出真相的。不是用來修正、不是用來究責，也不是用來寫新計畫。我依序評估三件事：狀態、設計，以及實際部署的內容。

以下是每項檢查涵蓋什麼，以及不一致時代表什麼：

檢查	我看什麼	它回答的問題	如果與其他檢查不一致
專案狀態	計畫、狀態報告、RAID 日誌、未結的變更請求、支出與預算的對比	這個計畫對自己的認知是什麼？	報告過於樂觀，或與實際交付脫節
設計	業務流程設計、Fit-to-Standard 產出、WRICEF 清單、未定的設計決策	業務單位被承諾了什麼？	建置已偏離當初的約定，或設計從未完成
實際部署的內容	開發與測試系統、設定、傳輸、客製程式碼、目前為止的資料載入	今天實際存在的是什麼？	回報的進度所對應的工作並不在系統中

第三項檢查是大多數審查會跳過的。它代表要坐在系統前面實際執行流程，而不是閱讀關於系統的文件。

狀態報告與設計文件是聲明。系統是證據。

誰應該執行這些檢查

寫狀態報告的人，不應該是驗證這些報告的人。這不是指控。這和稽核人員不稽核自己工作的道理一樣。

我會讓一位獨立於導入合作夥伴之外的人負責第一週，給他完整的系統存取權，以及與計畫中任何人談話的權利。如果做不到，至少要讓合作夥伴向您即時展示已部署的系統，而不是用投影片。

2018 年，我參與了一個航空業計畫的救援。模組都已經部署，但沒有任何一項是依據業務需求設定的。

這正是第一週三項檢查要揭露的情況。已部署的模組不等於一個可運作的設計，只有實際查看系統內部，才能看出差別。

航空公司把維修、採購與財務緊密地串在一起，所以一個領域的缺口會擴散出去。我在 SAP 航空業解決方案頁面中說明 SAP 如何適用於這個產業。

在我主導或救回的 21 個 SAP 計畫中，我看到最大的錯誤，是在導入一開始沒有好好規劃。救援往往就是這份缺少的規劃，在壓力下延遲補做。

還有兩個原因一再出現：

1. **廠商掌控範圍。**當系統整合商撰寫範圍時，它描述的是整合商打算交付的內容。缺口日後會以變更請求的形式出現，並由同一家廠商報價。
2. **客製程式碼超時。**依我的經驗，客製程式碼是移轉中最常超時的階段，也是最常被遺忘的隱藏成本。

預算面的問題，包括為什麼成本會在 Explore 階段跳升，我在為什麼 SAP 專案會超出預算一文中有說明。這裡不再重複。

管控薄弱是另一個常見的共同點。如果計畫從來沒有每週追蹤、升級處理與變更控制的節奏，救援就必須建立一套。我的 SAP 專案規劃與管控指南列出這套節奏與各項負責人。

一旦知道真相，救援就有明確的順序。跳過任何一步，通常意味著要救援兩次。

SAP 專案救援順序

1. 01

   診斷

   狀態、設計與已部署的內容，彼此交叉核對。

2. 02

   拿回範圍

   由客戶擁有範圍並凍結，每一項變更都要報價。

3. 03

   重新設定基準

   根據證據建立一份新計畫，預備金由您這一方保留。

4. 04

   為各階段設關卡

   在剩餘每個階段的結尾設置品質關卡。

5. 05

   演練與切換

   在確認上線日期之前完成完整演練。

1. 拿回範圍的主導權

在任何人重新規劃之前，先決定誰擁有範圍。如果答案仍然是廠商，新計畫會以和舊計畫相同的方式失敗。

由客戶這一方撰寫範圍，與已部署的內容比對，然後凍結。從那時起，每一項變更都是一個有負責人、經過報價的決策。

2. 根據證據，只重新設定一次基準

一次救援只設定一次新基準，而不是一連串的小幅延期。根據系統呈現的事實來建立，而不是根據舊計畫的期望。

先重新估算客製程式碼，因為超時最常來自這裡。接著是資料，因為資料移轉占工作量的 30% 至 40%，而在陷入困境的計畫中通常都已落後。

在您這一方保留 10% 至 20% 的預備金，只針對具名的風險動用。我的姊妹文章 S/4HANA 移轉成本說明這些數字由什麼決定。

3. 在每個階段的結尾設置品質關卡

陷入困境的計畫，通常是依日期而不是依證據從一個階段進到下一個階段。把這件事導正。

在 SAP Activate 中，Explore 階段進行 Fit-to-Standard 工作坊，核准的差異需求會放入 Realize 階段的產品待辦清單。如果計畫在設計未完成時就離開了 Explore，請回頭把它完成。SAP Cloud ALM 支援以檢查清單作為檢查點的品質關卡，並顯示在專案總覽上，所以關卡不必存在試算表裡。

4. 在承諾日期之前先演練

在 Brownfield 轉換中，切換前我會規劃三次模擬轉換。陷入困境的計畫常常為了省時間而刪減演練，結果把風險移到上線週末。

我看過的切換停機時間從一個週末到一週不等。一個被救回的計畫，應該從演練中得知自己的數字，而不是從估計。

5. 確認您真正面對的期限

對於強化套件 6 至 8 的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束，選購的延伸維護可延到 2030 年底，需額外支付兩個百分點（SAP News）。一次會把 ECC 移轉推到 2027 年之後的救援，應該公開地為延伸維護編列預算。

不要讓 2027 年這個日期逼出一個演練不支持的上線。延後上線要付維護費。上線失敗的代價則高得多。

救援常常會引出是否要保留現有系統整合商的問題。有時候更換合作夥伴是對的。但更常見的是，更大的問題在於計畫的建立方式，而新的合作夥伴會繼承這個問題。

以下是我在做決定之前會問的問題：

1. **您能對照已簽核的設計，即時展示已部署的系統嗎？**不是展示環境，也不是投影片。
2. 哪些 WRICEF 物件已經建置、測試並傳輸，哪些只是被回報為完成？
3. **您完成計畫的高階設計是什麼，有哪些您救回過類似計畫的參考案例可以讓我們打電話確認？**參考案例與高階設計，是我在簽約前向任何合作夥伴要求的兩樣東西。
4. **您需要我們提供、卻沒有得到的是什麼？**缺少的決策與只有兼職投入的關鍵使用者，往往占了問題的一半。
5. 對於 RISE with SAP 客戶：哪些問題屬於 SAP 而不是合作夥伴，由誰負責升級處理？

警訊和我在遴選時讓我直接離開合作夥伴的那一個相同：籠統的答案。如果救援計畫可以套用在任何公司，那它就不是為您的公司寫的。我的如何選擇 S/4HANA 移轉合作夥伴指南涵蓋遴選這一面。

如果這個計畫從來沒有對來源系統做過像樣的評估，現在就做一次。SAP Readiness Check 會分析您現有的系統，SAP 建議在正式環境中執行，以準確呈現真實的使用情況。我關於 SAP Readiness Check 與移轉評估的文章說明它會遺漏什麼，首先就是客製物件。

和您的計畫總監與 SAP 負責人安排半天，請他們把三樣東西並排展示給您看：最新的狀態報告、已簽核的設計，以及測試系統執行一個完整的業務流程。如果這三者說的是同一個故事，就推一把。如果不是，請在下一次指導委員會之前啟動正式救援。

如果您想對偏離軌道的計畫取得獨立的觀點，我協助企業進行的正是這類診斷。您可以與我預約通話。

什麼是 SAP 專案救援？

SAP 專案救援，是把偏離軌道的 SAP 導入或移轉重新拉回掌控之中的工作。它從診斷專案狀態、設計與實際部署的內容開始，接著拿回範圍的主導權、設定一個新基準，並在剩餘階段加上品質關卡。

如何知道我的 SAP 專案是否需要救援？

比較三件事：狀態報告怎麼說、已簽核的設計怎麼說，以及系統中實際部署了什麼。如果它們彼此一致，也與計畫一致，這個計畫需要的是推一把。如果不一致，在現行計畫上投入更多心力也修不好，您需要一次正式的救援。

SAP 導入救援的第一週應該做什麼？

只做診斷。評估專案狀態、審查設計，並評估實際部署的內容，最好由獨立於導入合作夥伴之外的人主導。在這三項檢查完成之前，不要寫新計畫。

救援期間應該更換 SAP 導入合作夥伴嗎？

不一定。請合作夥伴對照已簽核的設計展示已部署的系統，並提出完成計畫的高階設計，附上類似救援的參考案例。

如果答案很籠統，這是應該更換的強烈訊號。如果真正的問題是範圍主導權，或是您這一方缺少決策，新的合作夥伴會繼承這些問題。

為什麼 SAP S/4HANA 移轉會偏離軌道？

我看到最常見的根本原因，是在導入一開始沒有好好規劃。讓廠商掌控範圍是另一個原因，而客製程式碼是最常超時的階段。占工作量 30% 至 40% 的資料移轉，通常也會落後。

救援會讓我們的 ECC 移轉超過 2027 年的期限嗎？

有可能。強化套件 6 至 8 的 SAP ERP 6.0，主流維護於 2027 年 12 月 31 日結束，選購的延伸維護可延到 2030 年底，需額外支付兩個百分點。請為延伸維護編列預算，而不是強行推動一個演練不支持的上線。