SAP 專案規劃與控管：讓專案不偏離軌道

多數 SAP 專案都有計畫，真正做到控管的少得多。規劃訂下範圍、時程、預算與風險。控管則是每週的工作：對照計畫追蹤進度、管理相依關係、及早升級議題，並在每項變更獲准之前評估其影響。這份指南寫給專案總監、PMO 與發起人，適合 SAP 專案正在偏離軌道，或是想避免偏離的您。內容包括控管實際上是什麼樣子、三個公開的失敗案例（說明缺少控管會發生什麼事），以及一套附有負責人、本週就能採用的每週控管節奏。

我剛入行的時候，參與過一個書面上看起來無懈可擊的 SAP 專案。時程表、風險登錄表、變更紀錄，該有的都有。但沒有人照著做。指導委員會很少開會。財務在等資料移轉，IT 還沒開工。沒有人追蹤相依關係。每個人都以為別人在讓專案維持進度。

到了第六個月，一半的專案都落後了，我們忙著收拾自己犯的錯。最糟的是，事前沒有人看出來。

那不是規劃問題，而是控管問題。沒有真正的資源配置，沒有像樣的風險緩解，也沒有升級路徑。計畫只產出過一次，之後就被一場又一場的會議取代了。

規劃涵蓋範圍、時程、預算、資源、風險登錄表與里程碑承諾。多數團隊都會產出這些。問題在於，有沒有人每週真的拿來用。

控管則涵蓋對照計畫追蹤實際進度、及早揭露差異、管理相依關係、進度落後時升級處理，以及在範圍或時程正式變動時重新建立基準。多數團隊在這方面做得很差。

1. 01追蹤進度依工作包比較實際與計畫
2. 02揭露差異任何延誤三天的任務
3. 03檢查相依關係若這項延誤，誰會被卡住
4. 04議題升級依事先約定的路徑進行
5. 05評估變更先看時間、成本與資源
6. 06重新建立基準須經正式變更才進行

每週進行，並有明確負責人

缺少控管時，會出問題的地方如下：

缺少控管時會出問題的地方	原因
期限悄悄延後	兩次里程碑檢視之間沒有人檢查
假設無人驗證	每個團隊都以為另一個團隊會處理相依事項
範圍悄悄擴張	變更在會議中核准，卻沒有影響評估
風險等到成真才被處理	風險紀錄每季才更新，而不是每週
成本超出預算	工時記在工時表上，卻沒有對應到工作包
團隊不再溝通	狀態會議淪為報告，沒有後續行動

這些是公開案例，不是客戶的故事。它們的根本原因，正是我在顧問工作中一再看到的那些。

Lidl：約七年、估計 5 億歐元，然後叫停

Lidl 在 2011 年啟動以 SAP Retail 為基礎的 eLWIS 專案。其存貨評價做法與 SAP 標準模型不同，Lidl 選擇調整軟體，而不是調整做法。到了 2018 年，系統已在奧地利、北愛爾蘭與美國上線，但董事會認定，要在合理成本下達成原先的目標並不可行。Lidl 因此叫停專案，回頭開發自家系統。業界媒體估計花費約 5 億歐元，負責 IT 的董事會成員已在 2017 年離任。2018 年 7 月，Heise 報導了這項決定。教訓是：花多年時間客製化，只為了保住舊有做法，是控管的失敗，不是軟體的失敗。

Hershey：約 1 億美元的萬聖節訂單未能交付

Hershey 的新 SAP、Siebel 與 Manugistics 系統原訂 1999 年 4 月上線，那是糖果業的淡季。後來延了三個月，到 7 月才上線，正好碰上萬聖節訂單開始湧入。訂單無法從系統傳到倉庫。執行長向分析師表示，這些問題會使 Hershey 無法在萬聖節交付約 1 億美元的產品，第三季銷售額下滑了 12.4%。CIO 雜誌的報導把真正的失敗歸因於時機。若有一道保護旺季的時程控管，就會迫使上線日期另做安排。

Revlon：工廠受到干擾，內部控制出現重大缺失

Revlon 於 2018 年 2 月在北卡羅來納州牛津（Oxford）的工廠啟用 SAP，那是其最大的製造據點。服務中斷衝擊了製造，以及對美國大型零售商的出貨。2019 年 3 月，Revlon 揭露與這次上線有關的內部控制重大缺失，指出缺乏有效的持續風險評估，且受影響的營運單位中受過訓練的人員太少。投資人提起訴訟；TechTarget 報導了這起訴訟，訴狀主張約 6,400 萬美元的出貨未能履行。

這幾個案例都不是因為選錯了 SAP 而失敗。它們敗在已經存在數十年的規劃與控管基本功。

工作分解結構

