Management of change process flowchart (MOC, PSSR, expiry)
A management of change (MOC) process flowchart for process safety: replacement-in-kind screening, classification, hazard review, authorisation, PSSR before start-up, and the temporary-change expiry loop.
How it works
Rename the lanes to your site
Replace Originator, MOC coordinator, Technical authority, Hazard review team, Authorising manager and Operations with the roles your site really has. Most sites split the technical authority by discipline — process, mechanical, electrical, control and instrumentation — so decide whether that is one lane or several. Keep the coordinator separate from the technical authority: one runs the process and chases the register, the other owns the engineering judgement. If contractors originate changes, say so, because a lane called Originator that quietly means employees only is how contractor modifications escape the process.
Write the replacement-in-kind test down
"Replacement in kind?" is the one box that can take a change out of the process altogether, so it needs written criteria rather than judgement. Define in kind as identical in specification, material, rating, manufacturer's design intent and installed configuration, then name who is competent to apply that test — finding an equivalent part on the stores system is not an engineering determination. Obsolescence is where most sites lose it: once the original item is no longer made, the supplier's nearest current model is a change, and the form should say so rather than leave it to the person under the most time pressure.
Set the hazard review routing rule
Turn "What level of hazard review?" into a table rather than a conversation. Low risk might be a documented change checklist completed by two competent people. Medium risk is a what-if or structured what-if with a checklist. High risk — anything touching a chemical, an interlock, a relief system, a control philosophy or a safe operating limit — goes to a facilitated HAZOP with the original study open in front of the team. Name who decides the level, and require the reason to be recorded next to the decision.
Publish the authorisation matrix
Authorisation should follow the hazard, not the cost. Write down who may authorise a low-risk permanent change, who must authorise anything affecting a safety instrumented function, a relief case or an operating envelope, and who signs a change that alters the COMAH safety report or the safety case. Give "More work needed" real teeth as an answer: it returns the change to "Document the technical basis" rather than being conceded as a conditional approval whose conditions nobody afterwards owns.
Make the PSSR a walkdown with a closed action list
A pre-startup safety review that can be completed at a desk is not one. The checklist should confirm that construction matches the design, that operating, maintenance and emergency procedures are in place and current, that the people who will run the change have been trained, and that the hazard review actions are closed rather than assigned. Decide who is allowed to declare a pass, keep that person outside the team that built the change, and route any outstanding action back through "Close out the PSSR actions".
Own every expiry date, then walk the chart through and publish it
Give each temporary change a named owner and a date the register raises before it arrives, not after. Then agree what the maximum life of a temporary change is, and whether an emergency change re-enters the full process in days or weeks. Finally, walk the finished chart through with an operations shift, a maintenance supervisor, the technical authority and whoever authorises changes, correct it to what they actually do, and publish that revision while keeping the earlier ones, so anyone opening it later knows which version they are reading.
Frequently asked questions
What are the steps in a management of change (MOC) process?
Propose the change and log it in the MOC register; screen it against the replacement-in-kind test, so identical replacements leave as maintenance work; classify what remains as permanent, temporary or emergency, and give the temporary ones an expiry date and a removal plan; document the technical basis; run a hazard review sized to the risk, from a change checklist through a what-if study to a full HAZOP; assess the impact on safety systems, operating limits and the safety case, and record the actions; authorise at the level the hazard demands; update procedures, drawings and P&IDs; train everyone affected, including maintenance and contractors; pass a pre-startup safety review; implement and start up; then close out with records retained, or, for a time-limited change, review it at expiry and either convert it to a permanent change or remove it. Under OSHA's process safety management standard the written procedure has to cover the technical basis, the safety and health impact, procedure changes, the time period of the change and the authorisation requirements — this chart is that list turned into a route with gates.
What counts as a replacement in kind?
A replacement in kind is an item that is identical to the one it replaces in specification, material, rating and design intent — the same part, to the same drawing, installed the same way. Anything else is a change and enters the MOC process, no matter how small or cheap it looks. The distinction matters because it is the only legitimate exit from the process, and it is where most MOC systems leak. Common examples that are not in kind, whatever the storeman calls them: a pump with a different impeller diameter or seal arrangement, a gasket in a substitute material, a valve with different trim or a different fail position, a relief valve reset to a new pressure, an instrument with a different range or failure mode, and a firmware or software version change in a controller. Two practical rules help: require the determination to be recorded with the name of the competent person who made it, and audit the in-kind decisions rather than only the changes, because the ones that never entered the process are the ones nobody is looking at.
What is a pre-startup safety review and when is one needed?
A pre-startup safety review, or PSSR, is the last check before a new or modified installation is put into service. It confirms four things: that construction and equipment match the design specification, that operating, maintenance and emergency procedures are in place and adequate, that the hazard review has been completed and its recommendations resolved or implemented, and that everyone who will operate or maintain the change has been trained. Under OSHA's process safety management standard a PSSR is required for new facilities and for modified facilities where the modification was significant enough to require a change to the process safety information. The reason it is drawn as a decision with a loop rather than a signature box is that this is the gate under the most commercial pressure: the change is built, the outage is over and the plant is wanted back. In this chart a review with actions outstanding returns to "Close out the PSSR actions" and is taken again, so the only way onward is through it.
How long can a temporary change stay in place?
Only as long as the expiry date agreed when it was authorised, which is why the date is set at classification rather than left to be decided later. Many sites cap temporary changes at the next planned shutdown or at a fixed period such as six months, and require anything that outlives its cap to be re-authorised as a permanent change through the full process. The failure mode is well known and consistent: a temporary modification is fitted under pressure, the pressure passes, nobody owns the removal, the drawings still show the original arrangement, and years later somebody plans an isolation from a drawing that no longer describes the plant. Two things prevent it. Every temporary change has a named owner rather than a department, and the register raises the review before the expiry date rather than reporting the breach afterwards. In this chart "Still needed at the expiry date?" has exactly two branches — convert it to a permanent change, or remove it and restore the original condition. Silent extension is not one of the options.
How is management of change different from the IT change management process?
They share a word and almost nothing else, and treating one as a substitute for the other is a genuine hazard. IT change management, in the ITIL sense covered by the change management process flowchart at /templates/change-management-process, governs changes to a live service. It asks whether the change will cause an outage, whether it can be rolled back, when the change window is, and whether the CAB has approved it. Management of change in the process-safety sense governs modifications to plant, chemicals, operating limits, control systems, procedures and staffing at a site that can hurt people. It asks whether the change alters a hazard, whether a relief case or an interlock still holds, whether the safety case is still valid, and whether the operators have been trained before start-up. A CAB has no competence to answer any of those. The two processes do overlap in one place worth naming: a control system or safety instrumented system change is often raised in an IT or automation change queue and must also run through MOC. Where that happens, make the MOC the authority and the IT record the scheduling artefact, not the other way round.