FDE vs 系統整合商：比較範圍、驗收與營運責任

企業比較 FDE 與系統整合商時，應比較實際提供的工作，不能假設一個職稱代表「成果」，另一個只代表「規格」。兩者都能提供實作、迭代協作與持續支援，也都可以把承諾限制在約定範圍內。

FDE 通常指密切的客戶端工程協作；系統整合則涵蓋在企業環境中串接及實作系統。兩者的工作可以重疊。特定廠商的能力、人員是否可用，以及合約內容，比固定印象更有用。

在提案裡比較五個面向

部分問題相同是刻意的，因為這些條件不專屬某種交付標籤。廠商應對同一個客戶需求，說清楚方法與承諾。

使用規格，也保留不確定性

成熟的 ERP 串接若介面穩定，可以適用明確的實作範圍。輸入尚有不確定性的 AI 輔助流程，可能需要有人監督的試行與分階段驗收。兩種安排都需要目標、相依條件與變更程序。

FDE 不必假設所有規格都是錯的，SI 也不必採用瀑布式交付或忽略回饋。需求不確定時，應問團隊如何在擴大承諾前降低不確定性，以及客戶如何核准下一階段。

把例外寫成可處理的條件

以假設性的文件分流任務為例，例外可能是不支援的檔案、客戶識別資訊衝突，或缺少權限。決定應拒絕、請人補充，還是使用核准的替代流程。驗收涵蓋代表性例外，也記錄哪些情況不在範圍內。

這是規劃範例，不是製造業客戶故事或實測失敗率。任何團隊都不能保證發現所有可能例外。可用的承諾，是重要案例如何被辨識、測試及監控，新案例出現後又如何處理。

不能從標籤推論風險已轉移

委託可以指定監控與支援工作，卻不表示所有商業、法律或資安責任都已轉移。確認實際邊界、升級聯絡人、變更核准與事故處理。採用工作也需要客戶的流程決策、使用權限及審核人員配合。

GAO AI 問責框架提供治理、資料、表現與監控的提問方向。它是責任參考，不是某類廠商承擔所有風險的證據。商業上的分工應寫入實際協議。

比較完整投入與退出方式

計入客戶人員時間、權限準備、實作、授權、持續服務費、支援及變更。較低的建置報價可能排除了另一份提案已涵蓋的工作。現場時間、元件重用或產品合作關係，都不能直接證明總成本較低。

明列原始碼存取、文件、部署設定、第三方相依項目及交接接收者。權利、授權條件與可攜性，依合約與使用的軟體而定，不能從廠商類型就判定「完全擁有」或「一定綁定」。

選擇有證據能在必要邊界內完成工作的提案。如果現有團隊或標準產品能滿足同樣需求，也應納入選項。這樣得到的是可覆核的採購決策，而非虛構的採用數字，或 AI 專案一定要選 FDE 的結論。