SAP 導入與推展的差異，以及何時選哪一種

SAP 導入，是在原本沒有 SAP 的地方把系統建起來。推展（rollout），則是把集團內某處已在運行的 SAP 系統，延伸到新的國家、法人實體或事業單位。多數人以為推展只是規模較小的導入。這個假設造成的返工，比任何技術決策都多。

我曾經讓一位 CFO 相信，區域性的 SAP 推展會是隨插即用。我說明了風險，但沒有堅持。當時我們用的是全球範本，他以為每個據點不費多少力氣就會跟上。事情不是這樣發展的。有一個區域需要額外的稅務處理。另一個區域因為當地法令，必須有員工資料的必填欄位。看起來像是複製貼上的工作，實際上需要真正的客製。

所以，這個選擇會改變您如何配置人力、編列預算與推動工作。選錯了，系統或許還是會上線，只是不會照您原本規劃的樣子。

導入從零開始。您要界定範疇、對應流程、配置系統、移轉資料、建立整合。它適用於組織沒有 SAP，或要整個汰換舊系統的情況。

推展重用一套已經行得通的設計：流程、配置、主檔資料標準。要做的工作，是這套範本與新據點需求之間的落差。稅務、法定報表、幣別、語言、在地整合，還有實際使用系統的人。

1. 05在地使用者依在地流程調整教育訓練，並使用在地語言
2. 04在地整合新國家的銀行、稅務申報與物流系統
3. 03在地資料客戶、供應商與物料資料，對應到全球標準
4. 02在地需求稅務、法定報表與必填欄位。只收需求，不收偏好
5. 01全球範本已經行得通的流程、配置與主檔資料標準

兩者在實務上的比較如下：

面向	SAP 導入	SAP 推展
起點	沒有 SAP，或要汰換舊系統	總部或其他法人實體已在運行 SAP
設計	全新設計，採 Fit-to-Standard	全球範本，加上受控的在地差異
一般時程	12 至 24 個月，大型集團更長	每個據點 6 至 12 個月
主要風險	每個工作流都有未知數	在地化與在地準備度
資料	從舊系統完整載入	在地資料對應到全球主檔資料標準
測試	完整週期：單元、整合、UAT、效能	在地化、在地介面、UAT
變革管理	從零開始的完整計畫	沿用現有教材，依在地團隊調整

導入適用於以下情況：

1. 組織從未使用過 SAP。
2. 現有系統已經失靈，需要整體汰換。
3. 併購或新的營運模式，讓舊設計不再適用。
4. 首次引入產業解決方案，例如 SAP for Utilities 或 SAP for Public Sector。
5. 沒有任何現有範本涵蓋您需要的範疇。

導入花的時間較長，前期成本也較高。換來的是一套貼合您業務的設計，以及一個了解每項抉擇背後原因的團隊。草草走完需求階段的公司，事後修正錯誤要多花 30% 至 50% 的成本。這種事我看過一次又一次。

推展適用於以下情況：SAP 已在集團內某處運作良好，核心流程穩定，而且範本有足夠彈性，能容納在地需求又不至於壞掉。這三項只要有一項不穩，就先把範本修好，再推到任何地方。

技術面通常準時完成。延誤來自人，以及在新國家不成立的假設。

把範本硬塞給在地團隊

對北美行得通的做法，到了亞洲或中東可能不夠用。稅務結構、核准流程與資料輸入規則都不一樣。我曾與一家公司合作，它假設歐洲的範本在中東也能用。結果造成延誤、重寫，以及大量的摩擦。兩地的業務流程就是差太多。

解法是為新據點指派一位有決策權的業務負責人。由總部團隊替自己不了解的地方決定流程，做出來的設計一碰到在地使用者就會失敗。

測試階段才發現在地化需求

稅務處理、法定報表與必填資料欄位，必須在設計開始前確認。我曾支援一位客戶，一個很單純的稅務配置差異，就讓他們的上線延後超過一個月。問題不在技術。是沒有人及早驗證在地需求。

對不上的主檔資料

產品代碼、客戶編號與供應商分類，必須符合全球標準。上線後才發現不一致，修正成本很高，還會讓合併報表出問題。請在設計階段就把在地資料對應到全球模型，不要等到 UAT。

教育訓練講的是全球系統，不是在地系統

推展常常直接沿用原導入專案的教育訓練。那些教材講的是系統在總部如何運作，沒有講在地的調整。使用者不明白自己這一版為什麼不同，就會自己繞出變通做法。

上述框架依然成立。範本的部署模式，改變的是部分成本結構與擴充規則。

**在 RISE with SAP（Private Edition）上，**每新增一個國家，就是在以完整使用者當量（FUE）計價的訂閱中增加使用者。成本可預期，基礎架構的工作也比較少。不過成本在上線後仍會持續發生，所以請以數年為期來比較方案，不要只看第一年。

