我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

前面幾篇，我花了不少篇幅介紹在客戶現場中做的決策。客戶一開始找我，是希望做一套 AI 智能客服，希望透過知識庫回答印刷相關問題、縮短客服回覆時間，甚至在適合的時候推薦其他商品。最後真正做出來的，卻是一套派單與訂單履約追蹤系統。

中間大概經歷了這樣的變化：

如果這是一個傳統的軟體專案，看到 Scope 一直改，正常會開始思考，是不是一開始需求根本沒有訪談清楚？或是 PM 沒有底限不斷讓步？但我認真覺得，真正有價值的地方就藏在這幾次改變裡。每一次 Scope 改變，都是因為多訪談了一種使用者、深入了解先前沒看到的流程，或是進到實際工作的場景之後，對「什麼值得解決」有了新的理解。

如果把這整個案例濃縮成幾個我仍然持續使用的判斷原則，大略有下面五點。

1. 客戶提出的需求，只是冰山的表面

這個案子一開始的需求是 AI 智能客服。印刷商品複雜、工藝種類多，客服需要不少產品知識；招募和訓練客服也不容易。如果有一套 AI 可以協助回答問題、提供即時回覆，甚至在交期不合適時推薦其他商品，確實能夠帶來價值。

但當我把客服收到訂單之後的流程繼續往下看，才發現資料會從 LINE 進到 Google Sheet，再整理進 ERP，接著又被複製到美編使用的 Google Sheet。大量複製貼上造成的錯誤、漏單和追蹤問題，其實早就存在。如果 AI 客服真的成功提升成交量，更多訂單只會流進一套原本就不穩定的後端流程。

所以我現在的習慣是，把客戶最初說的需求，看成「冰山露出水面的部分」。它告訴我哪裡讓客戶最有感，但不一定代表那裡就是最值得先處理的位置。很多時候，真正需要解的問題，要沿著流程再往後看幾步，冰山下的結構才會浮現。

2. 先找主要營收流程，再處理最明顯的問題

接著我曾經認為，既然客服資料散落在 LINE 和 Google Sheet，也許真正需要的是 CRM。因為我一開始接觸的幾乎都是客服流程，自然從 B2C 的角度理解這家公司；但實際訪談業務、了解營收結構之後才發現，公司主要營收來自 B2B，而且是由業務主導。

真正重要的 B2B 業務可能需要經過多次會議、提案、特殊規格討論和報價，而且客服和業務之間還會因為需求複雜度、商品類型和付款方式互相轉單。所以，企業裡最明顯的問題，不一定是最重要的問題。

設計系統時不能只盯著眼前最容易被看到的問題。因此，我進入企業梳理流程時，會很早建立企業商業模式的藍圖：公司的主要營收從哪裡來？最重要的客戶是誰？訂單真正怎麼形成？主要營運流程的負責人是誰？如果連企業怎麼賺錢都還沒弄清楚，很容易把一個局部的流程改善，誤認成整個公司的數位轉型重點。

3. 不要急著數位化一個組織自己都沒有真正使用的管理流程

當我開始規劃 CRM 時，發現老闆和業務主管都認為商機管理很重要，那些常見的功能，像是客戶商機階段、接觸紀錄、Follow-up 等，這些本來就是 CRM 合理的功能。

可是繼續往下了解後，才發現每週沒有固定 Review 業務商機階段、跟進狀態，業務主管也不會真的拿既有 Google Sheet 的資料做決策，客戶組織內部尚未建立實際的管理機制。

雖然每一個管理欄位對主管來說都是多一份資訊，對第一線來說卻是多一個輸入成本。當主管沒有固定使用這些資料，卻要求業務持續更新，最後很容易出現一個循環：業務為了交差而填、資料品質下降、主管開始不相信資料、主管越來越少看，最後業務更不想填。表面上公司有 CRM，也有 Sales Pipeline，實際上管理行為並沒有真的改變。

所以一個很重要的問題是，管理者是否固定拿這份資料做決策？ 如果不是，我會覺得必須再次驗證這個需求是否有必要先做。因為一套管理機制如果連組織本身都還沒有建立，光靠系統很難讓它自然發生。

4. 技術做得到，不代表值得做

當時規劃的 CRM 如果要涵蓋完整流程，因為業務已經在 ERP 裡管理客戶和製作報價單，就必須額外處理 CRM 和 ERP 之間的資料交換。但是既有 ERP 沒有適合的 API。

技術上可以用 RPA 模擬使用者操作，也可以寫客製化爬蟲，硬把資料和報價檔案抓出來，再同步回 CRM。但如果 ERP 改版、欄位變動、畫面調整，RPA 和爬蟲都有可能需要跟著修改；而且即使成功串接，還是會增加業務切換系統、重複輸入與操作上的摩擦力。為了得到這個功能，要承擔多少 Integration Cost 是這裡的挑戰。

所以我後來整理出三個必須評估的因子：Business Value、Adoption Cost 和 Integration Cost。技術可行性只能回答「做不做得到」，但企業真正需要的答案往往是「做這件事情值不值得」。

5. FDE 的工作要持續找到最值得解的問題

這段旅程最「失控」也最「有趣」的地方，大概就是一變再變的 Scope。一開始是 AI 智能客服，後來跑去想 CRM；接著把 B2B 業務納進來，又開始討論商機管理；再往下碰到 ERP 整合，最後乾脆把 CRM 前半段切掉，只留下訂單成立後的派單和履約追蹤。

不過回頭看，每一次變化其實都是有原因的。最後進到業務、美編和工廠每天工作的場景，才真正看到一個高頻而且具體的問題：訂單成立之後，業務每天都需要追進度，但是資訊散落在人、Google Sheet 和通訊群組裡。走到這一步時，最值得解的問題才變得清楚。

FDE 如果要解決企業真正的營運問題，那麼必須有能力重新定義問題，也要有權限根據新的理解調整 Scope。

當然，這也不代表專案可以無限擴張。每一次改變都還是要重新確認商業價值、成本、使用者影響和開發範圍。AI Coding 確實降低了軟體開發成本，但這不代表看到的問題都應該塞進系統。軟體做得再快，組織的流程、權責與使用習慣仍然需要時間改變，開發速度太快，營運端反而可能跟不上。

所以，FDE 到底在做什麼？

我不敢說我看到的就是 Forward Deployed Engineer 的全貌，但如果只把 FDE 理解成「工程師進到客戶現場」，最後很容易把它看成換個名稱的外包工程師或駐點工程師。我覺得這樣會漏掉 FDE 服務模式很重要的一部分。

FDE 必須有機會和第一線使用者討論、理解企業怎麼賺錢、看實際的流程和資料，也要知道主管怎麼管理。更重要的是，要能進到真正工作的場景裡，看見文件沒有寫、訪談也未必會主動說出來的事情。然後還要有能力，也有足夠的權責，把看到的問題重新組合、做出取捨，再快速把新的假設變成可以驗證的東西。

找到這家企業當下最值得解的問題，然後把它真的解掉。

這也是接下來這個系列裡，我會繼續分享在企業內推動 AI 落地和數位轉型時，現場看到的那些挑戰和決策。

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！