SAP 利害關係人管理：在衝突發生之前化解

SAP 利害關係人管理，決定了專案是準時完成，還是把最後一季都耗在爭論上。歸結起來是四個習慣。盤點誰重要，以及每個群體在意什麼。寫下誰有權決定什麼。依 SAP Activate 的階段，執行相應的溝通節奏。把每一項重大決策連同其替代方案一併記錄下來。這篇指南寫給 S/4HANA 專案的專案總監、PMO 與高階發起人。請利用下方的角色表與各階段的溝通節奏，在第一場工作坊之前，建立好您的參與計畫。

我曾參與過一次 SAP 上線，IT 要求嚴格的系統控管，財務則需要更多彈性。等到我們進場時，兩個團隊已經不再交談。財務很沮喪，IT 很防備。管理階層想知道，為什麼沒有人在溝通。

我們建立了角色對照圖，定期召開對齊會議，並為決策建立了唯一的事實來源。如果這些基礎工作一開始就做好，我們可以省下好幾個月的爭論。

這個模式不只出現在那一個專案。技術本身很少獨自出問題。專案失敗，是因為決策沒有人做，期望從來沒有設定。是因為溝通靠的是個人關係，而不是固定的節奏；也是因為本該在執行層解決的衝突，晚了好幾週才傳到管理階層手上。

SAP 專案中的每個人，關切的事情和影響力都不相同。把他們當成同一群讀者，您就會發出無關的進度通知，並錯過真正的風險。

角色	他們在意什麼	如何與他們互動
高階發起人（CEO、COO、集團 CFO）	投資報酬、業務風險、專案的公信力	直接、定期、簡短
指導委員會（CIO、CFO、事業單位主管）	時程、預算、範疇	有結構的指導委員會檢視，並做出決策
財務領導層（CFO、會計主管）	收入認列、報表完整性、內部控制	及早參與設計；簽核 FI/CO 範疇
營運與業務主管	流程連續性、訓練、易用性	設計工作坊；負責使用者驗收測試（UAT）
IT 領導層（CIO、架構負責人）	架構、資安、整合、支援	簽核技術設計
業務流程負責人	流程的正確性、例外、邊界情況	主導設計工作坊；簽核組態設定
終端使用者	學習曲線、日常工作、工作內容的改變	訓練與變革管理
系統整合商（SI）	交付範疇、變更需求、人力配置	正式的治理與範疇文件
人資與變革管理	對人的影響、角色異動、溝通	與交付並行的工作流

權力與利益方格（power-interest grid）告訴您該把力氣花在哪裡。CIO、CFO 與發起人在兩個維度上都很高：他們核准變更、決定上線是否延後、調配人力，一旦他們抽身，專案就失去了掩護。流程負責人、會計主管與架構師的利益關係很高，正式權力較小，但他們對業務實際運作方式的了解，使他們在設計階段不可或缺。董事會成員與專案之外的高階主管，需要的是里程碑簡報，而不是每週更新。終端使用者影響力很小，受衝擊程度卻最高：他們在上線時是否買單，決定了這套系統在實務上行不行得通。

對結果的影響力高中低

• 董事會、專案外的高階主管

• 發起人、CFO、CIO

• 流程負責人
• 會計主管、架構師

• 終端使用者

低中高專案對他們的影響程度

最有效的互動，發生在還沒有人抱怨之前。在啟動會議上，先把三件事敲定。

決策權

誰能核准範疇變更？誰簽核 UAT？誰能把上線延後的議題提到指導委員會？把它寫下來，取得簽名，放進專案章程。專案進行到一半，有決策遭到質疑時，您指向的就是這份文件。

沒有這份文件，有爭議的決策就會落到聲音最大、或最能接近發起人的那個人手上。這兩者都不是治理，而且都會滋生怨氣。我寫的如何撰寫 SAP 專案章程說明了決策權章節應該包含哪些內容。

溝通節奏