工作分解結構（WBS）把整體範圍拆解成交付項目，並指定明確的負責人。沒有它，工作在延誤之前都是看不見的。對 SAP 專案而言，它涵蓋流程設計、組態、資料移轉、整合、測試、教育訓練與切換，每一項再拆解到有負責人與到期日的任務。

價值不在文件本身。它迫使大家談清楚要做什麼、由誰做，以及相依於什麼。相依關係正是專案的殺手。資料移轉延誤，會卡住整合測試，進而卡住 UAT，再壓縮切換的時間窗口。WBS 讓這條鏈條看得見。

時程管理

時程失敗的原因是可以預見的。人會被抽調。估算錯了。決策花的時間比預期長。從第一天起就要預留緩衝，而且是明確放在最可能需要的任務旁邊的緩衝，而不是平均攤在各處的灌水。

每週追蹤時程。第四週延誤一週，只是一次討論。第十六週延誤四週，就是一場危機。同樣的問題，修正的代價天差地別。

把上線時間點當成一項獨立的決策。絕對不要在業務旺季上線。Hershey 的教訓適用於每一家公司。

預算控管

預算失控有三個原因：未受管理的範圍變更、被低估的資料移轉，以及高於早期估算的 Hypercare 成本。從第一週起就對照計畫追蹤實際支出。等到差異送到指導委員會時，通常已經來不及在不造成干擾的情況下修正。

變更控制是預算最主要的保護機制。每項範圍變更在核准前，都要先就時間、成本與資源做影響評估。如果評估在核准之後才做，這項變更就已經繞過了預算。我的指南如何避免 SAP 導入中的範圍蔓延對變更委員會有更深入的說明。

風險管理

每季才維護一次的風險登錄表，只是做做樣子。風險需要每週檢視、指定負責人，並備妥應對計畫。每個 SAP 專案都要點名這幾項：太晚才發現的資料品質問題、整合延誤、人力可用性的缺口、切換時間窗口被壓縮，以及使用者採用度不佳。

有一位客戶因為資料移轉廠商一再錯過期限，損失了三個月。我們一直聽到「再給兩週就好」，直到想換廠商時已經太遲，換了就會爆預算。如果這項風險有負責人和觸發日期，這個決定早在幾個月前就會被逼出來。我的 SAP 風險評估矩陣提供了評分並指定這些風險負責人的範本。

溝通與升級

高階主管需要的是重點結論。交付團隊需要的是具體細節。專案經理需要的是差異數據。一份給所有人看的更新，對誰都沒有幫助。

要在危機發生之前，就把升級路徑寫成文件並演練。在某個 SAP 導入專案中，IT 以為財務在審查組態，財務也以為 IT 在審查。直到距離上線只剩三個月、關鍵核准還沒到位，才有人提出來；補救靠的是最後一刻的手忙腳亂、額外的成本，以及延後的推展。另一家公司做對了：報告有結構，並且與行動連動，所以問題一出現，每個人都知道由誰負責、影響是什麼、要如何解決。

範圍正是升級機制派上用場的地方。我曾與一家航空公司合作，一開始只是單純的訂位功能升級。六個月後，它又加上了忠誠計畫的變更、機組排班與財務模組。沒有一項是急迫的。沒有人說不。時程加倍，成本增加了 70%。

地端部署時代的做法，原封不動搬到 RISE with SAP 上行不通。有三件事不一樣。

RISE 改變了您要向誰升級

在 RISE with SAP 之下，SAP 負責營運基礎架構與技術作業，並提供客戶成功團隊來追蹤採用情況。您的控管架構必須把他們納入。對於平台層級的問題（系統效能、hyperscaler 區域、SAP 的服務水準），專案經理需要一條有文件記錄、通往 SAP 的升級路徑，而且不經過導入夥伴。在需要之前就先寫下來。

Clean Core 為範圍控管提供技術上的後盾

現在每一個落差都需要一個決定：用組態解決、透過已發布的 API 擴充（使用 ABAP Cloud 的 on-stack，或在 SAP BTP 上的 side-by-side），或是駁回。在 SAP S/4HANA Cloud Public Edition 上，修改核心不是選項。私有雲版本與地端部署雖然可以這麼做，但 SAP 的 Clean Core 指引把它視為最後手段，因為每一次修改都會增加升級工作。

這對範圍控管有幫助。一個要求「稍微調整標準的訂單到收款流程」，不再只是隨口聊聊的組態討論，而是變成一項需要設計、建置與測試工作量的擴充。在指導委員會之下設一個小型的擴充審查會議，由一位有權核准或駁回的架構師主持。沒有它，每一場客製化的爭論最後都會鬧到指導委員會。

AI 起草報告，決策由人來下

