SAP 專案的資源配置規劃

SAP 專案的資源配置規劃，就是決定您需要哪些角色、在哪個 SAP Activate 階段、每週投入多少小時，然後每週檢查現實是否仍與計畫相符。要依角色配置人力，而不是籠統的人頭數。計畫要配合各階段的曲線：Explore 以功能面人員為主，Realize 以技術面人員為主，Deploy 則以資料、Basis 與變革管理為主。要與直屬主管書面確認人員的可投入時間。這份指南寫給正在擬定或搶救 S/4HANA 資源計畫的專案總監、PMO 與 CIO。請把下方的 FTE 表與日費率區間，當作起點的參考基準。

我看過數十個導入專案卡在同樣的資源問題上。計畫假設了一種穩定，一進入執行階段，這種穩定就消失了。

我曾看過一個團隊整整損失一週，因為沒有人發現資安負責人連續請假又接著要受訓。這件事沒有被標示，也沒有被追蹤，結果讓一項關鍵的系統存取檢視延誤了九天。

多數 SAP 計畫都倚賴整齊的估算、全職投入的人力，以及可預測的工作流程。這樣的世界，撐不過 Realize 的第一個月。

我的規劃圍繞三件事：工作實際需要什麼、現有的人實際能交付什麼，以及現實與計畫不同時會有什麼改變。一份站得住腳的計畫涵蓋六個面向：

1. 依角色、依 Activate 階段配置的人數。 不是一成不變的配置。Explore 與 Realize 完全不同。
2. 由直屬主管確認的每週投入小時數。 要有書面，不能憑假設。
3. 每個人同時身負的承諾。 列為 100% 投入、卻又要兼顧正式環境支援的人，實際產出會少得多。
4. 關鍵路徑上每個角色的備援。 在 18 個月的專案中，交叉訓練不是選項。
5. 跨工作流的相依關係。 每一項都有指名的負責人、到期日與升級路徑，一旦延誤，當天就看得見。
6. 更新節奏。 主動階段每週更新。啟動會議時的計畫只是第一版。

當規劃者使用籠統的 IT 角色時，計畫就會出錯。SAP 需要明確的功能與技術專長分工。S/4HANA 專案的標準配置如下：

專案領導層。 專案經理、PMO 主管與解決方案架構師。架構師負責各模組之間設計的一致性。

功能顧問。 範圍內每個模組各一位負責人：財務會計（FI）、管理會計（CO）、物料管理（MM）、銷售與配銷（SD）、生產規劃（PP）、延伸倉儲管理（EWM），若在範圍內，還有人力資本管理（HCM）、工廠維護（PM）與專案系統（PS）。如果您還在使用傳統的倉儲管理（WM），請規劃轉換：它在 S/4HANA 地端部署版上的相容包（compatibility pack）使用權，已於 2025 年底結束。

技術顧問。 ABAP 開發人員，負責報表、介面、轉換、增強、表單與工作流程（RICEFW），以及以已發布 API 或 SAP BTP 實作的 Clean Core 擴充。整合專家，負責 SAP Integration Suite（Cloud Integration，前身為 CPI）、仍在運行的 SAP Process Orchestration，以及任何第三方中介軟體。

平台。 Basis 顧問，負責 HANA、核心修補、傳輸、系統複製與效能調校。資安顧問，負責角色設計、職責分離分析，以及（若在範圍內）SAP GRC Access Control。

資料。 移轉專家，使用 SAP S/4HANA Migration Cockpit 的「Migrate Your Data」應用程式（舊的 LTMC 交易已被淘汰）、處理客製物件的 Migration Object Modeler，以及處理複雜轉換的 SAP Data Services。我的指南為什麼 SAP 資料移轉會失敗說明了為什麼這個團隊需要比多數計畫所預留的更早開始。

變革管理。 變革管理負責人、教育訓練負責人與業務就緒度負責人。通常人手不足，因為這項需求要到 Deploy 階段才會顯現。

客戶端。 業務分析師（每個主要模組一位）、流程負責人（每個流程領域一位），以及為 UAT 從營運單位抽調的測試人員。

把這些角色當成可以互換的空格，是最常見的規劃錯誤。資深 FI 顧問無法主持 SD 的設計會議。初階 ABAP 開發人員無法設計整合架構。關於各角色的職責，請參閱我的SAP 導入團隊的必要角色清單。

