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.
What the management of change process flowchart (moc, pssr, expiry) process is
Management of change is the control that fails quietly. Nobody writes an MOC procedure that permits an unreviewed modification; what happens instead is that the process gets routed around one small decision at a time. A pump is replaced with a slightly different one and called like-for-like. A bypass hose is fitted until the next shutdown and is still there four years later. A change is made on nights and the paperwork is raised the following week to describe what is already installed. A pre-startup check is signed on the strength of a walkdown nobody did, because the plant was needed back. Investigations into major process-safety incidents keep landing in the same place: not an exotic unknown hazard, but a known process that was never applied to a change nobody thought counted as a change. Flixborough is the case every process engineer is taught (a temporary bypass pipe fitted between two reactors with no drawing, no calculation and no pressure test). That is why an MOC flowchart is worth drawing properly. The value is not in the sequence of boxes, which everybody already knows, but in the two or three points where the process has to refuse to continue, and in making those points visible to the shift that is under pressure to skip them.
This chart is process-safety management of change: a modification to plant, process, chemicals, operating limits, control systems, procedures or organisation at a site where getting it wrong means a release, a fire or an explosion. It is not IT service change management, and the two are not interchangeable. The ITIL-shaped change management process at /templates/change-management-process asks about downtime, rollback and service risk; run a plant modification through it and you get a CAB approval, a change window and no hazard review at all. The general change control process at /templates/change-control-process is the quality-system version, governing controlled documents and validated processes. A change to a released product, drawing or bill of materials is an engineering change and lives at /templates/engineering-change-request-process, while a change to a project's scope, cost or dates belongs at /templates/project-change-request-process. Repairs that genuinely restore the original specification are maintenance and run through /templates/equipment-maintenance-process, the "Replacement in kind?" decision here is exactly the boundary between the two. And if the change is being made because something has already gone wrong, the investigation that works out what to change is at /templates/safety-incident-investigation-process; this process is what gets the agreed fix installed safely.
Four decisions carry the chart, and most written procedures leave at least two of them implicit. "Replacement in kind?" is placed first, before anything is spent, because it decides whether the process runs at all, and it is the question most often answered in a corridor. "Permanent, temporary or emergency?" comes second, because the classification determines how much process follows: an emergency change gets an expedited hazard review and an on-shift authorisation carrying a time limit, but it rejoins the main route at "Update procedures, drawings and P&IDs", it still reaches "Train the affected personnel", and it still faces the same gate before start-up. "Pre-startup safety review passed?" is drawn as a loop rather than a signature, so outstanding actions go back to be closed and the review is taken again; nothing starts up on a promise. The fourth is the one most procedures omit entirely. "Still needed at the expiry date?" gives a temporary change two possible futures: back through the process as a permanent change, or removed with the original condition restored. There is deliberately no branch for quietly extending it.
What this flowchart covers
In this template
- Six swimlanes (Originator, MOC coordinator, Technical authority, Hazard review team, Authorising manager and Operations) across six phases: Request, Screening, Technical review, Authorisation, Preparation and PSSR, and Implementation and close-out.
- "Replacement in kind?" as the first gate, taken after "Log the change in the MOC register" so that the determination is on the record either way: an identical replacement leaves at "Handled as maintenance work", and everything else carries on as a change.
- A three-way "Permanent, temporary or emergency?" classification, where temporary changes pick up "Set the expiry date and removal plan" and emergency changes take a short route through "Carry out an expedited hazard review" and "Authorise on shift and set a time limit" before rejoining the main route.
- Hazard review scaled to the risk at "What level of hazard review?" (a change hazard checklist, a what-if review or a full HAZOP) followed by "Assess impact on safety systems and limits" and a recorded set of actions.
- Authorisation with three possible answers at "Authorised at the required level?": authorised, refused to a closed "Change refused and closed" terminator, or returned to "Document the technical basis" for more work.
- The two gates the chart will not let you skip: "Pre-startup safety review passed?", which loops through "Close out the PSSR actions" until it passes, and "Still needed at the expiry date?", whose only answers are conversion to a permanent change or removal and restoration.
When to use this template
- You are writing or rewriting an MOC procedure for a COMAH, Seveso or OSHA PSM site and want the screening test, the review levels and the authorisation matrix in one picture.
- Your register is full of temporary changes with no expiry date, and you need the remove-or-convert decision built into the process rather than left to an annual tidy-up.
- Emergency changes are being made on shift and written up afterwards, and you want the expedited route drawn so that it runs inside the process instead of around it.
- Your pre-startup safety reviews are being signed off with actions still open, and you need that gate shown as a loop that sends the change back rather than a box that gets ticked.
- You are training engineers, shift managers and operators on what actually counts as a change, and want the replacement-in-kind test taught from the same diagram as the rest of the process.
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.
Where this process fits
In most operations this process follows Safety incident investigation process flowchart (scene to controls).
Comes before
- Safety incident investigation process flowchart (scene to controls) — Safety incident investigation process flowchart: preserve the scene, classify potential severity, notify the regulator, gather evidence, interview witnesses, reach the organisational causes, verify the controls.