建立有效的 SAP 專案指導委員會

SAP 專案指導委員會是一小群高階主管，負責做專案團隊做不了的決定：預算、範疇變更、跨部門衝突，以及最後的 go/no-go。成員握有真正的權力、開會頻率高到足以在會議中當場決定，並且依證據而非日曆來判斷是否就緒，委員會才發揮得了作用。本指南寫給正在籌組委員會、或想把淪為聽取狀態報告的委員會救回來的專案發起人與專案總監。內容涵蓋委員會必須決定什麼、依專案規模決定成員、決策該怎麼運作、go/no-go 檢查清單，以及 RISE with SAP 與 AI 工具帶來的改變。

我從沒見過 SAP 專案在指導委員會薄弱的情況下成功。艱難的決定都在委員會裡發生。要嘛當下就做，要嘛一路堆積，直到切換 (cutover) 時一次爆發。

在一次 SAP 上線專案中，委員會每月開一次會。專案團隊提出核准流程壞掉、測試不完整、訓練缺漏等問題。管理階層說會「再檢視」，卻始終沒有。專案照樣上線，財務部門接下來花了六個月收拾殘局。

在另一家公司，委員會每週開會，並做出真正的決定。測試發現缺口時，它重新分配資源。流程行不通時，它就把流程修好。那個專案順利上線。

一個委員會在領導。另一個只是在開會。

如果委員會只是在聽狀態報告，它已經失敗了。下表呈現實務上的差別。

職責	好的樣子	弱的樣子
重大決策	審視案情，當場決定	「會後再討論」，問題下個月又回來
障礙排除	人資部門拖延測試？主席直接打電話給部門主管	承認問題，然後登記在案
範疇	每項變更請求都對照計畫衡量	誰喊得最大聲，就蓋章放行
風險	看到供應商吃力，在延誤發生前先安排備援	等著看問題會不會自己消失
預算	核准額外 $2M 讓專案延長三個月，因為營運中斷的代價更高	推到下個月
Go/no-go	因為測試未完成，把上線延後六週，並堅持立場	因為日期已排在行事曆上，就核准上線

最後一列最重要。我見過即使團隊急著往前衝，指導委員會仍把上線日期往後推。一家製藥業客戶的指導委員會，因為測試尚未完成，把上線延後了六週。這個決定不好下，卻讓他們免於一場災難。

成員太多，委員會就無法做決定；太少，又會少了關鍵的聲音。

專案規模	預算與範疇	成員人數	必須到場的人
小型	低於 $0.5M，單一部門，6 個月以內	3 至 5 人	部門主管、IT 負責人、財務代表
中型企業	$0.5M 至 $5M，數個部門，6 至 18 個月	5 至 8 人	受影響部門的業務負責人、IT 主管階層、財務
大型企業	超過 $5M，全企業範圍，18 個月以上	8 至 12 人	財務、人資、營運與 IT 的 C 級主管；專案經理；變革管理負責人

我的原則是：納入真正握有決策權的人。我見過指導委員會失敗，原因是頭銜很高的成員不先問過別人，就什麼都無法核准。如果財務長無法出席，請派一位真正被授權做決定的人，而不是只負責回去報告的人。

主席應由專案發起人擔任，通常是能要求其他高階主管負起責任的 C 級主管。由中階主管擔任主席，就無法否決財務長的意見，而當範疇或預算出現衝突時，這份權威至關重要。

憑證據。 我合作過一家製造業客戶，他們的 IT 團隊說某項流程變更會多花三個月。業務部門堅持這「很簡單」。委員會拒絕做決定，直到看到工作量估算、相依性分析與產能規劃。結果 IT 是對的。委員會之所以判斷正確，是因為它要求證據，而不是站在聲音最大的那一邊。

要快。 我見過一位客戶的委員會每兩週開一次會，卻總是以「我們會後再討論」收場。問題越積越多，直到專案落後了六個月。另一位客戶的委員會則在會議中當場做決定，專案提早完成，還低於預算。委員會慢，專案就會晚。

授權要明確。 有效的委員會可以否決部門主管的意見、核准計畫外預算，並在專案進行中拒絕範疇追加。如果這些權力沒有白紙黑字寫下來、讓大家都清楚，委員會就會淪為諮詢性質，而諮詢性質的委員會交付不了 SAP 專案。

範疇要有選擇。 在我的一位客戶那裡，有個部門突然要求多做 20 份報表。委員會逐一詢問：這份現在就需要嗎？會不會打亂時程？最後核准了五份關鍵報表，其餘的移到上線之後。這個決定很可能保住了上線日期。

會議控制在 60 至 90 分鐘。 談最重要的風險、需要做的具體決策，以及有負責人與日期的行動項目。不要報告事先讀文件就能看懂的技術進度。如果同一個議題連續三次會議都沒解決，那是治理問題，不是複雜度問題。

用數據，不用簡報。 我合作過一家能源業客戶，他們建了一個儀表板，呈現測試執行、缺陷解決、訓練完成度與預算消耗。會議不再是為了弄清楚進度到哪，而是開始解決問題。

讓委員會看到系統。 一家製藥業客戶的委員會走了一遍「一天的工作日常」情境，才發現已核准的設計會讓員工在一項常見流程中得切換五個不同的畫面。委員會當下就下令重新設計。

把政治因素算進去。 最常見的失敗不是能力不足，而是部門保護自己的地盤，以及團隊因為年底忙碌而拖延測試。在一個專案中，人資部門因為忙於年底工作，一再拖延薪資測試。委員會重新排定工作優先順序，並指派備援測試人員，專案因此保持在軌道上，沒有一路延誤好幾個月。

