---
name: fde-workflow-discovery
description: 以 forward deployed engineer（FDE）的方式，為某個客戶或團隊的一條工作流程寫探索筆記：跟著觀察與訪談時要問的問題、以泳道表呈現目前的步驟（執行者、工具、時間、痛點）、資料的輸入與輸出、例外狀況、AI 適合與不適合的地方、一個成功指標，以及一份小型試行提案。準備去客戶或內部團隊旁邊觀察、找出 AI 能幫上忙的地方，或有人要你做流程探索、流程盤點、現況流程圖、觀察訪談指南、AI 試行（PoC）提案時使用。
---

# FDE 流程探索

Forward deployed engineer 會坐到客戶團隊旁邊，讓產品在對方真實的系統和工作流程裡運作起來。最先做的探索任何人都做得到：在工作進行時觀察，把每個步驟連同耗時和痛點寫下來，然後才決定 AI 放在哪裡。人憑記憶描述自己的工作時，會漏掉那些變通做法和例外，而這些正是 AI 試行成敗的關鍵；實際看他們做事，就能抓到。

## 適用情境

- 為客戶或自己團隊的流程提出 AI 工具或代理之前。
- 有團隊說「我們想把 AI 用在 X」，但沒有人盤點過 X。
- 試行卡住之後，找出當初漏掉的步驟。
- 不適用於一次評分很多工作來挑選目標（請先用 automation-opportunity-scan）。

## 需要準備

- 用一句話描述這條流程，包含開始與結束的觸發點（「從收到發票 Email 到發票付款完成」）。
- 能接觸到 2 到 3 位實際做這份工作的人，最好是在他們做事的時候。
- 輸入與輸出的範例（表單、Email、檔案），並移除個人資料。
- 如果無法現場觀察，就用訪談的方式問這些問題，並在流程圖上標註「[來自訪談，未實地觀察]」。

## 步驟

1. **界定流程範圍。** 寫出開始的觸發點、結束狀態、參與的人，以及數量（每週幾件）。一次探索只看一條流程；如果分岔成兩份工作，就拆開。
2. **先觀察，邊看邊問。** 觀察實際工作 30 到 60 分鐘。當下就問：「你在那裡找什麼？」、「那個欄位空白的話會怎樣？」、「你是從哪裡學到這樣做的？」、「這裡出錯時你怎麼處理？」。記下變通做法：複製貼上、另外開的試算表、便利貼、傳訊息問同事。
3. **用泳道表畫出目前的步驟。** 每個步驟一列：執行者、步驟、工具、每件耗時（分鐘），以及痛點（等待、重工、錯誤、枯燥）。依時間順序排列。標出決策點（「金額 > NT$250,000 → 主管」）。
4. **列出資料的輸入與輸出。** 每個步驟進來什麼資訊（從哪裡來、什麼格式）、出去什麼。標出屬於個人資料、機密或受法規管制的資料。
5. **收集例外狀況。** 每 10 次或每 100 次會發生 1 次的情況：欄位缺漏、格式特殊、爭議、急件。能計數就計數。例外通常最花時間，也最容易讓天真的自動化失敗。
6. **標出 AI 適合的地方。** 每個步驟擇一：AI 草擬或擷取、由人確認；AI 單獨完成；或維持由人處理。這個技能的預設規則：只有在結果容易檢查、出錯也容易復原的地方才讓 AI 單獨完成；凡是涉及金錢、法律條款，或對某個人做出決定的，都保留人工核准。
7. **訂一個成功指標和一個試行。** 一個指標，基準值取自流程圖（每件耗時、錯誤率、處理時間）。試行：一個或幾個步驟、2 到 4 週、小量、客戶方有一位具名負責人，並寫清楚「繼續／停止」的標準。

## 輸出格式

```markdown
# 流程探索 — [流程]，[團隊／客戶]
**觸發點 → 結束：** [開始] → [結束] · **數量：** [每週 n 件] · **觀察：** [對象、日期] 或 [來自訪談]

## 泳道表：目前狀態
| # | 執行者 | 步驟 | 工具 | 每件分鐘 | 痛點 |
|---|---|---|---|---|---|
| 1 | [角色] | [步驟] | [工具] | [n] | [等待／重工／錯誤／無] |

## 資料輸入與輸出
| 步驟 | 輸入（來源、格式） | 輸出 | 敏感資料？ |
|---|---|---|---|

## 例外狀況
| 例外 | 頻率 | 目前怎麼處理 |
|---|---|---|

## AI 適合的地方
| 步驟 | AI 的角色 | 人工確認 | 理由 |
|---|---|---|---|
| [#] | 草擬／擷取／單獨完成／無 | [誰確認] | [理由] |

## 成功指標
[指標]：基準 [n] → 目標 [n]

## 試行提案
- 範圍：步驟 [#]，[數量]，[週數]
- 負責人（客戶方）：[姓名]
- 繼續條件：[門檻] · 停止條件：[門檻]

## 尚待釐清的問題
- [問題]
```

