什麼是 SAP 導入？一步一步的指南

SAP 導入，是把一家公司的財務、採購、供應鏈、銷售與人資，搬到單一 SAP 系統（通常是 S/4HANA）上的專案。它依 SAP 的 Activate 方法分六個階段進行，而成敗，取決於在任何人動手組態之前所做的工作：流程設計、資料品質，以及對的團隊。

本指南寫給即將啟動導入專案的高階主管與專案負責人。它會帶您走過各個階段、每個階段必須產出什麼、必須先做的規劃，以及現在才啟動的專案有哪些改變。如果只讀一個章節，請讀「組態開始之前的規劃」。

在 ERP 導入領域25 年之後，我一再看到同樣的模式。把導入當成軟體安裝的公司，會很吃力。把系統當成最後一步、先做流程工作的公司，則能準時交付，並拿到向董事會承諾的成果。

S/4HANA 是 SAP 目前的 ERP，運行在 SAP HANA 記憶體內資料庫上。舊的 ECC 系統在許多公司仍在運行，但 ECC 的主流維護將於 2027 年 12 月 31 日結束，並提供可選的延伸維護至 2030 年底，費用較高。

多數導入最先碰到的核心模組：

模組	管理的內容
FI（財務會計）	總帳、應付帳款、應收帳款、資產會計
CO（管理會計）	成本中心、利潤中心、內部訂單、管理報表
MM（物料管理）	採購、庫存、貨物異動、供應商管理
SD（銷售與配銷）	訂單到收款、定價、出貨、開立帳單
PP（生產規劃）	生產訂單、產能規劃、MRP
HCM（人力資本管理）	人事主檔資料、薪資、時間管理

多數企業從 FI/CO 與一、兩個營運模組開始。其餘的部分，會在後續階段陸續建置。

SAP Activate 取代了較早的 ASAP 方法。它有六個階段，每個階段都有一道必須通過才能繼續的關卡。

SAP Activate 的六個階段

1. 01

   Discover

   確認商業案例，並在試用或展示系統上測試優先的流程。

2. 02

   Prepare

   動員：團隊、治理、範圍文件、計畫與系統存取。

3. 03

   Explore

   與流程負責人進行 Fit-to-Standard 工作坊。建立組態、整合與擴充功能的待辦清單。

4. 04

   Realize

   組態、擴充、移轉資料並測試。這是最長的階段。要結束此階段，需要一次乾淨的迴歸測試。

5. 05

   Deploy

   以真實流程訓練使用者，演練上線切換，並在作戰室就位的情況下上線。

6. 06

   Run

   Hypercare、最佳化，並移交給卓越中心。

這張表，是我釘在專案辦公室牆上的版本：每個階段必須產出什麼、由誰負責，以及下一個階段開始之前必須成立的條件。

階段	必須產出	負責人	進入下一階段的關卡
Discover	商業案例、目標範圍、部署選擇	發起人與 CFO	經費核准
Prepare	範圍文件、計畫、治理、團隊就位	專案總監	發起人簽核範圍
Explore	Fit-to-Standard 結果、待辦清單、擴充決策	解決方案架構師與流程負責人	沒有未解決的差距
Realize	已組態並測試的系統、已移轉的測試資料	功能與技術負責人	迴歸測試通過；資料對帳一致
Deploy	受過訓練的使用者、演練過的上線切換、go/no-go 決策資料	上線切換經理	通過三天的結帳演練
Run	Hypercare 紀錄、CoE 移交、第二階段待辦清單	服務交付負責人	沒有未結案的 P1/P2；CoE 接受

每個階段背後的範本，都在我的 SAP Activate 範本指南裡。

三天結帳演練關卡

Realize 與 Deploy 之間的關卡，是團隊在時程壓力下最常跳過的一個。我建議在實際上線之前，先進行三天的結帳演練。如果財務無法在新系統上完成結帳，不論 IT 怎麼說，您的資料移轉都還沒準備好。略過這道關卡所付出的代價，比它可能造成的延誤還高。

順序很重要。在做出任何一個組態決策之前，有四件事要先完成。

1. 01盤點現行流程照它們實際的運作方式，包括變通做法
2. 02決定採用標準或擴充標準功能幾乎總是更快
3. 03稽核資料品質在資料移轉開始之前
4. 04先配置團隊，再確定範圍誰有空，決定了您能交付什麼

到這一步，才開始組態

照現行流程實際的運作方式來盤點

不是流程理應的樣子。而是它實際的樣子，包括變通做法。那些沒有人寫下來的需求，就藏在變通做法裡。

為每個流程決定採用標準功能或擴充

找出哪些流程由 SAP 的標準功能涵蓋，哪些需要擴充。標準功能幾乎總是更快。每一項擴充，都會增加測試週期、升級風險與維護工作。在 SAP 的 Clean Core 指引下，每一項擴充還必須被安排在一個經過深思的位置，這讓這個決定更加重要，而不是更不重要。

在資料移轉開始之前，先稽核資料品質

