MOC Planning in Manufacturing: Roles, Risks and Control

What MOC solves and where it usually breaks

MOC (Management of Change) in manufacturing serves one purpose: to make sure any change does not introduce new risks that nobody noticed. It's not bureaucracy for the sake of signatures; it's a way to see in advance how a change will affect people, equipment and product output.

Incidents often follow apparently "small" changes: replacing a unit with an "almost identical" spare, switching a raw material supplier, a new recipe or operating mode, updating controller firmware, disabling a sensor "temporarily", or moving a sampling point. The danger is that not only hardware or a document changes — the operating conditions of the whole system can change.

It's important to separate a change from routine work right away. Routine work is maintenance according to an approved procedure, within the same limits and materials. A change is leaving approved boundaries: a new part type, different control logic, a different routing, another raw material, a new sequence of operations, a temporary bypass of protection, a new contractor or a new competence.

MOC keeps clear boundaries where "small things" don't exist: occupational safety, product quality and compliance, environment and emissions, equipment reliability and availability, IT and cyber risks (for example, edits in SCADA or accounting systems that affect the process).

MOC most often fails in the same places: the change object is described vaguely; risks are assessed formally without measures; approvals are collected "by position" rather than by competence; the change was implemented but training, acceptance and documentation updates were forgotten.

The process must be able to demonstrate a simple chain: what was changed, who authorized it, what risks were found, what measures were taken, how the result was verified and what confirms closure. Example: a pump was replaced with a model having a different flow curve, pressure rose, fuses tripped and the line stopped. MOC is exactly what you need to see such effects before installation and lay down measures in advance.

Classification of changes and thresholds for starting the procedure

MOC planning starts with a simple question: what exactly is changing and could this change the risk? If classification is vague, there will be disputes, unnecessary approvals or, worse, missed hazards.

It's more convenient to classify changes by nature rather than by who initiated them. Typically these are:

• technical (equipment, units, I&C, electrical, controller software)
• technological (recipe, modes, parameters, operation sequences)
• organizational (staff, responsibilities, contractors, shift procedures)
• IT (networks, accesses, accounting systems, server and workstation updates)
• supplier/components (different manufacturer, material, quality class)

Keep permanent and temporary changes separate. Temporary means a decision with an end date, return conditions and a person responsible for the return — not "we'll put it back later." Extending the period is a separate decision, not silent continuation.

When a full MOC is needed and when a simplified one suffices

Set the threshold by consequences, not by "importance." Basic rule: if risk or any safety barrier changes (protection, interlock, alarm, procedure, competence), a full MOC is required.

A simplified MOC is acceptable when the change does not affect hazardous factors or barriers and can be easily verified by on-site acceptance. A full MOC is required if a new hazard appears, an accident scenario changes, or training/retraining is needed.

Typical triggers for a full MOC: replacing an "equivalent" with different characteristics (power, material, protection class), switching raw materials or changing a recipe, firmware updates for PLCs/drives that affect protection logic, changing setpoints and start/stop modes, introducing a new contractor for critical work.

A mini-check to decide the threshold:

• What will be different?
• What can go wrong?
• Which protections will be weakened or disappear?

If any answer is unclear, choose a full MOC.

How to describe the object of change so there's no ambiguity

If the description is vague, everything else breaks: risk assessment, approvals, control. Introduce a rule: one change object = one clear set of identifiers, boundaries and parameters.

Start by tying the description to location and to the "carrier" of the change. It's not enough to write "line upgrade" or "sensor replacement." Specify site, workshop, elevation, line/unit, then the exact module, equipment, system or document.

As-is and To-be without guessing

In the request, record the current state (as-is) and the target state (to-be) so that shift personnel can verify on site. Usually it's enough to note:

• exactly where: site, workshop, area, cabinet, rack, elevation
• what exactly: equipment tag/ID, I&C tag, spec position, software/firmware version
• as-is: wiring diagram, current setpoints, operating modes, active instructions
• to-be: what changes (component, algorithm, document) and the expected result
• critical parameters: pressure, temperature, speed, medium composition, access levels

After that, define the boundaries of influence. A change "in one cabinet" often affects neighboring units, power, ventilation, safety systems, I&C and IT (network, accounts, event logs). Better to list interfaces to be checked from the start.

Tying to identifiers

Use only verifiable references to artifacts: tags, inventory numbers, drawing and revision numbers, configuration versions, request and protocol numbers.

Example: "Replace pressure sensor PT-204 on line L-2, I&C cabinet CAB-7: as-is 4-20 mA, alarm setpoint 9.5 bar; to-be sensor with HART, setpoint 9.0 bar, PLC logic update (project PLC_L2 v1.6 -> v1.7), P&ID correction (rev. 12 -> 13)." Such a description immediately shows what to check: power, calibration, setpoints, instruction entry and shift training.

Risk assessment: the minimum that actually works

Without a simple risk assessment, changes start to drift on deadlines and safety. The basic minimum can be clear and verifiable without thick reports.

Start with five buckets and go through each: occupational safety, process safety, product quality, environment, cyber risks (especially if DCS, networks, accounts or remote access change). The goal isn't to list every possible risk but to identify those that realistically change because of this specific change.

