At 07:14 on a Tuesday, a maintenance planner opens the equipment record for a nitrogen storage vessel and edits one field. The criticality rating moves from A to B, because a project engineer emailed to say the vessel is now on standby duty behind a new package. The planner saves. The record is updated. Nothing else on the vessel changes. Within a fortnight the weekly PM has dropped off the schedule, the mechanical seal spares have fallen off the minimum stocking list, and the vessel is no longer on the statutory inspection route the site had baselined against its written scheme of examination. Nobody involved noticed. Everyone involved was doing their job.
This is the class of change that decides whether asset master data governance holds after go-live. The taxonomy, the data owner map and the validation rules were all designed during the programme. What survives is what happens to a live record on an ordinary Tuesday, with no programme office and no auditor in the room. The mechanism that decides is the change record.
What actually changes when the master record changes
An equipment record in Maximo, or in any comparable enterprise asset management platform, is not an isolated document. It is a node in a working graph. The criticality rating steers PM frequency, escalation routing, spares stocking, condition monitoring scope, capital planning weight and, in regulated sectors, the compliance schedule. The equipment classification steers failure codes, job plan applicability, meter attachment and asset attributes. The parent location and asset hierarchy steer cost roll-up, downtime accounting and the availability reports the operations director reads at the monthly review.
A change to a single field on the record is therefore rarely a single change. It is the top of a small tree of downstream events, most of which are triggered automatically by the platform and some of which fire slowly enough that the connection to the original edit is invisible by the time the consequence is felt. Governance that treats the edit as a data quality issue misses the point. The edit is a control point.
The change record: fields that hold governance in place
Every mature EAM operating model treats a change to a controlled master data field as its own record, not as a naked field update. The change record does not need to be a bespoke object; in Maximo estates it is typically a workflow attached to key business objects, or a change management application configured against the master data domains. Either way, the record needs to carry a fixed set of fields, and each field has an operational job.
- Reason category. A short controlled list of why the change is being requested: as-found correction, engineering modification, criticality reassessment, decommissioning, hierarchy correction, taxonomy realignment. The category decides the downstream path.
- Trigger evidence. The artefact that authorises the change: an engineering change notice, a management-of-change reference, a criticality review minute, a capital project handover pack, a P&ID revision. No trigger evidence, no change.
- Before and after values. Captured on the record itself, not inferred from the audit log. If the record is signed off, it must be readable in isolation a year later.
- Impact assessment. A named checklist of downstream effects on PMs, spares, compliance schedules, cost centres and reports, completed before approval. This is where the criticality-to-PM chain gets caught before it fires.
- Data owner and steward acknowledgement. Named individuals, not group inboxes. The data owner for the domain accepts the change; the steward closest to the asset confirms the impact assessment.
- Effective date. Distinct from the record modification date, because criticality reassessments and hierarchy changes should sometimes take effect at a shift change, an outage boundary, or the start of a compliance period, not on the calendar minute the record is saved.
A change record without those fields is a note taped to a database update.
The approval path that is defensible under audit
The purpose of the approval is not ceremony. It is to place a defensible signature next to the impact assessment. Approval paths tend to fail in two directions. Excessive ones route every field edit through a change advisory board that meets fortnightly and becomes the reason planners keep a shadow spreadsheet. Insufficient ones let a planner or a contractor change a criticality rating with a single save and no counter-signature.
The pattern that holds up is a tiered path defined by the field, not by the record. A change to the description or a non-controlled attribute is self-approved by the creator. A change to a controlled field with limited downstream impact, such as the parent location within the same functional area, is approved by the data steward. A change to a governed field with cross-domain impact, criticality being the archetype, is approved by the data owner for the domain and counter-signed by the operational role accountable for the consequence: the reliability engineer for criticality, the compliance lead for statutory scope, the finance controller for cost hierarchy.
Two design details make this operate rather than seize up. The tier of the field is stored on the data model itself, so the workflow selects the path automatically. The approver is defined by role and coverage, not by name, so leave and reorganisation do not turn the queue into a bottleneck.
What the change should trigger downstream
An approved change to a controlled field on the master record is an event, and it should fire a small, deterministic set of downstream actions.
- PM regeneration on the affected asset population, so the schedule reflects the new criticality within a defined window rather than at the next full regeneration cycle.
- Spares review, at least at the level of a task on the storeroom owner’s workspace, so minimum and maximum stocking levels are revalidated against the new criticality.
- Compliance scope check, so any change that could add or remove a statutory inspection is caught before the next examination round.
- Notification to condition monitoring, where the asset is on a Health, Monitor or Predict scope, so risk scoring and thresholds are refreshed.
- Audit trail write to a single immutable log, tied to the change record identifier, that a regulator or an internal auditor can query without asking IT for a database extract.
None of these are technically difficult. They are integration and workflow work that has to be scoped explicitly, or it will not happen.
What stays hard
Three things stay hard even when the change record is doing its job. Contractor edits during an outage remain the highest-risk source of undeclared change, because the operating rhythm and the governance rhythm move at different speeds; the control that works is a scoped, time-boxed contractor permission set with pre-agreed reason categories, not a blanket ban on edits. Hierarchy corrections after a plant reorganisation are always slow, because the impact assessment genuinely is large; treat them as a small project with their own approvals rather than as routine records. And criticality reassessment drifts downwards over time as assets age and PMs feel expensive; only a periodic, calendar-driven review by the reliability function pushes back on the drift.
For the wider frame this sits inside, see asset data governance that actually works and the operational readiness piece on how master data enters the estate in the first place.
Closing position
Master data governance is decided on the ordinary days, not on the audit days. The change record, with a named trigger, an impact assessment, a tiered approval path and a deterministic downstream fire, is the artefact that turns a live equipment record from a document into a controlled data asset. Every asset-intensive operator already has the platform features needed to implement this in IBM Maximo and MAS. What is usually missing is the design intent to treat a field edit as an event and to build the record around it. Programmes that do this rebuild trust in their master data within a year. Programmes that do not spend the next capital cycle explaining, again, why the reports do not agree.