ERP 現代化應避免的 10 個錯誤

傷害最大的 ERP 現代化錯誤是策略性的，不是技術性的：把上線當成終點線、把舊流程複製進新系統、太晚才開始做資料與變革工作、把所有東西都蓋進 ERP，以及在沒有五年模型的情況下簽授權。這些錯誤很少即時顯現。它們在上線之後才浮出水面，那時承諾的效率沒有出現，變通做法又回來了。

這份內容寫給正在規劃或搶救 S/4HANA 或其他 ERP 現代化專案的 CIO、財務長與專案總監。下面每個錯誤，都附上它在實務中的樣貌與修正方法，接著是一頁的早期警訊檢查清單，以及 2026 年 SAP 的各項變化代表什麼。

我看過資金充裕、團隊經驗豐富、顧問陣容完整的專案，依然未能達標。原因很少出在系統，而是出在權責、整合規劃，以及彼此決策相互依賴的團隊之間的溝通缺口。

1. 把上線當成終點線

系統一上線，許多團隊就以為最吃重的工作做完了。真正的壓力這時才開始：日常營運、不斷變動的需求與使用者的真實行為，都在對設計施壓。

我見過一些專案，指導委員會在上線後立刻解散。六個月後，採用率毫無起色，也沒有人負責待辦清單。

修正方法： 為上線後 6 至 12 個月的治理期編列經費。延長指導委員會的任期。監看流程的採用情形，而不只是系統運作時間。設定上線後的品質關卡，並指定負責人。

2. 不重新思考就移轉舊流程

我見過整條核准鏈照原樣重建，即使其中一半的人與現行流程毫無關係。沒有人問過這些步驟是否還需要。結果是一套現代的 ERP 跑著老舊的工作流程：只是把原本擁有的東西，換成一個更貴的版本。

S/4HANA 版本的情況是：客製批次作業原封不動地從 ECC 搬過來，而它們所建立的資料表結構已經不存在。技術上，移轉很乾淨。業務邏輯卻壞了。

修正方法： 在建置之前先重新設計流程。帶著營運、財務與交付團隊一起走過每一條工作流程，並質疑每一個步驟。

舊系統面向	常見的問題	該怎麼做
來自 ECC 的客製程式碼	沒用到的客製程式碼被搬進 S/4HANA	執行使用情形分析與 SAP 的客製程式碼檢查；淘汰沒用到的程式碼
舊的工作流程	明明現在可以自動化，核准流程卻被原樣重建	與業務負責人重新檢視；使用標準 Fiori 應用程式或 SAP Build Process Automation
非標準的主檔資料	舊系統的彈性設定通不過 S/4HANA 的驗證	移轉前先清理並整合，適用時搭配 SAP MDG
建立在舊資料表上的報表	直接存取資料表，與 S/4HANA 的資料模型不相符	改以 CDS view 重建
隱藏的人工變通做法	旁支流程在上線後重新出現	移轉前先用流程探勘 (process mining)，並把缺口數位化

3. 太晚才開始資料移轉

把糟糕的資料搬進新 ERP，就像搬家時什麼都不丟。雜物跟著您一起搬過去，而且一旦進了結構化的系統，就更難清掉。

我曾看過一次上線失敗，原因是沒有人發現，一份核心資料集裡的記錄來自五個不同的事業單位，每個單位都有自己的編碼邏輯。技術上的移轉是正確的，資料卻無法使用。報表壞掉，使用者失去信任，在運行中的系統上清理，花了好幾個月。

修正方法： 讓資料成為一個由業務負責的工作流。指派流程負責人，而不只是技術顧問。在移轉開始前，決定哪些要帶過去、哪些要封存、哪些要重建。至少執行兩次完整的模擬載入，附上載入順序的相依性對照圖，以及每次載入明確定義的回復做法。我那篇談 SAP 資料移轉為何失敗的文章有更深入的說明。

4. 把變革管理當成副業

常見的版本是：變革管理「已經處理好了」，意思是幾張投影片、一場展示，以及上線前的一堂訓練課。

人們抗拒，不是因為討厭改變。他們抗拒，是因為沒有人解釋為什麼要改變，或是這對他們有什麼幫助。他們只用系統用到能通過檢查清單的程度，然後就回頭用試算表了。

常見的導火線是時程壓力：訓練被壓縮以搶回時間，使用者在上線時手忙腳亂，而額外的 Hypercare 花的錢，比被砍掉的訓練還多。

修正方法： 從一開始就讓變革管理有自己的預算、時程與資深負責人。及早盤點角色、找出各地的推手，並把採用度 KPI 與技術里程碑並列追蹤。我的變革管理計畫指南說明了架構。

