變更管理流程圖（MOC、PSSR、期限）
製程安全的變更管理（MOC）流程圖：同類替換篩檢、變更分類、危害審查、授權批准、開車前安全審查（PSSR），以及臨時變更的期限循環。
甚麼是變更管理流程圖（moc、pssr、期限）流程
變更管理是那種會靜靜失效的管控。沒有人會寫一份容許未經審查就動手改的 MOC 程序書；真正發生的，是流程被一個又一個小決定繞了過去。一台泵浦換成規格略有出入的型號，被當成同類替換。一條旁通軟管說好裝到下次歲修為止，四年之後仍然在那裡。變更在夜班做完，文件下星期才補，用來描述早已裝好的東西。開車前的檢查憑一次根本沒有人做過的現場走查就簽了名，因為工廠急著要復產。重大製程安全事故的調查一再落到同一個地方：問題不是甚麼罕見的未知危害，而是一套人人都知道的程序，從來沒有被套用在一項沒有人覺得算是變更的變更上。Flixborough 是每一位製程工程師都學過的案例——1974 年，兩座反應器之間臨時加裝了一段旁通管，沒有圖面、沒有計算、沒有試壓。所以 MOC 流程圖值得認真畫一次。價值不在那串人人都背得出的方框次序，而在流程必須拒絕繼續走下去的那兩三個點，以及把這些點畫給正被催促跳過它們的那一班人看。
本圖畫的是製程安全意義下的變更管理：在一座出錯就代表洩漏、火災或爆炸的廠區裡，對設備、製程、化學品、操作界限、控制系統、程序書或組織編制所做的修改。它不是資訊科技的服務變更管理，兩者不能互換。/yue/templates/變更管理流程 上那份 ITIL 形態的變更管理流程問的是停機時間、回復方案與服務風險；把一項工廠設備修改丟進去跑，你會得到一個 CAB 核准、一個變更時段，以及完全沒有危害審查。/yue/templates/變更控制流程 上的一般變更控制流程是品質系統的版本，管的是受控文件與已驗證的製程。對已發行的產品、圖面或物料清單所做的變更是工程變更，屬於 /yue/templates/工程變更申請流程 ；而對專案範圍、成本或時程的變更則屬於 /yue/templates/專案變更申請流程 。真正把原規格復原的修理是保養維修，走 /yue/templates/設備保養流程 上的設備保養流程——本圖的「是否屬同類替換？」判定，正正就是兩者之間的分界線。而如果變更是因為已經出了事才要做，那麼查出應該改甚麼的調查在 /yue/templates/工業意外調查流程 上；本流程要做的，是把議定的對策安全地裝上去。
四個決策撐起整張圖，而大部分書面程序至少會把其中兩個留作預設。「是否屬同類替換？」放在最前，在花掉任何一分錢之前，因為它決定流程到底跑不跑——而它偏偏是最常在走廊上被回答掉的一題。「永久、臨時還是緊急變更？」排第二，因為分類決定後面要跑多少流程：緊急變更得到一次加速危害審查和一個帶時限的當班授權，但它會在「更新程序書、圖面與 P&ID」處匯回主線，它一樣要走到「訓練受影響人員」，開車前它一樣要面對同一道關卡。「開車前安全審查是否通過？」被畫成一個循環而不是一格簽名，未結的事項要退回去結清，審查再做一次；沒有東西可以憑一句承諾就開車。第四個是大部分程序書索性略過的那一個。「到期時是否仍有需要？」給臨時變更兩種可能的未來——以永久變更的身分再走一次流程，或者拆除並把原狀復原。這裡刻意沒有一條「靜靜延期」的分支。
本流程圖涵蓋的內容
本範本包含
- 六條泳道——提出人、MOC 協調人、技術權責人、危害審查小組、授權主管、操作單位——鋪在六個階段上：提出、篩檢、技術審查、授權批准、準備與 PSSR，以及執行與結案。
- 第一道關卡是「是否屬同類替換？」，它安排在「在 MOC 登記冊登錄變更」之後，好讓判定結果無論走哪一邊都留在紀錄上：完全相同的替換由「按保養維修工作處理」離開流程，其餘一切都當作變更繼續往下走。
- 三分支的「永久、臨時還是緊急變更？」分類：臨時變更會多接一步「訂定期限日期與拆除計劃」，緊急變更則走一條經「進行加速危害審查」與「當班授權並訂定時限」的短路徑，之後才匯回主線。
- 危害審查按風險大小調整，由「採用哪一級危害審查？」分派——變更危害檢核表、假設情境審查，或一場完整的 HAZOP——之後接「評估對安全系統與操作界限的影響」，以及一份留下紀錄的應辦事項。
- 授權批准在「是否已在所需層級獲授權？」有三個可能的答案：已授權；不批准，走向「變更不獲批准並結案」這個終點；或者退回「記錄技術依據」再補作業。
- 兩道本圖不容許跳過的關卡：「開車前安全審查是否通過？」會一直繞經「結清 PSSR 應辦事項」直到通過為止；而「到期時是否仍有需要？」的答案只有兩個——轉為永久變更，或者拆除並復原。
何時使用本範本
- 你們要為一座受製程安全管理規範的廠區撰寫或改寫 MOC 程序書（在台灣是職業安全衛生法下的製程安全評估要求，在歐盟是 Seveso 指令，在美國是 OSHA PSM），希望把篩檢判定、審查等級與授權權限矩陣放在同一張圖裡。
- 你們的登記冊裡塞滿了沒有期限日期的臨時變更，需要把拆除還是轉永久這個判定內建入流程，而不是留給一年一次的大清理。
- 緊急變更在當班時就動手、事後才補文件，你們希望把加速路徑畫出來，讓它跑在流程之內而不是流程之外。
- 你們的開車前安全審查在應辦事項仍未結清時就被簽掉，需要把那道關卡呈現為一個會把變更退回去的循環，而不是一格打勾就過的方框。
- 你們要向工程師、值班主管與操作人員說明到底甚麼才算變更，希望同類替換的判定準則跟流程其餘部分用同一張圖來教。
運作方式
把泳道改成你們廠區的角色
把提出人、MOC 協調人、技術權責人、危害審查小組、授權主管與操作單位，換成你們廠區真實存在的角色。大部分廠區會按專業把技術權責人拆開——製程、機械、電氣、儀電控制——所以要決定那是一條泳道還是幾條。令協調人與技術權責人保持分開：一個負責運行流程、追登記冊，另一個承擔工程判斷。如果承攬商也會提出變更，就要寫明，因為一條名叫提出人、實際上只默默指自家員工的泳道，正是承攬商的修改逃出流程的方式。
把同類替換的判定準則寫下來
「是否屬同類替換？」是唯一一格可以把變更整個帶離流程的方框，所以它需要成文準則，而不是靠判斷。把同類定義為在規格、材質、等級、製造商設計意圖與安裝形態上完全相同，然後指名誰有能力做這項判定——在庫存系統上找到一個相當品，不是工程判定。停產是大部分廠區失守的地方：一旦原品項不再生產，供應商最接近的現行型號就是變更，表單應該把這一點寫明，而不是留給當下時間壓力最大的那個人去拿捏。
訂定危害審查的分派規則
把「採用哪一級危害審查？」變成一張表，而不是一場對話。低風險可能只需要兩位適任人員完成一份留有紀錄的變更檢核表。中風險是配合檢核表的假設情境或結構化假設情境分析。高風險——凡是動到化學品、連鎖、釋壓系統、控制邏輯或安全操作界限的——就送去由主持人帶領的 HAZOP，並把原本那份研究攤開在桌上。指名誰決定等級，並要求把理由記在決定旁邊。
公布授權權限矩陣
授權應該跟著危害走，而不是跟著金額走。寫下誰可以授權一項低風險的永久變更，誰必須授權任何影響安全儀控功能、釋壓計算基準或操作包絡線的變更，以及誰簽署會改動製程安全評估報告或安全報告的變更。讓「需補充作業」這個答案真的有牙齒：它把變更退回「記錄技術依據」，而不是被讓步成一個附帶條件的核准，然後那些條件事後沒有人承擔。
把 PSSR 做成一次現場走查，配一份已結清的事項清單
一場可以坐在辦公桌前完成的開車前安全審查，不是開車前安全審查。檢核表要確認施工與設計相符，操作、保養與緊急應變程序齊備而且是現行版本，將要操作該變更的人已經受訓，以及危害審查的事項是已經結清，而不是已經指派。決定誰有資格宣告通過，並讓這個人置身於做出這項變更的團隊之外；任何未結事項一律經「結清 PSSR 應辦事項」退回。
為每一個期限日期指定負責人，然後走一次圖再發佈
給每一項臨時變更一位具名的負責人，以及一個由登記冊在到期之前、而不是之後才提出的日期。然後議定臨時變更的最長壽命，以及緊急變更要在幾天還是幾星期之內重新走完整流程。最後，帶著定稿的圖與一班操作人員、一位保養主管、技術權責人以及負責授權變更的人一起走一次，按他們實際的做法改正，再發佈該版本並保留此前的版本，令日後打開它的人知道自己看的是哪一版。
常見問題
變更管理（MOC）流程包含哪些步驟？
提出變更並在 MOC 登記冊登錄；用同類替換準則篩檢，完全相同的替換以保養維修工作的身分離開流程；把餘下的分類為永久、臨時或緊急，並給臨時的一個期限日期和一份拆除計劃；記錄技術依據；按風險大小做一次危害審查，由變更檢核表、假設情境分析，一直到一場完整的 HAZOP；評估對安全系統、操作界限與安全報告的影響，並把應辦事項記下來；在危害所要求的層級取得授權；更新程序書、圖面與 P&ID；訓練所有受影響的人，包括保養人員與承攬商；通過開車前安全審查；執行變更並開車；然後結案並保存紀錄，或者，如果是限期變更，在到期時檢視它，決定轉為永久變更還是拆除。美國 OSHA 的製程安全管理標準要求書面程序必須涵蓋技術依據、對安全與健康的影響、程序書的修改、變更的有效期間，以及授權的要求；在台灣，製程安全評估相關法規同樣把製程修改（變更管理）列為必要的管理事項。本圖就是把那份清單變成一條帶關卡的路線。
甚麼才算同類替換？
同類替換是指與被替換品項在規格、材質、等級與設計意圖上完全相同的東西——同一個零件、依同一份圖面、以同樣方式安裝。其餘一切都是變更，都要進入 MOC 流程，無論它看起來多小、多便宜。這個區分之所以重要，是因為它是離開流程的唯一一個正當出口，也是大部分 MOC 制度漏水的地方。以下這些都不算同類替換，不管倉管怎麼叫它們：葉輪直徑或軸封配置不同的泵浦、換了材質的墊片、內件不同或失效位置不同的閥、重設到新壓力的釋壓閥、量程或失效模式不同的儀器，以及控制器的韌體或軟件改版。有兩條做法很管用：要求把判定連同做判定的適任人員姓名一起記錄下來；以及去稽核那些判為同類的案子，而不是只稽核變更——因為從來沒有進入流程的那些，才是沒有人在看的那些。
甚麼是開車前安全審查？何時需要做？
開車前安全審查（PSSR）是新建或經修改的設施投入運轉之前的最後一道檢查。它確認四件事：施工與設備符合設計規格；操作、保養與緊急應變程序齊備而且足夠；危害審查已經完成，其建議事項已解決或已落實；以及所有將要操作或保養該變更的人都已受訓。依美國 OSHA 的製程安全管理標準，新設施必須做 PSSR，而經修改的設施，若修改幅度大到需要更動製程安全資訊，同樣必須做。它之所以被畫成一個帶循環的決策而不是一格簽名，是因為這是商業壓力最大的一道關卡：變更已經做好，停車期已經結束，工廠等著復產。在本圖裡，仍有未結事項的審查會退回「結清 PSSR 應辦事項」，然後重做一次；唯一的去路就是穿過它。
臨時變更可以留多久？
只能留到授權當時議定的期限日期為止——這正是為甚麼日期要在分類階段訂定，而不是留待日後再說。很多廠區把臨時變更的上限訂在下一次計劃停車，或者一段固定期間例如六個月，並要求任何超過上限的變更，必須以永久變更的身分走完整流程重新授權。失效的模式眾所周知，而且始終如一：一項臨時修改在壓力下裝了上去，壓力過去了，沒有人承擔拆除，圖面上畫的仍然是原本的配置，多年之後有人照著一份早已不再描述這座工廠的圖去規劃隔離。有兩件事可以阻止它。每一項臨時變更都有一位具名的負責人，而不是一個部門；而且登記冊在期限日期之前就提出檢視，而不是事後才報告逾期。在本圖裡，「到期時是否仍有需要？」正好只有兩條分支——轉為永久變更，或者拆除並把原狀復原。靜靜延期不在選項之列。
製程安全的變更管理與 IT 變更管理流程有甚麼不同？
兩者共用一個詞，其餘幾乎毫無共通之處，而把其中一個當成另一個的替代品，本身就是一項實在的危害。IT 變更管理，也就是 /yue/templates/變更管理流程 上那份 ITIL 意義下的變更管理流程圖所涵蓋的，管的是對一項運行中服務的變更。它問的是：這項變更會不會造成中斷、能不能回復、變更時段在甚麼時候、CAB 有沒有核准。製程安全意義下的變更管理，管的是在一座會傷到人的廠區裡，對設備、化學品、操作界限、控制系統、程序書與人力編制的修改。它問的是：這項變更有沒有改變某項危害、釋壓計算或連鎖是否仍然成立、安全報告是否仍然有效、操作人員在開車之前有沒有受訓。這些問題，CAB 一條都沒有能力回答。兩套流程確實有一個值得指明的重疊之處：控制系統或安全儀控系統的變更，往往是在 IT 或自動化的變更隊列裡提出的，但它同時必須走 MOC。遇到這種情況，要讓 MOC 成為權威，IT 那筆紀錄只是排程用的產物，而不是反過來。
此流程所處的位置
在大多數機構中，此流程緊接工業意外調查流程圖（由現場到控制措施）之後。
前置流程
- 工業意外調查流程圖（由現場到控制措施） — 工業意外調查流程圖：保護現場、評定潛在嚴重程度、向監管機構呈報、收集證據、分開會見目擊者、追查至組織層面的成因，並核實控制措施。