兩套系統如何串接？先確認資料方向、更新時機與失敗處理

先問：哪一筆資料不想再重打？

系統整合最常見的起點，是同事在兩個地方輸入同一份資料。例如表單送出後，還要到管理後台建立案件；訂單變更後，還要另外更新追蹤表。

先挑出一種資料與一段流程，列出現在由誰搬、多久搬一次、最常出什麼錯。這比直接要求「全部串起來」，更容易評估是否值得做。以下以規劃角度說明，實際能串哪些功能仍以各平台提供的介接方式為準。

如果兩套系統都能修改地址，串接後應該以哪邊為準？這個問題要先回答。可以指定一邊為主要來源，另一邊只接收；也可以依欄位分工，但規則要清楚。

還要確認同一筆資料如何辨認。姓名可能重複、電話可能變更，通常需要穩定的識別編號與對應關係。初次搬移舊資料時，也應先檢查重複與缺漏，不要直接把問題複製到新系統。

不是所有資料都需要立即同步。每日彙整報表，可能固定時間更新就足夠；影響下一步作業的狀態，則可能需要更快通知。先談可以接受的延遲，再選擇實作方式。

如果來源平台提供 API 或事件通知，可以依官方文件評估；若只能匯出檔案，也可能採批次匯入。介接限制、使用額度與費用都需要個別確認，不能假設所有平台都能雙向即時更新。

網路中斷、資料格式不符或對方服務暫時無法回應，都可能造成同步失敗。好的規劃會留下可追查的結果，讓負責人知道哪些已完成、哪些待重試，而不是只顯示一句「發生錯誤」。

重試也要避免同一份申請變成兩筆。可以討論如何識別已處理的資料、是否需要人工確認，以及重新執行會不會覆蓋後來的修改。通知中應只包含必要資訊，詳細內容留給有權限的人查看。

上線前，先使用去除個人資料的範例，核對新增、修改、重複送出與錯誤情境。不能只看資料有沒有出現，也要比較欄位、金額、日期與時區是否一致。

再約定異常時如何暫停、由誰核對，以及是否能回到原本作業方式。確認這些安排後，才逐步擴大範圍。自動化的目標是減少重複工作，不是讓錯誤更快傳到每個地方。

不一定。若平台支援規格穩定的檔案匯出入，仍可能安排批次交換；但更新頻率、可靠性與維護成本會不同。請先提供平台名稱、可取得的官方文件與實際需求，再判斷適合的方式。

帳號權限也應限於必要範圍，並約定憑證更新與停用流程。串接完成後，仍需要有人負責監看例外與核對結果。