如何建立審批流程
如何設計審批流程：想清楚每道關卡真正在決定甚麼，按你們的授權審批權限表設定門檻，為拒絕規劃去向，並記錄誰批准了甚麼。
運作方式
寫下每道關卡到底在決定甚麼
每次審批寫一句話：這個人在回答甚麼問題，依據的是甚麼文件？寫不成這種句子的關卡，通常是為了知情而存在的——而知情用一則不攔住工作的通知來實現會更好。
門檻從你們的授權審批權限表裡取
金額區間、風險等級與重要性水平屬於授權表，而不屬於設計流程的人。把金額和貨幣寫在決策點上，令分流判斷可供審核；並且把門檻設得足夠高，令那道額外的關卡很少被觸發。
每道關卡只給一位負有問責的審批人
其他人可以被徵詢意見；但只有一個人為這個決定負責。委員會可以審批，但那樣一來審批人就是這個委員會，其法定人數與主席都需要點名。兩位同級而又互相獨立的審批人，是那種會導致兩個人都不認真看的結構。
為每一次拒絕規劃去向
畫出被拒絕的事項去哪裡：帶着記錄在案的理由退回修改、向上呈報，或進入一個明確的已關閉狀態。沒有把拒絕畫出來的流程，會製造出既不在辦也未關閉、停在沒有人跟進的狀態的事項。
令覆核深度跟着風險走
在昂貴的覆核之前加一個分流決策，就像示例中的風險等級那樣。對所有事情都做完整盡職審查，要麼意味着流程太慢，要麼意味着盡職審查並不當真——而通常兩者兼有。
留下審批的證據
每次批准都需要一位審批人、一個時間戳記，以及它所針對的那個版本。在 QueryChart 中，圖表本身就帶有審批流程和不可篡改的歷史紀錄，因此「三月生效的那一版是誰批准的」會有答案，不必有人去翻電郵信箱。
常見問題
一個審批流程應該有幾級審批？
只保留真正作決定的那幾級——通常是一級，再加上超過某個門檻之後的第二級，而那個門檻取自你們的授權審批權限表。每多一道關卡都會增加排隊時間並稀釋問責：五分之一的審批人覆核得更不認真，而不是更認真，所以一個五道關卡的流程可能比兩道關卡的控制更弱，成本卻高得多。如果一道關卡從來沒有拒絕過任何東西，這本身就是它應該改成通知的證據。
批准和審核有甚麼分別？
批准是一個可以攔住工作、並且要為結果承擔問責的決定；審核是一次產生意見的檢視。把兩者混為一談是常見的設計缺陷：審核人被賦予了本不該有的否決權，或者審批人被當作審核人對待，於是他們的簽署不再有意義。把審核畫成步驟、把批准畫成決策，這個分別就由一種慣例變成了結構上的事實。
審批應該並行還是順序進行？
當後一位審批人要依賴前一位的決定時用順序，當他們評估的是互不相干的事情時用並行。多數流程只是出於習慣被畫成順序，白白拉長了好幾天而沒有任何分析上的理由——法務覆核合約條款和財務評估信貸風險，並不需要對方的結論。並行關卡在某些工單系統裡比較難表達，那是一種工具限制，值得點明，而不應把它固化進流程設計裡。
如何為審核留下審批紀錄？
記錄審批人、時間戳記，以及被批准的那個確切版本——最後這一項通常正是缺失的部分。一次無法與特定修訂關聯起來的批准，只能證明某人在某個時候批准了某個東西。QueryChart 把批准記錄在某個圖表修訂版上，並保留不可篡改的歷史紀錄，因此審核員真正會問的那個問題——當時生效的是哪一版、由誰簽署——可以直接回答。