老系統不用砍掉重練：用 API 與整合層串起 ERP、電商與會計

很多企業的系統地圖長這樣：一套用了十幾年的 ERP，是公司營運的核心；後來開了電商，用的是另一個平台；會計用現成的會計軟體；倉庫有自己的倉儲系統；業務用試算表或 CRM 管客戶。每一套都能用，但彼此不相通。

結果就是：電商的訂單要有人手動輸入 ERP，出貨後要再更新到電商平台，月底會計再從各系統匯出報表對帳。一筆訂單的資料，可能被人工搬運了三、四次 —— 每一次都可能出錯。

面對這種情況，很多人的第一個念頭是「全部換掉，做一套新的」。但這通常風險最高、時間最長、也最貴。

為什麼不建議砍掉重練？

• 老系統裡藏著大量的規則：十幾年來累積的例外處理、特殊計價、客戶專屬流程，很多沒有文件，只存在程式裡。重寫時很容易漏掉。
• 切換風險大：新系統上線那天，所有流程同時改變，只要一個環節出問題，整個營運就可能停擺。
• 時間太長：大型系統重寫動輒一兩年，期間業務還在變化，完成時需求可能已經不同。

比較穩健的做法，是先讓系統彼此串起來，再分階段汰換。

整合層：讓系統透過「翻譯官」溝通

整合層（也有人稱為中介層、整合平台）是一個獨立的服務，負責在各系統之間轉換與傳遞資料。每個系統只要和整合層溝通，不必直接認識其他系統。

整合層通常負責幾件事：

1. 統一介面（API）：把老系統的資料庫、匯入匯出檔、原廠介面，包裝成一致、好用的 API。
2. 格式轉換：電商的訂單格式、ERP 的訂單格式、會計的憑證格式各不相同，由整合層負責對應。
3. 資料同步：依照事件或排程，把資料送到需要的系統。
4. 錯誤處理與紀錄：某個系統暫時連不上，先排隊保存，恢復後補送；每一筆同步都有紀錄，可以追查與重試。

用「事件」驅動，而不是定時搬資料

傳統的做法是每天晚上批次匯出匯入，資料永遠慢一天。更好的方式，是以事件驅動：

• 電商訂單成立 → 自動在 ERP 建立訂單、在倉儲系統產生揀貨單
• 倉庫出貨完成 → 自動更新電商的物流狀態、通知客人、開立發票
• 會計收到款項 → 自動核銷應收帳款、更新訂單的付款狀態

每一個事件發生時，相關的系統幾秒內就會同步。這不只省下人工，也讓對帳變得簡單許多，因為每一筆資料都有清楚的來源與流向。

分階段汰換：一步一步把舊系統換掉

整合層還有一個很大的好處：它讓逐步汰換成為可能。軟體業常稱這種做法為「絞殺榕模式（Strangler Fig Pattern）」—— 新系統像藤蔓一樣慢慢包覆舊系統，直到舊系統可以安全退役。

第一階段：包上 API，先串起來

不改動舊系統，只在外面加上整合層與 API。先解決最痛的人工搬運，例如電商訂單自動進 ERP。

第二階段：新功能做在新系統

有了 API 之後，新的需求（例如客戶入口網站、行動版的業務工具、AI 助手）直接做在新的系統上，透過整合層讀寫舊系統的資料。舊系統不再長出新的複雜度。

第三階段：逐步搬移核心功能

一次搬一個模組，例如先把報價、再把庫存、最後把會計相關功能移到新系統。每搬一個，整合層就把流量切換過去；有問題可以隨時切回來。

第四階段：舊系統退役

當所有功能都已經搬走，舊系統只剩歷史資料查詢，就可以安全地退役。

整合層要怎麼做：自建、整合平台，還是現成連接器？

整合層的實作方式有好幾種，沒有絕對的好壞，取決於系統的數量、客製化程度與團隊能力：

實務上常見的是混合使用：標準的資料流用現成連接器，老系統與特殊流程由自建的整合服務處理。重點是讓所有資料流都有統一的紀錄與監控，出問題時知道去哪裡查。

整合上線後，要監控什麼？

• 同步失敗的筆數與原因：哪個系統最常連不上？哪種資料最常轉換失敗？
• 延遲時間：事件發生到其他系統收到，花了多久？
• 資料一致性：定期比對各系統的關鍵數字（例如訂單數、庫存量），確認沒有漏掉的資料。

開始前的準備

1. 畫出系統地圖：有哪些系統？資料怎麼流動？哪些地方靠人工搬運？
2. 找出最痛的一條資料流：通常是每天都要做、量大、容易出錯的那一條。
3. 確認每個系統能怎麼讀寫：有 API、有匯入匯出、還是只能直接讀資料庫？
4. 定義資料的「主人」：客戶資料以哪個系統為準？價格以哪個系統為準？避免多個系統互相覆蓋。

老系統不是包袱，它記錄了公司多年來的經驗與規則。與其冒險全部重來，不如先讓它和其他系統好好溝通，再按照自己的步調逐步升級。這也是讓 AI 接上公司系統最穩固的基礎（見〈MCP 是什麼？〉）。想規劃你的系統整合藍圖，歡迎參考我們的系統整合服務，或和我們聊聊你的系統現況。