A change process people will use at two in the morning

Every site has a management of change procedure for control system modifications. Most of them are designed for planned engineering work and are unusable for the situation that actually generates urgent changes: something is wrong at two in the morning and a setting has to be altered to keep the plant safe.

What happens then is predictable. The change is made, the paperwork is completed afterwards or not at all, and the site accumulates undocumented modifications that nobody can account for.

Tiered, or bypassed

A single process applied to every change means it is either too heavy for minor modifications or too light for major ones. Tiering is what makes compliance realistic.

Employment decisions require documented policy, consistent evidence and appropriate due process. Further details are available via this resource.

For process facilities, the surrounding management framework is covered in OSHA process safety guidance.

A minor tier for low-consequence changes — a display label, a trend group, a non-alarm parameter — with a lightweight record and a single approver.

A standard tier for normal engineering changes, with review, testing, documentation update and approval.

A major tier for anything touching protective functions, alarm rationalisation decisions, or control strategy, with a fuller review including operations and process engineering.

An urgent tier for changes required immediately for safety or availability, with a defined authority to make the change, a mandatory record at the time, and a required retrospective review within a short period.

What every record has to capture

Regardless of tier: what was changed, from what value to what value, why, who made it, when, who approved it, and what testing was done.

The from-value is the field most often omitted and the most important, because it is what allows a change to be reversed when it turns out to be wrong.

Changes that do not look like changes

Control system modification processes typically cover logic and configuration. Several categories that carry equal consequence are routinely outside scope.

Alarm threshold and priority changes, which are frequently made by engineers as routine adjustment.

Controller tuning, which is not usually treated as a change at all and can substantially alter plant behaviour.

Display modifications, which affect what the operator sees and therefore what they can detect.

Setpoint limits and operator entry ranges.

Firmware updates on field devices, which can alter behaviour in ways not obvious from the release notes.

Each of these should be in scope at some tier. Excluding them means the change record does not describe the system's actual configuration history.

Temporary changes need an expiry

A change made as a temporary measure — a forced value, a bypassed interlock, a widened alarm limit — is the most dangerous category, because temporary changes become permanent by inattention.

The controls are a mandatory expiry date, a register of everything currently temporary, review at every shift handover, and a periodic report to management of anything that has exceeded its expiry.

That register is one of the highest-value documents on a plant and one of the least commonly maintained.

Testing proportionate to consequence

The testing requirement should follow from what the change could affect. A display label change needs a visual check. A change to interlock logic needs a functional test of the interlock, with evidence.

Where testing on the live system is not possible, the alternative is offline testing on a simulator or a development system, which is an argument for having one.

Closing the loop on documentation

A change is not complete when the system is modified. It is complete when the drawings, the narrative, the alarm database and the operating procedures reflect it.

Making documentation update a required step for closure — rather than a follow-up action — is what prevents the accumulation of documentation drift that eventually makes the documents useless.

Auditing whether it is being followed

The test of a change process is not whether it exists but whether the system matches its records.

A periodic audit — comparing the current configuration against the documented baseline for a sample of the system — finds undocumented changes. The number found is a direct measure of whether the process is working, and it is uncomfortable enough that it is rarely done.

Who is competent to make the change

A change process defines approval and frequently does not define competence: who is qualified to make a particular kind of modification.

This matters most for changes to protective functions and sequence logic, where the consequences of an error are highest and where the required understanding is specialised.

A simple competence matrix — which categories of change each individual is authorised to make — is a short document that prevents a well-intentioned engineer modifying something outside their experience.

Vendor and contractor changes

Changes made by external parties during support visits or projects are the most common source of unrecorded modification, because the external party is not part of the site's change process.

The requirement has to be contractual and enforced practically: a site engineer accompanies the work, the change record is raised by the site, and the vendor's own record is a supplement rather than a substitute.

Reviewing the changes in aggregate

Individual changes are reviewed for their own risk. The cumulative effect is not, and a system that has received two hundred individually reasonable changes may have drifted substantially from its design intent.

A periodic review of change records — what has been modified, in which areas, and whether any pattern is visible — occasionally reveals that a series of small adjustments has collectively defeated something the original design relied on.

Changes driven by production pressure

The changes that most need control are frequently those requested under commercial pressure: a limit widened to allow higher throughput, an interlock timing adjusted to reduce nuisance trips, an alarm suppressed during a campaign.

Each may be entirely reasonable and each alters a designed constraint. The change process exists precisely so that these decisions are made deliberately and with the right people involved.

Where the process is bypassed under pressure, the record of why the constraint existed is lost along with the constraint, and reversing it later becomes impossible to justify.

Emergency changes and the review afterwards

The urgent tier depends entirely on the retrospective review actually happening. Without it, the tier becomes a route to bypass the process.

A short review within a defined period — was the change appropriate, is it still needed, should it be made permanent or reversed, what documentation is outstanding — is what keeps the tier legitimate.

Tracking the proportion of changes made under the urgent tier is also informative. A rising proportion usually means the standard route is too slow rather than that emergencies are increasing.