變革管理計畫：在抗拒出現之前就化解

ERP 專案的變革管理計畫，說明人們將如何從今天的工作方式，轉變為新系統所需要的工作方式，以及由誰負責帶領他們走到那裡。它從動員階段就開始，而不是從訓練才開始。它有七個部分，每個部分都有指名的負責人，並且與章程、設計工作坊及品質關卡連動，而不是當成支線來進行。

多數抗拒不是憑空出現的。它在啟動之前很久就慢慢累積。您會在早期會議中的旁敲側擊裡聽到它。您會注意到關鍵的業務主管變得沉默。等到正式的變革計畫草擬出來時，大部分的傷害已經造成了。

它通常從幾個可預期的地方開始：

1. 關鍵使用者被排除在早期設計之外。
2. 部門主管對沒有人跟他們討論過的衝擊感到意外。
3. 含糊的溝通，招來人們的猜疑。
4. 過去失敗的專案，留下了悄悄的不信任。

這些是結構性問題，不只是溝通問題。如果指導委員會很被動，就預期會有摩擦。如果專案章程對採用度隻字未提，您就已經失去了一個槓桿。

1. 01動員繪製影響力地圖並蒐集非正式的歷史
2. 02設計同意採用度 KPI，關鍵使用者共同撰寫
3. 03測試業務使用者測試自己的流程
4. 04訓練依角色、使用真實資料、在人們能出席的時間進行
5. 05上線關卡採用度門檻，而不只是功能簽核
6. 06前 90 天追蹤登入、錯誤、工單與權宜做法

在權宜做法變成習慣之前就攔下

變革計畫不是溝通行事曆。以下是七個組成部分，以及各自該由誰負責。

組成部分	目的	負責人
角色與影響力地圖	受影響的每個人，連同他們的影響力，而不只是職稱	變革負責人
變革衝擊評估	每個群體的角色、流程與工具如何改變	流程負責人與變革團隊
溝通計畫	對象、訊息、管道與時機，並附回饋迴路	溝通負責人
訓練與賦能	依角色設計的課程、練習、準備度檢查	訓練經理
領導層參與	領導者達成共識、已被說明，並公開支持這項變革	高層發起人，搭配變革負責人
採用度 KPI	在設計階段商定、上線後持續追蹤的行為指標	變革負責人
抗拒監控	對應到各團隊的早期警訊	所有工作範疇負責人

在多數變革計畫中，溝通指的是電子報、電子郵件與全員大會。那些不是真正能打動人的東西。

我記得有一次上線，我們按時溝通了所有事情，但沒有人能解釋為什麼流程要改變。我們有量，卻沒有清楚。

依對象量身調整。 高階主管想先看業務衝擊。終端使用者需要從自己的主管口中聽到，而不是從一位他們從沒見過的專案負責人。功能負責人在擁有部分訊息時，反應會更好。

內建回饋機制。 只有單向發送的溝通，只算半個計畫。我合作過一個團隊，每週的問答電話會議，比任何電子郵件都更有影響力。把您聽到的內容連結到風險登記冊，讓弱點在公開浮現之前就被看見。

掌握好時機。 太早會造成混亂。太晚則顯得被迫。在一次上線中，使用者以為他們的工作要被取代了。沒有人這麼說過。但沉默填補了空白。請直接而及早地處理這種恐懼，免得有人搶在您前面替您處理。

不要沿用上一個專案的人員地圖。影響力會隨著專案而變。請從零開始建立這份地圖，並每月更新。

對每個人，追蹤三件事：這項變革對他們的影響有多大、他們今天的立場（支持、中立或抗拒），以及他們對其他人有多大影響力。一位帶著團隊跟隨的抗拒型中階主管，比一位抗拒的個別使用者更重要。

也要蒐集非正式的歷史。過去失敗的專案，會以經驗教訓文件從未記載的方式塑造人們的行為。花幾個小時聽聽人們記得什麼，就能讓您知道自己真正面對的是什麼。我的利害關係人管理指南更詳細地說明了這份地圖。

訓練是變革管理的一部分，不是全部。常見的失敗是訓練來得太晚、形式不對，並且在人們有信心之前就停了。上線前兩週的一天課程，不等於準備就緒。

有效的做法：

1. 依角色設計的內容。 教每個群體做好自己工作所需的東西，而不是系統導覽。
2. 用真實資料練習。 使用業務自己的資料與交易，而不是示範情境。
3. 以關鍵使用者擔任訓練者。 人們向信任的同事學得更好。把關鍵使用者視為設計的共同作者，而不只是測試人員。
4. 在對的時間訓練。 我合作過的一個財務團隊，因為課程排在不對的時間而缺席。調整時間後就解決了。
5. 上線後的支援。 信心是在上線後下降，而不是上線前。請用能快速回答真實問題的人，來支撐上線後密集支援。

