政策檢討審批流程圖（由觸發到閱讀確認）

運作方式

1. 把泳道改成你們的管治架構

   把政策管理部、政策負責人、受影響業務部門、法律及合規、員工代表與審批機構，換成你們真實擁有的角色與組織。即使政策管理部只得一個人，也要令它與政策負責人保持分開：一個跑循環、管登記冊，另一個對內容負責、為這次改動辯護。如果你們並沒有勞資會議、亦沒有獲承認的工會，就把員工代表那條泳道連同引向它的判斷一併刪掉，而不是在圖裡留一個從不做事的組織。

2. 把觸發條件清單寫入政策管理框架

   按日曆觸發很容易；事後引起爭論的是事件觸發。把它們在框架文件裡逐條列明：法律或法規修訂、一次監管執法行動、一宗嚴重事故、一條內部或外部審核發現、營運模式的重大改變、一次架構重組，以及一次收購。寫明誰有權把檢討提前抽出來、以及怎樣抽，因為一次要靠某個人碰巧看到新聞才發生的計劃外檢討，算不上一項管控措施。然後在你們跑的每一次檢討上，都記錄是哪一項條件觸發的。

3. 在需要用到之前就把審批級別定下來

   趁現在沒有任何修訂在辦，先給登記冊裡每一份政策標上它的級別和具名的審批機構——等修訂稿已經草擬出來才去定級別，會把一個管治問題變成一場排會議的爭論。第一級怎樣判，請去讀董事會保留事項清單，而不是從主題上猜。然後把大部分框架漏掉的兩件事寫下來：誰可以把一次修訂在級別之間移動，以及當審批機構在生效日期之前開不到會時，授權審批應該是甚麼樣子。第二個缺口，正是未獲批准的政策悄悄生效的地方。

4. 界定甚麼算重大變更

   「是否屬須培訓的重大變更？」在你寫下判定準則之前是空的。重大，意味著這次改動改變了某個人必須做甚麼：一項新增責任、一個被調低的門檻、一條新的禁止規定、一條不同的匯報路線。它不意味著一個部門改了名，或者一處交叉引用被更正。這件事判錯了，兩個方向的代價都很高——拿雞毛蒜皮去培訓，只會教會大家一路按「下一頁」；而一次無聲的重大變更，會令員工理直氣壯地繼續按舊做法做。讓政策負責人提出答案，並由審批機構在審批時一併確認。

5. 決定閱讀確認與豁免怎樣追蹤

   從人力資源系統這類權威資料來源去圈定受影響人群，而不是從一份電郵群組名單；訂一個限期；透過直屬主管去追沒有回應的人；並把完成率歸檔到它所對應的那一版政策上——一個不帶版本的確認率甚麼都證明不了。然後把例外登記冊當成這次發布的一部分，而不是事後才補做的收尾工作。給它指定一位具名負責人，要求每一項豁免都帶到期日、批核人，以及它所依賴的補償性管控措施，並在這次修訂生效之前，把仍然存活的那些重新指向新的條文編號。

6. 走一遍，然後發布一個版本

   把畫好的圖拿給泳道裡的那些人——政策負責人、管登記冊的那位、一位法律審閱人，以及審批機構的秘書——用一份真實的政策由頭到尾走一遍，包括一次甚麼都沒有改的檢討。按他們實際的做法去改圖，而不是按框架上寫的。然後把這一版發布出去，並在它上面記錄一次審批，同時保留此前的版本，好讓這個用來檢討政策的流程本身，亦處於它對其他一切所要求的版本控制之下。

常見問題

政策檢討審批流程包含哪些步驟？

由政策本身寫明的到期日、或者由一件先於它發生的事件觸發檢討。確認誰是當責的負責人，因為架構重組會令政策變成無人認領。把現行文本對照觸發原因做差距分析，判斷是否需要修訂。如果不需要，就記錄本次檢討並訂下一個到期日。如果需要，就在已批准的版本上以追蹤修訂草擬修訂版，向該條文所管轄的業務部門諮詢，做法律及合規審核，並在勞資會議或獲承認工會持有諮詢或協商權利的地方，把這項改動交到員工代表那裡。修改草稿，提交到這份政策所屬的審批級別，並記錄決定。然後發布一個帶版本號和生效日期的新版，公告改了甚麼，收回並歸檔被取代的版本，在改動屬於重大時提供培訓，向受影響員工收集閱讀確認，並按新的條文編號更新例外登記冊。

