先確認需求是查資料，還是要寫回 ERP
老闆常說想把鼎新資料做成網頁，但實際需求可能完全不同。只是想讓主管查庫存、採購未交、訂單與工單狀態，屬於唯讀查詢；如果要從外部系統新增訂單、回寫報工或修改庫存，則屬於寫入整合。
兩者的風險差很多。唯讀看板通常可以先從小範圍開始，確認欄位與權限後逐步上線；寫回 ERP 則要處理交易規則、單號、審核、錯誤回復與權限，不能只看畫面上有沒有成功。
資料庫適合大量查詢，但要守住唯讀邊界
直接從資料庫讀取的優點，是可以依管理需求整理大量資料，也適合製作跨單據的主管報表。對既有報表、庫存彙總與異常清單來說，通常有較大的查詢彈性。
但資料表與欄位需要先釐清，查詢也不能影響正式 ERP。實務上應使用獨立的唯讀帳號、限制可讀範圍，必要時透過報表資料庫、檢視表或排程同步，避免看板直接對正式交易資料造成負擔。
- 帳號只開放 SELECT，不提供新增、修改與刪除權限
- 先確認品號、庫存、訂單與工單的實際來源表
- 大量報表安排快取或排程整理，避免尖峰時段重查
- 正式 ERP 升級前，先測試欄位與查詢是否受影響
API 適合明確流程，也比較容易控管交換格式
API 會把可使用的資料與動作包成明確介面，外部系統不需要直接理解所有資料表。當需求涉及正式交換流程、權限紀錄，或未來可能需要寫回 ERP 時，API 通常比較容易管理。
不過 API 能取得哪些欄位、呼叫次數、版本與授權方式，要依客戶目前使用的鼎新產品與環境確認。不能看到有 API 就假設所有資料都能直接拿到，也不能把畫面操作等同於 API 能力。
工廠可以用這 5 點做第一輪判斷
選擇資料庫或 API，不是比哪一個比較新，而是看需求、現況與風險。第一次評估時，先把以下問題回答清楚，就能避免做到一半才發現權限或資料來源不符合。
- 只需要查詢，還是需要寫回 ERP？
- 資料量與更新頻率是多少？
- 現有版本是否提供需要的 API 與欄位？
- 能否建立唯讀資料庫帳號或報表資料來源？
- ERP 升級、權限與維護由誰負責確認？
第一版建議：先唯讀、先單一看板
如果目標是改善主管查詢，第一版通常可以先做唯讀的庫存、採購未交或訂單看板。先證明資料能正確對上 ERP，確認使用者真的會看，再擴充通知、權限與更多資料。
這種做法不需要推翻原本 ERP，也能把整合風險控制在可驗收的範圍內。