如何建立流程文件管理制度
如何建立一套兩年之後仍然站得住腳的流程文件制度：一份寫明負責人的流程清冊、按變動速度而定的檢討周期，以及每一張落後的圖表都有一筆帶日期的缺陷紀錄。
流程文件管理制度令一整批流程文件長期保持真確：一份清冊，每條流程一位指名負責人，一個真正送得到那位負責人手上的檢討日期，以及一個有人量度的失效速度。
簡而言之
- 由清冊開始，不是由文件開始：一條流程一列、一位負責人、一個到期日。
- 寫第一份文件之前先建立元流程：建立、審批、發布、培訓、廢止。
- 放在整批文件上看，每份文件平均有一半的檢討周期是過時的。
- 先於圖表上線的改動，是一項有日期的文件缺陷。
- 甚麼都沒有改的檢討，仍然欠登記冊一筆有日期的紀錄，否則準確會被當成沒人理會。
制度是元流程，不是範本
任何機構都造得出五十份流程文件，有些更加造過兩次。一套文件制度要解決的不是它們怎樣寫，而是兩年之後它們還剩下多少是真的。這條算術並不客氣。如果除了日曆之外沒有任何東西迫使它被重看，年度檢討之後一個星期發生的改動，接下來大半年都不會有人察覺；而放在整批文件上看，每份文件平均有一半的檢討周期，都在描述已經搬走了的工作。一份寫作範本對這個數字毫無影響。
所以第一件產出並不是文件，而是一份清冊：機構運作的每一條流程各佔一列，寫上一位為它的描述負責的指名人士、它被記錄到甚麼細緻程度，以及一個檢討周期。跟著才是元流程——流程文件由建立、審批、發布、培訓到廢止所走的那條路線。沒有它，每一份文件都由碰巧記得它的人維護，而一條先於它的圖表改變了之後該怎麼辦，從來沒有寫下來。
下面畫的正是那條元流程本身，而不是它所管的其中一條流程。「確認該政策的負責人」是第二列，排在任何分析開始之前。「政策是否需要修訂？」的「無需修訂」出口通往「記錄本次檢討並訂下次到期日」——一次甚麼都沒有改寫、卻仍然把日期推前了的檢討，正是一批日漸老化的文件永遠不會有的那一筆紀錄。而「退回重擬」會把審批決定送回「以追蹤修訂草擬修訂版」。
分五個階段建立元流程
一整批文件賴以運作的元流程，而不是它裏面其中一條流程。請讀它在政策發布之後還欠登記冊些甚麼。
先有負責人，後有分析
觸發是一個日曆日期或一宗事件，而下一列在讀任何東西之前先確認問責的負責人。「政策是否需要修訂？」隨後把「無需修訂」當成一個真正的結局：「記錄本次檢討並訂下次到期日」正是令登記冊對文件年齡保持誠實的那一筆。
諮詢不是客套
先以追蹤修訂草擬，再到受影響業務部門，然後是法律及監管合規性。「是否須諮詢員工代表？」會導向員工代表，而「不同意」結束於「轉入正式協商」——一個在這批文件控制範圍以外的結局，被畫了出來而不是假設不存在。
分級令董事會鬆綁
「適用哪一級審批？」三路分開，通往董事會、執行委員會和政策委員會，三條路最後都匯入「審批結果？」。它的「退回重擬」出口指回草擬那一列；「否決」把修訂擱置，讓上一個版本繼續生效。
發布要寫回登記冊
登記冊由兩列寫成：「發布新版本並公告」和「作廢並歸檔舊版本」。新的修訂版號、發布日期和下一個檢討日期全部由它們而來。一個甚麼都不寫回的發布步驟，只會留下一份自己老下去的登記冊。
發布之後的責任
一個重大性判斷決定要不要培訓，閱讀確認對著受影響員工記錄下來，而「更新例外及豁免登記冊」會捉住那些對著已經不存在的條文批出的豁免。制度收結於「修訂後政策正式生效」，不是收結於發布。
運作方式
先寫流程清冊，再畫任何圖
把機構運作的每一條流程列出來，一條佔一列，寫上一位為它的描述問責的指名人士、它應該被記錄到甚麼細緻程度，以及它有多關鍵。這張清單會比大家擔心的短，而負責人那一欄才是真正的爭論所在。那一欄仍然有空格的時候，其餘一切都建不起來。
檢討周期由變動速度而定
周期取自這條流程過去兩年實際改動過多少次，而不是取自政策上的預設值：改過三次的值得半年一檢，五年沒有動過的兩年一次就夠。把周期、下一個到期日和記錄的細緻程度都寫進清冊，這三樣就不必每次修訂都重新爭論一遍。
先把元流程畫成圖表
在為任何真實流程寫文件之前，先把你們自己那條文件路線打成一列列：甚麼觸發一次檢討、由誰確認負責人、諮詢誰、由誰審批、怎樣發布和培訓。各個階段填進「方框文字」欄，再用「連線至」欄按列號接駁起來。之後每一份文件都由它繼承。
把審批級別當成決策畫在圖上
那條分流的列「形狀」設為決策，各個級別按「連線至」裏的號碼寫進「連線文字」，好讓一次修訂的路線在草擬開始之前就已經知道。「水平泳道」欄放階段，「垂直泳道」欄放負責人，令圖表看得出政策管理部與審批機構並不是同一回事。
把退回重擬的迴路畫成一個向後的列號
把工作送回去的審批，是一個指向較早那一列的列號，不是有人事後在圖上補畫的一條箭嘴。因為「連線至」欄裝的是數據，這條迴路在它上面插入一個步驟之後依然成立。一張只有向前動作的圖，描述的是一個從來未曾反對過任何東西的審批機構。
用文件自己的日期去審視整批文件
每季數四個數字：過了檢討日期的文件、沒有指名負責人的文件、流程先於圖表改動了的文件，以及檢討過但沒有改動的紀錄。最後一項是健康指標。在收結這一次點算之前，先把下一次寫進清冊，因為一次沒有下一個日期的點算會自己失效，而整批文件會繼續衰敗下去。
應避免的錯誤
把文件工作當成一個項目
項目交付了整批文件、然後解散，而衰敗就在它結束那個星期開始。文件工作是一項有負責人、有預算科目的常設職能，否則它只是某一季的一張快照，而且老得很難看。
把提示發給一個部門
「由營運部負責」的意思，就是這個到期日不會送到任何地方。一個部門既沒有日曆，也沒有一個會回覆的收件箱，所以提示照樣產生、寄給一個職能，然後沒有任何一個具體的人讀過。
只檢討架上有的東西
檢討周期只能處理它手上那張清單，所以完全沒有文件的那些流程，正是它永遠不會浮出來的。清冊要由機構實際在做的工作建立，而不是由現存文件的資料夾建立。
改動之後好幾個星期才重寫
三月改動、五月才重新記錄的流程，錯了八個星期，而整批文件裏沒有任何東西記下這件事。把這段間隔連同日期記低；這些間隔的規律，會顯示這套制度在哪裏漏水。
建立你們的文件制度
把政策檢討示例開啟為你們自己的圖表，然後訂下這批文件將會依循的負責人、審批級別與檢討周期。
相關指南
常見問題
甚麼是流程文件管理制度？
它是一套令整批流程文件保持真確的規則與角色，與文件本身是兩回事：一份清冊，每條流程一位指名負責人，每份文件記錄到甚麼細緻程度，一個到期日真正送得到負責人手上的檢討周期，一個經過量度、顯示這批文件落後於實際工作有多快的數字，以及一條由建立、審批、發布到廢止的路線。範本反而最不重要。真正的測試是：對於一份三年沒有人碰過的文件，登記冊說得出甚麼。
一份流程清冊應該包含甚麼？
一條流程一列：流程名稱、負責人（要寫一個人而不是一個團隊）、記錄的細緻程度、關鍵程度、現行版本的存放位置，以及最後檢討與下次到期的日期。另外兩欄很快就會證明自己有價值——這條流程運行在哪些系統，它告訴你一次系統遷移會令甚麼失效；以及它為了滿足哪一條條文而存在，它告訴你審核員會要求看甚麼。清冊必須最先建立，因為之後每一個決定都是對它的一次查詢。
流程文件管理制度應該由誰負責？
由一個人負責，而且不應該是持有最多文件的那一位。制度負責人掌管清冊、元流程和檢討日期登記冊；每份文件的負責人掌管內容。把兩者合併，就會出現那個熟悉的失效模式：每一次修訂都排在唯一懂這套制度的那個人後面，而這條隊列會被報告成資源問題，而不是設計問題。只要提示是自動的、每一位負責人都是一個名字，每星期半日已經撐得起五十條流程。
流程文件應該存放在哪裏？
清冊說在哪裏就在哪裏——這正是為甚麼存放位置是清冊裏的一欄，而不是一次過為整批文件作的決定。品質管理系統、wiki 和共用磁碟各自都可以存放一個現行版本；但它們一個都答不出哪些流程根本沒有現行版本。所以測試的不是選哪個平台，而是登記冊每一列有沒有寫明它把讀者送去哪裏，以及到達之後拿到的是不是登記冊聲稱的那個版本。一條在清冊上沒有一列的流程，對任何平台選擇都是隱形的。