政策應該多久檢討一次？

承載法律或監管責任的政策、以及一切由董事會持有的政策，每年一次；其餘大部分每兩年一次；而只要有事件先於日曆發生，就即時檢討。固定周期並不是重點——事件觸發才是。一份在法例修訂前一個月剛按計劃檢討過的政策，下一個星期就已經過時，真正要緊的是那次計劃外的檢討。周期要逐份政策分別訂定，而不是給整套體系訂一個；把它寫在政策本身上；並放進一本對每一條目都顯示下次日期、而不只是顯示上次日期的登記冊裡。還有兩點很實際。把日期錯開，好讓審批機構不會在一個季度裡收到四十份政策。以及在真的遇到之前，就先決定檢討逾期意味著甚麼：政策不會因為檢討日期過去就自動失效，它仍然有效，所以逾期條目必須在登記冊裡看得見，並呈報到負責人的上級那裡，而不是被維護清單的人悄悄改個日期。

政策應該由誰批准？

由承載這份政策所表達的那份責任的組織來批准——這也是為甚麼一位名義上的審批人很少能撐起整套體系。本圖通向三個。訂定風險胃納、履行法定責任或者對外約束機構的政策，交董事會。具跨部門影響的政策——開支怎樣申報、個人資料怎樣處理、供應商怎樣合作——交由相關職能都有代表在場的執行委員會。其餘的，由持有董事會授權的政策委員會批准。提前在登記冊裡給每一份政策標上級別，好讓路線在草擬之前就已經確定，而不是在提交時才爭。而且無論機構多小，都要令負責人與審批人分開：一份由同一個人草擬、擁有並批准的政策，從來沒有經過第二雙眼睛；而當一份政策最後被發現與法定責任或者已簽合約相抵觸時，第一件被檢驗的就是這一點。

本頁與文件管制流程圖有甚麼不同？

兩者處在不同的層級。/yue/templates/文件管制流程 上的文件管制流程圖，是每一份受控文件都要走的生命週期——變更申請、草擬、審閱、審批、版本編號、發放、分發、已作廢副本的收回與定期檢討——由一位文件管理員來跑。本頁則是一份政策的管治循環，並且假定那套文件管制機制就在它下面。它多出來的是政策所特有的那部分：一次能在架構重組之後抓住無人認領情況的負責人核對、對照觸發原因的差距分析、勞資會議與工會的諮詢、由董事會或執行委員會或政策委員會分級審批、受影響人群的閱讀確認，以及在條文位置變動之後必須重新確認的例外登記冊。如果你們要的是單次審批內部的路由判定，請用 /yue/templates/文件審批工作流程。另外請留意它與標準作業程序的分別：政策是一種按日曆檢討的管治工具，不論有沒有變化都要檢討；而 /yue/templates/受控標準作業程序範本 上的標準作業程序是一份作業指引，工作變了才修訂。

如果政策檢討的結論是無需修訂，會怎麼樣？

它仍然必須被記錄下來，而這正是大部分框架跳過的那一半流程。在本圖裡，「政策是否需要修訂？」的「無需修訂」分支不會無聲退出；它終止於「記錄本次檢討並訂下次到期日」。這份紀錄應該寫明誰檢討的、對照甚麼檢討的——現行法規、事故歷史、上次檢討以來的審核發現——檢討日期，以及下次到期日。亦可以選擇以同一版本重新發放並只更新檢討日期，而不遞增版本號，這樣文件歷史就不會被一堆甚麼都沒改的修訂塞滿。之所以要緊，是因為認證審核與監管檢查抽查的是檢討的證據，而不是修改的證據。一份內容在三年之後依然確實正確的政策，是一個好結果；一份因為沒有人登記過檢討、於是看上去三年無人問津的政策，則是一條不符合事項——而從登記冊上看，這兩者無法區分。