你不需要AI，你需要先把流程寫下來

工具買了，事情沒有變少

不少企業在AI應用這件事上的第一步是先買工具——買一套助理、接一個模型、試一個自動化平台。工具本身通常沒問題，問題是用了一陣子之後回頭看，做事的方式其實沒怎麼變，只是多了一個要維護的東西。

常見的原因不在工具選錯，而在流程從來沒有被真正寫下來過。沒有這份東西，AI只是把原本的混亂變快，不是把混亂解掉。

但「先把流程寫清楚」這句話本身太模糊了，多數人聽完還是不知道要寫到多細。以下是具體的判準。

寫到多細才算夠：六個欄位

「流程寫清楚」不是寫一段文字描述某個部門在做什麼。可用的最低標準，是每一個環節都能填滿這六個欄位：

這六欄任何一欄空著，這份紀錄就只是一張示意圖。AI沒有東西可以真的接上去，因為它不知道誰負責、用什麼資料判斷、卡在哪一步。

特別容易被跳過的是「等待時間」。多數人只記錄做事花多久，但實務上流程的總時間常常有一大半是花在等——等簽核、等對方回信、等下一個批次。這一欄空著，你就看不出真正該處理的地方在哪。

步驟和決策點是兩種東西，要分開畫

盤點流程時，把「步驟」和「決策點」用不同符號分開標記。步驟是「做了什麼」，決策點是「誰在這裡判斷、依據什麼規則判斷」。

這不是形式主義。真正能被AI接手的，往往不是整段流程，而是那些規則清楚、判斷依據講得出來的決策點。反過來說，如果一個決策點的規則講不清楚，只能說「這個要看情況」「他做久了就知道」，那代表這裡的判斷還停留在某個人的經驗裡——AI接不了，而且這件事跟你買了多好的工具無關。

把決策點單獨標出來的好處是，你會立刻看到哪幾個判斷是可以被規則化的，哪幾個是公司真正的專業所在、應該留給人。

問法決定你拿到的是哪一份流程

盤點時的提問方式，比表格設計更影響結果。正確的問法是「這件事實際上怎麼運作，帶我一步一步走過一次」，而不是「你們的流程是什麼」。

這個差別背後承認了一件事：企業寫在文件裡、掛在牆上的官方流程，跟員工每天實際在做的真實流程，經常是兩份不同的東西。問「你們的流程是什麼」，多數人會憑印象背出官方版本；問「帶我走一次」，才會問出真的發生了什麼。

只把官方流程交給AI，等於把AI套進一個沒有人真的照著走的版本。這是「先買工具」失敗最常見的根本原因之一。

最該挖出來的是「變通做法」

企業內部大部分的實際運作，本來就沒有寫在任何SOP裡——它們散落在員工的腦袋裡、臨時的口頭交接裡，以及各種變通做法裡。

而這些變通做法正是流程文件化時最該優先挖出來的部分。一個變通做法的存在，代表某個問題被默默接受、卻從來沒有被真正解決。它同時也是流程紀錄裡最容易被漏掉的那一段：例外處理。

一份流程文件如果只寫了「正常情況下怎麼走」，沒有寫「卡住的時候大家實際上怎麼繞過去」，AI遇到例外狀況一樣會卡住，只是卡得比人更快、而且不會自己想辦法。

盤點時可以直接問：「這個流程什麼時候會卡住？卡住的時候你們怎麼處理？」這個問題挖出來的東西，通常比前面所有表格加起來還有價值。

不用一次寫完整間公司

流程盤點完，不代表要一次把整套都丟給AI。比較務實的做法是刻意收斂：先聚焦一件事，把那一段的欄位補齊、決策依據講清楚，做完之後蒐集實際數據驗證它真的有效，再往下一個環節推進。

這也回答了「流程要寫多完美才能開始」這個問題——不需要完美，只需要最關鍵的那一段夠清楚。其他部分等第一段驗證過了再往下做，那時你對該寫什麼也會更有概念。

誰來寫，以及大概要花多久

這件事最常見的失敗方式，是整包外包出去。外部的人可以幫忙設計欄位、主持訪談、把東西整理成文件，但內容只能來自真正在做這件事的人。把流程盤點整包丟給外部，最後拿到的通常又是一份官方版流程——因為外部的人只問得到別人願意講的版本。

比較可行的分工，是找一位真正在跑這條流程的人當受訪者、一位不涉入這條流程的人當記錄者。記錄者不涉入很重要，因為涉入的人會自動跳過他覺得理所當然的步驟，而那些步驟往往正是新人接手時會卡住的地方。

時間上，單一條流程若範圍界定清楚，訪談加整理通常落在幾個小時到一兩天之間，不是需要排一整季的大工程。真正花時間的不是寫，是回頭確認——把整理好的版本拿回去給受訪者看一遍，問他哪裡跟實際不一樣。這一步常被省略，而它是整件事裡最便宜也最有效的品管。

結語

如果你已經買了工具、卻覺得事情沒有真的變簡單，值得先回頭看一件事：那條流程有沒有被寫到六個欄位都填得滿。多數卡住的案子，問題都出在這裡，而不是出在選錯了哪一套AI應用。

如果你想把某一條流程真的攤開來看清楚，但不確定該從哪一段開始盤，可以先進行一場「AI導入探索會議」——這是初步對談，目的是幫你把流程現況整理出頭緒、一起判斷哪一段最值得先處理，這個階段還沒有到出具診斷報告。在文末表單簡單描述你目前的狀況，我們收到後會主動與你聯繫，安排時間對談。