在啟動會議上就決定專案要多久溝通一次、透過哪個管道、溝通什麼內容。指導委員會每兩週一次。各工作流負責人每週一次。終端使用者在里程碑時溝通，並附上訓練通知。如果大家只有在出問題時才收到專案的消息，他們就會認定專案永遠在出問題。

範疇基準

寫下哪些在範疇內，哪些明確排除在外。排除項目與納入項目同樣重要，因為每一條沒有定義的界線，都是日後的衝突。設想一位財務主管，他以為費用管理在範疇內，卻在 Realize 階段才發現並不是。這個人在專案剩下的時間裡都會很難溝通，並不是因為他天性難搞，而是因為專案打破了一項心照不宣的承諾。

隨著專案走過 SAP Activate 各階段，參與方式的需求也會改變。在 Explore 行得通的做法，在 Deploy 行不通。請以此作為您參與計畫的骨幹：

階段	參與重點	節奏	主導者
Discover 與 Prepare	角色對照圖、治理結構、發起人簡報、與財務、營運及 IT 的第一輪對齊會議	開始時向發起人簡報；成立指導委員會	專案總監
Explore	與業務主管及流程負責人舉辦 Fit-to-Standard 工作坊；簽核前檢視 Fit-Gap 決策	每週工作會議；階段結束時召開指導委員會	解決方案架構師與流程負責人
Realize	準備 UAT；確保業務主管有時間投入測試；缺陷與資料移轉的狀態	指導委員會每兩週一次；工作流負責人每週一次	計畫經理
Deploy	切換準備度；在切換開始前先約定 go/no-go 準則	每日切換站立會議；向高階主管簡報 go/no-go	業務營運主管主導，IT 與 SI 協助
Run	Hypercare 溝通、問題回報管道、穩定化檢視	前兩週每日，之後每週；在第 30、60 與 90 天檢視	支援主管與流程負責人

有兩個階段最容易出問題。在 Explore，如果會議室裡坐的是不對的人，決策就會在 Realize、組態設定已經開始之後被重新翻出來。在 Realize，UAT 負責人抽不出時間或沒有準備好，是常見的模式。要在 Explore 階段就把它排進計畫解決，而不是等到測試開始前兩週。

傳統模式有三方：客戶、SI 與發起人。在 RISE with SAP 之下，SAP 以交付參與者的身分加入。它負責基礎架構與技術營運，其 customer success 團隊則追蹤採用狀況與價值。隨之而來有三項治理上的改變。

1. 擴充審查論壇。 每個落差都需要決策：用組態處理、透過已釋出的 API 擴充（以 ABAP Cloud 進行 on-stack 擴充，或在 SAP BTP 上做 side-by-side 擴充），或否決。在 S/4HANA Cloud Public Edition 上，不可能修改核心。在 Private Edition 上可以，但每一項修改都會增加升級工作。在指導委員會之下設一個小型論壇，並授權一位架構師拍板，可以避免每一場客製化爭論都落到指導委員會頭上。省略這一步，技術債會在第一次大型升級時浮現。
2. 與 SAP 的 customer success 節奏。 SAP 的團隊會就採用狀況、BTP 的使用與產品藍圖與您互動。它與導入治理並行，並在上線後持續進行。請把它納入您的治理，而不是另外各自運作。
3. 通往 SAP 的升級路徑。 當平台層級出問題時，CIO 需要知道在 SAP 該打給誰，而不是只知道合作夥伴那邊的窗口。簽約前，先確認聯絡人與服務等級。

Public Edition 上的 GROW with SAP 專案，也需要同樣這三項，只是分量較輕：擴充決策較少，因為可擴充的空間較小；customer success 節奏更為標準化；升級通常先經過合作夥伴。地端部署的專案則維持傳統模式，SAP 是供應商，而不是參與者。

AI 工具能協助處理參與工作中的文書作業，而不是人與人的關係。

會議摘要是最明顯的收穫。 Microsoft Copilot 能把錄下來的指導委員會會議，轉成會議紀錄草稿，只需要簡短檢視，不必長篇撰寫。它抓到的決策通常是對的，因為它依據的是逐字稿，而不是記憶。