這是最被低估的工作流。我看過公司花了好幾個月修報表，因為過時的客戶紀錄在未經檢查的情況下就被載入。有一位客戶有超過 18,000 筆重複的客戶資料，上線後修正它們，讓開立帳單作業中斷了好幾週。

先組成團隊，再最終確定範圍

您能交付的範圍，取決於誰有空來組態、測試並負責每一個工作流。先定範圍、後配人員的團隊，會花好幾個月重建他們過度承諾的部分。

挑戰	看起來像什麼	該怎麼做
範圍蔓延	「既然都在裡面了，順便加上……」的要求不斷堆積	從第一天起就實施正式的變更控制；每項要求都做影響評估
資料品質	移轉揭露了沒人知道存在的不一致	在上線前六個月分析資料；在來源系統中清理
使用者抗拒	上線兩週內，使用者就漂回 Excel	從 Explore 起就讓終端使用者參與設計；是參與，而不只是訓練
整合失敗	第三方連線在 UAT 中斷掉	在 Explore 中盤點介面；及早以貼近真實的資料量測試
測試週期被砍	為了趕上日期而縮短迴歸測試	保護測試階段；建置的延誤不得壓縮測試
團隊疲勞	最後衝刺階段士氣下滑，缺陷率上升	用簡單的每週情緒指數追蹤疲勞；以我的經驗，當它超過 25% 時，測試缺陷率就會飆升

我記得有一個案例，一家公司為了加快速度，跳過了小型的迴歸測試。一週後，財務無法對平關鍵報表。接下來是好幾個月的善後。那不是什麼重大的系統缺陷，只是一個本可避免的疏失。

上線前、上線期間與上線後

上線前：進行結帳演練，用對帳報表驗證已移轉的資料，以真實流程而不是展示情境來訓練，並測試回復計畫。帶著指導委員會逐項走過 go/no-go 的標準，並取得明確的簽核，而不是心照不宣的點頭。

上線期間：加強監控，並讓上線切換團隊在最初 72 小時內全天候待命。在那幾個小時裡所做的決定，決定了 Hypercare 是帶著信心展開，還是帶著一長串待處理的問題單展開。

上線後：至少執行四週的 Hypercare。依類別追蹤支援工單；它們會告訴您訓練在哪裡失敗、組態在哪裡需要調整。從穩定下來的基準規劃第二階段。18 個月前被延後的範圍，需要對照業務現在的需求重新檢查。

一家中型製造商不斷缺原物料。採購怪規劃人員；規劃人員怪沒有人信任的試算表。我們以 S/4HANA 取代了那套做法，並大量倚賴設有適當 MRP 組態的 SAP PP。庫存水位從憑感覺，變成即時資料，採購單依需求觸發，六個月後，缺料減少了超過 50%。這讓連持懷疑態度的人也感到意外。這項成果來自組態之前的流程再造。沒有流程工作的 PP，只會更快地給出錯誤的答案。財務也受益：月結更快了，而 CFO 說，這些數字好一陣子以來第一次「讓人覺得可信」。

一家全球專業服務公司則有不同的問題。每個國家各自運行自己的財務平台，沒有任何東西對得上，報表每個月都得手工重做。我們在一個親力親為的指導委員會之下，分階段推出了 SAP Finance。月結從超過兩週，降到略多於一週，各區域的報表終於對上了，連稽核人員也少了些疑慮。

為 2022 年寫的指南，經不起 2026 年買家的檢驗。有四項改變，需要從啟動會議起就設計進去。

雲端版本是預設選項

SAP 現在銷售兩種雲端 ERP 版本：SAP Cloud ERP（公有版，前身為 S/4HANA Cloud Public Edition）與 SAP Cloud ERP Private（私有版）。RISE with SAP 把私有版與由 SAP 負責的營運，以及包含 SAP Signavio、SAP LeanIX 與 SAP Cloud ALM 的轉型工具鏈，打包在一起。SAP GROW 則是為使用公有版的中型企業所提供的套裝方案。

版本的決定，現在位居舊有導入方式之爭的上方。Big Bang 與分階段，以及 Greenfield、Brownfield 與選擇性轉換之爭，都是在版本之內做的選擇，而不是取代版本的選擇。如果您仍在使用 ECC，且需要更多時間，SAP 提供一項涵蓋 2031 至 2033 年的 ERP 私有版過渡選項，但 SAP 明確表示，這是付費的過渡方案，不是維護期延長。

Clean Core 是分級的，不是非黑即白

2025 年 8 月，SAP 推出了四個 Clean Core 等級，A 到 D。A 級只使用已發布、穩定的 API，可以在 SAP BTP 上 side-by-side，或使用 ABAP Cloud 在系統內實現。B 級允許傳統 API 與仍被視為乾淨的技術。C 級需要特殊措施。D 級則不屬於 Clean Core。

公有版只允許 A 級擴充功能。私有版與地端部署允許傳統的擴充功能，所以在那裡，紀律來自治理，而不是平台阻擋您。對專案的實務重點是：在 Explore 階段決定每一項擴充功能的等級與位置，並指定一位能夠說不的人。沒有 SAP BTP 與 ABAP Cloud 經驗的夥伴，從第一週起就會製造出 C 級與 D 級的技術債。

