企業工作流程診斷：找出重工、等待與交接斷點

流程診斷要回答什麼

企業工作流程診斷，是追蹤一件工作從被提出到被接受的實際路徑，找出時間、錯誤與責任在哪裡流失。它應回答「為何這件事要等」「為何同一份資料要再輸入」「誰能決定例外」，再判斷 AI 是否有用。若主要問題是資料沒有負責人，增加一個摘要工具可能只會更快產生另一份待確認文件。本文提出可操作的診斷方法；所有樣本數、排序及驗收值都應由團隊依任務風險設定，並非工具供應商的通用門檻。

先定一件工作，不先畫部門組織圖

請流程負責人用一句話定義起點、終點與成果。例如「收到完整詢價資料，到客戶收到經確認的報價」。再列出取消、補件、退回與拆單如何處理，避免只算順利完成的案件。流程中的個案不一定是客戶；同一客戶可以同時有數件詢價，混用客戶識別會把互不相關的工作接成一條。資料窗口要標註來源系統、可取得日期、保存範圍與不能讀取的欄位，分析人員先用去識別副本，不為了畫流程而擴大存取權。

建立可以回放的事件資料

Microsoft 的資料準備說明以個案、活動與時間連接流程事件，並提醒目前狀態表未必保留事件歷史。[S1] 實作時先做事件字典，將「建立」「送出」「被接受」分開，不讓同一個「完成」同時代表草稿完成與正式交付。每筆事件保留原始時間、時區、執行角色與來源證據，另存清理規則。跨系統無共同識別時，先由人確認連結規則與無法配對的比例；不要讓模型憑相似名稱偷偷合併。缺時間的紀錄應留下缺值標記，不能以匯出時間充當活動發生時間。

把日誌與現場工作放在一起看

挑選正常、退回、逾期及取消的個案，請實際操作者帶著一件工作走一遍。記下收件時有哪些資訊、做判斷時查哪份資料、交出去後如何知道對方已收到。Fluxicon 的流程觀點以事件串回實際路徑，適合辨識瓶頸與偏離。[S2] 但沒有留下系統紀錄的電話、核對與協調仍需訪談補足。把「日誌可見」「人員回述」「分析推測」分欄，遇到衝突回到原始單據，不以看起來最整齊的流程圖取代證據。這也能避免把缺漏資料誤寫成某一部門沒做事。

將操作時間與等待時間分開

為每個步驟量實際操作、佇列等待、跨部門交接及重做；同時列案件完成時間的中位數、較慢尾端及觀察範圍。若只有一個時間戳，只能確定兩事件間隔，不能直接說整段都是人在操作。尚未完成的個案另外列出，避免它們從平均值消失。對退回原因逐件編碼，例如缺規格、價格權限不足、版本用錯或接收者不清。先分辨延誤來自資料、決策、容量還是規則，再討論技術；每類改善會需要不同負責人，不能全部交給 IT。

先驗資料品質，再計算改善幅度

在計算前逐項檢查重複事件、時間倒序、不同時區、同名活動與無法配對的個案。特別注意系統批次補寫紀錄：它可能讓數十個動作看似同時發生。工作日與日曆日也要擇一說明，跨週末的等待不能默默排除。清理前後保留筆數與排除原因，讓流程負責人確認被排除的資料是否集中在某種例外。若只剩容易處理的案件，報告必須縮小適用範圍，不把漂亮的平均值推到所有工作。

把問題轉成可試行的改善假設

每個問題寫出觀察證據、根因假設、可替代做法與驗證方式。格式是「在何情境，因何資訊或交接缺口，造成什麼可量測後果；若改哪一件事，預期哪個指標改善」。規格欄位固定的工作可先用表單驗證；重複搬運資料先評估既有整合；大量非結構文件的比對才考慮 AI 輔助。對 AI 候選列清楚輸入、輸出、人工核對點與禁止動作。若一項改善不用 AI 也能達成，仍應放入比較，讓投資選擇建立在成果與維護負擔上。

一張可以直接建立的診斷工作表

建議把個案事件表與問題表分開。前者紀錄實際發生的事，後者承載分析與建議，兩者以穩定的個案識別連結。原始資料只讀保留，清理後表與圖表屬衍生物，重跑時要能知道使用哪一版來源與規則。流程負責人確認範圍，資料窗口確認欄位意義，操作者確認實際路徑，分析者標示不確定處。成果不是一張漂亮圖片，而是別人能依同一套定義重現主要判斷。

• 事件表：個案識別、活動、開始與結束時間、時區、執行角色、來源紀錄、缺值原因。
• 問題表：發生節點、現象、受影響案件、證據位置、原因假設、改善方案、負責角色。
• 試行表：比較基準、測試區間、品質底線、人工介入方式、停止條件、檢討日期。

假設情境：詢價一直卡在補件

假設一個製造業團隊常覺得報價很慢，診斷先追蹤「收件到正式送出」，而非只量業務寫報價的時間。訪談可能發現規格缺漏要來回確認，日誌則顯示完整案件其實很快。可先試用必填規格檢查表，再讓 AI 從附件提出「待補資訊」草稿，由業務核對後詢問。此情境是方法示例，沒有宣稱任何公司的實測改善。試行須保留不使用 AI 的同類案件，區分表單改善、案件難度與模型協助的作用；如果 AI 列錯缺項，仍須計入返工與客戶溝通成本。

驗收診斷結果，而不只驗收圖表

驗收時抽查數件個案，從圖表回到事件、從事件回到來源，確認時間順序與完成定義一致。資料窗口應能說明遺失、重複、跨系統配對與未完成案件如何處理；操作者應能指出圖中看不到的工作。交付需包含範圍、事件字典、清理規則、主要路徑、例外、基準與優先改善清單。試行前先鎖定比較方式，否則導入後只挑成功案件，結果容易看似漂亮卻不可重現。若缺乏歷史事件，應交付補記計畫與觀察限制，不能假裝已完成精準流程探勘。

常見問題：沒有日誌、需要 AI、要追蹤誰

沒有系統日誌還能做嗎？可以先以工作樣本、訪談與短期人工記錄建立低解析度基準，但要標示回憶偏差與涵蓋不足。

每個瓶頸都適合 AI 嗎？不適合；權責不清、規則衝突與容量不足通常先處理流程設計。

能拿個人完成速度評分嗎？不宜直接如此使用，因事件紀錄未必包含協調、難度與等待的全部背景；若用途轉為人員評估，必須重新檢視資料使用範圍、告知方式與公平性。流程診斷的第一目標是找出系統問題並建立可驗證的改善起點。

來源依據與證據界線

1. S1 · Prepare processes and data

   Microsoft Learn · 查閱 2026-10-22

   事件紀錄需有流程個案、活動與時間；目前狀態表不必然包含事件歷史。並未規定本文抽樣數與驗收門檻。

2. S2 · Data Requirements — Process Mining Book

   Fluxicon · 查閱 2026-10-22

   流程分析以個案與事件連接工作路徑；不支持從事件日誌直接推斷員工努力程度或因果。