變更管理流程圖（MOC、PSSR、期限）
製程安全的變更管理（MOC）流程圖：同類替換篩檢、變更分類、危害審查、授權批准、開車前安全審查（PSSR），以及臨時變更的期限循環。
運作方式
把泳道改成你們廠區的角色
把提出人、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 那筆紀錄只是排程用的產物，而不是反過來。