SAP 導入團隊的關鍵角色與職責

一個 SAP 導入專案需要八個角色，並且各有指名的專職負責人：高階發起人、專案經理、功能負責人、IT 負責人、資料移轉負責人、變革管理負責人、導入夥伴，以及一位獨立的專案顧問。RISE with SAP 還要加上 SAP 自己的交付窗口，並把 Clean Core 的負責歸屬明確化。本指南寫給正在組建或修復團隊的發起人與專案總監。內容涵蓋每個角色負責什麼、缺了它會出什麼問題、依企業規模而定的團隊人數，以及如何在上線前建立卓越中心（CoE）。請先檢查這八個角色中，哪一個是由另有本職工作的人擔任。那就是您最大的風險。

多年來，我與數十個 SAP 團隊合作過。我看過資金充裕、廠商經驗豐富的專案失敗，因為關鍵角色缺位，或是分散在身兼他職的人身上。我也看過資金不足的專案成功，因為對的人在場、全心投入，而且權責清楚。

我合作過的一家全球零售商，有預算、有領導層支持，也選定了 SAP 作為它的 ERP。但它的導入團隊一塌糊塗。關鍵角色缺位。沒有人負責關鍵決策。溝通四面八方亂竄，卻沒有落點。期限一再延後，成本上升，信心崩潰。

每個 SAP 導入專案都需要這些角色到位。頭銜不重要，權責歸屬才重要。

1. 高階發起人決策、資金、升級處理
   ERP 專案顧問獨立監督、風險、高階主管對齊
2. 專案經理時程、預算、協調

• 功能負責人與領域專家流程設計、模組組態
• IT 負責人與團隊整合、開發、資安
• 資料移轉負責人資料品質、載入順序、上線切換
• 變革管理負責人訓練、採用、溝通
• 導入夥伴架構、整合設計、交付

角色	主要權責	缺了它會出什麼問題
高階發起人	策略決策、資金、升級處理的權限	方向漂移、範圍之爭，沒有人能打破僵局
專案經理	時程、預算、跨團隊協調	延誤、阻礙懸而未決、成本超支
功能負責人與領域專家	業務流程設計、模組組態	組態錯誤、上線後的變通做法
IT 負責人與團隊	整合、開發、資安、效能	技術債、介面故障、系統不穩
資料移轉負責人	資料品質、載入順序、上線切換的正確性	資料無法使用、上線失敗、數月的清理工作
變革管理負責人	訓練、採用、溝通	使用者抗拒、平行存在的試算表
導入夥伴	架構、整合設計、交付	過度建置、整合失敗
ERP 專案顧問	獨立監督、風險、高階主管對齊	決策各自為政、本可避免的錯誤

高階發起人

發起人不是指導委員會簡報上的一個名字。他們要做出沒有別人能做的決策：預算、範圍變更、跨部門的資源承諾。當這個角色流於形式，專案就會漂移。

我合作過一家略過這個角色的公司。專案漂移了。沒有決策，沒有進展，錢就這樣打了水漂。

有效的發起人會一路陪到 Hypercare 結束。他們在上線後仍會參加每月的指導會議，做出一些小決定，讓卡了數週的事情動起來。我寫的如何設立 SAP 指導委員會指南，說明了如何建構這個會議。

專案經理

專案經理負責日常運作：時程、風險記錄、協調、進度更新。在大型 SAP 專案中，這是一個需要專職、而且做過同類工作的人來擔任的角色。

我曾看著一位客戶在導入中途失去首席開發人員。整個專案停擺了好幾週，忙著找人接替。

反過來的問題同樣有害。我合作過一家公司，團隊有超過 30 人。沒有人知道誰負責決策。簡單的變更要開五場會議。光是溝通成本，就讓時程從 12 個月拉長到 18 個月。

功能負責人與領域專家

這些人把業務營運轉譯成 SAP 組態。他們必須足夠了解業務，才能質疑不好的流程；也必須足夠了解 SAP，才知道什麼是可行的。

我合作過一個製造業客戶，團隊表現出色，原因是它的功能負責人在設計流程之前，先花時間待在工廠現場。

