政策檢討審批流程圖（由觸發到閱讀確認）
政策檢討審批流程圖：按到期日或事件觸發、確認負責人、差距分析、諮詢、法律與員工代表審核、分級審批、發布與閱讀確認。
甚麼是政策檢討審批流程圖（由觸發到閱讀確認）流程
大部分政策體系不是轟然失效，而是無聲失效。政策都在，當初亦有人批准過，登記冊上甚至還寫著檢討日期——但其中三分之一已經逾期，好幾份的負責人在一次架構重組中早已離職，而內聯網上掛的那一版，跟入職資料包裡的那一版並不是同一版。原因很少是沒有人在乎政策，而是一次檢討被當成改文件的工作，而不是一個有觸發、有負責人、有決定、有紀錄的管治循環。有兩個徵狀可以直接確診。第一個是一次沒有產生任何改動、亦沒有留下任何痕跡的檢討，於是一份被讀過、亦被確認仍然正確的政策，看上去像是六年無人碰過。第二個是一次批准了、亦發布了，卻始終沒有落地的修訂：沒有人記得有過甚麼公告，沒有閱讀確認，而豁免仍然掛在已經不存在的條文編號上。這兩件都不是文字功夫的問題。它們都是文件周圍那個循環的失效：沒有人被指定去跑這個循環，沒有東西記錄它決定了甚麼，亦沒有一個步驟去跟這份政策所約束的那些人收上閉環。
本圖是一份政策的管治循環，畫在五個階段和六條泳道上。它不是通用的受控文件生命週期：版本編號、發放、分發、已作廢副本的收回，以及各類受控文件的定期檢討，屬於 /yue/templates/文件管制流程 上的文件管制流程圖；本頁假定那套機制已經存在，並且直接呼叫它。它亦不是單份草稿的路由判定——哪些審閱人是必審的、甚麼算編輯性修改、甚麼時候需要第二審批人，由 /yue/templates/文件審批工作流程 上的文件審批工作流程講得細緻得多。它更加不是一次標準作業程序的修訂。政策是一種管治工具：它訂明機構要求甚麼，由董事會或行政層面持有，並且不論有沒有變化，都會按日曆回到眼前。而標準作業程序是一份作業指引，工作變了它才變——這正是 /yue/templates/受控標準作業程序範本 上那份受控 SOP 範本圍繞活動本身、而不是圍繞檢討日期來搭建的原因。觸發一次政策檢討的發現，往往來自 /yue/templates/內部審核流程 上的內部審核流程：那一頁講一條發現是怎樣被提出來的，本頁講政策負責人拿到它之後做甚麼。
大部分成文的政策管理辦法留作預設的三件事，在這裡被明確畫成了分支。「政策是否需要修訂？」帶著一條不會就此停住的「無需修訂」通道：它終止於「記錄本次檢討並訂下次到期日」，因為一次沒有產生修訂的檢討仍然是一次檢討，而這恰恰是認證審核員會去抽查的東西。「適用哪一級審批？」是在修訂稿提交之前就回答的，而不是等它在錯誤的會議議程上躺了一個月之後；而且它通向三個不同的機構，而不是一位名義上的審批人。「是否須諮詢員工代表？」則是一條有真實出口的真實分叉。凡是勞資會議或獲承認工會持有諮詢或協商權利的政策，草案都要交到員工代表那裡，而「員工代表是否同意？」會被留在紀錄上；它的「不同意」分支不會把草案退回去再改一遍，而是把這項改動轉入一場有自己時間表的協商，這就是「轉入正式協商」離開本流程、而不是繞回去的原因。發布階段被刻意畫得比大部分辦法寫的更長——公告、作廢舊版、判斷這次改動是否重大到需要培訓、閱讀確認、更新豁免登記冊——因為失效真正發生的地方就在這裡。
本流程圖涵蓋的內容
本範本包含
- 六條泳道——政策管理部、政策負責人、受影響業務部門、法律及合規、員工代表與審批機構——鋪在五個階段上：觸發與界定、差距分析、草擬與諮詢、審批，以及發布與確認。
- 觸發要麼是政策本身寫明的檢討到期日，要麼是一件先於它發生的事件，隨後是「確認該政策的負責人」——正是這一步，在任何草擬開始之前就抓住那些因架構重組而無人認領的政策。
- 「政策是否需要修訂？」由一次明確的差距分析來回答，其「無需修訂」分支仍然收尾於「記錄本次檢討並訂下次到期日」，好讓一份無需修改的政策永遠不會看上去像沒被檢討過。
- 諮詢被拆到三條泳道上：「諮詢受影響業務部門」、「法律及監管合規性審核」，以及一道把草案導向員工代表的「是否須諮詢員工代表？」判斷——在那裡，「員工代表是否同意？」要麼把草案送回「按諮詢意見修改草稿」，要麼在「轉入正式協商」處離開，而不是繞回來。
- 「適用哪一級審批？」分出第一級（董事會）、第二級（執行委員會）與第三級（政策委員會），三條路匯合於三選一的「審批結果？」——批准，退回重擬回到草擬，或者否決，終止於「修訂撤回並擱置」。
- 一個發布階段，裡面是各種辦法通常預設存在的那些步驟：「發布新版本並公告」、「作廢並歸檔舊版本」、一道「是否屬須培訓的重大變更？」判斷、「記錄受影響員工的閱讀確認」、「更新例外及豁免登記冊」，以及終點「修訂後政策正式生效」。
何時使用本範本
- 你們要編寫或重建一套政策體系，需要用一張圖說清楚誰觸發檢討、誰負責內容、必須諮詢誰，以及由誰簽批。
- 你們的政策登記冊上還寫著上一次架構重組中已經離職的負責人，檢討日期兩年前就已經過去，而你們希望把負責人核對和「無需修訂」的紀錄內建入循環，而不是靠電郵去追。
- 一條審核發現、一次法規改動或一次架構重組剛剛逼出一次計劃外檢討，而你們希望它走的路，跟計劃內檢討是同一條。
- 本應由政策委員會解決的修訂一次又一次送到董事會，而你們需要在提交之前就定好級別，而不是在會議上爭。
- 你們發布了修訂後的政策，卻拿不出誰已經讀過的證據；又或者發現還有豁免掛在兩個版本之前就已經刪掉的條文上。
運作方式
把泳道改成你們的管治架構
把政策管理部、政策負責人、受影響業務部門、法律及合規、員工代表與審批機構，換成你們真實擁有的角色與組織。即使政策管理部只得一個人，也要令它與政策負責人保持分開：一個跑循環、管登記冊，另一個對內容負責、為這次改動辯護。如果你們並沒有勞資會議、亦沒有獲承認的工會，就把員工代表那條泳道連同引向它的判斷一併刪掉，而不是在圖裡留一個從不做事的組織。
把觸發條件清單寫入政策管理框架
按日曆觸發很容易；事後引起爭論的是事件觸發。把它們在框架文件裡逐條列明：法律或法規修訂、一次監管執法行動、一宗嚴重事故、一條內部或外部審核發現、營運模式的重大改變、一次架構重組，以及一次收購。寫明誰有權把檢討提前抽出來、以及怎樣抽，因為一次要靠某個人碰巧看到新聞才發生的計劃外檢討，算不上一項管控措施。然後在你們跑的每一次檢討上，都記錄是哪一項條件觸發的。
在需要用到之前就把審批級別定下來
趁現在沒有任何修訂在辦，先給登記冊裡每一份政策標上它的級別和具名的審批機構——等修訂稿已經草擬出來才去定級別，會把一個管治問題變成一場排會議的爭論。第一級怎樣判，請去讀董事會保留事項清單，而不是從主題上猜。然後把大部分框架漏掉的兩件事寫下來：誰可以把一次修訂在級別之間移動，以及當審批機構在生效日期之前開不到會時，授權審批應該是甚麼樣子。第二個缺口，正是未獲批准的政策悄悄生效的地方。
界定甚麼算重大變更
「是否屬須培訓的重大變更？」在你寫下判定準則之前是空的。重大，意味著這次改動改變了某個人必須做甚麼：一項新增責任、一個被調低的門檻、一條新的禁止規定、一條不同的匯報路線。它不意味著一個部門改了名，或者一處交叉引用被更正。這件事判錯了，兩個方向的代價都很高——拿雞毛蒜皮去培訓，只會教會大家一路按「下一頁」；而一次無聲的重大變更，會令員工理直氣壯地繼續按舊做法做。讓政策負責人提出答案，並由審批機構在審批時一併確認。
決定閱讀確認與豁免怎樣追蹤
從人力資源系統這類權威資料來源去圈定受影響人群，而不是從一份電郵群組名單；訂一個限期；透過直屬主管去追沒有回應的人；並把完成率歸檔到它所對應的那一版政策上——一個不帶版本的確認率甚麼都證明不了。然後把例外登記冊當成這次發布的一部分，而不是事後才補做的收尾工作。給它指定一位具名負責人，要求每一項豁免都帶到期日、批核人，以及它所依賴的補償性管控措施，並在這次修訂生效之前，把仍然存活的那些重新指向新的條文編號。
走一遍，然後發布一個版本
把畫好的圖拿給泳道裡的那些人——政策負責人、管登記冊的那位、一位法律審閱人，以及審批機構的秘書——用一份真實的政策由頭到尾走一遍，包括一次甚麼都沒有改的檢討。按他們實際的做法去改圖，而不是按框架上寫的。然後把這一版發布出去，並在它上面記錄一次審批，同時保留此前的版本，好讓這個用來檢討政策的流程本身，亦處於它對其他一切所要求的版本控制之下。
常見問題
政策檢討審批流程包含哪些步驟？
由政策本身寫明的到期日、或者由一件先於它發生的事件觸發檢討。確認誰是當責的負責人，因為架構重組會令政策變成無人認領。把現行文本對照觸發原因做差距分析，判斷是否需要修訂。如果不需要，就記錄本次檢討並訂下一個到期日。如果需要，就在已批准的版本上以追蹤修訂草擬修訂版，向該條文所管轄的業務部門諮詢，做法律及合規審核，並在勞資會議或獲承認工會持有諮詢或協商權利的地方，把這項改動交到員工代表那裡。修改草稿，提交到這份政策所屬的審批級別，並記錄決定。然後發布一個帶版本號和生效日期的新版，公告改了甚麼，收回並歸檔被取代的版本，在改動屬於重大時提供培訓，向受影響員工收集閱讀確認，並按新的條文編號更新例外登記冊。
政策應該多久檢討一次？
承載法律或監管責任的政策、以及一切由董事會持有的政策，每年一次；其餘大部分每兩年一次；而只要有事件先於日曆發生，就即時檢討。固定周期並不是重點——事件觸發才是。一份在法例修訂前一個月剛按計劃檢討過的政策，下一個星期就已經過時，真正要緊的是那次計劃外的檢討。周期要逐份政策分別訂定，而不是給整套體系訂一個；把它寫在政策本身上；並放進一本對每一條目都顯示下次日期、而不只是顯示上次日期的登記冊裡。還有兩點很實際。把日期錯開，好讓審批機構不會在一個季度裡收到四十份政策。以及在真的遇到之前，就先決定檢討逾期意味著甚麼：政策不會因為檢討日期過去就自動失效，它仍然有效，所以逾期條目必須在登記冊裡看得見，並呈報到負責人的上級那裡，而不是被維護清單的人悄悄改個日期。
政策應該由誰批准？
由承載這份政策所表達的那份責任的組織來批准——這也是為甚麼一位名義上的審批人很少能撐起整套體系。本圖通向三個。訂定風險胃納、履行法定責任或者對外約束機構的政策，交董事會。具跨部門影響的政策——開支怎樣申報、個人資料怎樣處理、供應商怎樣合作——交由相關職能都有代表在場的執行委員會。其餘的，由持有董事會授權的政策委員會批准。提前在登記冊裡給每一份政策標上級別，好讓路線在草擬之前就已經確定，而不是在提交時才爭。而且無論機構多小，都要令負責人與審批人分開：一份由同一個人草擬、擁有並批准的政策，從來沒有經過第二雙眼睛；而當一份政策最後被發現與法定責任或者已簽合約相抵觸時，第一件被檢驗的就是這一點。
本頁與文件管制流程圖有甚麼不同？
兩者處在不同的層級。/yue/templates/文件管制流程 上的文件管制流程圖，是每一份受控文件都要走的生命週期——變更申請、草擬、審閱、審批、版本編號、發放、分發、已作廢副本的收回與定期檢討——由一位文件管理員來跑。本頁則是一份政策的管治循環，並且假定那套文件管制機制就在它下面。它多出來的是政策所特有的那部分：一次能在架構重組之後抓住無人認領情況的負責人核對、對照觸發原因的差距分析、勞資會議與工會的諮詢、由董事會或執行委員會或政策委員會分級審批、受影響人群的閱讀確認，以及在條文位置變動之後必須重新確認的例外登記冊。如果你們要的是單次審批內部的路由判定，請用 /yue/templates/文件審批工作流程。另外請留意它與標準作業程序的分別：政策是一種按日曆檢討的管治工具，不論有沒有變化都要檢討；而 /yue/templates/受控標準作業程序範本 上的標準作業程序是一份作業指引，工作變了才修訂——如果你們真正想要的是 ISO 9001 第 7.5 條那個版本控制角度，而不是這個管治循環，請見 /yue/guides/iso9001品質管理系統的文件版本控制。
如果政策檢討的結論是無需修訂，會怎麼樣？
它仍然必須被記錄下來，而這正是大部分框架跳過的那一半流程。在本圖裡，「政策是否需要修訂？」的「無需修訂」分支不會無聲退出；它終止於「記錄本次檢討並訂下次到期日」。這份紀錄應該寫明誰檢討的、對照甚麼檢討的——現行法規、事故歷史、上次檢討以來的審核發現——檢討日期，以及下次到期日。亦可以選擇以同一版本重新發放並只更新檢討日期，而不遞增版本號，這樣文件歷史就不會被一堆甚麼都沒改的修訂塞滿。之所以要緊，是因為認證審核與監管檢查抽查的是檢討的證據，而不是修改的證據。一份內容在三年之後依然確實正確的政策，是一個好結果；一份因為沒有人登記過檢討、於是看上去三年無人問津的政策，則是一條不符合事項——而從登記冊上看，這兩者無法區分。
此流程所處的位置
在大多數機構中，此流程緊接內部審核流程圖範本之後。
它是文件管制中的其中一個步驟。
第 1 步: 文件管制流程圖
第 2 步: 文件版本控制範本
第 3 步: 文件審批工作流程決策樹
第 4 步: 文件變更控制流程圖
文件變更控制流程圖，涵蓋小改／大改分類、審閱人的影響評估、審批、加蓋版本印記、更新分發清單，以及正式把上一版本標示為作廢。
第 5 步: 政策檢討審批流程圖（由觸發到閱讀確認） 當前位置
政策檢討審批流程圖：按到期日或事件觸發、確認負責人、差距分析、諮詢、法律與員工代表審核、分級審批、發布與閱讀確認。