SAP 資料移轉為何失敗，以及如何修正

SAP 資料移轉失敗，最常見的原因只有一個：計畫是建立在業務端以為的資料樣貌，而不是抽取結果所呈現的樣貌之上。本指南寫給 S/4HANA 專案中的專案總監、資料負責人與財務主管。內容涵蓋移轉為何出問題、導致多數切換失敗的五個錯誤、一份可直接複製的模擬載入計畫，以及 2026 年哪些 SAP 工具適合哪種工作。如果您這週只做一件事，就把客戶、供應商與物料主檔做一次全量抽取，自己數一數筆數。

一家製造業公司花了 18 個月與 450 萬美元導入 SAP。上線日到了。每個人都緊張，卻也興奮。然後，資料移轉失敗了。

沒有一件事運作正常。客戶資料不見了。庫存數字不對。會計無法結帳。執行長大發雷霆。

問題不在軟體，也不在導入團隊。失敗出在業務端以為的資料樣貌，與資料實際樣貌之間的落差。

SAP 的資料模型不是單純的平面匯入。各記錄之間互相依賴。物料主檔有一般記錄（MARA）、工廠資料（MARC）、評價資料（MBEW），以及在使用 MRP 區域時的 MRP 區域資料（MDMA）。只載入表頭而沒有載入相依的視圖，物料雖然存在，卻無法在交易中使用。

S/4HANA 還增加了自己的規則。客戶與供應商都是業務夥伴。舊系統中的客戶，成為具有客戶角色的業務夥伴，供應商則成為具有供應商角色的業務夥伴。信用額度、銀行資料與稅號都掛在該業務夥伴之下。舊系統容忍有缺漏的記錄，在這裡會無法通過驗證。

再來是資料量。多數公司對自己實際擁有的資料量感到震驚。有位客戶以為自己約有 50,000 筆物料記錄。把所有變體與各工廠專屬記錄都算進去，數字接近 500,000。依第一個數字規劃的計畫，撐不過第二個數字。

業務端的估計全量抽取

範疇內的物料記錄500,000+450,000 · +900%

業務端的估計50,000

全量抽取500,000

• 每一個變體與各工廠專屬記錄都已計入
• 以估計值為基準的計畫，撐不過這個數字

這不是資料移轉問題。這是演變成資料移轉問題的範疇界定問題。

專案一開始的資料品質評估，通常是對資料的描述，而不是對資料的檢視。財務總監說供應商主檔維護得很好。倉儲經理說物料大致乾淨。這些都只是印象。

第一次抽取會告訴您真相。本應在多年前就清理、卻沒有清理的供應商。早就停產、卻從未停用的物料。國家代碼不一致的客戶地址。以電匯付款的供應商，卻缺少銀行資料。

每一項都需要業務決策，而不是技術修正。只有應付帳款部門能說出兩個重複的供應商中哪一個才對。只有採購部門能說出哪些過時物料要封鎖、哪些要留下。這些決策需要時間，也需要了解資料的人。如果評估不是依據真正的抽取結果，計畫就建立在撐不過接觸資料的假設之上。一旦您有了真實的筆數，我的免費資料移轉估算工具能幫您估算投入的規模。

1. 把移轉當成後期的技術任務

移轉屬於每一個 SAP Activate 階段。Explore 定義範疇：物件、來源系統、資料量與品質。Realize 建立範本並執行模擬載入。Deploy 執行最終演練與切換載入。Run 則在正式資料上核對第一次期間結帳。

在 Deploy 才開始移轉工作的專案，晚了好幾個月。本該在 Realize 解決的品質問題，會在切換前數週的第一次模擬載入中冒出來。我的 SAP 時程規劃指南說明了移轉在整體計畫中的位置。

2. 業務端參與太少

移轉在執行上是技術性的，在決策上卻是業務活動。IT 產出不了重複供應商的清單。哪些客戶帳戶以有效狀態移轉、哪些留作歷史，是財務決策。過時物料的清理，需要採購、倉儲與產品管理。

只讓技術人員負責移轉、把業務端當成最後簽核的專案，產出的是可以載入的資料。在商業上，它卻是錯的。

3. 規劃的模擬載入太少

一個運作良好的 SAP 資料移轉，在切換前至少需要三次模擬載入，複雜的專案需要更多。只規劃一兩次的專案，是在規劃乾淨的資料與乾淨的對應。這種情況很罕見。更多的循環不是移轉出問題的徵兆，而是規劃得當的徵兆。

4. 沒有核對試載入

載入作業沒有錯誤地完成，並不算驗證。驗證是把載入的內容與預期的內容比對：記錄筆數、財務總額、未清項目餘額。接著再用流程冒煙測試，確認資料能在交易中運作。

沒有核對的試載入，依然耗費時間。它造成的落差仍留在下一次模擬載入中，只是現在更難追溯到原因。每一次載入，都要核對完才開始下一次。

5. 切換載入與演練不同

切換移轉應完全重複最後一次模擬載入：相同的抽取腳本、轉換邏輯、載入順序、檢查與時間。切換時的任何改變，都是在專案壓力最大的時刻引入未經測試的風險。

最少被測試的部分，通常是差異。在最後一次模擬載入與切換之間，業務端仍持續新增供應商、修改訂單與移動庫存。請定義資料凍結日，並把差異載入納入最終模擬載入的演練。

以這個循環結構作為起點。每個循環都有目標與結束標準，核對簽核之前，它就不算完成。

