如何編寫業務流程文件
如何令流程文件一直站得住腳：每一步指定負責人，寫下判定規則，把文件納入版本控制與審批，並設定檢討日期。附一個可直接操作的示例。
運作方式
先決定這份文件用來做什麼
培訓新人、應付審核員、化解團隊之間的分歧，各自需要的詳細程度並不相同。寫下你正在做的是哪一種，因為它決定了要寫多少。想同時滿足這三種用途，只會得到一份長到無法用來培訓、又含糊到無法用來審核的文件。
先抓住流程本身，再寫文字
先把流程建立成一張圖——步驟是行，連接靠行號，每一步歸屬一條負責人泳道。圖表會把缺口逼到明面上：沒有負責人的步驟、沒有標示的分支、欠缺的例外路徑，在圖裡都看得見，在段落裡卻很容易藏起來。
為每一步指定負責人，為每一個判斷寫下規則
把問責的角色放進步驟所屬的泳道，把判定規則寫進它的備註：門檻、判定準則、誰可以批出例外。凡是可以用數字的地方，就用數字取代「視乎情況」和「適時」；確實做不到的地方，就寫明由誰決定。
寫清楚證據落在哪裡
對每一個產生紀錄的步驟——一次批准、一份已簽署的合約、登記冊裡的一行——都要寫下由哪個系統保存、以什麼名稱保存。這就是能捱過一次審核走查的文件，與會引來追加查詢的文件之間的分別。
要經過批准，而不只是發布出去
把完成的圖表送進 QueryChart 的審批流程，讓當前版本帶有審核人、簽署和日期。正是這一點令它成為受控文件而不只是一個檔案：一個已批准的版本、一條不可篡改的變更歷史，以及對該讀哪一份毫不含糊的答案。
設定檢討日期和觸發條件
選一個周期——每年一次很常見，變動頻繁的每半年一次——並加上一條規則：凡是涉及這條流程的事故、審核發現或系統變更之後都要檢討。文件會無聲無息地失效，而頁面上的一個日期是最便宜的防線。
常見問題
流程文件與 SOP 有什麼分別？
流程文件描述工作如何流動，通常橫跨多個角色：次序、判斷、交接。SOP 是執行某一份工作的指令，寫給動手的人看，往往包含流程圖承載不了的細節——螢幕擷圖、精確的欄位數值、安全提示。實際使用時兩者是配套的：流程圖顯示各份 SOP 如何銜接，而每份 SOP 展開其中一個步驟。
為了應付審核，流程文件需要寫到多細？
細到審核員可以隨手挑一個真實個案，照著你的文件走一遍，並在文件所說的位置找到證據。這代表寫明負責人、寫明判定準則，並為每一條紀錄寫明存放位置。審核員追查的不是篇幅，而是一致性：一份成文的流程、流程被遵守的證據，以及一條顯示成文版本就是現行版本的批准紀錄。
流程文件應該由誰來寫？
由不做這份工作的人來寫，根據對實際執行者的訪談。熟手的人會略過那些已經變成本能的步驟，而那恰恰是新人最需要的步驟。先以外部視角寫出初稿，再讓實際執行者去修正——修正很快，而他們補上的正是任何初稿都寫不進去的隱性經驗。
流程文件應該多久檢討一次？
按固定周期，並在特定觸發條件下檢討。每年一次是常見的基準，變動頻繁的流程則每半年一次。觸發條件更重要：在事故、審核發現、系統遷移，或者調動了泳道負責人的架構重組之後進行檢討。大多數失效來自沒有人檢討的變更，而不是時間流逝本身。