5. 依據供應商的產品路線圖做規劃

我見過團隊把整合策略建立在供應商未來的版本上，結果那個版本延後了 12 個月。在那段期間，他們只能卡在建造暫時性的變通做法，而這些變通做法後來變成了永久的。

供應商是為廣大的客戶群打造路線圖。您的業務，很少是那份設計的中心。

修正方法： 把路線圖視為輸入之一。依今天已正式推出的功能來設計，在把新功能納入規劃前，先在沙盒中測試，並把路線圖上的效益當成額外的上行空間，而不是預算的一部分。

6. 沒有舊系統的停用計畫

我曾見過一家公司，每年花六位數的金額維持一套舊系統運轉，只為了六位使用者每年兩次調閱報表。沒有人建立過停用計畫。

修正方法： 從第一天起就把停用寫進專案章程，並讓法務、法遵與資料治理一起參與，而不只是 IT。在上線前議定保存期限與封存方式，盤點並切斷每一條通往舊系統的介面，並指定一個團隊負責把它關掉。

7. 低估整合的複雜度

整合出問題時，業務端會比 IT 更早發現，因為工作流程是在正式環境、而不是在測試系統裡，做到一半就停了。

常見的模式是：IT 與業務端各自以為對方已經定義好整合需求。其實兩邊都沒有。等到缺口在測試中浮現時，已經沒有時間重新設計了。

修正方法： 在藍圖階段就開始整合設計。定義每個情境、中介軟體、對應規則與訊息量，並與業務端釐清每一條介面是即時還是批次。在上線前指定一位附有 SLA 的介面負責人。新的 SAP 專案，中介軟體用的是 SAP Integration Suite；SAP PI/PO 的主流維護將於 2027 年底結束。

8. 以為 ERP 什麼都能處理

我參與過一些專案，團隊因為不想牽涉 ServiceNow 這類外部系統，就把複雜的服務工作流程（IT 工單、資產申請、升級轉派）硬塞進 ERP。結果是到處都是客製欄位、人工變通做法，使用者困在一個從來都不合身的流程裡。

ERP 擅長結構化、以交易為主、與財務連動的流程。IT 服務請求、工作流程協調與知識管理，專屬的平台做得更好。

修正方法： 刻意決定哪些東西不要蓋在 ERP 裡。例外情況用 SAP BTP 上的 side-by-side 擴充，交易核心之外的流程協調則用 ServiceNow 或類似工具。我那篇談以 SAP 與 ServiceNow 做 ERP 現代化的文章說明了這種切分。

9. 低估長期的授權成本

我認識一個團隊，第二年的授權支出翻了一倍，只因為它需要一項藏在較高階授權後面的功能。商業案例只模擬了上線當下的成本。

ERP 授權依使用者、模組、交易與 API 用量計費，不論您有沒有規劃，成本都會隨業務一起放大。在 SAP 上，Digital Access 模式意味著由第三方系統建立的文件，可能帶來原始商務模型裡沒有的授權成本。在 RISE 與 SAP GROW 之下，Full User Equivalent (FUE) 的數量會隨採用度成長。

修正方法： 簽約前先建立三到五年的授權模型。把角色對應到授權類型，依務實的採用曲線為 FUE 成長建立模型，在連接外部系統之前先搞懂間接存取，並在上線後稽核不活躍的使用者。

10. 把 ERP 當成 IT 專案

這是最常見、也最具破壞力的模式。規劃從 IT 開始，由 IT 主導，解決的是 IT 的問題。

我見過團隊在紙面上達成每一個里程碑，業務端卻還在問，為什麼什麼都沒有變好。這通常代表 ERP 是為昨天的流程打造的，設計過程裡沒有營運、財務或商務主管。

修正方法： 從一開始就讓商務、財務與營運主管加入指導委員會。把策略對齊寫進專案章程，而不只是技術範疇。在設計開始之前，先拿專案目標去對照董事會層級的成果。

每次指導委員會都用這份清單。只要出現警訊，指定的負責人就要持續報告，直到它消失為止。

1. 專案章程權責與成本沒有營運或財務主管、沒有五年授權模型、沒有停用日期
2. 藍圖流程與整合設計照搬現行流程、介面還沒設計
3. 第一次模擬載入資料還沒有資料品質報告
4. 上線接下來會發生什麼上線後 12 個月沒有編列經費的治理