Simple matrix and who approves it

A "likelihood x consequence" matrix (for example, 1-5 by 1-5) with plain labels for levels is enough. The assessment is usually prepared by the initiator together with the area owner. It is approved by the MOC process owner or production manager. If a risk falls into the "red" zone, the decision to proceed is escalated to a higher level.

After the initial assessment, check the protective barriers: what protected the process before the change, what you remove or weaken, and how you compensate. Often this matters more than the number on the matrix.

Short checklist:

• Which accident/injury/defect scenarios become more likely?
• What barriers existed (locks, guards, instructions, interlocks) and what changes?
• What measures are required (equipment, procedure, training, checks)?
• What to check before start (tests, inspections, control points)?
• What assumptions are made and what remains unknown?

When extra expertise is needed

Deepen the assessment if critical control and protection loops, stop logic, explosive zones, high energies (electricity, pressure, lifting equipment) or unclear operating modes are affected. Then HAZOP, SIL review or electrical safety expertise may be appropriate.

Record assumptions and unknowns directly in the MOC card as actions: "confirm calculation", "obtain certificate", "perform test", with an owner and deadline. This turns "we think it's safe" into a plan to close risks.

Approvals: who must sign and why

Approvals are not for the "checkmark" but so the change passes through people responsible for safety, quality and operability. The signature should come from someone who can explain what they checked and what they agreed to.

A typical minimum set of approvers is:

• process/area owner: confirms purpose and boundaries
• production: assesses feasibility during shifts and impact on output
• technical services (mechanical/electrical/I&C): check compatibility, reliability and installation requirements
• HSE: reviews risks, need for permits, lockout/tagout, training
• quality (if product/traceability is affected): checks specs and control points

Separate the roles: the initiator describes and proposes, reviewers ask questions and require measures, the approver makes the decision and takes responsibility for the start, and the executors carry out tasks and record completion. If one person does everything, MOC becomes "signed by oneself."

For high-risk changes add an independent review: an expert not involved in the work and not pressured by deadlines. For example, edits to protection logic at a pumping station should be checked by another I&C engineer or the technical manager, not the change author.

Set authority limits in advance. Small area-level changes can be approved by the workshop manager, but anything affecting protection, hazardous substances, pressure/temperature, fire safety or training should escalate to the chief engineer or site management.

Before signing, a short checklist helps:

• what changes (object, boundaries, modes) and what doesn't change
• what hazards appear and what barriers are added
• what documents, instructions and labeling are updated
• are stops, tests, acceptance, training or contractor permits needed
• how we will know the change was successful: acceptance criteria and who accepts

Step-by-step MOC process from request to closure

To prevent MOC becoming an email ping-pong, the process should be the same for everyone and start with recording the change, not verbal agreements.

From request to decision

First register the request and assign a unique number. It links risks, approvals, permits, purchases and final documentation. The request needs: what we change, where, why, who is the initiator.

Then describe the change object and boundaries. Also note explicitly what is NOT included. Example: "replace a variable frequency drive on line 3, without changing PLC logic and emergency stop wiring."

After that — risk assessment and action plan. It's enough to identify key hazards (people, quality, downtime, environment, cyber risks) and record measures, owners and deadlines.

Then approvals and decision. It's useful to keep three statuses for decisions: approve, return for revision, reject. When returned, record specifically what to fix (for example, add training or recalculate network load).

Execution, commissioning and closure

After approval, actions are performed, training is carried out, then the item is commissioned. Close MOC only after acceptance: measures are implemented, tests passed, personnel are authorized.

After implementation, perform a follow-up check at a pre-agreed interval (for example, 2–4 weeks): were there deviations, false trips, increased rejects, new risks? And be sure to update documents: diagrams, instructions, spare parts lists, settings, configuration logs.

A short control checklist so steps aren't lost:

• MOC number assigned, initiator and date recorded
• object and boundaries described unambiguously
• risks assessed, measures assigned, deadlines realistic
• approvals complete, decision recorded
• acceptance, training, documentation updates and follow-up performed

Execution control: actions, deadlines, acceptance and training

After approval, the most common failure is "they forgot to finish." So define up front how you will check completion and what will prove everything was done correctly.

Make the action plan readable in six months without calling the "author." For each item include: one action (no "and/or"), responsible person and role, deadline (if needed — shift), acceptance criterion (measurement, act, log entry), and a flag whether it "blocks start."

Keep statuses simple: "not started", "in progress", "ready, awaiting check", "accepted", "overdue" (with reason and resolution). Regular control and clear escalation are more important than a pretty table.

Before start, a hands-on check is useful: walkdown, tests, measurements, label verification, protection and interlock checks. After pump replacement the acceptance criterion is not "pump installed" but "no leak at working pressure, vibration within limits, rotation direction confirmed, overcurrent protection trips on test."

Don't postpone training and permits. Specify who to train (operators, maintenance, I&C, contractors), the program and how to confirm (instruction record, test, log entry, permit). Agree where records are stored so they can be shown quickly.