循環	目標	結束標準	負責人
Mock 1	結構：每個物件依相依順序載入	每個物件的對應缺口與格式錯誤皆已記錄	資料移轉負責人
Mock 2	品質：測試對應修正，並暴露資料問題	每個物件的錯誤率下降；清理決策已記錄	資料管理員
Mock 3	業務規則：例外與邊緣案例	管理員接受各領域中已核對的樣本	資料管理員
Mock 4	以完整正式規模測試資料量與時間	完整載入在切換視窗內完成	切換經理
最終演練	切換的完整彩排，包括差異與凍結	筆數與財務總額已核對並簽核	財務會計主管與資料負責人

圍繞這份計畫，有五件事決定成敗：

1. 在 Prepare 階段做全量抽取。全部，而不是樣本。剖析完整性、準確性、一致性與重複，然後依結果估算清理工作與時程。
2. 逐物件對應。針對每個物件（業務夥伴、物料、未結採購與銷售訂單、未清項目、庫存、固定資產），記錄來源到目標的欄位、轉換規則、驗證檢查與例外規則。
3. 指名的資料管理員。財務擁有客戶與供應商的財務資料。採購擁有物料主檔。倉儲擁有庫存。每位管理員在每個循環後，簽核自己負責的領域。
4. 預先定義核對方式。在第一次模擬載入之前，就約定哪些筆數與總額足以證明載入正確，這樣切換時就不會有人為此爭論。
5. 書面的切換順序。凍結、抽取、轉換、載入、驗證、業務簽核、go/no-go。與最終演練相同的順序。

對新的 S/4HANA 導入而言，SAP S/4HANA Migration Cockpit 是 SAP 建議用於初始載入的工具。自 S/4HANA 2020 起，它以 Fiori 應用程式 Migrate Your Data 的形式運行。交易碼 LTMC 已被棄用，既有的 LTMC 專案只能檢視。該應用程式提供兩種做法：使用暫存表移轉資料（由檔案或您自己的工具填入），以及直接從 SAP 來源系統移轉資料。地端與私有雲團隊使用交易碼 LTMOM，也就是移轉物件模型工具，來調整標準物件或建立自己的物件。Cockpit 是為初始載入而設計，不適用於週期性介面或大量變更。

SAP Data Services 是 SAP 的 ETL 平台。適用於大量資料、繁重的轉換邏輯、多個來源系統，或當您想要一個能在專案結束後繼續使用的可重複使用資料品質框架時。

第三方 ETL 工具，例如 Informatica、Talend 或 Microsoft SSIS，適合組織已擁有並具備相關技能的情況。

SAP Datasphere 現已成為 SAP Business Data Cloud 的一部分，不是移轉工具。它的位置是上線後的分析層。若您把歷史資料留在舊系統中，卻仍需要對它做報表，它就重要。

對大多數標準導入，Migration Cockpit 涵蓋多數物件。資料量大、高度客製的舊系統，或不尋常的來源結構，通常需要在它之外搭配 Data Services 或 ETL 工具。從 ECC 轉換是另一種作業，我的 ECC 轉 S/4HANA 移轉指南有說明。

什麼是 SAP 資料移轉？

SAP 資料移轉，是在導入或轉換過程中，從舊系統抽取資料、轉換成符合 SAP 結構與規則，再載入 SAP。典型的物件有業務夥伴（客戶與供應商）、含工廠資料的物料、未結採購與銷售訂單、庫存餘額、財務未清項目與固定資產。它之所以困難，是因為 SAP 強制執行舊系統往往沒有的相依關係與驗證規則。

SAP 資料移轉有哪些主要做法？

新導入（Greenfield）把選定的主檔資料與未清項目載入全新的 S/4HANA 系統，歷史留在舊系統或封存檔中。系統轉換（Brownfield）則就地轉換既有的 ECC 系統及其歷史。選擇性資料轉換介於兩者之間，移動選定的公司代碼、物件或時間區段。正確的選擇取決於資料品質、歷史需求，以及您想保留多少舊流程。

什麼是 SAP Migration Cockpit？何時該使用？

SAP S/4HANA Migration Cockpit 是 SAP 建議用於把初始資料載入 S/4HANA 的工具，適用於所有版本。自 S/4HANA 2020 起，它以 Fiori 應用程式 Migrate Your Data 的形式運行；交易碼 LTMC 已被棄用。它提供預先定義的移轉物件，在過帳前驗證資料，並以欄位層級回報錯誤。適用於一般資料量下的標準物件。當資料量、轉換邏輯或來源結構超出範本所能處理的範圍時，請再加上 SAP Data Services 或其他 ETL 工具。

SAP 資料移轉計畫應規劃幾次模擬載入？

至少三次，最後一次是完整的切換演練。複雜的專案需要更多。在典型的計畫中，第一次找出結構性的對應缺口。第二次測試修正，並暴露資料品質問題。第三次處理業務規則與邊緣案例。最後一次完整重複切換，其核對結果會成為上線當日的基準。

如何把客戶與供應商移轉到 SAP S/4HANA？

以業務夥伴的形式。在 S/4HANA 中，客戶與供應商主檔資料透過業務夥伴維護，並附加客戶與供應商角色。在新導入中，Migration Cockpit 透過其業務夥伴物件載入它們。在從 ECC 轉換時，必須在轉換本身之前，先設定並執行客戶與供應商整合。

是什麼導致 SAP 資料移轉在切換時失敗？

五種模式造成多數切換失敗。模擬載入太少。切換順序從未端到端測試過。最後一次模擬載入之後，舊系統又有變動，卻只有未經測試的差異載入。核對缺口被擱著沒處理。業務簽核只依據抽樣檢查。「前 1,000 筆看起來沒問題」不算驗證。上線需要核對過的筆數與總額。