ERP、HRMS 如何連接 AI，而不必大幅客製？

連接前，逐欄訂清楚資料權責

每個共用欄位指定一個權威來源。例如某間機構可由 HRMS 管理員工狀態及部門，ERP 管理供應商資料及採購單狀態。這是機構要記錄的選擇，不是所有產品的通用規則。同時訂明哪個系統可以提出變更，誰有權批准。

列出流程支援的決定，刪除用不到的欄位。入職交接清單可能只需員工編號、到職日及部門，不必讀取薪酬或身份證明。整合帳戶只授予必要讀取權限，並用接近實際操作人的角色測試。以管理員全面存取連接，會令原本很小的試行範圍暴露太多資料。

確認受支援介面及穩定記錄編號

選平台前，先查現有系統版本、已購整合功能及介面文件。若每日報告已符合工作需要，定期匯出可能已足夠。優先採用受支援連接器或 API；提出客製前，比較修改核心畫面或資料表所帶來的維護及升級影響。

建立來源系統編號與目的地編號的對照。姓名、電郵地址及資料行位置都可能改變或重複。SCIM 核心綱要為實作該標準的系統訂明穩定、不可重新指派的資源編號；Dataverse 文件則介紹以外部業務識別資料設定替代鍵。這些是可參考機制，仍須確認你的 ERP 和 HRMS 實際支援甚麼。

分開資料同步與 AI 的理解

依明確對應規則複製獲准欄位：何謂在職、時間戳採用甚麼時區、部門代碼如何對照。對應規則要有版本，未知代碼應拒絕或交人處理。AI 不應因姓名相似就判定是同一員工，亦不應為了讓字句更順而改寫來源狀態。

AI 可在這個受控資料檢視之上，擬出解釋、指出表面矛盾或摘要要求。輸出旁要顯示記錄編號、來源時間及支持欄位，並清楚標示建議。關於採購單的生成答案，不能直接變成採購單的正式審批狀態。

實例演練：唯讀的入職交接

以下是假設例子，並非客戶項目：HRMS 保存新同事已確認的到職日及部門，ERP 則保存以員工編號連結的設備申請。唯讀檢視按編號整合，顯示設備申請仍未完成。AI 擬出「設備申請仍未完成，請在到職日前確認是否準備妥當」，並附上兩筆來源記錄。

找不到相符員工編號時，送到編號對應清單，不能靠相似姓名配對。ERP 資料超出議定時效時，標記狀態未核實，再刷新或詢問負責人。試行不改動到職日，也不批准採購；接手同事在原有系統確認下一步。

寫入前，先設計核對與復原

整合不能只處理新增記錄，還要涵蓋更新、停用、刪除規則、分頁、重複事件及存取權限到期。Microsoft Graph 的 delta 文件說明受支援資源的移除、重播及同步重設。不要假設 ERP 有相同機制，要記錄它真正的變更及故障恢復行為。

保存最後完成的檢查點及來源版本。中斷後，以最新來源樣本核對唯讀檢視；若只讀到部分資料或變更憑證到期，導致完整性不明，就依受支援程序重建限定範圍，核對後才恢復。日後的寫入試行，還需要可安全重試的動作、目的地核查及逐欄復原方案。

• 每項連接的系統負責人及支援聯絡人。
• 權威欄位、編號對應及代碼定義。
• 容許權限、排除資料及時效範圍。
• 檢查點、核對方法及例外負責人。
• 暫停方法、人工交接及復原程序。

用可用而且及時的交接評估唯讀試行

先量度現時組合同一交接所需工時。編號對應覆蓋率＝已核實編號對應的有效來源記錄數除以有效來源記錄數。時效合格率＝符合議定資料年齡的已查記錄數除以已查記錄數。與來源的重要差異、覆核時間及未解決例外要分開記錄，不能只看 AI 回答速度。

權責衝突持續、編號不能核實、所需權限過大、資料時效不符工作要求，或復原後出現無法解釋的差異，就應停止擴展。深度客製前，比較現有設定、匯出流程及小型 API 轉接。成本以 USD 按範圍、授權及維護列明，寫入則另作下一階段批准。