系統整合（System Integration，常簡稱 SI）是把企業裡各自運作的系統，例如官網、電商後台、POS、ERP 與客戶管理系統，依約定的規則交換資料，讓同一筆訂單、同一位客戶在各系統裡保持一致，不必靠人工重打。整合的做法不只一種，可以透過 API 即時串接、定時交換檔案、同步資料庫，或使用中介整合平台。動手前要先決定每一種資料以哪個系統為準，再規劃同步方向、錯誤處理與驗收方式，上線後也要有人負責監看與維護。
系統各自為政時常見的五種症狀
下列狀況出現越多，代表系統之間缺的是資料流，而不只是某一套軟體不好用：
- 同一筆資料打好幾次：官網訂單抄進 ERP，出貨後再到電商後台改狀態，每多一次轉抄就多一次出錯機會。
- 數字對不上：電商顯示有庫存、倉庫已經沒貨，或會員點數在門市與官網看到的不一樣。
- 報表靠人工拼：每到月底，要從三四個系統匯出試算表再合併，數字以誰為準說不清楚。
- 同一位客戶有多筆資料：名字、電話寫法不同，行銷與客服看到的是不同的人。
- 換一套系統牽動全部：流程靠人工銜接，任何一個系統更換或改版，相關的作業都要重新設計。
四種整合方式比較：API、檔案、資料庫與中介平台
| 方式 | 做法 | 適合情境 | 要注意的地方 |
|---|---|---|---|
| API 串接 | 依對方公開的介面即時交換資料，事件發生時也可由對方以 Webhook 通知 | 下單扣庫存、會員登入這類要即時反應的流程 | 需要對方的 API 文件與測試環境，並處理重送與頻率限制 |
| 檔案交換 | 定時匯出 CSV 等檔案，再由另一方匯入 | 每日對帳、舊系統沒有 API | 欄位順序、編碼與特殊字元要約定，資料有時間差 |
| 資料庫同步 | 一方直接讀寫另一方的資料庫 | 同一廠商或自建的內部系統 | 繞過原系統的檢核規則，原系統改版時容易出錯，需取得原廠同意 |
| 中介整合平台 | 在系統之間放一層整合服務，集中管理連接與轉換 | 系統多、整合點多，要集中監控 | 確認連接器是否支援現有系統、訂閱費用與日後搬遷 |
MDN 把 API 說明為軟體提供給其他程式互動的功能與規則，可看作雙方的合約。檔案交換常用的 CSV 也有規格可循，例如欄位內含逗號、雙引號或換行時，應以雙引號包住。中介平台以 Google Cloud 的 Application Integration 為例，官方定位為整合平台即服務（iPaaS），提供連接器、觸發條件與視覺化資料對應。API 規格確認與測試的細節，可參考API串接的流程與規格確認。
先決定主檔：每種資料以哪個系統為準
如果兩個系統都能改同一筆資料，改到後來就不知道哪一邊才對。規劃時先替每一種資料指定主檔，也就是由一個指定的系統負責建立與修改，其他系統只讀取，或只回寫約定好的欄位：
- 商品與價格：由 ERP 或商品管理系統建立，官網與電商讀取後顯示。
- 庫存：由進銷存或 ERP 計算，電商成交後回寫訂單，不自行改庫存數。
- 客戶與會員：指定由客戶管理系統或會員系統為準，合併重複資料的規則要先寫好。
- 訂單狀態：約定各狀態由哪個系統更新，例如出貨由倉儲端、退款由財會端。
料號、客戶編號的編碼規則也要統一。會員資料在系統間傳遞時，個資法所稱的「處理」包含連結與內部傳送，建議只傳必要欄位，適用細節請以主管機關公告或專業意見為準。ERP 的模組與單據流程可參考ERP 系統的常見模組。
系統整合的規劃步驟
- 列出系統與窗口：每套系統的用途、廠商、合約到期日、能否提供 API 或匯出功能。
- 畫資料流向圖：從接單到收款，標出每份資料在哪裡產生、流到哪裡、誰在用。
- 挑整合的優先順序：先處理人工轉抄多、出錯代價高的那一段，不必一次全部串起來。
- 決定主檔與欄位對應：寫成對照表，包含編號、狀態與金額的轉換規則。
- 選擇整合方式並寫規格：觸發時機、同步方向、失敗時的通知與補送方式。
- 清理舊資料：合併重複客戶、統一料號，再做初次匯入。
- 準備切換計畫：約定上線時間、切換後的觀察期，以及出問題時退回人工作業的方式。
驗收：用實際業務情境走完整流程
系統整合的驗收不能只看「資料有傳過去」，要請實際使用的單位依日常作業走一遍，並涵蓋例外情境：
- 正常流程：從下單、出貨、開立發票到收款，各系統的狀態是否同步更新。
- 例外流程：取消、退貨、部分出貨與修改訂單，兩邊的資料是否一致。
- 失敗情境：對方系統停機或回應逾時，資料會不會遺失、恢復後能否補送，而且不會重複建立。
- 數量對帳：測試期間比對兩邊的筆數與金額，差異都要找到原因。
- 權限：只有指定角色能看到或修改整合過來的資料。
重送時特別要注意：MDN 說明，POST 方法不一定具備冪等性，同一個請求送兩次可能產生兩筆資料，所以補送前要先確認對方是否已收到。
維運分工：系統整合商、內部工程師與原廠
整合上線後，若問題出在兩個系統的交界，很容易變成沒有人覺得是自己的責任。合約與內部分工要寫清楚：系統整合商負責整合程式、監控與異常排除；各系統原廠負責自家系統的穩定與 API 改版通知；內部的系統整合工程師或資訊窗口負責主檔維護、權限管理與跨廠商協調。日常維運至少要有呼叫紀錄、失敗通知與待補送清單，並定期對帳。任何一方改版前，要預留通知與測試的時間，整合文件也要隨之更新，人員異動時才交接得了。評估系統整合商時，可以請對方說明失敗補送與對帳的做法，並在合約中約定整合程式的原始碼與文件歸屬。
常見問題
系統整合和 API 串接是同一件事嗎？
API 串接是系統整合的一種做法。系統整合還包含檔案交換、資料庫同步或中介平台，以及主檔規劃、流程調整與維運分工，範圍比單一串接更廣。
舊系統沒有 API，還能整合嗎？
可以評估定時匯出匯入檔案、請原廠開放介面，或用 RPA 模擬人工操作，各有維護成本。若舊系統已無人維護，也可以藉這個機會評估是否汰換。
一定要把所有系統換成同一套嗎？
不一定。導入涵蓋多部門的 ERP 可以減少整合點，但換系統的成本與風險較高；保留既有系統、只整合關鍵的資料流，也是可行的做法，視作業痛點與預算決定。
系統整合工程師需要具備哪些能力？
除了程式開發，還要讀懂各系統的 API 文件與資料結構、熟悉資料庫與網路設定，能和不同廠商確認規格、排查問題，並寫出讓下一位接手的人看得懂的文件。
智慧家庭系統整合也是同一個概念嗎？
概念相通，都是讓不同設備或系統協同運作。不過智慧家庭系統整合處理的是燈光、空調、門鎖等設備與控制平台，本文談的是企業營運系統之間的資料交換。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先列出公司正在使用的系統、各自的廠商窗口，以及經常需要人工轉抄的資料。京采的網頁設計服務可以協助需求釐清、規劃主檔與資料流向，並開發官網、後台與既有系統之間的 API 串接；想評估整合範圍，歡迎與我們聯繫。
