Management of change (MOC) is how an organisation makes sure that a change to equipment, materials, procedures, software or staffing is reviewed for risk before it's made. A new pump with a different seal, a revised operating limit, a temporary bypass, a shift pattern change: each can introduce a hazard the original design never considered.
In process safety, MOC is a formal requirement. In the US, OSHA's Process Safety Management standard (29 CFR 1910.119) includes management of change as an element. But the logic applies to any operation where a small change can have outsized consequences.
The management of change process, step by step
1. Change request. Someone describes the proposed change, why it's needed, and whether it's permanent or temporary.
2. Classification. Is this a like-for-like replacement (usually outside MOC) or a genuine change? Getting this right keeps the process from either missing changes or drowning in trivial ones.
3. Technical and risk review. Engineering, operations and safety review the impact. For larger changes this is a formal hazard review.
4. Approval. The change owner and the required approvers sign off. Higher-risk changes need more senior approval.
5. Implementation. The change is made, and affected procedures, drawings and training are updated.
6. Pre-startup check. Before the changed system goes back into service, someone confirms the change was made as approved.
7. Close-out. Documentation is complete; temporary changes have an expiry date and are either removed or converted.
Why MOC turns into paperwork
MOC fails quietly when the steps exist on paper but nothing enforces their order. A change gets implemented while the review is still open. Training is 'to be updated'. A temporary change becomes permanent because nobody owned its expiry.
The fix is to treat each MOC as a running process: every step has one owner, approvals can only open once the reviews they depend on are signed off, and anything sitting past its target time is flagged rather than forgotten.
Run reviews in parallel, not in a queue
Engineering, operations and safety reviews rarely need to happen one after another. Running them in parallel, with approval waiting until all of them are signed off, shortens the cycle time of a change without skipping anything. It's the single easiest way to make MOC faster without making it weaker.
What to measure
Track how long changes take from request to close-out, how many are open, how many temporary changes are past their expiry, and which review step most often holds things up. Those numbers tell you whether the process is protecting the operation or just slowing it down.