SAP 專案風險評估：務實版本

SAP 專案風險評估，列出可能讓專案脫軌的事項，並依發生機率與影響程度為每項風險評分。每項風險都有一位指定的負責人，以及在事情發生之前就議定的因應措施，而且這份清單每週檢視一次。讓 SAP 專案沉沒的風險，很少是意外：資料移轉、整合、人員可用性、範疇漂移與採用度。本文寫給想要一份能改變決策、而不是躺在資料夾裡的風險登記冊的專案經理與贊助者。它提供有評分的矩陣、登記冊範本、三個公開的失敗案例作為實例，以及 RISE with SAP 與 Clean Core 帶來的風險。請先從為您手上已有的每一項風險，指定一位負責人開始。

多數 SAP 風險評估，是在第一次指導委員會之前建好、檢視一次，然後再也沒碰過。那不是風險管理。那是一份文件。

我見過有些風險被忽略，因為太令人不舒服，沒有人願意及早提出。這種沉默，幾乎總是在後來付出更大的代價。原本只是物料管理中的一個小整合問題，突然就擋住了財務。測試時看起來沒問題的報表，在系統更新後壞掉。這種事，我見過不只一次。

這些風險並不是意外。它們有記錄。只是沒有人處理。

**範疇。**專案一開始用的是標準模組。然後有人加上「再多一份報表」，接著是儀表板，再來是幾項增強功能。危險在於，這些範疇變更是在工作坊、電子郵件與走廊閒聊中非正式地引進，專案經理要等到配置完成後才聽說。我的指南如何避免範疇蔓延談了控管方式。

**資源。**架構師被抽調去處理正式環境的問題。一位關鍵的開發人員離職。業務使用者因為日常工作不會停，錯過測試週期。請把可用性寫成書面。口頭承諾，在人力壓力下就會蒸發。

**技術。**欄位對應從未對照目標結構驗證。介面通過了單元測試，卻在真實交易量下壞掉。客製程式碼看起來沒問題，直到正式環境的負載。只要知道往哪裡看，這些都是可預見的。

**時程。**藍圖延遲，會擠壓測試，但上線日期卻維持不變。UAT、教育訓練與資料準備被趕工。幾乎每個錯過階段關卡、卻沒有調整下游計畫的專案，都出現同樣的模式。

**採用。**人們會排斥自己不了解的東西。薄弱或太晚的教育訓練，會產生變通做法，變通做法會損害資料，然後系統就被拿來背變革管理失敗的黑鍋。

這些案例都是公開且記錄詳盡的。這些模式在各種規模都會重演。

Lidl：七年約 5 億歐元

Lidl 在 2011 年於 SAP for Retail 上啟動它的 eLWIS 專案，在一些較小的國家上線，並在 2018 年放棄了它，據報成本約 5 億歐元。一個廣為報導的原因是：Lidl 以採購價計算存貨價值，而 SAP 的標準零售模式使用零售價。Lidl 選擇客製化，而不是改變這項做法，公司表示，原本的目標無法以合理的努力達成。

啟示：您的資料模型與 SAP 標準之間的不一致，是第一週就該面對的風險，不該是第五年才發現的事。

HP：約 4 億美元的營收損失

2004 年，HP 把部分伺服器業務，移轉到一套整合的、以 SAP 為基礎的訂單與供應鏈系統上。訂單在舊系統的前端與 SAP 之間掉落，需要人工處理，積壓的訂單量翻了一倍。HP 的 CEO 表示，這些問題讓伺服器與儲存事業群損失了約 4 億美元的營收與 2.75 億美元的營業利潤，並留下 1.2 億美元的積壓訂單。HP 的 CIO 後來說，團隊原本只規劃了三週的中斷，應該要準備四到六週的緩衝。

啟示：應變準備要依糟糕的切換來估，而不是依平均的切換，並且在切換之前，先建立庫存或通路的緩衝。

Nike：逾 1 億美元的銷售損失

2000 年，Nike 在 SAP ERP 專案之前，先上線了 i2 的需求規劃軟體。這套軟體為了配合 Nike 的舊系統而大幅客製，執行緩慢，並在產品量下當機。它某些鞋款訂太多，某些訂太少。Nike 損失了逾 1 億美元的銷售額，股價下跌約 20%。Nike 後來把短期與中期規劃，移到 SAP 中。