錯誤	早期警訊	負責人
1. 把上線當終點線	上線後 12 個月沒有編列經費的治理計畫	專案發起人
2. 照搬舊流程	設計工作坊從「我們現在怎麼做」的畫面開始	流程負責人
3. 太晚處理資料	第一次模擬載入之前沒有資料品質報告	資料移轉負責人
4. 變革管理是副業	變革計畫只是一份訓練行事曆	變革管理負責人
5. 依賴路線圖	某項設計決策在等一個尚未推出的功能	解決方案架構師
6. 沒有停用計畫	專案章程裡沒有任何舊系統的停用日期	PMO
7. 低估整合	藍圖階段結束時介面仍未設計	整合負責人
8. ERP 包辦一切	為非交易性的工作流程建立客製物件	企業架構師
9. 授權	商業案例裡沒有五年授權模型	財務長
10. 只有 IT 的專案	指導委員會裡沒有營運或財務主管	專案發起人

部署方式。 新的 SAP 專案，預設是在 SAP Cloud ERP Private 上採用 RISE with SAP，中型企業則是在 Public Edition（SAP Cloud ERP）上採用 SAP GROW。新的地端部署已經很少見。ECC 客戶面對的是主流維護於 2027 年 12 月 31 日結束，這縮短了修正第 2、3、7 項錯誤可用的時間。

Clean Core。 SAP 現在把擴充分成四個 Clean Core 等級，從 A 級（只使用已釋出的 API，以 side-by-side 方式放在 BTP 上，或在系統內以 ABAP Cloud 實作）到 D 級（不算 Clean）。Public Edition 只允許 A 級，這迫使第 2 項錯誤背後的那場對話必須發生。Private Edition 仍允許傳統擴充，所以紀律必須來自治理。傳統的客製程式碼，正是讓每次升級都變成專案的原因。我那篇 Clean Core 策略進一步談了這件事。

交付工具中的 AI。 Joule 現在已進入 SAP Cloud ALM 與 SAP Activate Roadmap Viewer，SAP Build Code 也用 Joule 來做擴充開發。請問夥伴，AI 工具如何反映在他們的費率表上。如果沒有反映，不是價格偏高，就是省下來的成本進了他們的利潤。

生命週期工具。 SAP Cloud ALM 是雲端專案的生命週期管理工具。Solution Manager 7.2 的主流維護將於 2027 年底結束，所以兩者並行的環境，需要一份轉換計畫。

這十個錯誤沒有變。犯錯的代價變了。在 RISE 專案上，Clean Core 的決定、部署模式與 FUE 模型，全都在啟動的前幾週就定下來。能影響它們的時間窗很短。

ERP 現代化專案為什麼在上線後達不到預期？

大多數團隊只規劃到上線為止。沒有人負責功能增強、使用者回饋、流程修正或待辦清單。指導委員會在上線時解散，是最可靠的麻煩徵兆。從第一天起，就為上線後 6 至 12 個月的治理編列經費。

把舊流程複製進新 ERP 有什麼風險？

新系統會以更高的成本繼承舊的低效率。尤其在 S/4HANA 的移轉中，為 ECC 資料表打造的客製程式碼與批次作業常常無法運作，所以移轉在技術上可以很乾淨，業務邏輯卻是壞的。

資料品質不佳如何損害 ERP 現代化？

重複的供應商、不一致的主檔資料、舊有編碼與不完整的記錄，除非有人先清理，否則全都會被帶進新系統。報表壞掉，使用者不再相信數字，在運行中的系統上清理，要花好幾個月。

ERP 專案中的變革管理為什麼常被低估？

因為它不像組態設定那樣，在專案計畫上看得見。高階主管以為幾堂訓練課就夠了。變革管理，是在上線之前，讓人們為日常工作中實際會改變的事做好準備。像 WalkMe（現在歸 SAP 所有）這類數位採用工具，能協助提供應用程式內的引導，但取代不了對「為什麼」的說明。

為什麼舊系統在 ERP 上線多年後還繼續運轉？

因為沒有人打算把它們關掉。每個人都專注在讓新 ERP 上線，舊系統則因為法遵、查閱或心理上的安心感而繼續留著。停用必須從第一天起就納入範疇，並讓法務與法遵參與。

RISE with SAP 與 Clean Core 如何改變這些錯誤？

在 Public Edition 上，Clean Core 規則讓深度客製化不可能發生，這迫使第 2 項錯誤背後的流程對話必須發生。在 Private Edition 上，傳統擴充仍然允許，所以 Clean Core 取決於治理。隨著 PI/PO 的維護結束，整合轉移到 SAP Integration Suite。授權變成 FUE 成長的問題。停用變得更迫切，因為並行運行舊系統，是在多年期訂閱費之上再加一筆成本。