決策紀錄排第二。 Confluence 的 AI 功能，現在歸在 Atlassian 的 Rovo 品牌之下，在您建好範本之後，可以把會議筆記轉成結構化的決策紀錄條目。

需求草擬在 Explore 階段有幫助。 SAP Cloud ALM 可以從 Fit-to-Standard 工作坊的逐字稿草擬需求。每一行仍然需要有人來驗證。

情緒分析大多只是做做樣子，在少於 100 人的專案中尤其如此。訊號很弱，誤判很常見，而且被人看到在監控情緒，會付出實實在在的政治代價。在非常大型的專案中，它或許能及早發現正在疏離的群體。對大多數專案來說，AI 預算花在別處更好。

對 SAP 的抗拒，幾乎都有其合理的基礎。提出反對的人，通常是在保護某樣東西：一個彌補舊系統缺口的變通做法、一項標準流程看不到的人工檢查，或是擔心自己的團隊吸收不了這項改變。在做出反應之前，先找出這個基礎。處理底層的疑慮，抗拒通常不必正面衝突就會消失。

「我們需要這個客製化」

這通常是在保護一個今天運作良好、而且當事人不信任標準 SAP 能處理的流程。把標準流程走一遍，問清楚究竟在哪裡行不通。很多時候，疑慮來自一個組態設定就能處理的邊界情況。有時候疑慮是正當的。只有透過對話才能知道，而在 Clean Core 之下，賭注更高，因為答案決定了您要不要自行建置並維護一個擴充。

「我們還沒準備好上線」

要認真看待。當業務主管說自己還沒準備好，通常有原因：資料品質、訓練不完整、某個流程還沒測過。找出具體的疑慮。如果疑慮成立，就該延後上線。如果那是焦慮而不是證據，就用有重點的準備來回應，而不是給一個新的日期。

最常見的情況是：UAT 暴露出的問題還沒修好。硬往前推，只是把問題從 UAT 搬進正式環境。兩週的延後，成本通常遠低於一段把時間耗在上線前就已知問題上的 Hypercare 期間。

「沒有人告訴我們這項變更」

這是溝通上的失敗。這個人在寄送名單上，卻沒有參加設計會議，或是這項變更寫在一份他從來沒讀過的文件裡。不要爭論誰溝通了什麼。道歉，帶他把這項變更走一遍，把他加入日後他所屬領域的設計檢視，並補上參與計畫中的缺口。

當衝突超出執行層所能處理的範圍時，有三件事很重要。

把它留在治理框架之內。 財務與 IT 之間針對系統存取權限的爭議，該拿到指導委員會上處理，而不是由比較堅持的一方私下解決。以非正式方式解決結構性的衝突，只會製造怨氣，並讓決策被重新翻案。

用業務語言來呈現。 財務與 IT 為了存取控制爭吵，那是政治。財務與 IT 把資安風險與營運成本並排呈現，那就是一項業務決策，指導委員會可以做出決定。把前者轉換成後者，是計畫經理的工作，或是 SI 負責人的工作，視合約而定。

記錄每一項重大決策。 決定了什麼、由誰決定、何時決定，以及考慮過哪些替代方案。六個月後，會有人說「我們從來沒有同意過那件事」。當指導委員會問為什麼選了某個組態，或新加入的人質疑過去的決策時，您需要的是紀錄，而不是憑記憶重建。一份共享的決策紀錄，每週更新、在指導委員會上檢視，幾乎不花什麼成本，卻能省下很多麻煩。

如果計畫經理的收件匣裡塞滿了緊急的升級事項，代表計畫沒有奏效。健康的專案靠有結構的決策運作，而不是每天救火。

健康的跡象： 指導委員會會議產出的是決策，而不是延後；業務主管參加工作坊與 UAT，不必有人催；範疇變更透過變更流程提出；上線後的問題透過既定管道進來；決策紀錄是最新的，並在指導委員會上被引用。

