如何建立流程文件管理制度
如何建立一套兩年之後仍然站得住腳的流程文件制度：一份寫明負責人的流程清冊、按變動速度而定的檢討周期，以及每一張落後的圖表都有一筆帶日期的缺陷紀錄。
運作方式
先寫流程清冊，再畫任何圖
把機構運作的每一條流程列出來，一條佔一列，寫上一位為它的描述問責的指名人士、它應該被記錄到甚麼細緻程度，以及它有多關鍵。這張清單會比大家擔心的短，而負責人那一欄才是真正的爭論所在。那一欄仍然有空格的時候，其餘一切都建不起來。
檢討周期由變動速度而定
周期取自這條流程過去兩年實際改動過多少次，而不是取自政策上的預設值：改過三次的值得半年一檢，五年沒有動過的兩年一次就夠。把周期、下一個到期日和記錄的細緻程度都寫進清冊，這三樣就不必每次修訂都重新爭論一遍。
先把元流程畫成圖表
在為任何真實流程寫文件之前，先把你們自己那條文件路線打成一列列：甚麼觸發一次檢討、由誰確認負責人、諮詢誰、由誰審批、怎樣發布和培訓。各個階段填進「方框文字」欄，再用「連線至」欄按列號接駁起來。之後每一份文件都由它繼承。
把審批級別當成決策畫在圖上
那條分流的列「形狀」設為決策，各個級別按「連線至」裏的號碼寫進「連線文字」，好讓一次修訂的路線在草擬開始之前就已經知道。「水平泳道」欄放階段，「垂直泳道」欄放負責人，令圖表看得出政策管理部與審批機構並不是同一回事。
把退回重擬的迴路畫成一個向後的列號
把工作送回去的審批，是一個指向較早那一列的列號，不是有人事後在圖上補畫的一條箭嘴。因為「連線至」欄裝的是數據，這條迴路在它上面插入一個步驟之後依然成立。一張只有向前動作的圖，描述的是一個從來未曾反對過任何東西的審批機構。
用文件自己的日期去審視整批文件
每季數四個數字：過了檢討日期的文件、沒有指名負責人的文件、流程先於圖表改動了的文件，以及檢討過但沒有改動的紀錄。最後一項是健康指標。在收結這一次點算之前，先把下一次寫進清冊，因為一次沒有下一個日期的點算會自己失效，而整批文件會繼續衰敗下去。
常見問題
甚麼是流程文件管理制度？
它是一套令整批流程文件保持真確的規則與角色，與文件本身是兩回事：一份清冊，每條流程一位指名負責人，每份文件記錄到甚麼細緻程度，一個到期日真正送得到負責人手上的檢討周期，一個經過量度、顯示這批文件落後於實際工作有多快的數字，以及一條由建立、審批、發布到廢止的路線。範本反而最不重要。真正的測試是：對於一份三年沒有人碰過的文件，登記冊說得出甚麼。
一份流程清冊應該包含甚麼？
一條流程一列：流程名稱、負責人（要寫一個人而不是一個團隊）、記錄的細緻程度、關鍵程度、現行版本的存放位置，以及最後檢討與下次到期的日期。另外兩欄很快就會證明自己有價值——這條流程運行在哪些系統，它告訴你一次系統遷移會令甚麼失效；以及它為了滿足哪一條條文而存在，它告訴你審核員會要求看甚麼。清冊必須最先建立，因為之後每一個決定都是對它的一次查詢。
流程文件管理制度應該由誰負責？
由一個人負責，而且不應該是持有最多文件的那一位。制度負責人掌管清冊、元流程和檢討日期登記冊；每份文件的負責人掌管內容。把兩者合併，就會出現那個熟悉的失效模式：每一次修訂都排在唯一懂這套制度的那個人後面，而這條隊列會被報告成資源問題，而不是設計問題。只要提示是自動的、每一位負責人都是一個名字，每星期半日已經撐得起五十條流程。
流程文件應該存放在哪裏？
清冊說在哪裏就在哪裏——這正是為甚麼存放位置是清冊裏的一欄，而不是一次過為整批文件作的決定。品質管理系統、wiki 和共用磁碟各自都可以存放一個現行版本；但它們一個都答不出哪些流程根本沒有現行版本。所以測試的不是選哪個平台，而是登記冊每一列有沒有寫明它把讀者送去哪裏，以及到達之後拿到的是不是登記冊聲稱的那個版本。一條在清冊上沒有一列的流程，對任何平台選擇都是隱形的。