資源需求不是平的。Activate 的各階段會形成可預測的曲線，而平均配置會漏掉這些曲線。

Prepare（通常為第 1 至 4 週）。負荷較輕。專案經理、架構師，以及負責界定範圍的各模組負責人。業務使用者確認範圍。Basis 與資安開始建置環境。

Explore（通常為第 2 至 5 個月）。以功能顧問與業務使用者為主，設計工作坊決定時程。在設計決策確定之前，ABAP 與整合的工作量不大。Basis 準備沙箱與品質保證系統。

Realize（通常為第 5 至 12 個月）。以技術人員為主：組態、建置、單元測試與整合測試。ABAP 工作量達到高峰。業務使用者加入測試週期。資料團隊建置移轉物件並執行試跑。

Deploy（通常為第 12 至 14 個月）。以資料移轉、Basis、資安、變革管理與教育訓練為主。UAT 會占用業務端的人力。切換演練需要團隊集中在同一地點工作。Hypercare 規劃開始。

Run（第 14 個月起；Hypercare 通常為 30 至 90 天）。核心團隊精簡，支援涵蓋量大。Basis 與應用系統管理的人力增加，顧問則逐步退場。

如果把這些階段當成需求相同的時間窗口，您就會在 Prepare 階段人力過剩，在 Realize 階段人力不足，並在 Deploy 階段缺少資料移轉的人手。階段曲線，是計畫中最重要的形狀。

1. Prepare約 11 FTE第 1 至 4 週。負責人界定範圍，Basis 建置環境
2. Explore約 36 FTE第 2 至 5 個月。功能顧問與業務使用者
3. Realize約 56 FTE，達到峰值第 5 至 12 個月。建置，ABAP 工作量達到高峰
4. Deploy約 42 FTE第 12 至 14 個月。資料、Basis、資安、變革管理
5. Run約 12 FTE第 14 個月起。Hypercare 通常為 30 至 90 天

不斷出現緊急狀況。 團隊老是在救火，代表計畫已經無法預測現實。一個人缺席，不該就能讓整個工作流脫軌。

需要業務使用者時，他們卻不見了。 設計會議與 UAT 因業務使用者抽不出時間而停滯。這是延誤最常見的來源之一。原因幾乎總是一樣：時間是被假設的，而不是正式承諾的。只要承諾沒有正式化，營運壓力每次都會獲勝。

技術人員被分得太散。 Gerald Weinberg 在軟體管理方面的研究估計，一個人若同時分屬三個專案，只能發揮其總產能的約 60%，其餘都耗費在切換上。美國心理學會（American Psychological Association）對任務切換研究的摘要指出了相同量級的損失：在任務之間切換造成的短暫思緒中斷，最多可能吃掉 40% 的有效工時。計畫看起來很有效率。產出卻不是。

關鍵路徑每週都在變。 不斷重新洗牌、工作流晚啟動、每週改變優先順序，通常都能追溯到範圍不明或相依關係排序不當。先釐清範圍，再去修資源計畫。

1. 虛假的可用性。 列為 100% 投入的人，同時還要負責月結與正式環境支援。請問清楚每週有多少小時、還在做哪些事，以及直屬主管是否已書面確認。
2. 共用角色卻沒有界線。 一個人同時負責方案設計、測試與變革管理。依任務而不是職稱來切分職責，而且絕不要讓同一個人同時在兩個地方成為關鍵。
3. 缺少業務使用者的時間。 工作坊延後，UAT 簽核多拖好幾週。要讓時間承諾以書面確立並由部門主管簽署，追蹤出席狀況，並及早升級反覆出現的情況。
4. 沒有緩衝。 一個人缺席，整個工作流就停擺。緩衝要建在任務層級，而不只是階段層級，並且至少讓一個人接受每個核心角色的交叉訓練。
5. 計畫從不更新。 在啟動時建立後就再也沒有修訂。在主動交付期間每週檢視，與階段關卡連動，並在現實改變時更新。

從已確認的可用性開始。 在專案開始前，就去找直屬主管。確認每週小時數與其他承諾，並記錄下來。專案進行中如果可用性改變，這份基準就是您升級處理的依據。