AI 現在可以協助處理控管的文書工作。SAP Cloud ALM（SAP 的應用程式生命週期管理工具）保存專案任務、需求與測試狀態，並能從工作坊逐字稿產生需求草稿。Microsoft Copilot 根據儀表板與狀態報告，為指導委員會簡報起草差異摘要。Power BI 或 SAP Analytics Cloud 中的異常偵測，會標示偏離慣常模式的 KPI。這對資源使用率、變更申請數量與支援工單很有用，對本來就會自然波動的指標則比較沒那麼有用。

AI 做不到的是採取行動。儀表板可以連續六週用紅色顯示時程落後。如果指導委員會什麼都不做，落後就會持續下去。

這是處於主動交付階段的專案所需的最低節奏。如果下表缺了任何一列，就先補上，其他事情再說。

控管項目	最低做法	負責人	頻率
工作分解結構	每項任務都有負責人、到期日與相依關係	PMO 主管	每週更新
時程檢視	標示任何延誤超過三天的任務；檢查關鍵路徑	專案經理	每週
預算追蹤	依工作包對照計畫與實際	專案財務主管	每週追蹤，每月報告
風險檢視	每項進行中的風險都有負責人、觸發條件與應對措施	各工作流主管	每週
變更控制	核准前先就時間、成本與資源做影響評估	變更委員會主席	每週，或在申請送達時
擴充審查（RISE 與 GROW）	針對每個落差，決定要組態、擴充或駁回	解決方案架構師	每兩週
指導委員會	做決策，而不是報告狀態；會前先送出文件	高階發起人	每兩週；切換與 Hypercare 期間每週

多數規劃與控管的失敗，不是因為方法錯了，而是因為到第四個月紀律就鬆掉了。讓節奏保持精簡，精簡到團隊在第十四個月仍願意照著執行。關於指導委員會本身，請參閱我的指南如何建立有效的 SAP 專案指導委員會。

專案規劃與專案控管有什麼差別？

規劃產出路線圖：範圍、時程、預算、資源與風險。它在一開始訂定方向。

控管則是持續進行的工作：對照計畫追蹤進度、揭露差異、管理相依關係，並在發生正式變更時重新建立基準。它在專案存續期間，每週都要進行。

多數 SAP 專案在規劃上投入很多，在控管上卻投入太少。等到差異在指導委員會浮現時，數週甚至數個月的救援成本已經累積起來。

為什麼 SAP 專案明明有專案計畫，還是會失敗？

因為沒有人照著計畫做。相依關係沒有被追蹤，所以一個工作流的延誤，會悄悄卡住另一個工作流。風險紀錄每季才更新。範圍變更在非正式場合就核准了。指導委員會每月才開一次會，看到的是把現場實況掩蓋起來的里程碑摘要。

Lidl、Hershey 與 Revlon 都有計畫。他們缺少的是主動控管：誠實的追蹤、及早升級，以及在警訊出現時採取真正的因應。

在長期的 SAP 專案中，如何管理範圍蔓延？

每項範圍變更在核准前，都要有書面的影響評估：時間、成本與資源。沒有它，核准一項變更，就等於核准一個未知數。

最有效的規則是：任何新增項目都必須排擠掉別的東西。光是這一項限制，就會讓業務主管誠實地排定優先順序。

高階主管必須支持。當 CFO 或 COO 公開支持變更控制時，非正式的要求會很快減少。在 RISE 與 GROW 專案中，針對每個落差所做的擴充決定，還會在上面再加一道技術檢查。

什麼是工作分解結構？為什麼它對 SAP 很重要？

WBS 把整體範圍拆解成交付項目，每一項都有負責人與到期日。以 SAP 專案來說，就是流程設計、組態、資料移轉、整合、測試、教育訓練與切換，全部拆解到任務層級。

它的實際價值在於對應相依關係。資料移轉餵給整合測試，整合測試餵給 UAT，UAT 餵給切換。其中一環延誤，下游的影響立刻就看得見。

RISE with SAP 如何改變專案規劃與控管？

SAP 成為交付的參與方。它負責營運基礎架構與技術作業，其客戶成功團隊也有自己針對採用與價值的運作節奏。

隨之而來有三項改變。您需要一條有文件記錄、直通 SAP、不經過夥伴的平台問題升級路徑。您需要在指導委員會之下設一個擴充審查會議，決定在 Clean Core 原則下每個落差要如何處理。此外，您應該把 SAP 的客戶成功節奏納入自己的治理，而不是各自平行運作。

SAP 專案中，指導委員會該做什麼？

做決策。它的任務是解決專案團隊無法解決的事：資源衝突、範圍爭議、預算變更，以及任何需要跨部門權限的事項。一場沒有做出任何決策就結束的指導委員會會議，只是一次狀態更新。

大型專案若每月才開一次指導委員會，議題最長可能要等上四週。在主動交付階段，至少每兩週一次，切換與 Hypercare 期間則每週一次。進度報告事先送出，會議就專注在這些報告所引出的決策上。