只投入一半的領域專家，一定會留下缺口。專案要嘛得到他們的注意力，要嘛只得到簽核單上他們的名字。這兩件事並不相同。

IT 負責人與團隊

IT 團隊掌管技術基礎：開發、Basis、資安、整合與效能。在 S/4HANA 上，它還要負責 Clean Core 的紀律，也就是讓客製程式碼遠離核心。

整合是多數團隊最低估的部分。每一條連到外部系統的連線，都需要被設計、建置、測試，並且有人負責。當沒有人盤點資料流時，介面會在 UAT 階段壞掉。請讓 IT 參與藍圖工作坊，而不是等決策做完之後才加入。

資料移轉負責人

這個角色常常指派得晚，人力又不足。等到資料問題浮現時，專案早已面臨時程壓力。

有一位客戶以為可以略過資料清理。大錯特錯。它的系統有好幾個月根本派不上用場。在已上線的系統上清理資料，比一開始就好好清理要花更多錢。

專職的移轉負責人會對每一次載入進行對帳，結構性的問題就是這樣在上線之前浮現的。當這個角色由另外扛著三條工作主軸的人兼任時，就不會發生。我那篇談 SAP 資料移轉為何失敗的文章，說明了方法。

變革管理負責人

這是一貫最缺人力的角色。我看過價值數百萬美元的系統閒置在那裡，因為沒有人願意改變自己的工作方式。

我看過一個技術上完美的導入案，因為使用者討厭它而失敗。組態是正確的，流程設計也很紮實。但每天使用它的人，沒有參與設計。他們不明白為什麼要改，於是繼續使用舊的 Excel 檔案。

有一家零售客戶之所以成功，是因為它傾聽了收銀員對新系統的疑慮，並調整了做法。

企業級專案的最低配置，是兩位專職的變革管理人員。一個人無法同時涵蓋訓練設計、溝通、抗拒管理與採用追蹤。

ERP 專案顧問

獨立顧問不是導入夥伴。這份工作是監督與修正航向：確認方向是否仍然合理，發現交付團隊因為離得太近而看不到的風險，並縮小高階主管以為正在發生的事與實際情況之間的落差。

我為擁有強大交付團隊、卻沒有獨立聲音的客戶擔任過這個角色。我合作過一個製造業客戶，差點導入錯誤的模組，因為沒有人把它的成長策略與它的 SAP 路線圖連起來。

及早發現問題是另一半。我曾在一位客戶的資料團隊中，識別出一個關鍵的技能缺口，比它會延誤上線的時間點早了三個月。我們在它變成危機之前就把它補上了。

八個角色的模型依然成立。2026 年有三件事，需要接進這個模型。

RISE 上 SAP 自己的交付窗口

在 RISE with SAP 私有雲上，由 SAP 負責基礎架構與技術營運。它的角色與職責文件，讓客戶與 SAP Cloud Architect Advisor、Client Delivery Manager 或 SAP 私有雲客戶中心團隊約定各項服務。把 SAP 指派的人，與夥伴團隊並列放進您的名冊，並指定您這一側負責這段關係的人。在地端部署的情況下，SAP 是軟體廠商，這一點不適用。

Clean Core 與擴充功能的負責歸屬

在 S/4HANA Cloud Public Edition 上，Clean Core 是由設計強制落實的：擴充功能透過已發布的 API、關鍵使用者工具或 SAP BTP 實現。在私有雲與地端部署上，仍然可以修改，但每一次修改都會讓升級更困難。必須有人負責守住這條線。

在較大型的專案中，這會是一位專職的 Clean Core 架構師，或向解決方案架構師報告的 BTP 擴充功能負責人。在中型企業的專案中，解決方案架構師通常會把它一併承擔，但權責歸屬需要白紙黑字寫下來。評估夥伴時，請詢問他們交付過多少個 BTP 擴充功能，並要求看範例。

AI 改變的是生產力，不是權責

SAP Joule for Consultants（自 2025 年起正式推出）能根據 SAP 自己的知識庫回答組態問題，並解說 ABAP 程式碼。SAP Build Code 能在 SAP BTP 上產生 Java 與 JavaScript 擴充程式碼。Microsoft Copilot 能起草指導委員會的簡報與狀態報告。