交付團隊中的 Joule 與 SAP Build Code

Joule 現在已內建在 SAP Activate Roadmap Viewer 與 SAP Cloud ALM 中，在那裡回答任務相關的問題，並根據方法論起草內容。SAP Build Code 自 2024 年起正式推出，它使用 Joule，為 SAP BTP 上的 Java 與 JavaScript 擴充功能，產生應用程式邏輯、資料模型與測試。SAP 也為 ABAP 開發人員加入了類似的生成式 AI 協助。

坦白說：AI 在 SAP 專案中是真實的，但資料品質決定了它的價值。乾淨的流程文件與乾淨的主檔資料，會產出有用的結果。髒資料只會產出信心滿滿的雜訊。這一切都不會消除需要有一個人為每項決策負責。

這對現在才啟動的專案意味著什麼

這套做法依然有效。階段依然適用，工作的順序依然重要。改變的是版本的決定、擴充功能的紀律，以及團隊的工具。一個在啟動時就吸收這些改變的專案，會把它們當成設計上的限制條件。忽略它們的專案，則要花頭三個月去弄清楚什麼改變了，而且通常是從夥伴提出的變更請求中才得知。

同樣這些決策在成本面的部分，請參閱我的 SAP 導入成本分解。如果您仍在使用 ECC，ECC 到 S/4HANA 的遷移指南涵蓋了各種轉換路徑。

SAP 是用來做什麼的？

SAP 在一套系統、一個資料模型中，運行核心的業務功能（財務、採購、供應鏈、人資、銷售）。

實務上，一筆收貨會更新庫存、觸發應付帳款流程，並流入管理報表，而不需要重新輸入。報表只和底層的交易一樣準確，這就是為什麼流程設計與資料品質，比組態更重要。

SAP 導入需要多久？

範圍與團隊，是最能影響時程的兩個變數。一個聚焦的 S/4HANA 導入，涵蓋單一公司的 FI/CO 與一個營運模組，可能需要 6 至 9 個月。橫跨許多法人實體、模組與語言的全球推行，則需要 18 至 36 個月。

拉長時程的因素：太晚才發現的資料問題、在沒有調整日期的情況下追加範圍、由兼任人員擔任的關鍵角色，以及為了彌補先前延誤而被砍掉的測試週期。這些在規劃階段都是可以控制的。

SAP Activate 的六個階段是什麼？

Discover（商業案例與契合度）、Prepare（團隊、治理、計畫）、Explore（Fit-to-Standard 工作坊與待辦清單）、Realize（組態、擴充、移轉、測試）、Deploy（訓練、演練上線切換、上線），以及 Run（Hypercare 與移交給卓越中心）。

SAP 導入失敗最常見的原因是什麼？

幾乎每個出問題的專案，都有三個根本原因。略過流程工作，於是 SAP 是依照有問題的舊流程來組態。資料品質一直被忽略到上線切換，那時已沒有時間好好修正。把變革管理當成訓練：訓練教人怎麼操作，變革管理讓人願意去做。

第四個比較新：夥伴在沒有 Clean Core 計畫的情況下建置擴充功能，留下的債務會在第一次大型升級時浮現。

我該如何選擇合適的 SAP 導入夥伴？

在您這個規模上的產業經驗，以及您真的能打電話聯絡的參考客戶。指名的資深人員投入：提案簡報上的那個人，應該就是主導專案的人。獨立性：靠授權或訂閱銷售獲利的夥伴，有動機建議更多的範圍。Clean Core 經驗：詢問他們建置過多少個 SAP BTP 與 ABAP Cloud 擴充功能，並要求看看。

還有一條規則。負責交付工作的夥伴，不該撰寫您的商業案例。他們的動機是開始。您的動機是完成。

上線之後會發生什麼事？

Hypercare 至少執行四週，全體團隊待命，並每天檢視未結問題。第一週的工單類別，是訓練在哪裡不足、或組態在哪裡出錯，最誠實的訊號。

Hypercare 結束後，卓越中心接手功能增強、升級規劃、新進人員訓練與變更治理。在專案期間略過建立 CoE 的公司，通常在接下來兩年裡，要為本該由內部負責的工作，付錢給顧問。

RISE with SAP 是什麼？它適合我的組織嗎？

RISE with SAP 是 SAP 針對 SAP Cloud ERP Private 的訂閱套裝方案：包含軟體、由 SAP 管理的基礎架構與營運，以及一套用於流程分析、架構與生命週期管理的工具鏈。導入仍然由您的夥伴交付。

它適合想離開 ECC、並希望平台與營運只簽一份 SAP 合約的較大型組織。能夠貼近標準作業的中型企業，應該考慮使用公有版的 SAP GROW。如果法規要求由客戶自行管理基礎架構，或是大量客製程式碼無法在可用的時間內清理乾淨，RISE 就不那麼適合。