顧問實際在做什麼：務實的觀點

SAP 顧問為企業配置、建置、測試並穩定 SAP。實務上，他們的大部分價值是在專案中段交付的。他們釐清已經偏移的範疇、執行沒有人做過的逐步演練、為 UAT 缺陷分流，並在上線後穩定營運。功能顧問負責模組配置，技術顧問負責擴充與整合，專案與變革顧問則負責交付與採用。本文寫給正在判斷是否該引進外部協助的領導者，以及正在評估顧問職涯的人。如果您是領導者，下方的訊號表會告訴您何時該打電話。如果您是顧問，日常工作的各個段落會呈現這份工作真正涉及的內容。

每次有人評估外部支援時，都會出現這個問題：顧問到底做了哪些我們自己做不到的事？

誠實的答案，對顧問業並不特別好聽。大部分的價值，來自修好本不該壞的東西。來自問出本早就該問的問題。也來自在內部團隊人力與思路都用盡的時刻，補上人力與清晰度。

這不是在批評內部團隊。這就是 SAP 專案常見的運作方式。內部團隊已經疲於奔命。系統整合商有自己的優先順序。決策堆積，範疇漂移。在十二個月的專案走到第六個月時，有人打開問題清單，發現有二十項標著「待解決」的事項，從第三週起就一直擺在那裡。

通常就是這個時候，電話打進來了。

有些顧問是在藍圖或規劃階段被請來。許多顧問則是在專案中途接到電話，通常是在進展緩慢或交接失誤兩三個月之後。指導委員會的報告看起來是橘燈。團隊很努力。進度緩慢，卻沒有人能確切說出原因。

1. Explore工作坊與差異Fit-to-Standard 工作坊，記錄差異
2. Realize建置與逐步演練配置與擴充開發。專案中期通常是救援求助電話打進來的時候
3. DeployUAT 分流與切換是配置、流程還是教育訓練的缺口？由分流來決定
4. Hypercare穩定化第一次月結與問題佇列

典型的切入點：

1. 範疇已經偏移。在 Explore 階段簽核的內容，與建置團隊正在做的事不再相符。需求是在工作坊中非正式加進來的，變更記錄沒有維護，沒有人手上有一份確定的範疇清單。
2. 關鍵的工作流停滯了。資料移轉卡在同一個錯誤率好幾週，卻沒有改善計畫。UAT 開出的缺陷比結案的還多。
3. 上線日期已定，計畫卻撐不起來。日期是董事會訂的。計畫沒有與實際進度對齊。專案經理知道照目前的走勢趕不上日期，卻還沒有升級回報。

在每一種情況中，工作都不是在既有計畫上加人。而是看清楚實際發生了什麼，坦率點出問題，並提出前進的路徑。我寫的讓 SAP 專案重回正軌指南，談的就是這套救援順序。

範疇與流程的釐清

有時配置是對的，但圍繞它的流程是壞的。常見的模式：團隊依據 Explore 階段的 Fit-to-Standard 文件進行配置，而業務使用者自簽核之後就沒再看過這份配置。他們被告知了正在建什麼，卻沒有人把它給他們看。

修正方法不是技術性的。這是對話上的缺口。工作是在 UAT 之前，帶著業務使用者走過配置，並在測試開始前產出一份清楚的變更清單。

這一點也不光鮮。工作就長這樣。

在技術團隊與業務團隊之間翻譯

SAP 專案經常產出技術上正確、業務卻用不了的東西。一個價格決定邏輯，在 90% 的情況下行得通，卻在出口訂單上出錯。一筆貨物移動過帳正確，卻產生了對帳團隊不認得的財務憑證。

功能顧問補上這個缺口。不是因為他是會議室裡技術最強的人，而是因為他對系統行為與業務影響的理解，足以讓對的人做出對的決定。

UAT 支援

使用者驗收測試，是專案累積的各項決策成敗見真章之處。Explore 階段的每一個走捷徑、每一項非正式增加的範疇，以及每一個只寫到摘要層級的測試案例，都會在這裡浮現。

良好的 UAT 支援，意味著正確地為缺陷分流，把配置缺口、流程缺口與教育訓練缺口區分開來。也意味著當業務使用者遇到一連串失敗、對整個專案失去信心時，能夠穩住氣氛。少了這一點，UAT 場次中的每一個缺陷都會成為質疑上線的理由，這通常是因為分流薄弱，而且沒有人定義過什麼叫「可以上線」。

上線後的穩定化

SAP 顧問工作中最不光鮮的，是 hypercare。上線完成了，慶祝的電子郵件寄出去了，導入團隊開始撤場。然後第一次月結來了。過帳與對帳格式對不上。生產訂單完成了卻無法結算。服務台湧入了接受過訓練、卻沒有為邊緣案例做好準備的使用者。

這正是許多真正價值被交付的地方，也是多數專案人力最不足的地方。hypercare 團隊有系統地處理問題佇列，把系統性問題與一次性錯誤分開，並重建對系統的信心。

工作的結構沒有變。變的是時間的組成。

文件大多會自己草擬。SAP Joule for Consultants 自 2025 年起正式推出，能從 SAP 自家知識庫（包括 SAP Notes）回答配置問題，並解釋 ABAP 程式碼。SAP Cloud ALM 中以 Joule 為基礎的助理，能依工作坊素材草擬需求與測試案例。功能顧問花在打字寫文件的時間減少，花在質疑工作坊結論的時間增加。

程式碼審查多於撰寫。SAP 的開發人員助理能草擬程式碼，包括用於 SAP BTP 上 Java 與 JavaScript 擴充的 SAP Build Code。技術顧問現在則負責審查、保護並測試它。

