如何建立文件審批工作流程
如何建立一條先分流、後簽署的文件審批工作流程：把改動分類，讓文件類型決定審閱人，並為編輯性改版留一條略過審閱的路。
文件審批工作流程首先是一個分流決定，其次才是一串簽署——文件的類型與改動的重要程度，共同決定哪些審閱和審批適用於它。
簡而言之
- 先為文件分類。必須參與的審閱人由文件類型決定，而不是由設計流程的人決定。
- 一次不改變任何意思的編輯性改版，需要的是一條登記紀錄，而不是一輪審閱。
- 審閱意見匯合到作者身上；而會簽性質的審批，必須排在它所會簽的那次審批之後。
- 訂明觸發第二位審批人的條件，而不是寫死第二位審批人是誰。
- 發布不是單一狀態：一次登記在案的編輯性更新，與一次附帶培訓的發布並不相同。
多數文件並不需要多數審閱人
每一條文件審批工作流程裏都有一個分類步驟，而多數流程從來不把它畫出來。總有人在決定這一版要三位審閱人、那一版一位都不要——憑習慣、憑誰有空、憑上一版惹出過多少麻煩。畫出來，這個決定就是一條有紀錄可查的規則；不畫出來，它就是一連串無法證明曾經一致執行過兩次的個人判斷，而一致性正正是分流規則裏唯一可以被檢查的性質。
一條好用的分流問題，提交人一分鐘之內就答得出，而且不必讀文件的實質內容：這是哪一類文件、是否受規管、這次改動有沒有改變別人必須做的事。一條要先讀完文件才答得到的問題，等於把它本來要省下的工夫先花掉了。這就是分類必須通過的檢驗，也是這些問題只問文件、從不問哪位審閱人剛好有空的原因。
下面的示例是一棵決策樹而不是一串簽署，而且分流在任何人讀文件之前就已經決定。「是編輯性修改還是實質性修改？」把一次改版整個帶離審閱，而「作者能否即時解決？」把未解決的意見送回「收集審閱意見」再走一輪——這種回流，串連圖根本畫不出來，這也是為甚麼串連圖在紙上永遠比它所描述的流程更快。
八個決策，一個回流
一棵文件審批決策樹，頭三條問題就決定了餘下部分究竟有多少適用於這份文件。
先分類，再分流
編輯性改版在任何人讀它之前就離開了流程。「是新文件還是改版？」把改版交給「是編輯性修改還是實質性修改？」，其「編輯性」分支通往「登記今次編輯性更正」——問到第二題就有出口，流程在此決定它欠這份文件多少工夫。
誠實地畫出審閱回流
分類決定審閱範圍：「是否屬於受規管的文件類型？」會在涉及管理體系或牌照時加入品質與法規審閱人。意見匯合到同一個步驟，而「所有審閱意見是否都已處理？」把未決的交給「作者能否即時解決？」，答「是」就再走一輪。
先批准，再談第二個名字
審批以兩列進場，一列在讀、一列在決定——「審批人審閱最終稿」排在「是否批准發布？」之前；到這個切面，只有它的「批准」出口有地方可去，通往「是否須要第二位審批人？」，而「取得第二位審批」在那裏加上一個會簽。
發布不止一種結局
「是否須要「已閱讀並明白」確認？」決定發布是否附帶培訓責任；完成的決策樹除了「退回作者返工」與「已否決並關閉」之外，還提供三種已發布狀態——五種這條流程真的產生得出的結果。
運作方式
先做分流表，再畫圖
一種文件類型一行，加上兩欄大家會爭論的東西：這個類型必須有哪些審閱人，以及可以放行它的授權級別。在那張表上把爭論解決掉，代價是一個下午，而不是一份改版。之後的圖只是把這張表畫出來，所以一個沒有人同意過的類型，就會變成一條沒有人走的路線。
用文字寫清楚編輯性與實質性
編輯性的意思是讀者不會因此有任何不同做法：排版、版面、部門改名、更正交叉引用。其餘一律屬於實質性。要指名由誰仲裁有爭議的分類，因為邊界個案——改動了的公差數值、調整過次序的步驟清單——正正是這個定義值錢的地方。
把分流問題放在最前面幾列
把分類問題打進試算表最上面幾列，並把每一列的「形狀」設為決策。因為「連線至」填的是列號，一條略過整個審閱區塊的路線，不過就是一個跳過去的號碼——編輯性出口是一個數字，不是一張重畫過的圖。
把審閱收成一列，再排好簽署次序
同時進行的審閱人是同一列：他們的意見並行送達，並匯合到作者身上。只有在後一個簽署要會簽前一個時才排成順序，例如「取得第二位審批」；其餘的都是把習慣畫成了圖。分支的字填進「連線文字」，次序與它承載的號碼一致。
每一種結局都要有自己的終止符
文件獲發布的地方把「形狀」設為成功，被否決的設為拒絕，退回作者的設為結束。三種已發布狀態並不是重複：完整審批後發布、附帶培訓任務發布，以及一次登記在案的編輯性更新，留下的責任確實不同。
拿三次有紀錄的改版重走一遍
由文件管制紀錄裏取最近三筆，只用頭三條問題去分類。如果三筆都落在同一條路線上，說明這個分類目前甚麼工作都沒有做——要麼定義劃得太闊，要麼那三次改版真的很相似。把樣本擴大，直到其中一筆走出不同的路為止。
應避免的錯誤
分流規則只存在於一個人腦裏
一串固定的簽署至少是公開可見地在執行。非正式地保存下來的分流規則，會被逐份文件重新詮釋，而這些詮釋只會朝一個方向漂移：利害最大的那些改動，走了最短的路線。
批准之後又改文件
審批人簽的是一份草稿；之後在發布前又做了一次排版、一處遲來的更正，或者合併了一條意見。如果發出去的檔案不是當初獲批的那一份，這個簽署就屬於一個沒有人手上有的版本。
太遲才問第二個名字
「是否須要第二位審批人？」排在「是否批准發布？」之後，於是需不需要會簽，要等第一位審批人已經表態才決定。哪些類型需要兩個名字，在分類的時候就知道——那就在那裏問。
確認要麼人人都做，要麼無人要做
兩種預設都會失敗。連排版微調都要求確認，會訓練大家一路點過去；從來不要求，則等於沒有任何證據顯示有人正按改動後的現行版本作業。
建立你們的文件審批流程
把這棵決策樹開啟為你自己的圖表，設定好那幾條真正決定你們文件需要哪些審閱與審批的問題。
相關指南
常見問題
文件應該由誰批准，誰只做審閱？
審批人是這份文件的流程負責人，或者持有該類型授權的那個人——一個指名的人，絕不是一個職位信箱。審閱人同樣不是逐份文件去揀：名單屬於文件類型，而示例中「是否屬於受規管的文件類型？」正是在解決這件事，為一條原本兩者皆無的路線加上品質與法規的名字。把類型爭論一次，就等於為它日後每一次改版都作了決定。
每一次文件改版都要走完整的審批嗎？
不需要，而把它當成需要，正是審閱周期一拖幾星期的原因。一次不改變任何意思的改版——排版、部門改名、更正引用——需要的是一筆記錄在案的編輯性更新，而不是重新收集一輪簽署。凡是改變了別人必須做的事，就走完整路線，包括它的文件類型所要求的那些審閱人。關鍵是這個檢驗在改版到來之前就已經存在，而且不是只有作者一個人在應用它。
一份文件應該審閱多少輪？
一輪，只有在第一輪找到實質問題時才需要第二輪。工作流程真正要交代的，是第二輪仍然收不了尾時會怎樣，而這正是「作者能否即時解決？」的職責：答「是」就把意見再送一輪，答「否」則終止於「退回作者返工」——這是決定停止審閱一份本來就未準備好的草稿，而不是繼續讓它轉圈。沒有上限的輪數，只會換來四位審閱人份量的意見和一個沒有人負責的結果。
「已閱讀並明白」的紀錄有甚麼用？
它是做這項工作的人知道有這次改動的證據——與文件是否獲批准，是兩個不同的問題。如果改動改變了某人在受規管、安全關鍵或面向客戶的步驟裏實際上必須做的事，要求這份確認就有意義；如果每一次措辭修改都要求，它就只是一次點擊。審核員會看文件生效日期與確認紀錄之間的空隙，因為那段時間正是大家仍在按舊版本作業。