## 範例

**輸入：**「跟著禾豐食品的應付帳款專員志豪觀察了一小時。發票以 PDF 透過 Email 寄來（每週約 120 張）。打開 Email、存下 PDF 約要 30 秒。他把供應商、金額、PO 號碼手動輸入 ERP（每張約 4 分鐘）；他說這很枯燥，也常打錯字。發票上有供應商的匯款帳戶資料。沒有 PO 號碼的話，他會寫 Email 問採購（寫一封約 2 分鐘）並等待（約每 8 張有 1 張，要等 1–2 天）。超過 NT$250,000 要在 ERP 上由主管美玲核准。有些供應商寄來的是掃描圖檔，比較難判讀。」

**輸出：**

```markdown
# 流程探索 — 供應商發票登錄，禾豐食品應付帳款
**觸發點 → 結束：** 收到發票 Email → 發票在 ERP 核准 · **數量：** 每週約 120 張 · **觀察：** 志豪，1 小時

## 泳道表：目前狀態
| # | 執行者 | 步驟 | 工具 | 每件分鐘 | 痛點 |
|---|---|---|---|---|---|
| 1 | 應付帳款專員 | 開啟 Email、下載 PDF | Email | 0.5 | 無 |
| 2 | 應付帳款專員 | 把供應商、金額、PO 號碼輸入 ERP | ERP | 4 | 枯燥、打錯字 |
| 3 | 應付帳款專員 | 沒有 PO 時：寫 Email 問採購並等待 | Email | 2 + 等待 1–2 天 | 等待 |
| 4 | 主管（美玲） | 超過 NT$250,000 時：核准 | ERP | [待確認] | 等待 |

## 資料輸入與輸出
| 步驟 | 輸入（來源、格式） | 輸出 | 敏感資料？ |
|---|---|---|---|
| 2 | PDF 或掃描圖檔 | ERP 發票紀錄 | 供應商匯款帳戶：是 |
| 3 | 沒有 PO 的發票 | 寄給採購的 Email | 否 |

## 例外狀況
| 例外 | 頻率 | 目前怎麼處理 |
|---|---|---|
| 缺少 PO 號碼 | 約每 8 張 1 張 | 寫 Email 問採購，等 1–2 天 |
| 收到掃描圖檔而非 PDF | [待確認：件數] | 較難判讀 |

## AI 適合的地方
| 步驟 | AI 的角色 | 人工確認 | 理由 |
|---|---|---|---|
| 2 | 擷取欄位到確認畫面 | 志豪逐筆確認 | 容易對照 PDF 檢查；付款資料需要人工 |
| 3 | 草擬寄給採購的 Email | 志豪寄出 | 風險低，省下打字時間 |
| 4 | 無 | 美玲 | 支出核准維持由人處理 |

## 成功指標
步驟 2 每張發票耗時：基準 4 分鐘 → 目標 1.5 分鐘以內

## 試行提案
- 範圍：步驟 2，限 2 家寄來清晰 PDF 的供應商，3 週
- 負責人（客戶方）：志豪，並知會美玲
- 繼續條件：每張 1.5 分鐘以內，且錯誤不比現在多 · 停止條件：錯誤增加

## 尚待釐清的問題
- 目前打錯字是怎麼被發現的？有多少錯誤一路到了付款階段？
- ERP 能匯入資料，還是一定要手動輸入欄位？
```

## 寄出前檢查

- [ ] 流程有一個開始觸發點、一個結束狀態，以及每週數量。
- [ ] 泳道表每一列都有執行者、工具和分鐘數，或標「[待確認]」。
- [ ] 例外狀況都列出發生頻率。
- [ ] 凡是涉及金錢、法律條款或對某個人做決定的步驟，都保留人工確認。
- [ ] 成功指標的基準值取自流程圖。
- [ ] 試行寫出客戶方負責人，以及繼續／停止的門檻。

## 常見錯誤

- 照文件上的正式流程畫圖，而不是照實際的做法。變通做法才是真正的流程。
- 提議把整條流程自動化。先試行耗時最明確、最容易檢查的那一個步驟。
- 因為例外很少見就忽略。人們是否信任這個試行，就看例外處理得好不好。