使用者驗收測試也是採用的一部分。我記得一次 UAT，定價邏輯中的一個小錯誤，會導致開立錯誤的發票。一位組長發現了它。其他人都沒有。那一次抓出，就省下好幾週的善後，而這之所以發生，是因為一位業務使用者覺得這套系統有一部分是屬於他的。

把採用度門檻放進您的品質關卡。「系統可以運作」是功能簽核。「使用者已準備好在其中工作」是另一種，而多數專案只要求第一種。我的 SAP 訓練策略指南更深入說明訓練計畫。

上線前就該商定的採用度 KPI

在設計階段就設定這些，才有基準可以衡量：

1. 前 90 天各使用者群體的登入率。
2. 關鍵交易的錯誤率，對照舊系統的基準。
3. 依數量與類別區分的支援工單。
4. 權宜做法的頻率：匯出到試算表、平行記錄、系統外的手動核准。
5. 來自簡短脈動調查、由主管回報的信心程度。

時間窗口很窄。我見過使用者在數週內悄悄切換回試算表，不是因為系統壞了，而是因為沒有人幫助他們度過這場變革。上線幾個月後，權宜做法就成了習慣。

數位採用工具

SAP 於 2024 年 9 月完成對 WalkMe 的收購，股權價值約 15 億美元。SAP 當時表示，WalkMe 的 AI 能力將為 Joule 在各工作流程中增添情境感知的協助。這表示 SAP 現在擁有兩個各有所長的採用工具：

• SAP Enable Now 適合結構化的訓練內容：錄製一次流程，就能產出文件、模擬與測試腳本。
• WalkMe 適合在使用當下於應用程式內提供引導，而且可橫跨 SAP 與非 SAP 的應用程式。

請一併評估它們。如果您想要不綁定 SAP 的採用工具，Whatfix 是主要的獨立替代方案。這些工具都無法取代主管解釋這項變革為何重要。

即使準備得很好，新的摩擦還是會出現。過度控制通常會適得其反。目標是及早看見它。

警訊包括缺席的工作坊、會議中的沉默、測試中含糊的回饋，以及關鍵使用者建立非正式的權宜做法。把每個訊號對應到它所來自的團隊，這樣您就能在它傳到指導委員會之前採取行動。

一個有效的做法：依階段輪替變革負責人。由一個人負責為期兩年專案的變革，通常會倦怠並失去視角。隨著抗拒的性質改變，處理它的人也該跟著改變。

最重要的是，讓變革管理留在專案架構之內。行為成果屬於專案章程。人員風險，例如團隊超載與對舊系統的不信任，應和技術風險並列於風險登記冊。當變革管理被併入一份泛泛的 PMO 更新，它就淪為打勾的形式。

變革管理計畫應包含什麼？

七個部分：影響力地圖、變革衝擊評估、附回饋迴路的溝通計畫、依角色設計的訓練、領導層參與、採用度 KPI 與抗拒監控。每一項都需要指名的負責人，而且計畫應該與章程、設計工作坊及品質關卡連動。

變革管理的 5 個 C 是什麼？

有好幾種版本。我使用的是：清楚（Clarity，人們知道什麼對自己改變了）、一致（Consistency，領導者說同樣的話）、承諾（Commitment，發起人持續現身）、溝通（Communication，相關、及時且雙向）與能力（Capability，訓練、支援與適應的時間）。缺少任何一個，人們就會回到舊習慣。

變革管理的 7 個 R 是什麼？

它們來自 IT 服務管理，用於在採取行動之前評估一項變更請求。誰提出的、原因、預期的回報、風險、所需的資源、誰負責，以及與其他變更的關係。它們適用於技術性的變更控制，而不是專案中人的那一面。

組織變革管理與技術變更管理有何不同？

組織變革管理讓人做好準備：在他們工作方式改變的過程中提供溝通、訓練與支援。技術變更管理控制哪些變更進入 SAP 系統，透過傳輸、核准、測試與回退。ERP 專案通常把技術面管理得很好；採用失敗源自組織面。我的 SAP 技術變更管理工具指南涵蓋技術面。

我該用 WalkMe 還是 SAP Enable Now？

通常兩者都用。SAP Enable Now 更擅長在上線前建立結構化的訓練內容。WalkMe 更擅長上線後的應用程式內引導，尤其是當使用者在 SAP 與其他應用程式之間切換時。既然 SAP 同時擁有兩者，請一併評估。Whatfix 是主要的獨立替代方案。

ERP 專案的變革管理應該何時開始？

在動員階段，第一場設計工作坊之前。最重要的早期行動，是繪製影響力地圖、蒐集過去專案的非正式歷史、把行為成果寫進章程，以及設定發起人的溝通節奏。