用一個真實情境，說明FDE到底解決了什麼問題，以及企業該怎麼判斷自己適不適合
某間企業投入資源導入AI，想解決客服回覆速度慢的問題。技術團隊做出一個demo，準確率報告漂亮，主管看了都點頭，決定上線。三個月後，數據卻很難看：第一線客服幾乎沒人在用這套系統，理由五花八門，有人說輸出的內容跟實際案例對不上，有人說操作起來比原本手動查資料還麻煩。
專案陷入僵局，直到公司找來一位工程師，不待在技術部門的辦公室，而是搬到客服中心，跟第一線人員坐在一起，一邊聽電話、一邊調整模型的邏輯，一週內改了十幾個版本。三週後，這套系統終於變成客服真正願意用的工具，處理時間縮短了三分之一。
這位工程師做的事，正是在企業AI轉型裡愈來愈常被提到的角色—FDE（Forward Deployed Engineer）。這篇文章要說明FDE到底是什麼、為什麼企業開始重視這個角色、什麼樣的企業真正需要它、能帶來哪些具體成果，以及導入時該注意哪些風險。
這篇文章的重點
- FDE是同時具備技術落地能力與業務判斷力，貼身進駐業務現場、快速迭代出真正堪用的AI應用的角色
- 不是每個企業都需要FDE，適合導入的情境有幾個共同特徵，可以對照自己的組織
- 導入FDE的直接效益是速度與貼合度，間接效益是讓組織自己也累積出落地能力
- 常見風險包括角色定位模糊、過度依賴單一個人、知識沒有留在組織裡
- 判斷要不要導入FDE，關鍵在於企業目前卡住的環節，到底是技術問題，還是落地問題
什麼是FDE（Forward Deployed Engineer）
FDE直譯是「前線部署工程師」，但這個翻譯不太容易望文生義，比較實用的理解方式，是把它想成一種角色設計，而不是一個職稱。傳統的技術團隊通常待在自己的部門裡，接到需求後在辦公室裡開發，開發完交付給業務單位使用；FDE的做法不同，這個角色會直接搬進業務現場，跟第一線人員一起工作，親眼看見系統實際被使用的樣子，再依照現場反饋快速調整。
這跟傳統的內部工程師或外部顧問都不一樣。內部工程師通常隸屬於技術部門，優先順序由技術部門排定，容易跟業務需求脫節；外部顧問通常做完交付就離開，很少留下來看系統實際用得順不順手。FDE介於兩者之間，一方面要有足夠的技術能力，能夠現場修改程式、調整模型；另一方面要有業務判斷力，能夠理解第一線人員在意什麼、卡在哪裡，甚至比對方自己還清楚問題出在哪。
回到開頭那個客服案例，技術團隊原本做出的demo之所以沒人用，是因為模型訓練時參考的案例，跟客服人員實際遇到的情境有落差。這種落差，光靠會議室裡的需求訪談很難完全補齊，需要有人親自坐在現場，一邊觀察、一邊修改，才能把落差一點一點磨平。這正是FDE存在的核心價值：把技術開發跟業務現場之間的距離，縮到最短。
什麼樣的企業適合導入FDE
FDE不是萬用解方，導入之前，值得先確認自己的組織是不是真的卡在這個環節。比較適合導入的情境，通常有幾個共同特徵。
第一種情境，是企業已經有一批做出來卻沒人用的AI專案。這代表問題可能不在技術能力，而在最後一哩路的落地過程，這正是FDE最擅長處理的地方。第二種情境，是業務現場的情境複雜、變化快，光靠書面需求文件很難描述清楚，需要有人親自蹲點才能抓到重點，例如客服應對、第一線銷售、現場作業流程這類工作。第三種情境，是企業準備推動一項對經營結果影響較大的AI應用，值得投入額外的資源，確保落地成功，而不是隨便找個團隊試試看。
相對地，如果企業的AI應用場景相對單純、規則明確，例如固定格式的資料整理、標準化的報表產出，這類需求通常不需要FDE這種高投入的做法，一般的專案開發流程就足夠應付。判斷要不要導入FDE，關鍵不在企業規模大小，而在於現在卡住的環節，到底是技術做不出來，還是做出來了卻用不起來。如果是後者，FDE值得認真考慮；如果是前者，問題通常出在別的地方，導入FDE也解決不了。
導入FDE，企業可以預期哪些具體成果
導入FDE之後，最直接的成果是速度與貼合度的提升。因為FDE直接在業務現場迭代，省去了需求訪談、開發、驗收、再修改的多輪往返，原本可能要花幾個月才能磨合出堪用系統的專案，往往能在幾週內看到明顯進展，而且做出來的東西，會更貼近第一線人員真正的使用習慣，而不是工程師想像中的使用情境。
更值得重視的，是間接效益。FDE在現場工作的過程，其實也是在幫組織累積一種能力—怎麼把技術跟業務現場銜接起來。如果企業能把FDE在現場觀察到的細節、修改的邏輯、跟業務人員磨合的方式記錄下來，這些經驗會慢慢變成組織自己的資產，而不是只存在某個人的腦子裡。等到下一次要推動新的AI應用，組織就不必每次都從零開始摸索，落地的速度會愈來愈快。
以開頭的客服案例來說，三週內完成的不只是一套系統，還有一份清楚的紀錄，說明客服人員在乎哪些細節、模型在哪些情境容易出錯、怎麼樣的介面設計比較容易被接受。這份紀錄後續應用到其他部門的類似專案時，省下的時間比第一次導入時還要多。FDE帶來的成果，因此不只是單一專案的成功，更是組織對「怎麼把AI真正用起來」這件事的理解，被具體地留了下來。
導入FDE的風險，以及怎麼管理
FDE這種角色設計，也帶著幾個需要正視的風險。第一個風險，是角色定位容易模糊。FDE同時跨技術與業務兩邊，如果組織沒有講清楚這個角色的權責範圍，很容易變成什麼問題都丟給他解決，卻沒有相對應的資源與決策權限，最後把人累壞，也做不出成果。
第二個風險，是過度依賴單一個人。當一個專案的成功高度仰賴某位FDE的判斷力與經驗，一旦這個人離開，組織可能會突然發現自己什麼都留不住。這個風險，比較務實的管理方式，是從專案一開始就要求FDE跟業務團隊裡的固定人員搭配工作，而不是讓FDE單獨作業，這樣至少有一部分現場知識，會同步留在業務團隊自己人身上。
第三個風險，是知識沒有真正留在組織裡。FDE做完一個專案就離開，如果沒有留下紀錄，組織下一次遇到類似問題，還是得從頭摸索。比較負責任的做法，是把FDE的工作方式制度化，要求每個專案結束時，留下一份說明現場觀察與調整邏輯的紀錄，並且指定專人負責維護與更新這套系統，而不是讓知識隨著FDE的離開一起消失。
這幾個風險都不是導入FDE不能承受的代價，而是需要在導入之前，就先想清楚配套機制。把FDE定位為一種需要搭配制度設計的做法，而不是找到一個厲害的人就能解決所有問題，是讓這個角色真正發揮價值的關鍵。
收斂成一句話：FDE解決的不是「AI能不能做到」，而是「AI能不能真正被用起來」的問題。回到開頭那個客服案例，技術從來不是卡關的原因，卡關的是技術跟現場之間的那段距離，而FDE的價值，就在於有人願意親自站進那段距離裡，一點一點把它磨平。企業要不要導入這個角色，不必看別人有沒有跟風，只需要誠實回答一個問題：手上那些做出來卻沒人用的AI專案，卡住的到底是技術，還是最後那一哩路。
發表迴響