SAP 與 AI 交付的七個顧問框架

SAP 或 AI 專案停滯時，原因通常出在結構，而七個簡單的框架就能找出來。描繪現況。用 RACI 談定誰決定什麼。把工作與業務能力連結起來。用五個為什麼找出根本原因。用 MoSCoW 為需求排序。依真正能讓專案停擺的程度為風險排序。每個階段結束後，辦一場真正的事後檢討。這篇指南寫給 SAP 與 AI 交付的計畫經理、顧問與發起人。請從下表開始：找出您遇到的症狀，先使用對應的框架。

卡達有一家中型媒體公司，正在多個區域推行 SAP。財務與採購在第一階段上線。它還希望在報表中加入 AI 預測模型。

到了第六週，延誤開始悄悄出現。業務使用者說，他們已經簽核了需求，卻仍然搞不清楚自己會拿到什麼。AI 應用情境已經提出，卻沒有人說得出誰擁有資料，也不知道輸出結果要如何使用。有人開會遲到，有人乾脆不來。

那是一段不上不下的階段。要說是失敗，還太早。要假裝它會自己好轉，又太晚。

我們一步一步套用這些框架。一開始並非所有人都歡迎。有些會議很安靜，有些則偏離了方向。但這個結構讓工作變得更容易：團隊不再原地打轉，待辦清單變得可以管理，AI 應用情境也有了真正的負責人。專案比計畫晚了八週上線。談不上完美。但它落地了，第二階段也在更好的基礎上展開，未知數更少。

在 23 年的交付經驗中，我在海灣地區、歐洲及其他地方的 SAP、Oracle 與 AI 專案裡，用過這七個框架的各種版本。沒有一個是稀奇古怪的東西。只要您帶著紀律去運用，而不是當成文件作業，它們都有效。

把症狀對應到框架：

您看到的症狀	框架	產出	一般工作量
使用者簽核了需求，卻仍然困惑	1. 現況對應	一張大家共有、描繪今天工作實際如何進行的地圖	3 到 5 天的工作坊
決策在會議之間不斷被踢來踢去	2. 針對關鍵決策的 RACI	為 20 到 30 項關鍵決定指定決策負責人	一場工作坊，之後落實執行
發起人已不再關心「IT 專案」	3. 能力對應	以業務能力來回報進度	納入 Fit-to-Standard 之中
同一類缺陷一再出現	4. 五個為什麼	一個您能改變的根本原因	每個問題一場有引導的會議
所有項目都被標為高優先級	5. MoSCoW	一份已排序的範疇，附上務實的 Must Have 清單	一場業務與 IT 的聯合會議
風險紀錄看起來沒問題，但團隊感覺緊繃	6. 風險排序	分開列出足以讓專案停擺的風險與只是造成麻煩的風險	每週 30 分鐘檢視
同樣的錯誤階段接著階段重複	7. 事後檢討	三到五項有負責人的改變	每個階段之後半天

專案一開始最常見的錯誤，是在記錄現有狀況之前就跳到解決方案。流程文件通常已經過時。人們描述的是事情應該怎麼運作，而不是實際怎麼運作。兩者之間的落差，正是導入問題藏身的地方。

一份有用的現況對應圖，需要與實際做事的人，而不是管理他們的人，一起進行三到五天的工作坊。內容涵蓋依序排列的流程步驟、每個步驟使用的系統、人工介入與變通做法，以及部門之間的資料流。

要找出的是：因為已經隱形而沒有人提起的人工步驟、運行得太久而被當成標準流程的變通做法，以及大家都知道卻沒有人去修的資料品質問題。

在卡達，現況對應圖來自與使用者的工作坊，而不是來自文件。對於已簽核需求的困惑，就是從那時開始釐清的。

做得正確的話，現況對應圖只需要幾天。如果把它當成蒐集文件的作業，就要花上好幾個月，而且產出的東西沒有人信任。

決策權是 SAP 與 AI 專案中最常缺少的結構性要素。每個人都有意見。沒有人知道誰做最後決定。決策被送到下一場會議，那場會議推給指導委員會，指導委員會又把它退回工作小組。

RACI 矩陣（Responsible 負責執行、Accountable 當責、Consulted 被諮詢、Informed 被告知）讓每項決策與交付成果都有一位負責人。一個人是 Accountable，他可以同時也是 Responsible，或把執行委派出去。Consulted 的人提供意見。Informed 的人聽取結果。

務實的做法是：列出目前階段最關鍵的二十到三十項決策，並在決策者都在場的情況下，辦一場 RACI 工作坊。如果某項指派有爭議，您就學到了一件事：不是治理不明確，就是有一場圍繞權限的政治角力。不論是哪一種，都要在第二週就讓它浮上檯面，而不是等到第十四週。

沒有落實執行的 RACI 只是裝飾。上面的名字必須對應到真正有權限的人。把當責指派給一個職稱，而不是一個具名的人，是一種迴避「誰來承擔風險」這場對話的方法。

