1～2：需求與成功樣子先寫清楚
先寫「誰、每天、要看什麼、看了要做什麼決定」。例如生管每天看欠料、老闆看庫存異常，而不是只寫「要接 API」。
成功標準也要可檢查：例如上線兩週後，指定報表不再每天人工匯出。沒有成功樣子，串接容易變成無限加欄位。
- 使用者角色與使用頻率
- 第一版只要查詢還是也要寫回
- 可接受的資料延遲（即時／每小時／每日）
- 上線後誰維護帳號與異常
3～5：環境、帳號、權限
確認有無測試環境可先串；正式環境 API 或中介服務由誰申請。帳號原則最小權限：能讀該讀的，不開多餘寫入。
若走資料庫唯讀，同樣要獨立帳號、只給 SELECT、限制 Schema 或檢視表。權限文件要留存，方便 ERP 升級時重測。
- 測試區／正式區是否分開
- API 授權方式與到期策略
- 可存取的公司別、廠別、模組
- 密碼與金鑰誰保管、如何輪替
6～8：欄位、頻率、失敗怎麼辦
列出第一版必要欄位與來源（API 欄位或資料表／檢視）。更新頻率與快取策略要先講，避免尖峰時段重查拖慢 ERP。
也要定義失敗時看板怎麼顯示、誰收通知、是否允許顯示「上次成功同步時間」。整合不是只做 happy path。
- 必要欄位清單與對照樣本
- 同步頻率與流量上限
- 錯誤紀錄、重試與人工補救
- ERP 升級前的回歸測試窗口
清單過完，第一版通常就能估了
八件事有答案後，比較能判斷是「兩週可上的唯讀看板」還是「要更長的雙向整合」。也能避免業務端以為接了 API 就自動什麼都通。
若你還在收集資料，可以把這份清單當開會題綱，和鼎新維護窗口、內部資訊與現場主管一起填。
想把這個痛點做成第一版系統？
可以先從一段流程開始，例如庫存查詢、缺料追蹤、訂單交期、鼎新資料看板或 Excel 轉網頁。範圍先小、驗收先清楚，再逐步擴充。