FDE vs 傳統系統整合商 (SI):5 個關鍵差異與該選誰的時機

FDE(前線部署工程,Forward-Deployed Engineering)是一種交付模式:工程師直接進駐客戶現場,把企業 AI 從 Demo 一路扛到生產環境與真實採用;傳統系統整合商(SI)則是依規格文件交付一套可驗收的系統,上線後責任告一段落。當你在評估「FDE vs 系統整合商 SI」時,真正該問的不是誰的技術好,而是你要買的是一套「交付物」,還是一個「上得了線、有人在用」的結果。

先講一個現場

去年底我們接了一個製造業的案子。客戶前一年找了一家很知名的 SI,導入一套 AI 品質檢測系統,驗收那天所有指標都漂亮達標。合約結案、尾款付清、系統上線。

半年後我到現場,產線的老師傅還是用肉眼複檢,那套系統的判定被當成「參考值」,實際採納率不到兩成。系統沒壞,SI 也沒違約——他們交付的東西完全符合規格書。問題是,規格書裡從來沒寫「要讓師傅願意信任它、把手放開」。

這就是 FDE 與 SI 最本質的分歧。差異不在技術棧,在三條軸線:交付方式、風險承擔、邊角案例。

三軸拆解:FDE vs SI

交付方式:交「系統」還是交「結果」

SI 的商業模式建立在一份清楚的規格書上。這是它的優點——範圍明確、報價明確、驗收明確。但企業 AI 的難處在於,真正決定成敗的變數,幾乎都寫不進規格書:使用者願不願意改變習慣、模型面對髒資料時的判斷、例外流程怎麼接手。

FDE 反過來,一開始就假設規格書會是錯的。工程師進場先看真實流程怎麼跑,再邊做邊改。交付物不是一套通過驗收的系統,而是「有人在用、而且指標在動」的狀態。

風險承擔:誰在為採用率負責

這是最容易被忽略、卻最貴的一條軸線。

SI 合約裡,採用率通常不在承諾範圍。系統能跑、功能齊全,責任就了了。至於員工用不用,那是「組織變革」的事,另一個部門的問題。

FDE 把這件事攬過來。我們的立場很直接:Demo 很美不算數,上線且有人在用才算數。這意味著風險轉移——如果三個月後使用率是 4%,那是我們沒做好,不是客戶不配合。這種承擔會逼出完全不同的做法:你會去搞懂為什麼師傅不信任系統,而不是把它寫進結案報告。

邊角案例:一般方案死在不一般的地方

SI 擅長把 80% 的標準流程做到穩。剩下那 20% 的例外,通常變成客製報價,或乾脆排除在範圍外。

但企業現場的殘酷真相是:AI 專案往往就死在那 20%。那家製造業客戶的產線,有一批舊料的表面反光會讓視覺模型誤判——這種事不會出現在任何規格書裡,只會出現在現場。FDE 的價值,正是有人蹲在那裡,把每一個「我們這裡比較特別」的地方摸清楚、補進系統。

那,該選誰

不是說 SI 不好。如果你要導入的是成熟、標準化、規格清楚的系統——ERP 模組、標準報表、既有軟體的部署——SI 又快又划算,找 FDE 反而是殺雞用牛刀。

但如果這是一個結果不確定、高度依賴現場知識、而且「用不用得起來」才是關鍵的 AI 專案——Copilot 導入、Agentic 工作流、RAG 知識系統——那你需要的是有人把風險跟你一起扛到採用成立為止。

這也是 Tenten 做 FDE 的方式:我們不交一套通過驗收的系統就走,而是把工程師放進你的現場,盯著使用率跑起來,再談放手。