依階段塑造計畫。 ABAP 開發人員在 Explore 與 Realize 的工作量不同。業務使用者在 Explore 因設計而達到高峰，在 Deploy 則因 UAT 而達到高峰。平均配置在紙上看起來均衡，到了現場卻行不通。

明確對應相依關係。 資料移轉餵給整合測試，整合測試餵給 UAT，UAT 推動切換。讓每項相依關係都有負責人、日期與標記，如此一有延誤，當天就看得見。

在指導委員會層級保護業務使用者的時間。 他們的本職工作仍在繼續。如果沒有其管理層就每週小時數明確簽核，營運壓力一來，他們就會放掉專案。向部門主管要這些時間的，應該是發起人，而不是專案經理。

每週更新計畫。 兩週沒動過的計畫，多半是錯的。追蹤實際與計畫的使用率。有人連續兩週達到 120%，就是一個訊號：不是他們超載了，就是計畫錯了。

以下是可作為起點參考基準的 FTE 與費率區間，僅供參考。產業、範圍、地區與合作夥伴都會讓它們有所變動。請把這些表格當作合理性檢查，而不是報價。

中型企業 Brownfield（500 萬至 1,500 萬美元，約 12 個月）

典型範圍：單一法人實體或小型集團，三到四個模組（通常是 FI、CO、MM、SD），標準流程，以及有限的客製開發。

工作流	Prepare	Explore	Realize	Deploy	Run
專案經理	1	1	1	1	0.5
解決方案架構師	1	1	1	0.5	0
功能顧問（FI/CO、MM、SD 再加一位）	1	4	4	2	1
ABAP 與技術	0	1	3	1	0.5
整合	0	0.5	2	1	0.5
Basis	0.5	0.5	1	2	1
資安與授權	0	0.5	1	1.5	0.5
資料移轉	0	1	2	3	0
測試負責人	0	0.5	1	1	0
變革管理與教育訓練	0.5	1	1	2	0.5
客戶端業務分析師	1	4	3	2	1
FTE 峰值總計	5	14	20	17	5

企業級 Brownfield（3,000 萬至 8,000 萬美元，15 至 18 個月）

典型範圍：多個實體、六到九個模組、複雜的整合、可觀的客製開發，以及數個國家的推展。

工作流	Prepare	Explore	Realize	Deploy	Run
專案經理與 PMO	2	2	3	3	1
解決方案架構師（總架構師加各模組架構師）	2	3	3	1.5	0.5
功能顧問（範圍內所有模組）	2	10	12	5	2
ABAP 與技術	0	3	8	3	1
整合與中介軟體	0.5	2	5	2	1
Fiori 與 UI5	0	1	3	1	0.5
Basis	1	1	2	4	2
資安與 GRC	0.5	1.5	2	3	1
資料移轉	0	2	5	6	0.5
測試	0.5	1	3	4	0
變革管理與教育訓練	1	2	3	5	1
客戶端業務分析師	2	8	7	5	2
FTE 峰值總計	11	36	56	42	12

各角色與地區的日費率（2024 至 2025 年）

這些是合作夥伴對每位專家的計費費率，不是薪資。整個專案的混合費率，通常會比在地資深費率低 30 至 50%，因為多數專案會把在地架構師與離岸交付人員搭配使用。

角色	在地：美國/英國/德國	GCC（阿聯/沙烏地）	近岸（拉丁美洲/東歐）	離岸（印度）
解決方案架構師（資深）	$2,000 至 $3,500	$1,500 至 $2,500	$900 至 $1,500	$500 至 $1,000
功能顧問（資深）	$1,500 至 $2,800	$1,200 至 $2,000	$700 至 $1,400	$300 至 $700
功能顧問（中階）	$1,000 至 $1,800	$800 至 $1,400	$500 至 $900	$200 至 $500
ABAP 與技術（資深）	$1,400 至 $2,500	$1,000 至 $1,800	$600 至 $1,200	$300 至 $700
整合專家	$1,500 至 $2,800	$1,100 至 $1,900	$700 至 $1,300	$350 至 $800
Basis	$1,400 至 $2,200	$1,000 至 $1,800	$600 至 $1,100	$300 至 $700
資安與 GRC	$1,500 至 $2,500	$1,100 至 $1,900	$700 至 $1,300	$350 至 $800
資料移轉	$1,300 至 $2,200	$1,000 至 $1,700	$600 至 $1,100	$300 至 $700
變革管理與教育訓練負責人	$1,200 至 $2,000	$900 至 $1,500	$500 至 $1,000	$250 至 $600
初階顧問（任何角色）	$800 至 $1,400	$500 至 $900	$400 至 $700	$150 至 $350

