Resonance
Insights

Why the Reliability Module Sits Idle

Bill Carrick · September 15, 2026

Organizations that implemented their EAM five or ten years ago tend to give the same answer when asked what the reliability functionality is doing. It was configured at go-live and has not been opened since. Why would a capability that came with the platform, already paid for and already configured, go unused for a decade?

The reason is in the work-order close-out. When a technician finishes a job and closes the work order, the record written at that moment is the input nearly every reliability capability runs on. Maintenance writes that record and reliability is the only function that reads it, so the quality of the record depends on a team that is measured on something else.

A technician entering close-out details beside a transit vehicle at the end of a job.

The four codes at close-out

CERN's asset management group describes the close-out schema in its EAM user meeting material. The problem code records what was observed, the failure code the technical reason, the cause code the root cause, and the action code what was done.

The technician closing the job knows all four answers and is standing next to the equipment. Anyone who reads the record later has to reconstruct them.

ISO 14224:2016 exists so that this record can travel. It covers the collection and exchange of reliability and maintenance data so that failure and maintenance history is comparable between plants, owners, manufacturers and contractors.

Who produces the record and who uses it

Maintenance and reliability are measured on different things, and both depend on the same four close-out codes.

What is your maintenance team measured on? Schedule compliance, backlog age, wrench time, PM completion, and cost against budget make up the usual list. A correct failure code moves none of those numbers.

What is reliability measured on? Failure-mode analysis, PM optimization, condition thresholds, and criticality refresh all read from the same four fields, and so does the reliability module in the EAM.

Given those two scorecards, close-out gets treated as an administrative step at the end of the job, and the fields get filled in accordingly.

The Friday close-out pattern

Of 21,107 maintenance work orders, 19,597 closed on a Friday, against 4,221 for an even spread.

How does that show up in real data? NIST researchers studied 21,107 maintenance work orders and looked at when each one was opened and when it was closed. Openings were spread fairly evenly across the week, at about 20 percent on each weekday.

Closures clustered on one day. Of the 21,107 records, 19,597, about 93 percent, closed on a Friday, where a uniform spread would put four to five thousand. The authors read that as batch behavior, with somebody sitting down at intervals to clear a queue.

A queue cleared on Friday afternoon contains Tuesday's jobs, so the four codes for those jobs are being written from memory, days after the technician stood in front of the equipment.

Corrected for that batching, the median work-order duration in the same dataset fell from 14 days to 9 or 10, a reduction of more than 30 percent. The authors note that reading duration straight off the close date would overstate downtime or labor hours by a significant margin.

What happens when the codes are made mandatory

Can't you just make the fields required? Restricting close-out to a controlled vocabulary does force an entry, but the person making the entry still has no reason to get it right.

NIST and the University of Western Australia reported in 2019 that restricted-entry systems can increase error probability under some circumstances. The documented failure is a technician selecting "misc" or "other" to skip categorization and typing the real answer into free text, which defeats the controlled vocabulary that was put there to prevent it.

Two attempts to use the record

What happens when somebody tries to use the history? CERN went looking for predictive-maintenance candidates in its EAM in 2021, starting with lifts and compressors and working from work-order history alone. Its user meeting slides record that very few corrective work orders corresponded to real failures requiring repair, and that "No (consistent) closing codes were found allowing to filter." CERN ended up writing equipment-specific screening algorithms to get anything usable out of its own maintenance history.

Hodkiewicz and Ho found the same condition in 2016. Work-order histories, they reported, frequently contain missing or incorrect functional location, failure mode, maintenance action and work order status fields.

Their paper also shows the records can be recovered from the free-text field by someone who understands how the site maintains its equipment and where the asset sits in its life cycle. That is reliability work done after the fact, and it has to be redone every time the analysis is refreshed.

Scoring the maintenance-reliability pair

Close-out is a single countable event inside a system both disciplines already share, which makes it one of the cheapest places in an asset organization to measure how well the two are working together.

The Resonance Score does that on a 0 to 5 scale. For a discipline pair it scores practice maturity on one side and system enablement on the other, reports the lower of the two as the score, and reports the gap between them as the Detuning, which shows which side to address first.

The launch article works an example with a practice maturity of 3.4 and a system enablement of 2.1. The score is 2.1 and the Detuning is −1.3, so the system side is the constraint, and the practice will not deliver above 2.1 until the system side moves.

The reliability module inside Octave Attune EAM (formerly HxGN EAM) is the first thing that reads the close-out record. Octave Attune APM sits a level above it, adding analytics that read from the same work-order history, and that level becomes reachable once the record underneath it holds up. If you are on that product line, the question is whether the close-out record is good enough for the module you already have.

A Resonance Score session runs on the EAM you already have. It starts with a decision about what the close-out record is for, then checks whether the four codes are good enough for anyone downstream to act on. Both numbers come back in a single working session.

Sources

Request a working session