hypercare 服務台的例行問題減少。Joule 能在 SAP 應用程式內回答例行問題，例如休假餘額或費用狀態，這讓 hypercare 服務台少了一些量。顧問的時間轉向流程缺口、主檔資料問題，以及需要真人處理的案例。

引進顧問的目的沒有變。學會這些工具的顧問，把更多時間花在判斷、溝通與升級處理上，花在 AI 現在已能充分草擬的工作上的時間則減少。SAP 自己對 Joule for Consultants 的說明，是對其涵蓋範圍的合理概述。

功能顧問專精於 FI、CO、SD、MM、PP、EWM 或 SuccessFactors 等模組。他們圍繞業務流程配置系統，並縮小 SAP 標準與客戶需求之間的差距。他們的價值是模組深度加上業務流程知識。

技術顧問（ABAP 開發人員、SAP BTP 專家、整合架構師、Basis）打造配置無法涵蓋的擴充與整合。在現代的 S/4HANA 專案中，Clean Core 原則把新的擴充推向 SAP BTP 或已發布的 API，這需要與傳統 ABAP 修改不同的技能組合。

專案經理與計畫經理提供交付的結構：治理、風險、時程與問題解決，並且能看到整個專案的全貌，讓問題在演變成危機之前就被升級處理。

變革管理顧問處理人的這一面：教育訓練、溝通、參與，以及決定使用者是採用系統、還是繞過它的治理。

多數大型 SAP 專案四種都需要。中型市場的專案，往往是由較少的人兼任好幾種角色，缺口就是在這裡形成的。顧問框架與顧問業重要的技能，在這四種角色之間是共通的。如果您是顧問，正在規劃自己穿越這些角色的路徑，SAPopedia 整理了職涯路徑與課程，ERPCV 則協助您向招募人員呈現這些經驗。

代價最高的顧問錯誤，是太晚才請人來。在上線前四到六週進行的切換前風險審查，能在還來得及的時候發現重大問題。切換失敗後的救援委託，成本要高得多。而且還是在營運壓力之下進行，面對的是已對系統失去信心的組織。

下表列出各種訊號，以及各自需要的協助。

訊號	通常意味著什麼	該引進的協助	他們在兩週內應交付什麼
問題清單中的項目開著超過四週，沒有解決日期	是治理問題，而不是技術問題	獨立的專案顧問	一份附有負責人與日期的決策清單
距離上線不到 60 天，而且沒有切換演練	切換未經測試；上線時的意外，無法即時挽回	切換或專案負責人	一份經過演練的切換計畫與 go/no-go 標準
業務負責人已不再出席	若不刻意介入，UAT 會失敗	變革負責人加一位功能負責人	與關鍵使用者的逐步演練，以及重新參與的計畫
某一條工作流多週卡在同一個錯誤率	尚未找到根本原因	該工作流的專家	一份根本原因分析與一份救援計畫
對專案健康度的唯一視角，是 SI 的報告	沒有獨立查核	客戶端的顧問	一份給發起人的坦率健康度評估

SAP 顧問在專案上實際做些什麼？

他們分析業務需求，配置 SAP 來支援這些需求，並縮小 SAP 預設值與業務需要之間的差距。在 Explore 階段，他們主持 Fit-to-Standard 工作坊並記錄差異。在 Realize 階段，他們建置配置，並與開發人員合作處理擴充。在 Deploy 階段，他們支援 UAT、管理缺陷並準備切換。在 hypercare 階段，他們解決上線後的問題。職務說明中缺少的部分，是為階段之間的缺口分流，並在壓力下維持交付紀律。

組織真正需要顧問的時候是什麼時候？

三種情況涵蓋了多數委託。專案救援：範疇已經偏移、某條工作流停滯，或上線日期面臨風險。專業能力：團隊缺乏某個模組或技術技能，例如 PP-PI 配置或 SAP BTP 上的整合。以及治理：組織希望對由系統整合商主導的專案進行獨立監督。等到情況惡化才打電話，是最常見的模式，也是代價最高的。

功能與技術 SAP 顧問有什麼差別？

功能顧問在 FI/CO、SD、MM、PP 或 EWM 等模組中，配置 SAP 以支援業務流程，並直接與業務使用者討論需求。技術顧問則打造配置無法做到的部分：ABAP 與 BTP 擴充、整合，以及透過 Basis 進行的系統管理。Clean Core 原則正把技術工作，從系統內的 ABAP 修改，轉向 BTP 擴充與已發布的 API。

如何判斷顧問是否創造了價值？

三項指標。他們會挖出從未被檢驗的假設與被拖延的決策，而不是附和既有的意見。卡了好幾週的決策開始被做出來。問題清單縮短，是因為根本原因被修好了，而不是因為項目在未解決的情況下被結案。若問題清單的長度在忙了一陣之後仍然不變，代表問題是系統性的，或是修正沒有觸及原因。

顧問工作最困難的部分是什麼？

點出客戶早已知道、卻一直沒有處理的問題：偏移的範疇、沒寫出來的測試案例、不再投入的發起人。這需要足夠的信任才會被聽進去，需要足夠的信譽才會被相信，也需要足夠的直率才敢說出令人不舒服的話。為了維護關係而犧牲診斷的顧問，只是昂貴的附和。

客戶已經有 SI 了，為什麼還要聘請獨立顧問？

系統整合商負責交付合約約定的範疇。獨立顧問則是對客戶的成果負責。這是不同的工作。客戶端的顧問會質疑設計假設，並驗證設計是否滿足業務需求。他們在變更控管中保護客戶的商務立場，並讓管理階層看到一份不經整合商報告過濾的專案健康度。這是結構性的利益衝突，不是在批評整合商。