FDE 與 SaaS 導入：何時需要嵌入式工程團隊？

選擇 SaaS 或前線部署工程（FDE），要先看工作能否使用既有產品設定完成，以及客製整合後由誰維護。FDE 是一種交付方式，不能只憑名稱推論比較快、比較便宜或一定提高使用率。

本文提供選擇框架。下面的客服情境是用來討論採購與整合責任的假設範例，沒有報告客戶使用率或專案成果。

先找出需要改的是設定、整合還是流程

假設客服團隊已有一套平台，但回覆需要讀取 ERP 訂單狀態，特殊報價規則留在試算表中，法遵又要求重要資訊附來源。團隊應先確認平台的 API、可設定範圍與供應商支援，再判斷缺口。

如果現有設定就能處理，新增工程團隊可能沒有必要。若缺口是資料串接，可以購買整合服務或由內部團隊完成。當工作還涉及反覆釐清規則、處理例外與修改既有系統，嵌入式工程才有較明確的工作範圍。

不能把所有 SaaS 供應商都視為不處理例外，也不能把所有 FDE 合約都視為涵蓋長期維運。責任要以產品能力、服務內容與合約確認。

比較交付責任，而不只比較名稱

這些是採購時應問的問題，不是兩類供應商的固定表現。

什麼情況適合先買現成產品？

當工作流程標準、產品能涵蓋主要需求、資料能匯出，而且內部有人負責導入與維護，現成產品可以減少自建範圍。郵件、會議與一般行政功能通常值得先比較成熟產品，仍需確認實際需求與總成本。

比較成本時，把授權、整合、培訓、人工覆核、維護和離開供應商的費用一起列入。產品採購不會自動完成這些工作，客製工程也不會讓它們消失。

什麼情況需要工程師貼近工作？

若需求會隨使用者回饋改動、資料規則尚未整理、例外需要跨部門判斷，團隊可能需要工程師與實際使用者一起縮小範圍並測試。嵌入式方式的價值在於能否持續處理這些具體問題，而非承諾某個固定上線週數。

先選一個工作樣本，請供應商展示正常流程、缺資料及例外情況。確認誰批准變更、誰修正錯誤、上線後誰負責，以及未包含的項目如何處理。再依證據決定交付方式。