在重要關卡做獨立查核。 一家製造業客戶在核准上線之前，請外部審查人員評估其就緒程度。審查發現了好幾項嚴重問題，都是專案團隊漏看或輕描淡寫帶過的。我的 SAP 品質關卡指南說明了如何安排這些查核點。

以日期壓力作為核准上線的依據是錯的。表決之前，委員會應該針對下列每一項看到證據：

1. 整合測試與使用者驗收測試完成，且沒有未結的重大缺陷
2. 最後一次模擬資料移轉已完成核對，並由財務簽核
3. 切換演練在計畫的時間窗內完成
4. 關鍵使用者已受訓，現場支援與作業輔助工具已就緒
5. 每位流程負責人都已書面確認業務就緒
6. 回復計畫已測試並獲同意
7. Hypercare 團隊、問題升級路徑與首次結帳支援均已就位

只要有任何一項亮紅燈，強勢的委員會就會說不。延後六週是補得回來的。一次失敗的上線如果干擾了營運或財務結帳，可能要花好幾個月才能穩定下來。我收拾過太多只因為日期好像動不了就被核准的上線。讓委員會的議程來自一份持續更新的風險登記冊，這些項目才能及早浮現。

RISE 把 SAP 帶進治理模型。 在 RISE with SAP 上，由 SAP 負責基礎架構與技術營運。SAP 的 RISE 角色與責任文件指出，客戶會與 SAP Cloud Architect Advisor、Client Delivery Manager 或 SAP 的私有雲客戶中心合作。遇到效能、可用性或服務水準等平台問題時，委員會需要一條不經過導入夥伴、直達這些窗口的管道。請在相關議程項目邀請他們參加，而不是讓他們成為常設成員。

Clean Core 論壇應該設在委員會之下。 在 RISE 專案中，請成立一個設計權責小組 (design authority)，依 Clean Core 原則核准或駁回客製化請求。只有當具業務關鍵性的請求被擋下時，才往上呈報委員會。少了這一層，每一項客製化都會變成委員會裡的一場爭吵。在地端環境，傳統模式仍然適用，SAP 是供應商，不是參與者。

1. 指導委員會由專案發起人擔任主席。負責預算、範疇、衝突與 go/no-go
   SAP 交付窗口針對平台議題受邀參加，不經由導入夥伴轉達

• 專案管理辦公室日常執行、風險紀錄與協調
• Clean Core 設計權責小組裁決客製化請求，只上報被擋下的關鍵請求

AI 能省下文書作業的時間。 Microsoft 365 Copilot 可以根據錄下的會議草擬會議紀錄。工作變成審閱一份草稿，而不是從零開始寫，決議則取自逐字稿。範本建好之後，Atlassian 的 Rovo 能把會議筆記轉成結構化的決策紀錄條目。SAP Cloud ALM 中以 Joule 為基礎的助理，能針對範疇請求草擬第一版影響評估，讓委員會在會議中就能決定，而不必延後處理。

情緒分析暫時先跳過。 有些供應商會把專案溝通的情緒分析包裝成委員會的決策輸入。在大多數專案裡，那只是做做樣子：訊號很弱，誤判很常見，而且被人看到在監控情緒，還要付出政治代價。只有在非常大型的專案，它才有機會及早標出正在疏離的群體。對大多數委員會來說，AI 預算不該花在這裡。

SAP 專案中，指導委員會的角色是什麼？

它做專案團隊做不了的決定：預算核准、範疇變更、資源升級處理，以及最後的 go/no-go。它化解跨部門衝突，並要求部門主管兌現測試與訓練的承諾。如果它只是聽取狀態更新，就是沒有盡到職責。價值在於做出的決策，而不是出席的會議。

SAP 指導委員會應該有幾個人？

小型單一部門專案三至五人；中型企業五至八人；大型企業專案八至十二人。常見的失敗是人太多：20 人的委員會會變成聽簡報的觀眾。每位成員都應該對某件事握有真正的決策權。在 RISE 上，請針對平台議題邀請 SAP 的交付窗口，而不是讓他們成為常設成員。

RISE with SAP 如何改變指導委員會？

SAP 成為基礎架構與技術營運的交付參與者，所以委員會需要一條直達 SAP 指派窗口、不經過導入夥伴的管道。委員會之下也需要一個 Clean Core 設計權責小組來處理客製化請求，只有被擋下的業務關鍵請求才往上呈報。在地端環境，SAP 仍然只是供應商。

指導委員會與 PMO 有什麼差別？

專案管理辦公室 (PMO) 負責日常執行：任務、風險紀錄與各工作流之間的協調。指導委員會則做 PMO 做不了的決定：預算調整、範疇變更與 go/no-go。在較大的組織裡，會有一個專案組合層級的委員會位於數個專案之上，在專案之間分配資源。

指導委員會的議程應該放什麼？

放決策，不放進度更新。先談最重要的三到五項風險，接著是需要簽核的具體決策，再來是需要化解的跨部門議題，最後是上次會議的行動項目，附上負責人與日期。如果某個項目出現三次仍未解決，就該針對它的處理方式往上呈報，而不是再討論一次。

指導委員會何時應該延後上線？

當測試尚未完成、關鍵使用者尚未受訓、資料移轉尚未核對、關鍵整合不穩定，或回復計畫未經測試時。延後幾乎總是比上線後收拾殘局便宜。延後六週是補得回來的；一次失敗的上線如果干擾供應鏈或財務結帳，可能要花好幾個月才能穩定。