啟示：在整合以真實資料、以正式環境的資料量跑過之前，絕對不要假設它行得通。

建立在假設之上的評估，比沒有評估更糟，因為它製造了虛假的信心。六項輸入很重要：

1. 範疇文件：章程、核准的範疇與簽核的需求。如果它們不存在，範疇風險就已經很高。
2. 資源承諾：部門主管的書面承諾、關鍵角色的技能矩陣，以及每個關鍵職位的指定備援人員。
3. 預算與時程：含預備金的核准預算，以及對照可比專案查證過的時程。完整推展只給六個月與最低限度的資金，是現在就該指出的風險。
4. 廠商承諾：載明服務水準與罰則的合約。在 RISE 上，則是 SAP 的責任與議題升級的管道。
5. 技術環境：舊系統相容性、資料移轉的複雜度、部署模式，以及針對任何客製工作的 Clean Core 計畫。
6. 過往專案紀錄：先前 SAP 或 ERP 專案的風險登記冊、問題紀錄與事後檢討。多數風險並不是新的。

依發生機率與影響程度，為每項風險從 1 到 5 評分，然後相乘。下例是 S/4HANA 專案典型的起點；您的分數會有所不同。

風險	發生機率（1-5）	影響程度（1-5）	分數	優先順序
資料移轉失敗	4	5	20	高
整合延誤	4	4	16	高
資源限制	4	4	16	高
預算超支	3	5	15	中
核心中的客製程式碼擋住升級	3	5	15	中
範疇蔓延	4	3	12	中
測試涵蓋缺口	3	4	12	中
尖峰負載下的效能	3	4	12	中
法遵缺口	2	5	10	中
沒有向 SAP 升級議題的管道（RISE）	2	5	10	中
使用者採用度低	3	3	9	中
訂閱或授權成本風險	2	4	8	中
未追蹤 KPI	3	2	6	低

分數在 16 以上，需要立即指定負責人並採取行動。8 到 15 分，需要監控，並訂出明確的升級觸發條件。低於 8，保留在登記冊上，不必花優先的時間處理。分數是起點，不是判決：在受法規管理的產業，一項評為 10 的法遵缺口，可能變成 25。

光有分數，什麼也改變不了。每項風險都需要這些欄位，並且填寫完整。

欄位	該寫什麼	範例
風險	用一句話描述事件	在第 2 次模擬載入之前，供應商主檔資料尚未清理
負責人	一位指定的人員	應付帳款負責人
分數	發生機率 × 影響程度	4 × 5 = 20
觸發條件	您採取行動的可量測時點	第 1 次模擬載入的擷取資料中，重複率高於 5%
因應措施	迴避、減緩、轉移或接受，並寫明行動	減緩：兩位應付帳款分析人員投入三週清理
下次檢視	日期	下週一的風險檢視會議
狀態	開啟、處理中、已結案	處理中

在可行的地方，用真實的數字說明成本。「高風險」很含糊。「UAT 延誤一週，團隊工時成本約為六位數，並可能讓上線往後推三週」才會引起注意。

**客製程式碼本身就是一個風險類別。**在 S/4HANA Cloud Public Edition 上，核心內不可能有客製程式碼。擴充要透過 SAP BTP、已釋出的 API 或關鍵使用者工具進行。在私有雲與地端環境，您仍然可以修改核心，而習慣這麼做的合作夥伴就會去做。這種技術債，會在第一次重大升級時浮現。請追蹤有多少已辨識的客製項目，有議定的 Clean Core 做法，查證合作夥伴在 BTP 擴充上的經驗，並在 Explore 階段結束前，成立一個檢視論壇。

**RISE 改變了誰負責可用性。**SAP 運行基礎架構，所以風險從「我們的團隊負責可用性」，轉變為「SAP 負責，而我們在出事時需要快速的聯絡管道」。請記錄 SAP 的指定聯絡人、議題升級的管道與服務水準，以及在上線前議定的事件處理計畫。沒有這些，本該交給 SAP 的問題，會在專案團隊內部待太久。

**AI 幫得上文書工作，幫不上判斷。**SAP Cloud ALM 中以 Joule 為基礎的助理，以及像 Microsoft Copilot 這樣的工具，可以從狀態報告、缺陷紀錄與會議紀錄，起草登記冊項目與指導委員會的簡報資料。在來源資料乾淨的專案中，這加快了登記冊的維護。它找出的是資料中已經看得見的風險。它不會決定哪些風險值得採取行動、讓負責人去行動，或把領導層寧可忽視的風險升級上去。