在地、近岸與離岸的分工

多數 SAP 專案會混合不同地區。這是成本與速度之間的取捨，不是非此即彼。

美國民間部門專案的在地占比，依 FTE 計通常為 30 至 60%。在地人力集中在架構、變革管理、業務分析與資深功能角色，這些角色靠近業務很重要。離岸人力集中在 ABAP、整合建置與資料移轉執行，這類工作比較容易明確定義規格。美國聯邦專案則常常是完全在地，並受限於美國人身分的要求，視工作內容而定。

GCC 專案的在地占比通常為 60 至 70%，因為當地的聘僱規定與阿拉伯語的要求把比例推高。離岸工作則因時區重疊而傾向南亞的中心。歐洲專案差異很大：製造業通常在地占比約 50%，公部門與受監管產業則因資料落地的原因而更高。

一個常見的錯誤，是只為成本去最佳化這個比例。一個 80% 離岸、20% 在地架構師的團隊，在試算表上看起來很便宜。隱藏的成本在於每天的交接循環，以及缺乏業務脈絡而變慢的設計工作坊。最便宜的團隊，很少能做出最便宜的專案。比較合作夥伴時，我的指南依規模分級的 SAP 導入夥伴談到了他們在費率與團隊組成上的差異。

只建立一次、從不重新檢視的計畫，不算計畫。把裡面的每一項假設，都當作要在執行第一週驗證的假說，之後每一週也一樣。

SAP 專案中的資源配置規劃是什麼？為什麼重要？

就是決定專案需要哪些人、何時需要、需要投入多少時間，然後追蹤這是否與現實相符。

SAP 專案仰賴特定的個人：了解您會計科目表的 FI/CO 負責人、熟悉您舊系統資料的移轉專家、在業務端有人脈的變革管理負責人。當他們在關鍵時刻無法投入，工作就會停擺，或是做錯。許多看似技術性的延誤，其實是資源問題。

資源配置不良如何造成 SAP 專案延誤？

透過相依關係。組態負責人在 Realize 階段被抽調去別的專案。他的工作停擺，進而延誤整合測試，再延誤 UAT，然後是切換就緒度。第八週出現的兩週缺席，到上線時可能變成六週的延誤。

早期的小缺口，會在後期變成大延誤。等到影響看得見時，救援的成本是早期修正的好幾倍。

業務使用者有本職工作，如何讓他們承諾投入 SAP 專案？

在專案開始前，取得直屬主管的書面承諾：每週小時數、哪些階段最需要他們，以及可用性改變時需要什麼核准。

像追蹤其他資源一樣追蹤他們的出席狀況。一旦下滑，就在指導委員會層級升級處理。部門主管可以強制執行這項承諾；專案團隊不行。

專案進行到一半，關鍵人員離開時該怎麼辦？

一開始就避免單點故障：每個關鍵工作流，至少要有另一個人了解到足以讓它繼續運轉。

有人離開時，要立刻把他所知道的記錄下來：沒有文件記載的決策與組態背後的理由。這往往比找接替的人更難。就補位而言，交接文件、錄下的說明會議，以及一週的重疊期，是最低限度。

資源問題該在什麼時候升級處理？

比您覺得舒服的時間更早。當指名的相依關係負責人已有超過一週無法聯繫、某位業務使用者一再缺席會議、某位技術人員連續兩週的使用率超過 120%，或是某個工作流因為延後的人力決策而被卡住時，就該升級。

太早升級的代價，是一次尷尬的對話。太晚升級的代價，是好幾週的延誤。

跨多個專案共用的資源該如何處理？

假設共用的人在壓力來臨時會優先處理別的事。與他們的主要直屬主管約定明確的每週小時數，在依賴他們的工作中預留緩衝，並且除非有備案，否則別讓他們處在您的關鍵路徑上。

至於共用的業務使用者，請求必須由發起人提出。專案經理向部門主管要時間，每次都會輸給營運的優先事項。