訪談得到的，是流程描述，還是流程真相？

訪談給你的是流程的描述；流程的真相，要到事件、單據與現場裡核對。

流程圖畫得再清楚，現場的人可能還是接不住。

這件事，是一位新進員工教會我的。

我曾經在一個職位上，幫部門整理流程圖。 每個節點該做什麼、要用哪些文件、對應哪些說明，我都整理得清清楚楚。後來因為一個機緣，新進員工的教育訓練，也由我協助。

我原本以為順序很理所當然： 先看流程圖，按步驟理解流程；再看文件；最後學 ERP 操作。

結果對新人來說，這條路太空泛，也太複雜。 他真正能接得住的方式，是一位老手，用他聽得懂的說法，實際帶著他走一遍。 先有感覺，知道「原來大概是這樣做」，再慢慢對回流程、文件和系統。

那時候我才第一次很深刻地發現： 流程圖是我畫的。 文件是齊的。 每個節點也都有說明。 連 ERP 操作需要的資訊，我也都已經考慮進去了。

但對真正要動手的人來說，這些「描述」，不一定能直接轉換成「會做」。

這個衝擊，對我蠻大的。

後來一位前輩分享的情境，又讓我想起這件事。 有一項工作，長期由一位資深同仁負責。平常問他流程、看文件，好像都沒有什麼問題。 直到主管說： 「那這個工作交給我，你教我做一次。」

真的坐下來，一步一步操作，很多原本看不到的東西才第一次浮現。

繞路的步驟。 必須人工判斷的情況。 從來沒寫進 SOP 的例外。 還有那些只有資深同仁自己知道，要去哪裡找的資訊。

重點不是員工隱瞞。 他其實已經把自己「知道自己在做」的部分，都誠實說出來了。 真正麻煩的是： 很多隱性知識，連執行的人自己都沒有意識到——原來那也是一個需要被說明的步驟。

所以我後來發現，這其實是兩個方向、同一件事。 把完整的流程描述交給新人，他還是不一定會做； 請資深的人完整描述自己的工作，你也不一定看得見真正的流程。

被描述出來的流程，不一定等於真正運作的流程。

也因為這樣，後來不管是流程訪談，還是跟客戶討論需求，我都會刻意多往現場追一步。 我自己最常用三個方法:

第一，還原「最近一次」。 不只問：「通常怎麼做？」 而是繼續追： 最近一次是什麼時候？ 那一次，你實際做了哪些事情？ 因為「通常」是整理過的版本。 真正的繞路、例外、臨時判斷，通常都藏在某一次具體事件裡。

第二，跟著單據走。 從一張訂單、一筆請購、一份報表開始，一路追到結果。 訪談裡說只有三個步驟，紀錄卻顯示走了四個人、花了八天。 這中間的差異，往往才是最值得追的地方。

第三，到現場看。 有機會的話，我甚至很喜歡直接坐在他們的辦公室裡，看他們遇到問題時，實際上怎麼處理。 成本最高的做法，是像前面那位主管一樣： 自己接手做一次。 但通常，看見的也最多。

這件事放到 AI 導入上，含義其實很直接。 如果我們只是拿著訪談紀錄和 SOP 去設計自動化，我們自動化的，很可能只是「被描述出來的流程」。 那些沒有被說出口的判斷，上線之後，要嘛變成一連串例外與客訴，要嘛直接消失。 而消失的那一部分，可能恰恰就是這條流程過去一直沒有出事的原因。

所以現在，我會用一句話提醒自己： 訪談給你的是流程的描述；流程的真相，要到事件、單據與現場裡核對。

這一篇談的是：一條流程裡，「描述」和「真相」為什麼會有落差。 下一篇我想再往上一層談一個更尷尬的現象： 為什麼每個部門都說自己做完了，公司整體還是卡？

原文 2026-09-03 發表於 原文；本頁為站內整理版，文字與原文相同，只調整了平台相關的說法。