更換 ERP，還是連接現有系統？

沿着一張有問題的訂單追查

生產計劃員每天早上從 ERP 匯出訂單清單。採購在另一處保存供應商確認，品質部門則用別的記錄放行物料。到了下午，排程已需要在試算表內修訂。管理層問為何 ERP 無法提供可靠答案時，團隊提出更換系統並不奇怪。但啟動項目前，值得先查清楚究竟缺少哪個答案。

選一張延誤訂單，重建事件次序。哪份記錄保存承諾日期？供應商何時改變承諾？誰知道庫存被暫停使用？計劃員在甚麼時候得知原有安排已不可行？與作出決策的人核對記錄。調查可能發現 ERP 能力不足、連接缺失、責任不清，或幾種問題同時存在。

Excellence industrielle 關於 CEI Montréal 加入 NUMERI 的文章，也以實際需要界定這項選擇：先釐清應發展現有軟件，還是需要新 ERP。它沒有提供普遍適用的答案。決定取決於營運缺少甚麼能力，以及長期維持可靠方案的成本。 [1]

區分四類問題

先檢查記錄本身。重複物料編號、不可靠的計量單位及過時工藝路線，在新舊系統都會造成問題。指出誰可修正每項定義，以及下游使用者如何得知改動。遷移是整理資料的機會，但搬移資料不會自動令它正確。

接着測試交接。ERP 可能保存準確的採購單日期，計劃員卻看不到修訂。如果介面、權限及責任合適，整合可以在排程時顯示變動。相反，試算表可能保存沒有正式負責人的資料。若未解決擁有權便連接，只會更快散播互相矛盾的版本。

第三類是欠缺功能。企業可能確實需要現有軟件無法以可維護方式支援的規劃、成本核算或追溯能力。最後要考慮平台的營運狀況：支援供應、安全、存取控制、復原能力，以及是否只靠一人理解客製部分。系統即使能處理今天的交易，仍可能帶來不可接受的營運風險。

測試最小但有意義的整合

假設一家裝配企業的訂單及採購交易可靠，但計劃員反覆致電採購，查問最新零件到貨日期。一個有限範圍試驗，可以把供應商確認日期及物料暫停狀態，連接到受影響訂單的視圖。真正有用的測試，是計劃員能否更早識別並處理交付衝突，同時看見資料來源與更新時間。

現有 ERP 仍應作為其原有交易的權威來源。定義每個共享欄位的來源、更新方向、容許延遲及修正負責人。先考慮受支援介面或受控匯出，再考慮脆弱的畫面操作替代方法。確認授權及供應商支援影響。依靠未記錄資料庫假設的連接，可能成為昂貴的長期例外。

刻意測試失敗，與正常更新同樣重要。來源不可用、編號缺失或更新重複到達時怎麼辦？過期資料要清楚標示，保留錯誤佇列，並指定核對人。不要讓刷新失敗看起來像供應商確認沒有變動。若有助團隊安全驗證資料意義與後果，初期不要自動回寫營運系統。

辨認更換系統較有理據的情況

若缺少的能力是日常工作的核心，而加入功能必然造成大量例外，更換便值得認真考慮。支援或復原已不可靠，或維持客製功能的成本超過價值時，也應評估更換。記錄依據，不要只因畫面老舊便認定系統過時。

請新系統供應商使用代表性記錄，示範工廠實際需要作出的決策。包括訂單變更、部分收貨、品質暫停、返工及修正。單示範一張資料完整的銷售訂單如何變成發票，不能證明建議配置能處理現場困難交接。區分標準功能、配置、客製及未來開發承諾。

查明哪些仍在新系統以外。機器連接、產品定義、客戶入口或專用生產軟件，可能仍需要整合。淘汰 ERP 不等於淘汰全部介面。列出保留、更改及移除項目，並為每項轉換指定負責人。可信的更換建議，會同時解釋新系統，以及導入期間必須繼續運作的業務。

比較完整營運成本與干擾

用相同規劃年期及範圍比較兩個選項。包括授權、實施、資料清理、整合、測試、內部人員時間、培訓、支援及持續更新成本。更換亦需要遷移演練、切換準備及歷史記錄安排。整合則需要監察、介面維護，以及日後底層系統改變時的退出方法。

保留假設，不要把全部壓成一個看似確定的節省數字。分別估算可避免的現金支出、可能可用的產能，以及可能減少的管理工作。如果團隊仍不能為未達交付承諾建立可信基準，標示不確定性，並指出甚麼觀察可減少它。

把干擾當作營運情景考慮。切換期間可處理哪些訂單？如何核對結餘及未完成交易？誰可暫停轉換，甚麼條件令回復舊系統可行？整合方案也要回答連接失敗時的同類問題。如果一個選項包括復原，另一個假設永不需要，較便宜報價便不具有可比性。

為決策指定負責人與結束條件

用附帶的決策摘要記錄依據、選項、未解問題及議定決策條件。觀察期要適合流程，涵蓋相關訂單變化與例外，而不只是平靜的示範日。決定甚麼結果支持擴大整合、更改範圍，或改為更換系統。

Quindart 先把業務問題連接到背後的資訊與人。有時這會導向一個小介面，有時現有基礎已不再合適。目的是讓工廠有可維護的決策方式，而不是換了系統後，仍由同一批人手動填補缺口。