SAP 與 AI 專案會產生大量業務看不見的技術活動。正在建置的東西，與它應該帶來的成果之間的連結，變得抽象。發起人抽離，而「IT 專案」被拿來背黑鍋，承擔那些其實是業務決策所造成的延誤。

能力對應把系統功能連結到業務能力，也就是組織需要能夠做到什麼。與其追蹤採購訂單工作流程是否已設定完成，不如追蹤組織能否在收到供應商發票後三天內處理完畢。組態設定是機制。能力才是成果。

在 SAP Activate 中，這對應到 Explore 階段的 Fit-to-Standard 工作坊。範疇內的每個流程都是一項能力，而 SAP 標準功能與所需能力之間的每個落差，都是一項決策：接受標準、組態出一個變體，或做擴充。把對話維持在能力層級，能讓業務在整個建置期間持續關注，也能揭露那些大家以為在範疇內、卻從來沒有人確認過的能力。

當同一類問題在各個 sprint 或階段中反覆出現，逐一修補每個個案是沒有幫助的。原因在上游。

五個為什麼是最簡單的根本原因分析工具。問問題為什麼會發生，再問那件事為什麼會發生，一直問到您能改變的事情為止。問五輪，通常就能找到真正的原因。只問兩輪，通常停在症狀上。

舉一個資料移轉的例子。試載入出現資料品質錯誤：這是症狀。為什麼？來源擷取檔的欄位對應是錯的。為什麼？對應規格從來沒有經過業務的資料負責人審閱。為什麼？資料負責人是在對應工作完成之後才被指派的。為什麼？計畫沒有把資料負責人的參與，設為對應工作的相依條件。這就是根本原因，而解法是一項治理決策，不是資料修正。我寫的為什麼 SAP 資料移轉會失敗一文，顯示了這條一模一樣的因果鏈有多常出現。

1. 01試載入出錯這是症狀
2. 02欄位對應錯誤為什麼載入失敗？
3. 03規格從未被審閱為什麼對應是錯的？
4. 04負責人太晚指定為什麼規格沒被審閱？
5. 05計畫漏掉相依關係為什麼負責人這麼晚才指定？

根本原因是治理上的決策，而不是資料修正

在不究責的場合做根本原因分析，會得到誠實的答案。在追究責任的場合，只會引發防衛心態。引導者的工作，是讓對話聚焦在流程，而不是人。我寫的結構化思考與問題解決指南，談到了在開始問為什麼之前，如何拆解一個雜亂的問題。

每一場 SAP 與 AI 的範疇討論，都有一個共識陷阱。沒有人想做取捨，所以所有項目都變成高優先級。當所有項目都是高優先級，就等於沒有任何項目是，而建置團隊會試圖全部做完。

MoSCoW（Must have、Should have、Could have、Won't have this time）會逼迫大家做選擇。Must Have 是上線所需的最低限度。Should Have 很重要，但不會阻礙上線。Could Have 是在時間與預算允許時，值得做的項目。Won't Have 則明確延後。

紀律就在 Must Have 這條線上。MoSCoW 練習的第一輪，通常會把太多東西放進 Must Have。MoSCoW 的出處，也就是 Agile Business Consortium 的 DSDM 指引，把 Must Have 的工作量上限訂在 60%，並警告超過這個比例會讓交付面臨風險。第一輪結果與務實清單之間的差距，大多來自未經檢驗的假設。

要讓業務與技術在同一個房間裡進行 MoSCoW。如果分開進行，IT 的 Must Have 清單與業務的 Must Have 清單，結果會互不相容，而且直到組態設定開始之後，都沒有人去調和。

多數風險登錄表都是依機率與影響評分的長清單，每月檢視一次，RAG 狀態很少變動。它們記錄了風險，卻沒有推動行動。

把能讓專案停擺的風險，與只是讓專案更難推動的風險分開。前一組需要負責人、因應計畫與每週的可視性。後一組只需要監控。

在卡達，風險紀錄在紙面上看起來沒問題，但每個人都神經緊繃。一份快速的風險影響矩陣，每週而不是每月檢視一次，把真正的疑慮帶了出來。

登錄表看起來沒問題，團隊卻感到緊繃，幾乎總是代表有事被藏起來了。登錄表不是真相，圍繞它的對話才是。一場每週的檢視，如果問的是「昨晚什麼事讓您睡不著？」，比問「第 14 項的狀態是什麼？」更能挖出東西。我的 SAP 風險評估矩陣提供了評分與責任歸屬的範本。

階段結束或上線之後的事後檢討，能防止同樣的錯誤在下一階段重演。當時程吃緊時，它們也是最先被砍掉的項目。

一場有用的事後檢討會問四個問題。我們原本計畫達成什麼，實際達成了什麼？什麼做得好，應該重複？什麼做得不好，原因是什麼？我們會怎麼做得不一樣？結尾應該是三到五項有負責人的具體行動，而不是一份摘要發生了什麼的文件。

