不要先問如何同步，先問誰對資料負責
ERP 通常關心可交易、可出貨與可請款的資料，例如正式客戶編號、統一編號、付款條件、信用狀態、產品料號與稅務資訊；CRM 則更接近業務流程，管理潛在客戶、聯絡偏好、商機階段、關係人與業務活動。兩邊都可能有「客戶名稱」或「地址」，但欄位同名不代表語意相同。ERP 的地址可能是發票或送貨地址，CRM 的地址則可能只是業務拜訪地點。
我們通常不建議直接指定某一套系統為所有資料的唯一真實來源。更實際的做法是以業務物件與欄位為單位建立權責矩陣。例如 CRM 可以建立潛在客戶，但只有完成必要資料並通過審核後，ERP 才建立正式客戶；ERP 回傳正式客戶編號、交易狀態與付款條件，CRM 不得自行覆寫。若一個欄位允許雙向修改，就必須明確定義優先權、核准流程與衝突處理，否則最後寫入者勝出的機制很容易悄悄破壞資料。
使用穩定識別碼，並保留業務實體之間的關係
跨系統整合需要一個不因名稱、電話或組織調整而改變的內部識別碼。ERP 客戶代碼與 CRM Account ID 應被視為各系統的外部鍵，透過中央對照表連到共同的主資料 ID。統一編號適合用於比對與重複檢查，但不宜單獨作為主鍵，因為分公司、海外實體、個人客戶、格式差異或資料更正都可能使它失去唯一性。
資料模型也不應把公司、據點、聯絡人、付款方與收貨方壓成一張客戶表。比較耐用的模型會分開保存法人或組織、營運據點、聯絡人、地址，以及它們扮演的角色與有效期間。這會增加初期映射工作，但能避免同一地址被多處複製，也能處理一個集團有多個 ERP 客戶代碼、同一聯絡人服務多個關係企業等常見情境。
- 主資料 ID：由整合層或主資料服務產生，建立後不得重用。
- 系統對照鍵：保存 ERP、CRM 與其他來源的原生 ID，以及建立時間與狀態。
- 資料角色：區分潛在客戶、交易客戶、付款方、收貨方、供應商與合作夥伴。
- 有效期間：保留地址、關係與狀態何時生效及失效，避免直接覆蓋歷史。
- 停用標記：優先採用軟刪除或封存，並明確傳遞停用原因，不把刪除當成一般更新。
Canonical Model 要小而清楚，不要變成第三套 ERP
整合層可以建立共同資料模型，但它只應包含跨系統真正需要交換的欄位。若把 ERP 與 CRM 的所有欄位都塞進 canonical model，模型會快速膨脹，任何一端的客製欄位都可能迫使所有介面一起修改。較好的策略是保留穩定核心，例如主資料 ID、名稱、角色、狀態、必要地址與系統鍵，再針對報價、訂單或行銷需求建立有版本的延伸訊息。
每個欄位映射都要記錄來源、目標、格式、必填條件、預設值、轉換規則與允許值。例如 CRM 的產業分類可能比 ERP 細，不能只靠文字相等；幣別、國家代碼、語系與業務區域也應使用明確代碼表。遇到無法映射的值，應進入待處理佇列並保留原始內容，而不是套用看似方便的預設值。介面版本也要與欄位版本分開管理，使舊消費者能在遷移期間繼續運作。
把同步設計成可重送、可對帳、可人工介入
事件同步適合需要快速反映的狀態，例如 ERP 核准客戶後通知 CRM；批次同步則適合大量參考資料或每日對帳。實務上常需要兩者並用。無論採用 webhook、訊息佇列、CDC 或排程 API，每筆訊息都應有事件 ID、實體 ID、版本或更新時間。接收端必須具備冪等性，讓同一事件重送時不會重複建立客戶。對同一實體的事件還要處理順序問題，避免較舊資料覆蓋較新的狀態。
- 寫入與發布一致性：可使用 outbox 類型的設計，降低資料已更新但事件未送出的風險。
- 錯誤分類：區分暫時性連線錯誤、資料驗證錯誤與權限錯誤，採取不同重試策略。
- 可觀測性：記錄來源版本、映射結果、目標回應與關聯 ID，但避免在日誌暴露敏感個資。
- 定期對帳：比較筆數之外，也檢查關鍵欄位雜湊、缺漏對照鍵與長期未處理的失敗資料。
- 人工修復：提供查看差異、選擇正確值、補齊映射並安全重送的流程。
上線前應用實際資料測試重複客戶、合併、停用、重新啟用、名稱變更與訊息亂序等情境。主檔設計完成後，仍需要明確的資料負責人、變更審查與對帳節奏；否則技術同步正常，資料語意仍會逐漸分歧。若流程橫跨多套系統，由熟悉整合與業務資料模型的團隊共同制定規則，通常能減少後續重工。