Management of Change, or MOC, is a formal process used to evaluate and control risk when a technical, operational, organizational, or system change could affect performance.
MOC is different from general Change Management.
Change Management focuses strongly on adoption, stakeholders, communication, and behavior.
MOC focuses on whether a proposed change creates new technical or operating risk.
Define what requires MOC
Not every small adjustment needs the same level of review.
Organizations should define triggers.
Examples may include changes to:
- equipment;
- process chemistry;
- operating parameters;
- control logic;
- safety systems;
- materials;
- suppliers;
- maintenance strategy;
- layout;
- software;
- staffing model;
- procedures.
The threshold should match the organization’s risk profile.
Describe the proposed change
The request should explain:
- current condition;
- proposed condition;
- reason for change;
- affected equipment or process;
- expected benefit;
- planned timing.
Vague requests make risk review difficult.
Process Governance can help clarify decision rights for cross-functional changes.
Assess risk before implementation
The review should ask what could be affected.
Potential dimensions include:
- safety;
- environment;
- quality;
- customer requirements;
- reliability;
- cybersecurity;
- regulatory compliance;
- training;
- maintenance;
- downstream processes.
FMEA may be useful when the change introduces new failure modes or modifies existing controls.
Identify required actions
A change may require:
- drawing updates;
- procedure revisions;
- training;
- spare parts;
- inspection changes;
- control plan updates;
- software testing;
- supplier approval;
- permit changes;
- customer notification.
The change should not be released until required prerequisites are understood.
Use appropriate approvals
Approval should come from roles with relevant accountability.
Depending on the change, that may include:
- process owner;
- engineering;
- quality;
- maintenance;
- safety;
- IT;
- regulatory;
- customer representative.
Approval is not a ceremonial signature.
The approver should understand the part of the risk they are accepting.
Control temporary changes
Temporary changes can be especially risky because organizations may forget to remove them.
Examples include:
- bypasses;
- alternate material;
- temporary software logic;
- temporary operating limits.
Temporary MOC should include:
- expiration date;
- owner;
- restoration plan;
- review before extension.
Abnormality Management can help make temporary deviations visible during operation.
Verify after implementation
A completed change should be checked.
Confirm:
- expected function;
- updated documentation;
- trained people;
- effective controls;
- no unexpected new risk.
Process Confirmation can support verification at the Gemba after release.
Close the change formally
Closure should confirm that actions are complete and the normal operating system reflects the new condition.
Do not leave approved changes permanently “open” because documentation or training was never finished.
Common mistakes
Using MOC only for capital projects, treating approval as paperwork, failing to control temporary changes, ignoring downstream impacts, implementing before training or documentation is ready, and closing the change without field verification are common mistakes.
Practical sequence
- define MOC triggers.
- describe the proposed change.
- identify affected systems and stakeholders.
- assess technical and operational risk.
- define required controls and prerequisites.
- obtain appropriate approvals.
- implement under controlled conditions.
- verify performance and documentation.
- restore or extend temporary changes deliberately.
- close the change formally.
The practical lesson
Management of Change protects the organization from the unintended consequences of improvement.
A change should not only solve the original problem. It should enter the operating system without creating a larger one.