Custom Management of Change (MOC) Software for Industrial Operations

What is industrial Management of Change?

Management of Change, or MOC, is a structured process for identifying, assessing, authorizing, implementing, and closing changes that may affect an industrial installation or process. A change can involve equipment, materials, technology, operating conditions, procedures, instrumentation, or an installation.

The goal is not to create a simple register. The record should retain the rationale, impact assessment, reviewed risks, approvers, updated documents, and conditions required before start-up. CCPS describes MOC as a system for reviewing and approving changes before they are implemented.

The software should answer an operational question: what is changing, why, what is affected, who approved it, and under what conditions can the new situation be put into service?

What is the difference between industrial MOC and change management?

Organizational change management helps people adopt a transformation through communication, training, new responsibilities, or a new organization. Industrial MOC controls the technical, operational, and safety consequences of a change to a real system.

Replacing an HR system is organizational change management. Changing a reactor alarm threshold, a gasket material, a pump, or an operating procedure may require MOC. Organizational changes can still fall within MOC when they materially change operating conditions or process risks.

Which changes should trigger an MOC?

The software should let each site define its own categories and route a request to the right assessments. Common categories include equipment, processes, materials, procedures, and automation.

Replacement in kind or actual change?

Replacement in Kind, or RIK, means a replacement that genuinely meets the existing item’s design specifications. In some frameworks, including OSHA PSM, it can be handled differently from a change requiring a full MOC.

Replacing a valve with the same model and characteristics may be classified as replacement in kind. Using another material, pressure rating, or operating principle is a change. The software can start with screening, an initial classification, and route the request to the normal process or the MOC workflow.

Replacement in kind should not be presented as a universal legal exemption in France. It is primarily a classification rule to be formalized against the site’s applicable framework.

How should the complete MOC workflow be organized?

The workflow should make gate conditions visible and block a transition when a required action is still open. An “approved” status is not enough if evidence, documents, or required checks are missing.

Request → screening → impact assessment → risk review → approval → pre-implementation actions → implementation → readiness / PSSR → start-up → close.

What information should be captured at request time?

An MOC request can capture the site, installation, affected asset, requester, change owner, description, rationale, current state, and target state.

The record should also distinguish temporary from permanent changes, desired date, urgency, affected documents, attachments, and an initial impact estimate. The requester should not need to know every required assessment: initial answers can trigger the right roles and checks.

How do you perform a useful impact assessment?

The impact assessment should ask what the change may affect without pretending to replace process safety expertise. MOC acts as an orchestration point: it triggers assessments, assigns them, retains their results, and checks completion before implementation.

HAZOP, What-if, or simple review: how should the study level be chosen?

Not every change requires a full HAZOP. A minor change may use a checklist or a What-if review based on questions such as “what if…?”. HAZOP, Hazard and Operability Study, systematically examines possible process deviations.

The software should determine the required study, assign it to a competent person, retain the result, and track actions. It must never replace a process engineer, risk study, or safety expertise with a generic checklist.

How should temporary changes be managed?

A temporary change becomes particularly risky when it becomes permanent through neglect. The record should retain a start date, expiry date, operating conditions, owner, and action to restore the normal state.

The software should remind owners before expiry and prevent a temporary change from remaining open indefinitely. At expiry, it must be closed, explicitly renewed, or formally converted into a permanent change.

How should an urgent change be managed?

Urgency should not mean bypassing MOC. A workflow can provide a shorter Emergency MOC: urgent request, mandatory minimum assessment, emergency approvers, implementation, and a complete retrospective review.

The required people, deadlines, and checks depend on site policy. The software records the reason for urgency and requires any remaining assessments or documents to be completed.

How should pre-start-up actions be tracked?

An assessment can produce actions such as changing a shutdown procedure, installing a safeguard, updating a P&ID, training operators, or testing an interlock. Each action becomes a traceable object with an owner, due date, evidence, status, and approval.

Some actions block start-up while others may be completed after start-up with a controlled deadline. The record must not become “ready” while a blocking action remains open.

What is a PSSR or pre-start-up readiness review?

A PSSR, Pre-Startup Safety Review, is a review performed before starting a new or materially modified installation. In a French or European context, it is safer to speak more broadly of a pre-start-up readiness review and use PSSR when the client’s framework uses that term.

The checklist can verify that the installation matches the approved change, tests are complete, safeguards work, procedures and documents are available, training is complete, blocking actions are closed, and start-up is authorized. The software orchestrates the review; it does not make a site compliant by itself.

How should impacted documents be managed?

A change can make a P&ID, operating procedure, electrical drawing, maintenance instruction, asset record, risk assessment, or training plan obsolete.

MOC does not necessarily replace the DMS, document management system. It can create a document change request and verify that the new version is approved, published, and effective before the change is closed.

How do you ensure teams are trained before a change?

