FDE 營運分析 Skill · 白話解說版

先把工作弄順,
再談 AI。

許多公司一看到業務卡住,第一反應就是「買個 AI 機器人」或「做套大系統」。但真實世界的卡點,往往不是因為少了高科技,而是因為動線打結、交接沒講清楚、每個人都在重複做別人做過的事。

FDE(Forward Deployed Engineer)是嵌入具體業務現場的工程師:先把每天卡住的原因理清楚,把混亂的工作整理成可行流程;確認規則與責任後,才判斷哪一步需要流程調整、確定性軟體、人工判斷或 AI。

核心白話比喻 · THE KITCHEN METAPHOR

把它想成重整一間手忙腳亂的餐廳廚房

尖峰時間客人一直催餐,內場廚師忙得滿頭大汗卻老是出不了菜。這時老闆如果花大錢買最頂級的「多功能料理機(AI)」,廚房就會變順嗎?

答案通常是不會。因為走進去一看才會發現:洗碗槽和備料砧板靠太近,大家轉身一直撞在一起;外場手寫單字跡潦草,廚師每張單都要跑出去問;而且沒人負責算雞蛋剩多少,煎到一半才發現缺料。

STEP 01 第一步:把動線和桌子分開(動線重整) 把備料、炒菜、出餐的桌子分開排好,讓每個人不用轉身打架,省下大半折返與等待時間。
STEP 02 第二步:把點單規格寫標準(明確規則與責任) 外場改用標準勾選單,每道菜明確寫好「誰負責炒、誰負責擺盤、誰檢查」,杜絕推諉與漏單。
STEP 03 第三步:只有揉麵最累時買攪拌機(理性選用 AI) 流程順了之後,若仍有明確負擔,再依工作性質選專用工具;只有語言負擔且有比較證據時才考慮 AI。
FDE 的核心理念: AI 是眾多廚具中的一種,不是每道菜都需要買一台新機器。先把流程弄順,才是最划算的投資。
4 步分析方法論 · 深入淺出

FDE 怎麼把一團混亂變成能落地的下一步?

四個層層遞進的步驟。每一步都先回答一個關鍵問題,完全不堆砌聽不懂的技術黑話。

  1. 01 邊界定義 · 抓出痛點

    到底哪裡卡住?

    不要只說「我們系統很慢」或「跨部門溝通很差」。我們要精確找出:到底是在哪張辦公桌前面、是誰在苦等哪一份單據、最後要拿到什麼東西才算真正搞定?

    白話舉例(掛號問診) 就像去醫院看診,護理師先問清楚「哪裡痛?痛多久?之前吃過什麼藥?」,先框出病灶範圍,而不是一進診間就直接推上手術台。
    答案要能說明 使用者、流程位置、預期結果、待做決策與問題範圍
  2. 02 根本原因 · 追查病根

    為什麼會一直發生?

    順著正常流程和例外情況一步步倒推。常常會發現:根本不是員工偷懶,而是「規則沒寫清楚」、「三個人重複查同一份表」、或是「遇到突發狀況沒人知道找誰拍板」。後續若有新證據進場,只重算真正具依賴關係的環節,不擅自擴大重整範圍。

    白話舉例(老修車師傅) 車子震動,老師傅聽出是火星塞積碳就只換火星塞,不會因為一個火星塞問題把整台車底盤懸吊全部拆掉重裝。精準重算,才不浪費成本。
    答案要能說明 正常、例外、升級與重工路徑,受影響之依賴關係,以及真正造成負擔的原因
  3. 03 簡潔介入 · 不過度設計

    最簡單的改善是什麼?

    能用「改一張表格」或「刪除多餘審核」解決的,就不要寫程式;用三行固定規則能算準的,絕不用昂貴黑盒子 AI。只有當需要理解海量多變的非結構文字時,AI 才是絕佳幫手。

    白話舉例(打掃家裡) 吸塵器裝個定時開關就能每天準時吸地板,不需要特地買一台會跟你聊哲學的昂貴人形機器人。選對工具,省錢又不容易壞。
    答案要能說明 在證據限制內,選出能支持下一個決策的最小充分介入
  4. 04 可交付行動 · 責任交接

    誰要做下一步?

    分析完不能只留下一份「大家都覺得有道理但沒人知道要幹嘛」的投影片。我們會寫明:明天誰負責執行?做到什麼標準算驗收通過?如果系統異常誰來手動接手?同時嚴格分離向知情角色查證客觀事實與向當責角色提請決策授權;使用者交辦的分析工作直接交付成果,絕不把工作包成選項推回給提問者。

    白話舉例(大隊接力交棒) 接力賽交棒不能把棒子往後隨便一扔,而是要親手交到下一棒手裡、確認對方握緊了、並指明終點線的方向。
    答案要能說明 一個有責任歸屬、權限清楚、可被下一位 owner 接手的具體行動
