以 .NET 整合舊有 ERP 的五個實務原則

這篇文章適合誰

• 營運／IT 主管：評估是否該「整批換 ERP」，還是以 .NET 漸進整合；需要向管理層說明投資優先順序。
• 架構師／開發：負責訂單、庫存、生產排程與舊 ERP 介接的 .NET 團隊。

問題背景

製造業客戶的 ERP 往往已運行十年以上，模組深度客製、報表與結帳流程綁在一起，一次汰換的停機與資料遷移風險難以接受。同時，電商接單、客製報價、即時庫存查詢等新需求又必須上線——於是常見做法是「新系統也寫一份、舊 ERP 也改一份」。

這種雙寫在平日測試可能正常，卻常在月結、出貨尖峰或促銷檔期才暴露：兩邊訂單狀態不一致、庫存被重複扣減、某筆出貨單只存在其中一個系統。承辦人只好人工對帳，IT 被問「到底是哪個系統的錯」。

決策者摘要：整合失敗多半不是 .NET 技術不夠新，而是寫入責任與系統邊界沒定清楚；先定規則再寫程式，比急著上線 API 更省後續維護成本。

原則一：單一寫入來源——避免雙寫

決策者關注： 若訂單狀態兩套系統都能改，出錯時沒有人能負責「最終版」；稽核與客訴都難收斂。

技術重點：

• 為每個業務實體（訂單、庫存異動、出貨單）指定唯一寫入系統；其他系統僅能讀取或透過明確指令請求變更
• 新 .NET 服務若需更新 ERP 資料，應走單一整合通道（API、訊息佇列或批次檔），禁止業務人員同時在兩個畫面手動修改
• 狀態機要文件化：例如 已確認 → 已排產 → 已出貨，並標註哪個狀態轉換由哪個系統觸發

常見陷阱： 為了「先上線」讓新前台直接寫入 ERP 資料表——短期省事，長期每次 ERP 小改版都可能弄斷前台。

原則二：以 .NET API 層包裝舊 ERP

決策者關注： 舊系統介面可能是 COM、預存程序或夜間批次檔，直接讓新模組依賴這些細節，等於把技術債複製到新專案。

技術重點：

• 建立 Integration API（ASP.NET Core）：對內提供 REST 或 gRPC，對外封裝 ERP 查詢與寫入邏輯
• 將 ERP 欄位對照、單位換算、客製驗證規則集中在這一層，新功能只呼叫穩定契約
• 對無即時 API 的舊模組，以輪詢佇列 + 狀態回寫取代直接跨庫寫入
• 版本化 API 契約；ERP 升級時先在 staging 驗證對照表，再切換正式流量

相關實績：製造型客戶 ERP 與訂單整合

原則三：定義清楚的系統邊界

決策者關注： 「全部串在一起」聽起來整合度高，實務上卻讓任何小改動都要協調三個廠商。

技術重點：

• 畫出系統邊界圖：哪些流程留在 ERP（結帳、成本核算）、哪些放在 .NET（接單、追蹤、對外 API）
• 跨邊界只交換已驗證的 DTO 或事件，不共用資料庫連線或隱性依賴「某張暫存表」
• 明訂主檔歸屬：客戶主檔在 ERP 還是 CRM？料號以誰為準？歧義處先寫進整合規格
• 排程與即時查詢分離：月結批次不應與白天訂單 API 搶同一連線池

邊界類型	建議歸屬	理由
財務結帳、成本分攤	ERP	法遵與既有報表
B2B/B2C 接單、物流追蹤	.NET 服務	變動快、需對外 API
庫存餘額（權威）	單一指定系統	避免雙寫

原則四：非同步與事件驅動降耦合

決策者關注： 尖峰時若同步呼叫 ERP 逾時，整個接單流程卡住，營收損失比整合專案預算更明顯。

技術重點：

• 接單流程採非同步：先寫入本地 outbox，背景工作者再推送至 ERP
• 使用訊息佇列（Azure Service Bus、RabbitMQ 等）傳遞「訂單已建立」「庫存已預留」等領域事件
• 實作 outbox pattern：確保資料庫交易與事件發布一致，避免「訂單有、事件沒出去」
• ERP 回寫結果以事件或 webhook 通知下游，而非讓每個模組輪詢同一張表
• 設計冪等鍵（idempotency key），重試時不會重複建立出貨單

實務節奏： 先讓讀取（庫存查詢、訂單狀態）走 API；寫入改為佇列；最後才評估即時雙向同步的必要性。

原則五：可觀測性——每筆整合可追蹤

決策者關注： 出貨延遲時，若只能說「系統有問題」，無法區分是 ERP、網路還是新模組，協調成本會拖垮專案時程。

技術重點：

• 每筆跨系統請求帶 correlation id / trace id，從前台一路追到 ERP 呼叫與佇列訊息
• 記錄請求 payload 摘要、回應碼、耗時；敏感欄位遮罩後留存
• 儀表板區分：同步 API 錯誤率、佇列堆積深度、ERP 維護窗口內暫停次數
• 建立對帳作業：每日比對「.NET 已出貨」與「ERP 已過帳」筆數，差異自動開工單
• 整合層要有斷路器與降級策略：ERP 不可用時，接單仍可暫存並顯示預計處理時間

上線前檢查清單

項目	通過標準
寫入責任	每個實體有文件化的單一寫入系統
API 契約	有版本號與 staging 驗收紀錄
尖峰演練	模擬 2× 訂單量，佇列與 API 仍在 SLA 內
失敗重試	冪等、退避、死信佇列與人工處理流程
對帳	至少一種自動比對報表，差異可追溯到 trace id

下一步

若貴單位正規劃「不換 ERP、但要上新前台或電商」，建議先從邊界圖與單一寫入規則工作坊著手，再評估 .NET 整合層的範圍。我們在製造業訂單、庫存與電商串接有多起實績——歡迎透過網站聯絡，討論現況盤點與分階段導入。