1. **跨五個類別辨識風險。**與 IT、業務端與廠商一起辦工作坊；各方看到的風險不同。在 RISE 上，至少在一場中納入 SAP 的聯絡人。團隊通常漏掉的風險：IT 與業務端期待不同的東西、定義不清的外部整合、無法到場的 UAT 負責人，以及非正式的範疇變更。
2. 為每項風險評分，依發生機率與影響程度，盡可能使用真實的數字。
3. **每項風險指定一位負責人。**是一個人，不是一個團隊。沒有負責人，就沒有追蹤，也沒有解決。
4. **在風險降臨之前就定義因應措施。**迴避、減緩、轉移或接受。「監控並回應」不是計畫。那是延後的決定。
5. **每週檢視。**檢查未結風險、加入新風險、在條件改變時重新評分，並把接近觸發條件的任何事項升級。把最重要的風險，連同擬議的決策，而不是一個顏色，帶到指導委員會。

1. 01辨識涵蓋全部五個類別
2. 02評分發生機率 × 影響程度，1 到 5
3. 03指定負責人一個人，不是一個團隊
4. 04定義因應措施迴避、減緩、轉移或接受
5. 05每週檢視重新評分，接近觸發條件時升級

16 以上：這週就要有指定的負責人與行動

SAP 專案中的風險評估是什麼？

它是辨識可能出錯的事項、依發生機率與影響程度為每項風險評分、為每一項指定負責人，並在事情發生前議定因應措施的過程。SAP 專案同時要面對多個模組、整合、資料移轉、變革計畫與固定的上線日期，所以非正式的風險管理撐不住。一份有負責人的簡短真實風險清單，勝過一份沒人讀的長文件。

如何為 SAP 專案建立風險矩陣？

列出範疇、資源、技術、時程與採用等類別的風險，再加上 RISE 上的 Clean Core 與向 SAP 升級議題的風險。依發生機率與影響程度各從 1 到 5 評分，然後相乘。16 以上視為高，8 到 15 視為中，低於 8 視為低。為每一項中度與高度風險指定負責人與可量測的觸發條件，例如「如果第 16 週時 UAT 完成度低於 80%，上線日期就送交檢討」。每週重新評分，並在每個階段關卡時重新評分。

SAP 導入中最常見的風險有哪些？

資料移轉失敗，因為舊資料幾乎總是比估計的更亂。整合延誤，特別是無文件記錄的舊介面與第三方廠商。壓縮了測試與教育訓練的範疇蔓延。資源限制，例如關鍵人員被調走，或使用者在月底的 UAT 期間無法到場。教育訓練只是示範畫面、而不是模擬工作所造成的低採用度。在 RISE 上，再加上核心中的客製程式碼，以及缺少向 SAP 升級議題的管道。

SAP 專案中，風險評估應該在何時進行？

在專案開始之前，因為這時資料模型不一致或不切實際的時程這類結構性風險，修正的成本最低。在每個 SAP Activate 階段關卡之前，因為每個階段都會改變風險輪廓。每當範疇、預算或資源改變時。還有當一項風險變成問題時，檢查它還牽動什麼。在這些時點之間，每週檢視。

SAP 專案中，風險該由誰負責？

能對它採取行動的人。資料負責人負責資料移轉風險，技術架構師負責整合風險，變革負責人負責採用風險，解決方案架構師負責 Clean Core 風險。在 RISE 上，CIO 或專案總監負責向 SAP 升級議題的管道。專案經理追蹤登記冊的健康狀況，但不負責每一項風險。

略過 ERP 風險評估會發生什麼事？

在大規模上，就會出現像 Lidl 的案例，它在花了約 5 億歐元之後，於 2018 年放棄了 SAP 零售專案。或是 HP，它在 2004 年的 SAP 訂單系統移轉，讓伺服器事業群損失了約 4 億美元的營收。在較小的規模上，機制是一樣的：太晚才發現資料模型不一致、整合在正式環境的資料量下失敗，以及教育訓練薄弱造成的採用失敗。這些風險在變成問題之前，是可以辨識的。