警訊： 大家繞過治理架構，直接找計畫經理；業務主管沒讀就核准交付成果，事後又提出異議；發起人在兩次指導委員會之間消失；沒有參加設計的人，質疑變更凍結；同一個衝突連續三次出現在指導委員會上。

警訊出現時，不要在既有的計畫上更用力。找出是哪個環節出了問題（節奏、權責、溝通或文件紀錄），然後只修那一個。更多的電子郵件、更多的會議，只會讓情況更糟。關於指導委員會本身，請參閱我寫的如何建立有效的 SAP 指導委員會；關於上線時人的層面，請參閱我的 SAP 變革管理筆記。

SAP 導入中的利害關係人管理是什麼？

它是一項有結構的工作：找出誰對專案有影響力或利害關係、了解他們的疑慮、建立溝通與決策機制，並讓他們從啟動到 Hypercare 都保持參與。

SAP 同時牽涉財務、人資、採購、營運與 IT，各自的優先順序與影響力都不同。把他們當成同一群人來管理，只會產出千篇一律的進度通知，並錯過造成抗拒的疑慮。SAP Activate 把這一點內建在每個階段：Explore 階段的工作坊、Realize 階段的 UAT 負責人，以及 Deploy 階段的準備度檢視，都仰賴準備充分的業務參與者。

如何為 SAP 專案建立角色對照圖？

把每個人或每個群體標在兩個軸上：對結果的影響力，以及專案對他們的影響程度。發起人、CFO 與 CIO 在兩個軸上都很高，需要直接、定期的接觸。會計主管、流程負責人與架構師的利益關係高，需要參與設計。專案之外的高階主管需要里程碑簡報。終端使用者需要有針對性的溝通，讓他們知道自己有什麼改變、何時受訓，以及去哪裡求助。

讓這張圖保持最新。人會換職務，影響力會隨著專案被看見而轉移，範疇擴大時也會有新的參與者加入。

SAP 參與計畫應該包含什麼？

一份角色登錄表（姓名、職能、影響力、利益關係、主要疑慮）、一份溝通計畫（每個群體的管道、頻率與內容）、針對範疇變更、設計決策與上線準備度的決策權、Activate 各階段的活動、有爭議決策的升級路徑，以及正式提出疑慮的方式。

每到一個階段關卡就更新。文件要寫得夠清楚，讓團隊不必靠計畫經理親自處理每一次互動也能運作，因為超過三十位具名參與者之後，這種做法就撐不住了。

如何處理業務主管對 SAP 的抗拒？

先找出根源。常見的有：擔心新流程漏掉某個重要的邊界情況、害怕生產力下降，以及覺得自己被排除在決策之外。流程上的疑慮，要拿到設計會議上處理。對生產力的擔憂，需要務實的訓練與明確的 Hypercare 支援。被排除在外，是溝通上的失敗，要去修補，而不是爭辯。

沒有合理基礎的抗拒就比較難處理。槓桿通常是發起人，他必須讓大家清楚看到，這個專案有領導層的承諾。不處理抗拒就硬推，是最糟的選擇：疑慮會在 UAT 時再次冒出來。

如何處理 SAP 專案中財務與 IT 之間的衝突？

多數衝突歸結為三種張力之一：存取權限與職責分工、報表彈性與資料治理，或整合步調與資安審查。

精確地說出這個張力是什麼。「財務希望會計主管能以唯讀權限查看生產訂單來做報表，而 IT 認為這會破壞職責分工」是可以解決的；「財務想要彈性」則不行。帶著各個選項與其風險，提到指導委員會上。然後記錄決策與替代方案，因為人事更替時，這些爭議還會再回來。如果指導委員會無法解決，就交給發起人。這正是治理依設計在運作。

RISE with SAP 如何改變利害關係人管理？

SAP 從單純的供應商，變成參與者。您需要一個擴充審查論壇，來決定在 Clean Core 之下每個落差如何處理；需要在治理中替 SAP 的 customer success 節奏保留一席之地；也需要一條有文件記錄、通往 SAP 的升級路徑，處理不必經由合作夥伴的平台問題。簽約前，先確認升級窗口與服務等級。