效益會出現在需求分析、狀態報告與客製開發這類工作流程繁重的角色上，而且只有在大家持續使用這些工具時才會出現。對於別人向您報出的任何生產力數字，請當成一個要在您自己專案上驗證的說法。

團隊比這些工具出現之前、同樣範圍所需要的略小一些，但沒有大幅縮減。請把這些工具寫進角色定義，而不是當成附帶的活動。AI 起草得更快。人仍然對草稿所說的內容負責。

下表列出各角色依企業規模的典型配置。請把它當作起點，再依範圍與地域調整。同樣的問題在 SAP 之外的情況，請參閱我寫的 ERP 導入團隊指南。

角色	小型企業	中型企業	大型企業
高階發起人	資深總監	CIO 或 CFO	C 級主管，並設有指導委員會
專案經理	1 位專職	1 至 2 位專職	專案群組經理，加上各工作主軸的專案經理
功能負責人	每個模組 1 至 2 位	每個模組各有專職人員	每個模組有數位
IT 團隊	2 至 3 位（共用）	4 至 6 位（專職）	8 位以上專家
資料移轉	1 位負責人	1 位負責人加分析師	專職的工作主軸
變革管理	至少 1 位	至少 2 位	3 至 5 位專職
Clean Core 或 BTP 擴充功能負責人	解決方案架構師	解決方案架構師	專職角色
SAP 窗口（RISE）	指名窗口	指名窗口	指名窗口，並進行每季檢視
導入夥伴	5 至 10 位顧問	15 至 25 位顧問	30 位以上，並有一位專案總監

技術能力讓系統建起來。情緒智商決定人們會不會使用它。

我合作過一家製造公司，倉儲經理在會議上面帶微笑，私下卻暗中破壞專案。一位敏銳的變革經理及早發現了跡象，並把他轉變成支持者。若是到上線時才發現，要補救會困難得多。

有一位客戶的專案經理技術上很傑出，卻無法調整自己傳達訊息的方式。CFO 需要的溝通方式，與倉儲人員不同。結果是整個組織的認同度偏低，上線過程也很痛苦。

「要用員工還是顧問？」這個問題的答案，幾乎總是兩者都要。

員工了解業務：流程、政治，以及沒有人記錄的變通做法。我合作過一家製造公司，它的員工發現了外部顧問完全漏掉的導入問題。這些洞察讓它避開了一次災難性的倉儲組態。

員工往往缺乏導入經驗。有一家零售客戶堅持全部使用內部團隊。六個月之後，他們已經嚴重落後，因為他們一邊導入 SAP，一邊在學 SAP。

顧問帶來的是模式辨識能力。我為一位客戶找來一位顧問，他立刻識別出一種會讓客戶上線當機的資料移轉做法。

顧問的風險在於知識轉移。如果內部沒有人學會這套系統，顧問費用在上線之後還會持續很久。

行得通的模式是影子搭檔。有一家製藥客戶為每位顧問配一位內部對口，由這位對口在上線後負責該領域。顧問負責交付，對口負責學習，知識就留了下來。圍繞這個模式，有六個做法造成了差別：

1. 在選軟體之前先建團隊。 有一位客戶買了團隊維護不了的模組，隨之而來的是六個月的混亂。
2. 讓人專職投入。 兼任代表壓力來臨時，本職工作會勝出。我看過關鍵的組態因為某個人太忙，而擱置了好幾週。
3. 盡可能集中辦公。 有一家製造業客戶讓團隊每週三天在同一個房間辦公，省下了數週的來回溝通。
4. 及早定義升級路徑。 有一家零售客戶有一份一頁式文件，清楚標示決策如何逐級向上。它省下了無數的延誤。
5. 把決策與理由一併寫下來。 我合作過一家公司，會記錄它決定了什麼、為什麼這麼決定。這讓新的高階主管在專案中途加入時，省去了無止境的重新討論。
6. 沿途標記里程碑。 一家製造業客戶舉辦每月表揚活動。雖然是小事，卻讓團隊在漫長艱辛的 18 個月導入期間保持士氣。

