公司系統各做各的怎麼辦？系統整合的規劃順序、串接方式與常見陷阱

公司用的系統多半是一套一套長出來的：先有會計軟體，接著開了電商後台，業務用 CRM，倉庫又有自己的進銷存。每一套單獨看都沒問題，問題出在它們彼此不講話：訂單要人工轉打進 ERP，庫存每天匯一次還是對不上，同一位客戶在三個系統裡有三種寫法。於是有人提議「把系統整合起來」。整合確實能解決這些事，但不是買一個工具或接一條 API 就結束；做得草率的整合，只是把人工打錯字，換成系統自動把錯誤資料同步到每個地方。以下依實務順序說明怎麼規劃，以及哪些地方最容易出事。

先畫出資料流，決定誰說了算

整合最常見的起手式是問「A 系統能不能接 B 系統」，但更該先問的是：哪些資料要流動，從哪裡到哪裡。其中最關鍵的決定是主資料的歸屬，也就是每一種資料由哪個系統說了算。例如商品資料以 ERP 為準、客戶聯絡方式以 CRM 為準、付款狀態以金流後台為準。沒有先定下來，兩邊都能改同一個欄位，系統就會互相覆蓋，最後誰也不知道哪個數字才對。主資料定好之後，其他系統原則上只讀取，要修改就回到主系統改。接著把每一條資料流的下列條件寫清楚：

• 資料與方向：傳的是訂單、庫存、客戶還是發票，單向還是雙向。能單向就不要雙向，雙向同步要處理兩邊同時修改的衝突，開發與維護的難度都高出一截。
• 時效：業務上到底要多快。搶購時的庫存要接近即時，會計資料一天同步一次通常就夠。「最好即時」不是需求，該問的是延遲十五分鐘會造成什麼實際損失。
• 量與尖峰：平常一天幾筆、活動時幾筆。這決定會不會撞上對方 API 的呼叫次數限制。
• 對照關係：同一個商品或客戶，在兩個系統的編號通常不同，要有一張對照表。組合商品、一對多的料號與單位換算，都要先想好怎麼對。
• 出錯的代價：資料錯了或晚到，後果是多打一通電話，還是超賣、開錯發票。代價越高，後面的檢查與對帳就要做得越細。

四種串接方式的取捨

• 檔案交換（CSV、Excel、SFTP 定時傳檔）：最樸素，卻常被低估。對方系統沒有 API，或一天同步一次就夠時，這是成本最低、也最好排查的做法，出問題時打開檔案就看得到內容。代價是時效差，檔案格式一改就會斷，還要有人確認檔案真的有產出、也真的有匯入。
• API 定時同步：排程每隔一段時間向對方查詢異動。實作單純、不依賴對方主動通知，能滿足多數中小企業的需求。代價是間隔太短會耗掉呼叫額度，間隔太長又不夠即時，而且對方要查得出「某個時間之後異動的資料」，否則每次都得全部掃過一遍。
• Webhook（事件通知）：對方在事件發生時主動通知你，時效最好，也不必反覆查詢。代價是你要有一個隨時在線的接收端，而且通知可能重複、亂序或根本沒送到，所以仍要搭配定時補查，不能只靠它。
• 中介層（自建整合服務或 iPaaS 整合平台）：所有系統只跟中間這一層溝通，資料轉換、重試與紀錄集中在一處。系統超過三、四套時，可以避免每兩套之間都拉一條線；換掉其中一套時，影響也只到中介層為止。代價是多一個要維運的元件，只有兩套系統要接時通常不值得。

選擇時從需求往回推，不要從技術往前推。一天同步一次就夠，檔案交換或定時同步就能解決；要即時反應，用 Webhook 搭配定時補查；系統多、規則複雜，再考慮中介層。標準雲端服務之間、規則單純的串接，n8n、Make 這類自動化工具往往就夠用；牽涉金額、庫存或需要細緻對帳的資料流，則適合寫成有完整紀錄的整合程式。如果對方是沒有 API 的老舊套裝系統，先問原廠有沒有匯入匯出功能或付費介面。RPA（用軟體模擬人工操作畫面）放在最後考慮，它能用，但畫面一改就壞，只適合當過渡方案。

串接一定會出錯，先想好出錯時怎麼辦

• 重複處理也不出事：網路逾時後重送、通知送了兩次，都可能讓同一張訂單被處理兩次。每筆資料要帶唯一編號，接收端先檢查是否處理過，才不會重複開單或重複扣庫存。工程上這叫冪等性，發包時值得直接問開發方怎麼做。
• 重試要有上限，失敗要有去處：暫時性錯誤自動重試，間隔逐次拉長；一直失敗的資料放進待處理清單並通知負責人，不能靜默丟掉，也不能讓它卡住後面所有資料。
• 定期對帳：再好的同步都可能漏資料，所以要定期比對兩邊的筆數與金額，例如每天核對訂單數與營業額，有差異就主動通知。對帳是發現問題的最後一道防線，也是最常被省略的一步。
• 留下紀錄：每筆資料何時收到、轉換成什麼、寫入結果如何，都要查得到。有人問「這張訂單為什麼沒進 ERP」時，才不必翻遍程式與對方後台。紀錄裡不要留下信用卡號、密碼這類敏感資料。
• 保留補跑的能力：對方系統停機一天，恢復後要能重新處理那段時間的資料。設計時就要想好怎麼依時間區間補跑，以及補跑會不會把較新的資料蓋成舊的。

最常見的幾個錯誤

• 直接讀寫對方的資料庫：看起來最快，但資料表結構可能隨改版變動，又繞過了系統本身的商業邏輯，寫入錯誤資料時連原廠都未必願意處理，有些授權條款也不允許。有官方介面就走官方介面。
• 每兩套系統各接一條線：初期最省事，系統一多就變成蜘蛛網，換掉其中一套要同時改好幾條串接，也沒有人說得清楚資料到底怎麼流。連線變多之後，就該畫出全貌並考慮收斂。
• 資料沒整理就開始同步：重複的客戶、不一致的料號，原本只是一個系統的問題，同步之後會擴散到所有系統。先清理資料、建好對照表，才開工。
• 簽約前沒確認 API 的實際條件：「有 API」不代表夠用。要問清楚開通是否另外收費、有沒有測試環境、文件是否涵蓋你要的欄位、呼叫次數限制，以及舊版介面保留多久。不少系統的 API 只能讀不能寫，或正好缺了最關鍵的欄位。
• 直接拿正式環境測試：串接測試會真的開單、寄信、扣庫存。對方沒有測試環境時，要用獨立的測試帳號與測試資料，並限定範圍，先小量放行再全面開啟。
• 金鑰掛在個人帳號底下、權限開到最大：員工離職、帳號一停，串接跟著斷；金鑰外洩時，影響範圍就是整個系統。改用專用的服務帳號，權限只給需要的部分，並定期更換。
• 上線後沒有人負責：外部 API 會改版，憑證與金鑰會到期，公司流程也會調整。要先說好誰收告警、誰處理、跨廠商的問題由誰主導排查，否則串接壞掉時，兩邊廠商都會說問題不在自己這裡。

系統整合不必一次到位。先挑一條最痛、最常出錯的資料流，定好主資料與對照規則，把它接穩，確認對帳數字一致之後再接下一條，比一開始就規劃全公司的大整合穩當得多。判斷順序也是固定的：先決定誰說了算，再依時效需求選串接方式，最後才決定用什麼工具。如果你手上的系統已經各做各的，或不確定現有軟體接不接得起來，浮石數位可以協助盤點資料流、評估串接方式，並負責開發與後續維運。