IL 101 · 模組 2

流程與基準

畫出現況流程，標註排隊、處理、覆核與重做，建立可查證的 baseline log。

開始第一節

時長60 分鐘
難度核心
先備知識完成 Module 1（從 Use Case 到專案章程）

已完成 0 / 2

學習目標

畫出現況流程圖，標註排隊、處理、覆核、重做四種階段。
建立一份 baseline log，記錄現況流程的實際耗時與案例量。
區分「估計」與「有證據支持的實測數字」，並在數字旁明確標記。

現況流程與 Baseline

30 分鐘

畫出現況流程

在提出任何 AI 方案之前，必須先看清楚「現在到底怎麼做」。多數團隊高估自己對現況流程的了解：實際流程往往比腦中想像的多出排隊等待、跨部門覆核與重做的隱藏步驟。

示範服務公司 A：客服問答現況流程

客戶提出問題（信件／表單）
排入客服佇列，等待分配（排隊）
客服人員搜尋內部知識庫文件（處理）
不確定時轉主管或資深同事確認（覆核）
草擬回覆內容
部分案件因引用錯誤或過期文件被退回重寫（重做）
回覆客戶並記錄結案

資訊

這個流程對應共用合成案例 SYN-CS-001（示範服務公司 A 客服知識助理）。IL 101-302 都會用到同一組合成資料，方便你在後續課程追溯同一個案例的演進。教材完整檔案可在課程資源頁下載，見本模組「下載」小節。

排隊（Queue）：任務已到，但尚未有人處理的等待時間
處理（Process）：實際執行任務的時間
覆核（Review）：需要他人確認或核准的時間
重做（Rework）：因錯誤或不完整而重新處理的時間

第一步
選定你自己專案的一個具體任務（不是整個部門，是一個可以在一頁畫完的流程）。
第二步
訪談實際執行者，畫出「排隊 → 處理 → 覆核 → 重做」四種階段各自發生在哪裡。
第三步
標出流程中「靠記憶」或「靠口頭確認」而非文件記錄的步驟，這些通常是後續資料準備（IL 202）的風險點。

重點: 沒有畫出來的流程，就無法量化改善的空間；先看見隱藏的排隊、覆核與重做，才知道 AI 應該協助哪個階段。

30 分鐘

建立 Baseline Log

Baseline log 是後續所有價值計算（Module 3）與 IL 201 評估設計的起點。沒有基準，任何「AI 讓效率提升 30%」的說法都無法被檢驗。

Baseline log 最低欄位（可參考 SYN-CS-001 的 baseline_log.csv 格式）
欄位	說明
log_id	唯一識別碼
case_category	案例類型（例如：一般、缺漏資訊、來源矛盾、來源過期、無答案、權限限制）
search / verify / draft / rework minutes	各階段實際花費的分鐘數
total_minutes	總耗時
agent_code / log_date	記錄人員代碼與日期（不使用真實姓名）

合成範例（節錄自 SYN-CS-001 baseline_log.csv）

log_id=BL-001, case_category=normal, search=5min, verify=6min, draft=8min, rework=2min, total=21min log_id=BL-003, case_category=conflicting_sources, search=7min, verify=9min, draft=10min, rework=8min, total=34min

注意

常見錯誤：只記錄「處理」時間，忽略排隊與覆核，導致 baseline 被低估，之後很容易高估 AI 的改善幅度。另一個常見錯誤：把少數幾筆估計數字當作「已驗證」的基準，卻沒有標記樣本數與觀測期間。

自我檢測

客服人員因為找到的知識庫文件已經過期，被主管要求重寫一次回覆內容。這段時間應該歸類為流程中的哪個階段？

處理（Process）重做（Rework）排隊（Queue）

重點: 至少記錄 10-15 筆真實或高保真的觀測樣本，並清楚標記樣本數與觀測期間，才能作為後續價值計算的基準。

另存 PDF