如何編寫業務流程文件
如何令流程文件一直站得住腳：每一步指定負責人，寫下判定規則，把文件納入版本控制與審批，並設定檢討日期。附一個可直接操作的示例。
為流程編寫文件，就是把發生了什麼、每一步由誰問責、判定規則是什麼記錄下來，而且這份紀錄只有一個現行版本、一位指名的負責人和一個檢討日期。
簡而言之
- 只有一個現行版本，而且能被辨認為現行版本。其餘的都是副本。
- 每一步都寫明問責的角色；每一個判斷都寫明規則與門檻。
- 寫清楚證據落在哪裡：哪個系統、哪本登記冊、哪一條紀錄。
- 帶簽署與日期的批准，才是把一份檔案變成受控文件的關鍵。
- 設定檢討日期——並在任何出問題之後進行檢討。
揀流程文件工具
流程文件為什麼會失去公信力
幾乎每間機構都有流程文件。真正被信任的卻很少，原因很少出在寫得好不好，而在於沒有人分得清哪一份才是現行版本。同一條程序同時存在於共用磁碟上的一個 Word 檔案、某個人簡報裡的一張圖，以及十八個月前最後更新的一個 wiki 頁面裡，而這三者各自說對了一部分。為流程編寫文件，只有一半是把它寫下來；另一半是令其中一個版本可以被辨認為大家認可的那一個。
內容層面的檢驗很簡單：一個從未做過這份工作的人，能否照著做下來？一個外部人士，能否看出流程有沒有被遵守？這代表每一步都寫明負責人，每一個判斷都寫明規則和門檻，而不是寫「視乎情況」，並且每一個產生紀錄的步驟都說明紀錄歸到哪裡。「核對銀行帳戶資料」是一種意願。「按已簽署合約上的號碼致電供應商——絕不用發票上的號碼——並記錄由誰核對、何時核對」才是一項控制。
下面的示例是供應商引進流程。請把畫布下方的程序正文和圖表對照著看：它們是由同一批行生成的，這正是關鍵所在。當圖表和書面程序是兩份文件時，它們就會逐漸脫節——而這種落差在審核員把它們並排放在一起之前都是看不見的。
一份成文的流程：圖表與正文
跨五條泳道的供應商引進流程。畫布下方的程序正文由同一批行生成——兩種檢視，一個來源。
記錄觸發條件與受理入口
一份申請表，加上一次有據可查的核查：現有供應商是否已經能滿足這個需求。把受理入口寫進文件，才能防止流程由中途插進來——未經批准的供應商正是這樣進入帳目的。
寫明有哪些審查、由誰執行
合約條款由法律部審查，信貸由財務部審查，資料保護由保安團隊審查。四項審查、四位負責人、各佔一條泳道——一份只寫「進行盡職審查」而不寫明誰做哪一部分的程序不是文件，只是一個標題。
把判定規則寫下來
風險級別決定審查的深度，盡職審查這道關卡帶有明確的拒絕路徑。當規則和門檻寫在步驟上時，無論誰當值都能作出同樣的判斷，而不必取決於問了誰。
把控制寫進文件——包括那條循環
銀行帳戶資料以回撥方式核實，未核實的資料會退回重新核實——付款設定不會在未經核實的帳戶上繼續推進。只以政策裡一句話形式存在的控制會被略過；畫成帶循環關卡的控制，則明顯不可繞過。
運作方式
先決定這份文件用來做什麼
培訓新人、應付審核員、化解團隊之間的分歧，各自需要的詳細程度並不相同。寫下你正在做的是哪一種，因為它決定了要寫多少。想同時滿足這三種用途，只會得到一份長到無法用來培訓、又含糊到無法用來審核的文件。
先抓住流程本身，再寫文字
先把流程建立成一張圖——步驟是行，連接靠行號，每一步歸屬一條負責人泳道。圖表會把缺口逼到明面上：沒有負責人的步驟、沒有標示的分支、欠缺的例外路徑，在圖裡都看得見，在段落裡卻很容易藏起來。
為每一步指定負責人，為每一個判斷寫下規則
把問責的角色放進步驟所屬的泳道，把判定規則寫進它的備註：門檻、判定準則、誰可以批出例外。凡是可以用數字的地方，就用數字取代「視乎情況」和「適時」；確實做不到的地方，就寫明由誰決定。
寫清楚證據落在哪裡
對每一個產生紀錄的步驟——一次批准、一份已簽署的合約、登記冊裡的一行——都要寫下由哪個系統保存、以什麼名稱保存。這就是能捱過一次審核走查的文件，與會引來追加查詢的文件之間的分別。
要經過批准，而不只是發布出去
把完成的圖表送進 QueryChart 的審批流程，讓當前版本帶有審核人、簽署和日期。正是這一點令它成為受控文件而不只是一個檔案：一個已批准的版本、一條不可篡改的變更歷史，以及對該讀哪一份毫不含糊的答案。
設定檢討日期和觸發條件
選一個周期——每年一次很常見，變動頻繁的每半年一次——並加上一條規則：凡是涉及這條流程的事故、審核發現或系統變更之後都要檢討。文件會無聲無息地失效，而頁面上的一個日期是最便宜的防線。
應避免的錯誤
兩份文件，一條流程
圖表在一個檔案裡、書面程序在另一個檔案裡，它們必然脫節，而且在被放在一起對照之前沒有人會發現。保持單一來源，再由它生成各種檢視。
「視乎情況」
含糊的限定詞把決定由文件轉移到碰巧當值的那個人身上。這與為流程編寫文件恰恰相反。寫下門檻，或者寫下由誰決定。
沒有指名的負責人
人人都可以編輯、卻沒有人負責的文件，就是沒有人更新的文件。頁面上要有一個名字。
靠檔案名稱做版本管理
流程_v3_最終_修訂2.docx 不是版本控制，而是一場考古發掘。請使用一個能告訴你哪個版本已獲批准、以及各次修訂之間改了什麼的系統。
為你自己的流程編寫文件
把供應商引進示例開啟為你自己的圖表，或者由空白開始，用你的行建立整條流程。
相關指南
常見問題
流程文件與 SOP 有什麼分別？
流程文件描述工作如何流動，通常橫跨多個角色：次序、判斷、交接。SOP 是執行某一份工作的指令，寫給動手的人看，往往包含流程圖承載不了的細節——螢幕擷圖、精確的欄位數值、安全提示。實際使用時兩者是配套的：流程圖顯示各份 SOP 如何銜接，而每份 SOP 展開其中一個步驟。
為了應付審核，流程文件需要寫到多細？
細到審核員可以隨手挑一個真實個案，照著你的文件走一遍，並在文件所說的位置找到證據。這代表寫明負責人、寫明判定準則，並為每一條紀錄寫明存放位置。審核員追查的不是篇幅，而是一致性：一份成文的流程、流程被遵守的證據，以及一條顯示成文版本就是現行版本的批准紀錄。
流程文件應該由誰來寫？
由不做這份工作的人來寫，根據對實際執行者的訪談。熟手的人會略過那些已經變成本能的步驟，而那恰恰是新人最需要的步驟。先以外部視角寫出初稿，再讓實際執行者去修正——修正很快，而他們補上的正是任何初稿都寫不進去的隱性經驗。
流程文件應該多久檢討一次？
按固定周期，並在特定觸發條件下檢討。每年一次是常見的基準，變動頻繁的流程則每半年一次。觸發條件更重要：在事故、審核發現、系統遷移，或者調動了泳道負責人的架構重組之後進行檢討。大多數失效來自沒有人檢討的變更，而不是時間流逝本身。