When a procedure or operating mode changes, the affected people must be identified: line operators, maintenance teams, contractors, or site managers. The record can generate the affected population and track training required → assigned → completed → evidence available.

OSHA PSM requires affected employees and contractors to be informed and trained before start-up. This should remain tied to site rules and the applicable framework, not presented as a universal French requirement.

How should MOC connect to existing assets and software?

MOC becomes more useful when it knows the affected objects. A CMMS, computerized maintenance management system, can provide assets, work orders, and inspections. A QHSE, quality, health, safety, and environment, system can provide risks, non-conformities, CAPA, and audits.

The DMS provides drawings and procedures, the ERP, enterprise resource planning system, provides items, suppliers, and investments, the MES, manufacturing execution system, provides lines and production parameters, and the training system provides people and skills. MOC owns the change decision cycle while retrieving reference data from the systems that own it.

What is the difference between MOC, CAPA, and a change request?

A change request states the need: “we want to change the pump.” MOC examines the consequences and conditions of that change. CAPA, corrective and preventive action, addresses the cause of a problem and actions intended to prevent recurrence.

A CAPA can therefore trigger an MOC: incident → CAPA to replace a pump technology → MOC → assessment → change → verification → CAPA closure. The two processes should be linked without being conflated.

Seveso III: why does change management matter?

For establishments covered by the European Seveso III framework, Annex III of Directive 2012/18/EU includes management of change in the safety management system. Procedures must be established to plan changes to installations, processes, storage areas, and new elements.

MOC can help structure part of these procedures in regulated environments. The software does not make a site Seveso-compliant: compliance depends on the complete safety management system and its actual implementation.

OSHA PSM: why does this reference appear in MOC software?

In the United States, OSHA PSM, Process Safety Management, and specifically 29 CFR 1910.119(l), describes Management of Change for covered processes. It addresses the technical basis, safety and health impact, affected procedures, duration, and authorizations before implementation.

The framework also addresses updates to affected process safety information and procedures, plus training for affected people. OSHA is a US regulation and should not be presented as the default law applicable to a French plant.

ISO 45001 and MOC: what can be said in 2026?

ISO 45001:2018 remains the published edition in force in September 2026. It was confirmed in 2024 and a new edition is being prepared. It provides a general framework for occupational health and safety risks; MOC can fit within it when changes affect those risks.

Do not claim that software is ISO 45001 certified or that using it makes an organization compliant. Certification concerns the management system and the organization, not a software workflow alone.

Which indicators should be tracked on an MOC process?

The number of open MOCs is not enough. Indicators should show where the process is blocked, which changes are aging, and whether start-up conditions are actually being met.

Can AI be used in MOC software?

Yes, but only as assistance. AI can classify a request, identify potentially affected assets or documents, summarize an assessment, find similar MOCs, suggest questions, or flag a potentially missing piece of evidence.

It must not decide by itself that a change is safe, approve a risk, remove a control, or authorize start-up. Critical decisions should rely on rules, assessments, and identifiable competent people.

How should approvals be secured?

For critical changes, one person should not necessarily be able to request, assess, approve, and authorize start-up. The software can separate the requester, change owner, safety, operations, maintenance, quality, engineering, and final approver roles.

Every important decision should retain who, what, when, the comment, and the assessed version. Rules depend on change type, risk level, and site policy.

SAP Management of Change or custom MOC software?

SAP provides a Management of Change application for changes to equipment, materials, chemicals, operating conditions, procedures, and organization, with assessments, approvals, and task tracking. EHS/MOC solutions such as Intelex and Cority also provide configurable modules.

A standard product may be preferable when it properly covers change categories, assessments, approvals, sites, integrations, and documentation requirements. Custom software becomes relevant when rules are tightly linked to the existing information system or several industrial workflows need orchestration. The decision should come from a fit-gap, not an automatic preference for custom development.

How much does custom Management of Change software cost?

Cost depends on the number of workflows, assessment depth, integrations with CMMS, DMS, QMS, ERP, MES, or training systems, number of sites, migrations, notifications, and required traceability.

A workflow-based MOC register is very different from a multi-site platform connected to assets, documents, permissions, and quality systems. Scoping should separate approval gates, blocking rules, history, and future operations rather than presenting an artificial average price.

How would Koragence structure an MOC project?

The project starts from several real changes already handled: an equipment change, a process change, a temporary change, and ideally a record that caused difficulty. The goal is to reconstruct the process actually used rather than design a theoretical workflow.

Rules are then made explicit: which changes require MOC, which assessments are triggered, who participates, which documents must be updated, and which conditions block start-up. The first workflow is tested against known scenarios before progressively integrating the CMMS, DMS, quality system, and other reference systems.

Existing MOCs → screening rules → impact assessments → workflow → actions → readiness → integrations → testing → migration → deployment.