公司的 ERP 不能改，新系統一樣串得起來，例如電商訂單進 ERP、業務用手機查庫存、產線報工回寫 ERP。ERP 串接的原則是讀寫分開：讀資料走原廠的 API，或由原廠開一個只能查詢、只看得到必要欄位的帳號；寫回 ERP 一律走原廠的 API 或匯入功能，不直接改它的資料表。這樣新系統出問題時停用它，ERP 照常運作；已經寫回的資料則要能沖銷、對帳。能不能這樣接，要先問原廠。
為什麼 ERP 不能動？原廠也要你別改核心
ERP 不能動，通常不是 MIS 保守。核心程式改過，每次升級都要重測，帳務出錯影響整間公司。
大型 ERP 原廠也是這個方向。SAP 稱為 clean core：核心保持標準、升級穩定，新功能透過已發布的 API 擴充，也可以做成核心之外獨立運作的應用；修改原廠程式、寫入 SAP 資料表，則被列為風險最高、會留下大量技術債的做法。Microsoft Dynamics 365 的財務與供應鏈應用，已不再支援覆寫原廠程式，只接受不改原廠程式的擴充。
所以新需求做成 ERP 外面的系統，靠介面交換資料，要決定的是怎麼讀、怎麼寫。
ERP 串接有哪幾種方式？四種做法比較
整合領域的經典著作《Enterprise Integration Patterns》也寫到，有些系統「不是為整合設計、也不能改」。實際做 ERP 串接，常見的是下面四種：
| 方式 | 怎麼接 | 資料多新 | 要原廠配合什麼 | 容易出問題的地方 |
|---|---|---|---|---|
| 原廠 API | 新系統呼叫 ERP 開放的介面讀寫 | 多半即時；有些原廠的讀取走副本 | 要有 API，可能另計授權 | API 也會改版，要問原廠會不會先公告 |
| 唯讀資料庫連線 | 開只能查詢的帳號，讀指定的檢視表 | 接正式庫即時，接副本稍落後 | 原廠允許、開帳號 | 查詢拖慢正式作業；原廠升級改了資料表 |
| 檔案匯出匯入 | ERP 定時匯出檔案；寫回時新系統產檔，用 ERP 的匯入功能進去 | 看排程 | 匯出多半有，匯入要確認涵蓋哪些單據 | 檔案格式一改就讀不進來、排程沒跑沒人發現 |
| 畫面自動化（RPA） | 程式模擬人操作 ERP 畫面 | 看排程 | 不用改 ERP，但要一個登入帳號，授權也要允許 | 畫面改版常失效 |
怎麼選，順序大致是：有 API 先用 API，資料的正確性由 ERP 自己把關；沒有 API、只需要讀，才接唯讀資料庫；兩者都沒有，用檔案交換；畫面自動化只當最後手段，連 RPA 廠商的文件都把畫面版面變動列為自動化失敗的常見原因。
讀和寫要分開：讀走唯讀，寫走原廠介面
讀：查詢不會改資料，風險在兩件事：拖慢正式作業，和看到不該看的資料。所以給新系統的帳號只開查詢權限，而且只開需要的檢視表，不是整個資料庫——這是資安的最小權限原則（NIST SP 800-53 AC-6），SQL Server 內建可讀全部資料表的角色（db_datareader）就不符合。要讓 AI 查 ERP，OWASP 也建議連資料庫的身分只能讀它需要的表。
寫：直接對 ERP 的資料表新增、修改，會繞過 ERP 自己的規則。Oracle E-Business Suite 的文件寫得很直接：用 ERP 以外的工具改資料，可能只改到一張表、相關的表沒跟著改，也失去 ERP 的檢查與異動紀錄；Microsoft 的中小企業 ERP Business Central 則說，繞過伺服器直接整合資料庫「不建議，也不支援」，也沒有把讀取排除在外。所以寫回一律走原廠的 API 或匯入功能，讓 ERP 自己檢查、自己記錄。
寫回比讀難得多，交給誰做都先問清楚三題：寫回失敗，誰會知道？重送一次，會不會重複開單？兩邊的數字，怎麼對帳？
唯讀串接要注意什麼？
只讀不會寫壞資料，但仍有風險：
- 查詢也會拖慢 ERP。 Microsoft 的文件提到，報表型的大量讀取和日常交易擠在同一個資料庫，會造成鎖定與等待。大查詢放離峰，或接唯讀副本。
- 唯讀副本要看資料庫版本。 SQL Server 用可用性群組做可查詢的副本要 Enterprise 版，Standard 版的基本可用性群組副本不能讀；記錄傳送、交易式複寫另有做法與限制。PostgreSQL 的備援機可以直接查詢，但長查詢可能和複寫衝突而被取消。副本通常比正式庫晚幾秒，網路出狀況時會更久。
- 原廠升級可能改資料表。 以 SAP 為例，已發布的 API 有穩定性承諾，內部物件則寫明可能「不經通知」變更。讀原廠提供的檢視表或唯讀通道，比直接讀原始資料表穩，升級前先在測試環境把串接跑一次。
- 在 ERP 資料庫裡加東西，也算動到 ERP。 自己建檢視表前，先問原廠或經銷商建在哪裡才不影響升級。
- 開放範圍是業務決定。 哪些欄位給誰查，要老闆先決定，再做成受限的檢視表，每次查詢留下紀錄。
ERP 串接動工前，先問原廠這五件事
用國內 ERP 也一樣，向原廠或經銷商確認：
| 先問原廠 | 為什麼 |
|---|---|
| 有沒有 API？讀得到、寫得進哪些資料？要不要另付授權費？ | 決定能不能走最穩的那條路，以及授權成本 |
| 能不能開只能查詢的帳號？資料庫是什麼版本、有沒有副本？ | 沒有 API 時讀資料的方式，副本決定查詢會不會拖慢正式作業 |
| 授權與維護合約允不允許第三方程式連線？ | 合約不允許，串接做好也不能用 |
| 升級時 API 或資料表會不會變？會不會事先通知？ | 決定串接怎麼測、誰負責修 |
| 有沒有測試環境？ | 寫回的動作要先在測試環境跑過 |
另外先講好每份資料以誰為準。客戶、產品這類主檔通常留在 ERP 維護，新系統只讀，不然兩邊各改一份，很快就對不上。
原廠的回覆看不懂，可以轉給我們判斷。
什麼情況其實不用串？
資料一週才更新一次、量也不大，ERP 匯出 Excel 給新系統讀就夠；需求只是看報表，先問 ERP 內建報表做不做得到；原廠或經銷商有現成的串接模組又合用，直接找原廠最省事。如果問題是流程本身沒理順，串得再好，錯的資料也只是更快傳到新系統，先看〈系統導入後反而更慢？〉。
我們怎麼做？
我們設計並正在實作一套讓員工用 ChatGPT 查 ERP 非敏感資料的唯讀查詢架構：資料來自 ERP 的唯讀副本，再經過只開必要欄位的檢視表，AI 只能呼叫寫死的查詢工具，ERP 主庫全程不接觸（案例說明）。
合作分兩步。第一步是不收費的初步判讀：寫信告訴我們用哪套 ERP、想讓新系統讀什麼、要不要寫回，原廠的回覆一起附上；我們回你可能的串接路線與寫回風險。第二步是顧問諮詢，單獨報價：盤點流程與資料、確認原廠條件，交付 SOP 文件與軟體設計需求單，文件歸你所有，拿去給其他廠商比價也可以。確認後才報開發價。服務內容見企業系統客製開發；還在用 Excel 管進銷存的，先看〈Excel 進銷存系統做到什麼程度該換？〉。
常見問題
ERP 串接一定要原廠配合嗎？
多半要。讀資料要有原廠的 API，或由原廠、經銷商開一個只能查詢的帳號；兩者都沒有，只能用檔案匯出或畫面自動化。寫回 ERP 則一定要走原廠的 API 或匯入功能。動工前也要確認授權條款允不允許第三方程式連線。
可以直接連 ERP 的資料庫讀資料嗎？
要先確認三件事：原廠允許；帳號只開查詢權限，而且只開需要的檢視表；查詢不要拖慢正式作業，能接唯讀副本最好。有些原廠不支援繞過它直接連資料庫，例如 Business Central。
唯讀串接的資料是即時的嗎？
看接法。接正式資料庫是即時的；接唯讀副本通常落後幾秒，網路出狀況時會更久；有些原廠的 API 讀取也走副本；檔案匯出則看排程。查詢與報表多半可以接受，要確認可賣數量、扣庫存的動作，要以 ERP 正式資料為準。
新系統可以直接把資料寫進 ERP 嗎？
不建議直接寫資料表。庫存、會計、單號這些連動，是 ERP 存檔時自己做的，繞過去可能只改到一張表、相關的表沒跟著改，也少了異動紀錄。寫回要走原廠的 API 或匯入功能，讓 ERP 自己檢查。
ERP 串接的費用和時程怎麼估？
看三件事：原廠有沒有 API、要不要另付授權費；要串的資料有幾種；只讀還是也要寫回。只讀比寫回單純，寫回要先在測試環境跑過。原廠條件問清楚之前給的總價與時程，多半只是猜。
本文引用資料來源
- SAP：Extend SAP S/4HANA Cloud the right way、Clean core extensibility best practices
- Microsoft：Dynamics 365 extensibility、Business Central：不支援直接整合資料庫、Business Central read scale-out
- Oracle：E-Business Suite 不直接修改資料的警語
- 資料庫：SQL Server 可讀次要複本、SQL Server 基本可用性群組、SQL Server 2022 各版本功能、SQL Server 資料庫角色、PostgreSQL Hot Standby
- 整合與資安：Enterprise Integration Patterns：Integration Styles、NIST 最小權限、OWASP LLM06 Excessive Agency、UiPath 選擇器失效原因