**在 GROW with SAP（Public Edition）上，**先確認 SAP 是否為該國提供在地版本。截至 2024 年 2 月，SAP 列出了 59 個國家與地區的在地版本。至於其他國家，SAP 的在地化自助服務計畫，讓合作夥伴可以用 Configuration Localization Tool 建立客戶專屬的在地版本，目前採早期採用者途徑（SAP Learning）。如果兩者都不適用，那就是範疇界定的問題，不是推展的問題。

**Clean Core 適用於每一項在地差異。**Public Edition 只接受透過已釋出介面所做的擴充。在 Private Edition 上，這是治理上的選擇，但您允許的每一項在地修改，都是每次升級時要多測一遍的物件，還要乘上國家數。我堅持的原則很簡單：稅法、法定報表與法規要求，足以成為差異的理由。在地偏好則不行。

在您為下一個國家承諾日期之前，這幾項都要得到明確的肯定答覆。每一項都有負責人。

1. **在地業務負責人（新國家）：**已指定，並有權簽核在地設計。
2. **稅務與法務顧問：**設計開始前，稅務、法定報表與必填資料欄位已有文件記錄。
3. **範本負責人（總部）：**列出所有擬議的差異，並逐項標明是需求還是偏好。
4. **資料負責人：**在地的客戶、供應商與物料資料，已對應到全球標準。
5. **整合負責人：**必須連接的在地系統，例如銀行、稅務申報或物流，已辨識並界定範疇。
6. **變革負責人：**教育訓練已依在地流程調整，使用在地語言與在地案例。
7. **專案總監：**一次只做一個據點，並把上一次上線的經驗帶進下一次。

我的範疇範本指南對第 3 項有幫助，專案章程指南則說明如何把決策權限寫下來。

**埃及的 Greenfield 導入。**一家總部位於埃及的區域製造公司，被老舊且彼此不連通的系統，以及大量人工作業困住。供應鏈、生產追蹤與財務報表彼此不通。他們從零開始導入 SAP S/4HANA，把財務、採購與生產連在同一套系統中。他們建立了自動化的供應鏈規劃，並在上線前訓練了四個國家、逾 5,000 名員工。他們沒有急著趕。結果營運成本降低 25%，預測誤差降低 35%。

**推展到 15 個市場。**一家零售公司已在總部運行 SAP S/4HANA，需要把它推到 15 個新市場。每個市場的稅務規則、幣別與商業慣例都不同。他們從全球範本出發，依據點調整，用兩年分階段推展，而不是一次全上，並為每個區域建立教育訓練。結果是財務合併更快、各門市的庫存即時追蹤，以及集團層級的報表準確度提高 20%。

一個是從無到有建立新系統。另一個是延伸一套已經行得通的系統。兩者都不是隨插即用。如果您正處於第一種情況的起點，可以從我的指南如何正確啟動 SAP 導入開始。

SAP 導入與 SAP 推展有什麼差別？

導入是從零開始建置 SAP：需求、流程設計、配置、資料移轉、整合、測試與上線。推展則是把既有的 SAP 系統及其全球範本，延伸到新的國家、法人實體或事業單位。推展的工作，是範本與在地需求之間的落差：稅務、法定報表、語言、在地整合與教育訓練。

企業何時該選導入而不是推展？

當沒有 SAP 可以延伸，或舊系統要整個汰換時，選導入。當業務模式的改變大到現有設計已不適用，或沒有任何範本涵蓋所需範疇時，導入也是較好的路。硬把不對的範本推展出去，造成的返工會比重新乾淨設計更多。

SAP 推展與導入相比，要花多久？

導入一般需要 12 至 24 個月，大型集團更久。推展一般每個據點需要 6 至 12 個月，視在地化、整合與資料而定。最大的變數，是在設計開始前，在地需求驗證得多徹底。

多國 SAP 推展最大的挑戰是什麼？

有四件事一再出現。範本在沒有在地團隊參與的情況下被硬塞下去。在地化需求在測試階段才被發現。主檔資料不符合全球標準。教育訓練講的是全球系統，而不是在地系統。多數是人與規劃的問題，而不是技術問題。

SAP 推展一定比完整導入便宜嗎？

通常是，因為設計已經存在而且經過驗證。如果某個國家的稅務或薪資規則很複雜、需要好幾個在地整合，或資料品質不佳，節省的幅度就會縮小。在 RISE with SAP 下，每個新國家的訂閱費在上線後仍會持續，所以請以數年為期比較成本。

全球範本在 SAP 推展中如何運作？

全球範本是集團標準流程的書面化、已配置的 SAP 設計。每次推展都從它出發，只加入真正必要的在地變更。每一項差異都會在每次升級時形成維護負擔，所以要加以治理：稅法這類需求足以成為差異的理由，偏好則不行。