常見的失敗，是淪為一場辯護，團隊在替決策辯解，而不是檢視它們。要保持向前看。問題不在於是誰造成了第六週的延誤，而在於什麼樣的結構性改變，能在下一階段防止它們。

在卡達，事後檢討在上線後立刻進行，聚焦在行動，而不是究責。這是第二階段能在更好的基礎上展開的一大原因。

框架本身沒有改變。改變的是它們被運用的方式，有三個面向。

草擬變快了，傾聽沒有。 AI 工具現在能在幾分鐘內，把工作坊的逐字稿與流程文件變成地圖初稿，SAP Cloud ALM 也能依 Fit-to-Standard 的逐字稿草擬需求。工作坊本身花的時間和以前一樣長，因為重點就在傾聽。草擬省下來的時間，應該用來與人一起檢驗這張地圖。

RACI 草稿現成可得，困難的部分依然存在。 通用型 AI 助理，只要一分鐘，就能依專案章程與工作包清單產出一份 RACI。紀律轉移到協商上：每一格都需要一場關於權限與升級的真實對話。建立草稿省下來的時間，應該投入那些困難的對話。

有 AI 在場，MoSCoW 變得更難。 AI 對需求的排序看起來合理、包裝精美，卻常常搞錯當地的政治生態。不加質疑就接受它的顧問，產出的優先順序清單，比從空白紙開始的顧問更差。把 AI 的草稿當成起點，絕不是答案。

疊加在這些框架之上的判斷力，現在比以往更有價值，而不是更低。如果您身為顧問正在培養這些技能，SAPopedia 的職涯路徑說明了在 SAP 職涯的每個階段，哪些技能最重要。

什麼是顧問框架，為什麼 SAP 專案要使用它們？

它們是用於分析、決策與解決問題的結構化方法。在 SAP 與 AI 專案中，它們讓業務主管、架構師、專案經理、整合商與發起人，擁有一套共通的方法。

沒有共通方法，每個群體都會回到自己的思維模型：流程成果、架構，或時程與資源。像現況對應、RACI 與 MoSCoW 這樣的框架，能讓分歧變得明確而且可以解決。SAP Activate 本身就是一個關於階段、關卡與交付成果的框架；這七個框架在它之內運作，處理的是單靠方法論無法解決的結構與人的問題。

SAP 導入中的現況對應是如何運作的？

它在組態設定開始之前，記錄流程實際上如何運作，而不是現有文件所說它們應該如何運作。要與執行流程的人一起，在工作坊中建立：步驟、系統、交接、人工介入與變通做法。

它會餵進 SAP Activate 的 Explore 階段的 Fit-to-Standard 工作坊，在那裡，現況成為與 SAP 標準流程比較的基準。要在那些工作坊開始之前完成它，否則您的落差分析就建立在假設之上。

什麼是 MoSCoW 優先順序排序法，在 SAP 專案中何時使用？

MoSCoW 把需求分為 Must have、Should have、Could have 與 Won't have this time。Must Have 是上線的最低要求；Won't Have 被明確排除，讓它們無法偷偷溜回來。

它在 Explore 階段最有用，當時 Fit-Gap 的發現會推動擴充決策；在 Realize 階段也有用，當時缺陷與增強項目在爭奪建置時間。常見的問題，是第一輪的 Must Have 太多。DSDM 建議 Must Have 的工作量不超過 60%；一位會質疑每一項的引導者，讓業務與 IT 在同一場會議中，就能帶您到達這個目標。

如何在 SAP 專案中進行有效的風險檢視？

把它當成一場對話，而不是狀態更新。先從開放式問題開始，例如「本週有哪個您最大的疑慮，是不在登錄表裡的？」，然後再逐項檢視登錄表。

針對每個高優先級風險，問問有什麼改變、採取了什麼行動、趨勢是否在改善，以及因應計畫是否仍然適用。連續好幾週評等不變、也沒有採取行動的風險，往往是被低估了。在積極進行的階段每週檢視，並向指導委員會呈現前五大風險的狀態與下一步行動，而不是整份登錄表。

SAP 上線後的事後檢討，怎樣才有用？

針對下一階段，提出具體、可執行的改變。發生了什麼的摘要，只是紀錄，不是事後檢討。

涵蓋您原本打算達成什麼、實際達成什麼、什麼有效、什麼無效。要往表面解釋的下方深挖，例如「我們人力不足」：是人力計畫錯了、範疇錯了，還是升級路徑斷了？最後以三到五項改變作結，每一項都有負責人與日期。

顧問框架如何協助 SAP 環境中的 AI 導入？

AI 專案失敗的結構性原因，與 SAP 專案相同，再加上幾個自己特有的：沒有負責人的資料、沒有定義成功衡量指標，以及沒有談定如何依輸出結果採取行動的流程。

現況對應能看出模型所需的資料由誰擁有、品質如何。RACI 回答誰來驗證輸出、誰決定依此行動，以及出錯時誰當責。MoSCoW 把必要的應用情境與有趣的情境區分開來。先從兩、三個有明確負責人與成功衡量指標的必要應用情境開始，而不是一次十五個。