目錄
ERP 導入團隊需要一位有決策權的發起人、一位懂 ERP 的專案經理、來自每個受影響職能的業務流程負責人、功能與技術顧問，以及整合、資料遷移、測試、變革與切換上線的專屬負責人。雲端 SAP 專案還要加上一位 Clean Core 架構師與一位具名的 SAP 窗口。團隊規模要依複雜度決定，而不是公司人數，並且讓每位顧問搭配一位內部人員，由那位內部人員在上線後負責該領域。
本文寫給為 ERP 專案配置人力的發起人、CIO 與專案總監。內容涵蓋各個角色、讓每個角色成功或失敗的因素、團隊規模、雲端 ERP 與 AI 帶來的改變，以及如何與導入夥伴分工。
我合作過的一家公司，同時進行兩套 ERP 導入：一套是 SAP，一套是 Oracle。Oracle 專案有 4,500 人投入。SAP 專案有 38 人。一套順利上線。另一套是沒完沒了的災難。差別在於團隊。
在做了 25 年的 SAP 導入之後，這個模式始終成立。團隊找錯了，或是對的人放在錯的結構裡，專案就會拖延、成本攀升，到上線時使用者早已認定自己討厭這套系統。
- 專案發起人掃除障礙、確保預算、在部門之間做決定SAP 服務窗口在 RISE 專案中，負責平台問題升級與服務檢討
- 專案經理時程、範圍、風險與夥伴協調
- 業務流程負責人驗證設計並測試真實的工作流程
- 功能與技術顧問設定、延伸並提出異議
- 資料遷移負責人清理、載入與切換用資料
- 整合負責人中介軟體設計與資料流
- 變革與訓練負責人溝通、推動者、採用
- Clean Core 架構師在雲端版本中，決定每個延伸功能放在哪裡
| 角色 | 他們實際做什麼 | 何時參與 |
|---|---|---|
| 專案發起人 | 掃除障礙、確保預算、做出跨部門的決定 | 所有階段 |
| 專案經理 | 管理時程、範圍、風險與夥伴協調 | 所有階段 |
| 業務流程負責人 | 驗證設計、測試情境、代表真實的工作流程 | Explore 到 Deploy |
| 功能顧問 | 蒐集需求、設定模組、支援測試 | Explore 到 Deploy |
| 技術顧問 | 延伸功能、介面、系統設定 | Realize 到 Deploy |
| 整合負責人 | 跨系統的中介軟體設計與資料流 | Explore 到 Deploy |
| 資料遷移負責人 | 資料策略、清理、載入、切換用資料 | Prepare 到 Deploy |
| 變革與訓練負責人 | 訓練、溝通、採用度量 | Explore 到 Run |
| 測試負責人 | 測試腳本、SIT、UAT、缺陷追蹤 | Realize 到 Deploy |
| 切換上線經理 | 正式環境切換、停機、回退計畫 | Deploy |
| Clean Core 架構師（雲端版本） | 決定每個延伸功能放在哪裡，以及位於哪個 Clean Core 等級 | Explore 到 Run |
| SAP 服務窗口（RISE） | 平台問題升級處理、服務檢討、SAP 藍圖對齊 | Prepare 到 Run |
我的 SAP 導入團隊角色文章，逐一更詳細地說明各個角色。
專案發起人
發起人的工作不是簽完章程就消失。當專案經理之上沒有人有權在部門意見分歧時做決定，專案就會停擺好幾個月。發起人必須找得到人、願意做艱難的決定，而且在整個穩定期都在場，而不只是在啟動會議。
出錯的地方：把一切交給 IT 的發起人。ERP 改變的是企業的運作方式。如果領導層沒有帶頭推動，它就會失敗。指導委員會指南說明如何規劃發起人的議事論壇。
專案經理
ERP 專案經理需要了解 SAP 或 Oracle 專案實際上如何運作，而不只是一般的 IT 專案管理。風險、相依項目與切換上線時的壓力都不同。
出錯的地方：在範圍上對顧問讓步，或無法要求業務遵守測試期限的專案經理。
業務流程負責人
IT 不經營您的企業。營運、財務、採購與人資才是。流程負責人確保系統適用於真實的流程，而不只是紙上談兵。把他們排除在外，您得到的就是一套在工作坊中說得通、第一週就失敗的組態。
從一開始就讓他們參與，而不是在 UAT 才請他們核准自己沒參與過的決定。
ERP 顧問
好的顧問會提出異議。如果您的顧問什麼都同意、從不質疑任何需求，他們賺的是工時，而不是增添專業。最好的顧問會在錯誤耗掉好幾個月之前就攔下來。
弱顧問的一個徵兆：他們過度客製化，因為這比解釋業務為什麼該改變某個流程更容易。每一支自訂程式都必須維護、在升級時測試，並向下一個團隊說明。有了 SAP 的 Clean Core 等級，這筆債現在是看得見的：以舊方式建立的延伸功能會落在 C 或 D 級，並在第一次大型升級時浮現。
資料遷移負責人
舊系統中的壞資料，會變成新系統中的壞資料。如果在遷移之前沒有人負責資料品質的討論，財務報表在第一天就不會符合現實。
資料遷移是一個需要業務負責的業務流程。IT 可以搬資料。業務必須確認它是對的。
變革管理與訓練負責人
變革管理不是訓練。它是溝通、及早參與，以及在上線前於業務內部找到推動者。當企業以為訓練就夠了，不信任新系統的使用者就會回頭用他們的試算表，而在上線後修正這一點代價高昂。
這位負責人應該在建立內容、執行試行、衡量準備度，而不是在上線前兩週發一份 PDF。在 SAP 專案中，他們現在也負責數位採用工具：SAP 正把 SAP Enable Now 併入它在 2024 年收購的 WalkMe，所以新內容應該規劃在 WalkMe 中。
Clean Core 架構師（雲端版本）
SAP 現在以四個 Clean Core 等級為每個延伸功能分級，從 A 到 D。必須有人針對每個缺口決定，它是以標準組態解決、以 SAP BTP 上或系統內 ABAP Cloud 的 Level A 延伸功能解決，還是根本不解決。在大型專案中這是專屬角色。在中型企業專案中，通常由解決方案架構師兼任。
沒有 SAP BTP 與 ABAP Cloud 經驗的夥伴無法擔任這個角色。請問他們在這些規則下交付過多少個延伸功能，並要求看實例。
SAP 服務窗口（RISE 專案）
在 RISE with SAP 之下，SAP 營運您系統的基礎架構與營運，所以 SAP 是交付的一部分。CIO 需要一位具名的 SAP 窗口，處理平台問題升級、服務檢討與藍圖對齊。請從 Prepare 起，就把這個人列入團隊名冊，而不只是指導委員會的邀請名單。
我合作過的一家公司，同時進行兩套 ERP 導入。Oracle 有 4,500 人，SAP 有 38 人。一套順利上線。另一套是沒完沒了的災難。差別在於團隊。
團隊規模應符合複雜度，而不是員工人數。
| 公司類型 | 典型團隊規模 | 複雜度的來源 |
|---|---|---|
| 小型（單一法人，員工少於 500 人） | 10-25 | 多半是標準功能，整合不多 |
| 中型市場（多據點，500 至 5,000 位員工） | 30-75 | 更多整合、地區流程變體、大規模變革 |
| 大型企業（全球，5,000 位以上員工） | 100-500+ | 多個法人與整合、跨轄區的法遵 |
一座執行複雜接單生產的 50 人工廠，可能需要比一家執行標準零售流程的 500 人公司更大、更專業的團隊。請依需要完成的工作來決定規模。我的 SAP 專案資源配置規劃指南說明如何建立這份計畫。
Joule 現在位於 SAP 的導入工具中（SAP Cloud ALM 與 SAP Activate Roadmap Viewer）。SAP Build Code 使用 Joule 協助開發人員在 SAP BTP 上建置延伸功能。Microsoft Copilot 可草擬狀態報告、指導委員會簡報與變革溝通內容。
持續使用的話，這些工具能加快工作流程繁重的角色。它們讓專案比幾年前相同範圍所需的規模稍微精簡一些，但不會大幅縮小。
把這些工具寫進角色定義。功能顧問用 AI 草擬需求與 Fit-Gap 文件的初稿。專案經理用它做狀態報告。開發人員在有幫助的地方使用它。AI 沒有改變的是課責：它草擬得更快，但草稿上寫的內容，仍然要由人負責。
多數企業會結合一支了解業務的內部核心團隊，與一位帶來技術與方法深度的夥伴。
內部團隊必須真正參與，而不是只出席狀態會議。否則專案交付的，會是夥伴看得懂、但公司內部沒有人能運作的系統。
對夥伴的期待：結構、更快的決策，以及處理您這類錯誤的經驗。不該委派的：範圍決策、流程設計簽核與使用者準備度。這些需要內部負責人。
持續有效的模式是影子搭配（shadow pairing）。每位顧問都有一位內部對應人員，由他在上線後負責該領域。顧問負責交付，內部人員學習，顧問離開時知識就留了下來。
在審查夥伴時，請索取與您規模和產業相當的公司的參考，而不是廠商的展示客戶。請以實例詢問 Clean Core 經驗，以及他們如何在 RISE 專案中與 SAP 合作。含糊的答案會告訴您，誰跟得上時代，誰還在賣三年前所熟悉的那版 SAP。
ERP 導入團隊有多少人？
與其說取決於公司規模，不如說取決於複雜度。流程單純的小型企業通常需要 10-25 人，多據點的中型企業 30-75 人，全球大型企業 100-500 人以上。一家流程為接單工程設計的製造商，所需的人力，比執行標準零售功能的更大型公司還多。
雲端 SAP 專案需要哪些新的團隊角色？
兩個。一位 Clean Core 架構師或延伸功能負責人，決定每個延伸功能放在哪裡、位於哪個 Clean Core 等級；在較小的專案中，由解決方案架構師接下這項工作。還有，在 RISE with SAP 上，一位具名的 SAP 服務窗口，負責問題升級與服務檢討，因為 SAP 營運您系統的基礎架構與營運。
專案發起人在 ERP 導入中扮演什麼角色？
發起人確保預算、掃除障礙，並在部門意見分歧時做決定。他們的存在是為了讓專案可管理，而不是去管理它。發起人最重要的事，是在整個穩定期都保持投入。在切換上線後失去高層關注的專案，會產生持續多年的權宜做法。
ERP 導入為什麼需要業務流程負責人？
因為財務、營運、人資與採購的人，知道工作實際上是怎麼完成的。沒有他們，團隊設計出來的系統，在紙上說得通、在實務上卻行不通。請從一開始就讓他們參與工作坊與設計決策；到了 UAT，要改正錯誤的地方成本太高了。
我該如何挑選 ERP 顧問？
看他們是否願意提出異議。凡事都同意的顧問，是在讓自己輕鬆，而不是讓您輕鬆。好的顧問會質疑不好的需求、標出範圍蔓延，並解釋為什麼標準通常比客製化更適合您。接著再查驗他們的 Clean Core 經驗與實例、您能打電話查證的相近規模參考客戶，以及他們是在解決您的問題，還是在推銷自己早已熟悉如何交付的專案。
ERP 導入中的資料遷移該怎麼處理？
指派一位專屬負責人，掌管策略、清理規則、載入與上線驗證。資料品質由業務負責：IT 可以搬動一筆供應商記錄，但只有業務知道它對不對。
ERP 專案中的變革管理是什麼？為什麼重要？
在上線前、中、後，讓人們為其工作方式的重大改變做好準備。它涵蓋溝通（盡早說明什麼在改變、為什麼）、參與（關鍵使用者參與設計與測試），以及支持（協助同事適應的推動者）。把它當成訓練行事曆的專案，每次都得到相同的結果：權宜做法、試算表，以及沒有人信任的系統。
作者
Noel D'Costa
SAP 導入團隊的關鍵角色與職責
多數 SAP 專案失敗，根源在團隊，而不是技術。本指南說明每個專案都需要的八個角色、RISE 與 AI 如何改變這些角色、依企業規模而定的團隊人數，以及如何在上線前建立 CoE。
避開昂貴錯誤的最佳 SAP 導入策略
SAP 導入很少因為技術而失敗。失敗的原因，是策略不符合業務，或團隊守不住背後的紀律。
SAP 導入範本：逐階段指南
每個階段真正重要的 SAP Activate 範本，從範圍界定與 Fit-Gap 到切換上線與上線後密集支援，附上可直接參考的版面配置。跳過 Prepare 範本的團隊，會在 Realize 付出代價。
需求蒐集範本：我在專案中使用的 7 個技巧
需求蒐集範本要有用，就得逼大家及早面對困難的對話。這是我使用的大綱、我從不跳過的五個章節，以及七個讓利害關係人說實話的技巧。
下一步
您目前正在進行 ERP 專案嗎？
如果這篇文章談到的正是您目前進行中的專案，30 分鐘的對談通常比再花一週做內部分析更有進展。