For temporary changes set an end date and a renewal rule: who approves, what checks repeat, how return to the original state is recorded. After closure, collect key evidence (plan, statuses, acceptance, training) into one archive package.

Minimal set of roles and artifacts for an audit

For audit confidence you need two things: clear roles and documents that show the chain from the reason for change to evidence that measures were completed.

Roles: the minimum that closes risks

Even in a small team roles must be explicitly assigned (one person can hold multiple roles, but not all). Minimum:

• initiator (proposes the change and explains why)
• owner of the equipment/process (responsible for the area and consequences)
• technical expert (engineer, I&C, IT/DCS, electrical — depending on the topic)
• HSE (checks safety, permits, risks, measures)
• approver (authorized to allow the work)

Main rule for role combination: one person should not single-handedly "design the solution", "assess the risk" and "accept the work." A minimal conflict-of-interest protection is that acceptance and closure are signed by someone other than the initiator.

Artifacts: what to show the auditor

An auditor cares about evidence, not pretty templates. Usually enough:

• MOC cards/forms with object and boundaries
• risk assessments with assumptions
• action plan with deadlines and owners
• approval log/signature sheet with dates
• acceptance/check records (act, acceptance checklist, inspection/test results)
• training and information records

As needed, add updated instructions, drawings, software/config versions, test or commissioning results. Versioning and dates in documents are important; otherwise it's hard to prove the work was done to the current data.

Common mistakes and traps in MOC

The most common reason MOC fails is not the request form but differing interpretations of what exactly is being changed. Typical mistakes:

• too broad a description: no boundaries, key parameters or affected systems, so the contractor and operations implement different things
• risk assessment replaced by general phrases like "risks minimal" without measures, owners and criteria "done/not done"
• a temporary fix "until shutdown" becomes permanent without risk review, documentation updates and training
• work starts before approvals or without shift training
• instructions, diagrams, tags, software versions and configuration logs are not updated, so the actual configuration diverges from documentation

A separate trap is closing MOC "by date" rather than by fact. Closing without acceptance evidence (test protocols, test results, signatures) almost always appears in internal audits or after the first deviation.

Example: a bypass is temporarily fitted around a pump so the line doesn't stop. The request notes "temporary piping" but not which valves must be sealed, which signals are disabled/retuned and how return to the original state is checked. After a month the bypass becomes "normal", and during the next repair people follow the incorrect scheme.

The cure is simple: clear boundaries of the change, measurable risk mitigation, shift training before start and closure only after acceptance and documentation updates.

Simple example: replacing an equipment module without weeks-long shutdown

On a packaging line a variable frequency drive (VFD) fails. The warehouse has a similar model from the same vendor but a different revision. If installed "as is" you can easily get downtime, quality issues and disputes about who authorized the change.

First describe the object so it cannot be interpreted differently: which drive (power, RPM, gearbox), which cabinet/cell (marking, wiring diagram), current parameters (ramp/start-stop times, currents, frequency, protection settings), interfaces (discrete signals, 4-20 mA, Modbus/Profinet, etc.), firmware and configuration versions, and software used for setup. Clearly state what remains unchanged: cables, motor, sensors, PLC algorithm (or that PLC will require changes).

Next — a brief risk assessment specifically due to the replacement: starting currents and motor overheating, false trips, line stops due to incompatible signals, access to the cabinet and energy isolation during tests. If there's a network interface, include the risk of losing communication or unauthorized reconfiguration.

Approvals typically involve production (work window and impact on output), electrical service (connection and protections), HSE (permit, LOTO, permits), quality (impact on process parameters). If the VFD connects to networks or accounting systems, involve IT.

To keep it short and practical, plan in advance: bench test and load basic settings before the shutdown, configure protections and monitor currents/temperature during the first run, a trial run with parameter logging and observation of rejects, update diagrams/settings/instructions, and brief training for on-call electricians and operators on version differences.

Closure is confirmed with a package: test protocol, acceptance act, updated diagrams/instructions and the training record.

Short checklist and next steps

To quickly determine if a change is safe to start, focus on four things: what we change, where the risks are, what measures are already done and who is responsible.

Quick checks before each stage

• Before start: MOC number exists, owner assigned, boundaries described; temporary changes have end dates and return plans.
• Before implementation: risks assessed, measures assigned to named people, critical checks scheduled by date.
• Before commissioning: acceptance performed against criteria, staff trained, instructions and diagrams updated and available at the workplace.
• After start: follow-up check performed in the agreed window, findings closed, actual state reflected in documents.

Simple test: if you cannot answer in 2 minutes "what are we changing", "how could it end", "what measures are already done" and "who signed acceptance", the MOC is not ready.

How to keep the process from falling apart

Start by making MOC repeatable and verifiable:

• standardize forms and statuses (request, risk assessment, action plan, acceptance, closure) and define who moves MOC between statuses
• set up a single register: MOC log, deadlines, overdue items, related permits, post-check results
• agree on short reporting: how many MOCs open, how many overdue, common causes and where nonconformities are found most often

If the volume of changes is large, approvals and execution control are easier to manage in an IT system. System integration and support from GSE.kz (gse.kz) can help in such tasks, especially when you need to connect production, IT and safety requirements in one process.