合成案例庫 · 方法壓力測試

看看不同營運問題如何被拆解

這些案例用來展示或驗證 repository reasoning;不代表任何企業已接受、授權、上線或取得成效。

自動巡邏 + AI 摘譯 + 人工把關

第三方 API 變更監測

白話場景:外部串接服務改版沒人知道,導致線上付款壞掉、客戶抱怨連連。
解決方式:用自動比對抓出改動,AI 翻譯成白話影響摘要,再由工程師確認排程,防患未然。

可回放算術基線 → 模型演化

庫存補貨決策演化

白話場景:像超商補貨茶葉蛋,叫太少會缺貨被罵,叫太多又會報廢虧錢。
解決方式:先用「賣多少補多少」的固定算術規則跑一遍,確認可靠了,再來評估是否需要考慮促銷與天氣等複雜模型。

釐清權責 → 規範流程 → 輔助工具

供應商發票例外治理

白話場景:廠商請款發票金額對不上,財務跟採購每天互相踢皮球、拖延請款。
解決方式:在花幾百萬買 OCR 辨識前,先明確定義「差額多少以內誰能簽字核准、少發票找誰補件」。

全員同頻 · 跨角色交付套件

客戶退款狀態交付套件

白話場景:客人打電話問退款到哪了,客服去問財務、財務去問工程師,沒人講得清楚。
解決方式:打造像包裹物流追蹤一樣透明的進度狀態機,工程、客服與主管都看同一份資料。

老手經驗數位化 · 決策軌跡

決策記憶演化分析

白話場景:資深主管離職後,新人接手遇到突發狀況不知道為什麼過去要這樣決策。
解決方式:把每次重要決策的「背景原因、參考數據、最終選擇」白紙黑字存起來,變成能傳承的企業記憶。

主管報告 · HTML5 投影片

退款狀態互動式簡報

白話場景:如何向非技術的老闆和跨部門主管說明「我們到底要改什麼、為什麼這樣改最省錢」?
解決方式:用乾淨直觀的簡報投影片,5 分鐘說清業務痛點、決策矩陣與投資報酬。

誠信與邊界承諾 · 白話菜單

說清楚「知道什麼」與「還不知道什麼」

就像去海鮮餐廳點菜,菜單上老實標明「哪些是現撈鮮魚、哪些是今日推薦、哪些今天缺貨」,才是負責任的態度。我們絕不把「想像中的美好」當成「已經做好的成果」;若中途有了新資訊,也僅重算具依賴之結論,不擅自擴大無關範疇。

  • 有證據
    來源與限制可追溯(現撈鮮魚):有可檢查的 repository evidence,結論只延伸到該證據能支持的範圍。
  • 這是提案
    整理好的好方案(今日推薦):提供給主管或團隊評估的選項,需等負責人點頭核准才算數。
  • 還缺資料
    知道缺什麼(季節限定待補貨):需要對接真實企業環境、特定系統權限或內部數據才能進一步落實。
  • 無法確認
    絕不瞎猜(產地未明不供應):缺乏足夠證據時誠實承認,縮小說法並安排下一步的小規模實驗來驗證。