公司在上線後常犯的錯，是解散導入團隊。而那正是 CoE 需要接手的時候：負責功能增強、升級、治理、新使用者訓練，並讓組態持續貼合業務實際的運作方式。

請在導入期間就規劃好。我有一位製造業客戶沒有聽從這個建議。上線三個月後，它的關鍵組態專家離開了。沒有人知道如何維護已經建好的東西，系統隨即開始退化。

以下是從導入的最初幾個月就該規劃的 CoE 角色。

CoE 角色	主要職責
CoE 總監	SAP 策略、與業務目標對齊、CoE 營運
解決方案架構師	架構、整合設計、Clean Core 治理
Clean Core 或 BTP 擴充功能負責人	擴充功能目錄、升級影響分析
功能顧問	模組最佳化、流程改善
技術顧問	開發、Basis、效能、資安
變革與訓練負責人	採用、訓練、能力提升
資料治理負責人	主檔資料品質與標準
整合負責人	中介軟體、API、跨系統資料流
支援負責人	問題解決、持續改善
SAP 關係負責人（RISE）	對 SAP 的升級處理、服務檢視、路線圖對齊

一家製藥公司指派了模組負責人，任何可能影響其領域的變更，都必須經過他們核准。這套治理避免了不協調的變更，而這類變更通常是系統在兩、三年後變得難用的原因。

有一位客戶把 CoE 預算的 10% 投入持續學習。三年後，它正在導入競爭對手碰都碰不了的新功能。一個運作良好的 CoE，就是這個樣子。

為什麼 SAP 導入團隊在計畫看似紮實時仍會失敗？

通常是因為計畫涵蓋了技術，卻忽略了人。常見的模式有：關鍵角色由另有本職的人擔任、領域專家在專案中途被調回營運單位，以及把變革管理當成訓練功能。當沒有人負責某項決策、也沒有升級路徑時，阻礙會擱置好幾週，專案就敗在協調，而不是技術。

在任何 SAP 導入專案中，哪些角色是沒得商量的？

有六個角色需要專職、有權責的人：高階發起人、專案經理、每個主要模組至少一位功能負責人、IT 負責人、資料移轉負責人與變革管理負責人。少掉任何一個，缺口都會在上線前的最後幾週浮現。變革管理是人力最不足的一個。在 RISE 上，還要再加上一位明確負責擴充功能，以及負責與 SAP 交付窗口之間關係的人。

RISE with SAP 的團隊設計有什麼改變？

SAP 負責基礎架構與技術營運，所以您會與 SAP 指派的窗口合作，例如 Client Delivery Manager 或 Cloud Architect Advisor。把他們放進名冊，並指定您自己這一側的關係負責人。Clean Core 的負責歸屬也必須明確：大型專案由專職架構師負責，中型企業專案則由解決方案架構師負責。

SAP 專案團隊該用員工還是顧問？

兩者都要。員工帶來顧問無法快速複製的業務脈絡。顧問帶來員工通常缺乏的導入模式辨識能力。把每位顧問與一位內部對口配對，由這位對口在上線後負責該領域，這樣顧問離開後，知識才會留下來。略過這一點的公司，往往要為本該自己處理的支援，付上好幾年的費用。

應該何時開始建立 SAP CoE？

在導入期間，最好從最初幾個月就開始。您最優秀的 CoE 成員，通常是導入階段貢獻最大的人；如果等到上線才開始，他們在您識別出來之前就已經離開了。有一位製造業客戶等得太久，在上線三個月後失去了關鍵的組態專家，也沒有人知道如何維護已經建好的東西。

AI 在 2026 年如何改變 SAP 團隊設計？

SAP Joule for Consultants、SAP Build Code 與 Microsoft Copilot 這類工具，在大家持續使用時，能提升工作流程繁重角色的生產力。團隊比這些工具出現之前、同樣範圍所需要的略小一些，但沒有大幅縮減。請把這些工具納入角色定義，並讓權責歸屬於人：AI 起草得更快，人仍然對草稿所說的內容負責。