The definition
Operator-driven reliability is a way of running a plant in which the operators who run it take a defined share of its care — the routine checks, the readings, the first notice of a change in sound, temperature, vibration or leak — and what they record reaches the maintenance and reliability side while the fix is still small.
Three parts of that sentence carry the weight. Defined: the operators' share is written down as rounds and checks, not left to whoever happens to look. The first notice: the operator who walks past the equipment every shift sees a change weeks before a survey is due or a work order exists. Reaches the maintenance and reliability side: an observation that stays in the operator's head, or on a sheet in a binder, has not driven anything. It is the third part that most programmes lose.
Other names for the same thing
The phrase belongs to the reliability profession. SKF, the bearing maker, says it pioneered operator-driven reliability in 1997, and the maintenance and reliability press has written about ODR programmes ever since.
Depending on the site and the consultant you will also hear operator care, operator asset care, basic care, operator-based maintenance, and autonomous maintenance — the pillar of Total Productive Maintenance in which operators clean, inspect and lubricate their own equipment. The emphasis differs: autonomous maintenance has operators doing light maintenance; operator-driven reliability has them watching, measuring and reporting. The common ground is the same, and it is the ground an operator round stands on: the people nearest the equipment, every shift, with a defined list, leaving a record somebody else can use.
Why it stands or falls on the record
Every version of the idea has the same weak point, and it is not the operator. The operator's part works: they walk, they look, they notice. What fails is the next step. The reading goes onto a sheet; the sheet goes into a binder; the person who could have trended that bearing temperature over six weeks never sees it, and the reliability engineer builds the programme on the instrumented points alone, because those are the ones that reach a database.
So the question for a site starting or restarting an operator care programme is not which checks to add. It is where the operator's record goes, whether the people who decide what to fix can read it, and whether it still says what it said on the day — which limit the reading was judged against, which equipment it was taken on, and what was not checked at all.
What the record has to hold
Amberhold is the operator's record. These are the things it keeps, and why each one matters to the people on the maintenance and reliability side:
- Each reading, with the limit it was judged against when it was taken and the equipment it was taken on, as both were at the time. A later change to the limit or to the plant never rewrites an earlier reading. A trend built from readings judged against three different limits over a year is only usable if each reading still says which.
- A reading beyond one of the site's action limits is flagged as the number is typed, with the limit it crossed and the site's own response word. It opens an item in a Needs-attention queue that stays open until a manager or site administrator answers it, once, with the decision recorded against their name and the time. A reading back inside the limit never closes it.
- Something an operator has seen that no round asked about, in their own words, linked to a machine or an area, with their own answer to whether somebody needs to act on it.
- The gaps. A missed round stays visible as overdue until it is completed late or acknowledged with a reason. The trend for a point shows the windows that were missed alongside the readings that were taken. A reliability engineer who cannot see the gaps will trend a bearing that was not read for a fortnight as if it had been quiet.
- Append-only, enforced by the database. A re-check adds an entry; the earlier reading stays, attributed and marked superseded. Corrections are added, never written over.
Getting it to the reliability side
A record the reliability engineer cannot reach is a binder with better handwriting. Amberhold gives it out three ways:
- Readings as CSV, or through a read-only Readings API with the same columns, into Excel, Power BI or any system that can read REST. Power BI, Power Automate and a plain REST pull have each been connected to a live Amberhold site, unattended, and the site's access register recorded every pull.
- A trend view for each point in the product, including the windows that were missed. The CSV and the API carry the readings that were taken; the gaps are shown in the trend view.
- A full export of the site's records, run by a site administrator from Settings, with every run recorded — and, at the end of a pilot, an Operational Evidence Report: rounds completed, checks missed, exceptions and their dispositions, temporary controls declared and cleared, audit history.
Where your CMMS takes over
Your CMMS — SAP PM, Maximo, whichever — is the system of record for maintenance: notifications, work orders, spares and history against the asset register. It answers “what work was done on this equipment?” Amberhold answers “what did the plant look like between the work?” It records against the equipment names and functional locations your plant already uses, so that a finding on a round can be raised in the CMMS against the same equipment by the people whose job that is.
Amberhold does not raise work orders and writes nothing into your CMMS. The Readings API is read-only, so nothing in your maintenance system is touched by it. SAP PM and Maximo can read that API the same way Power BI does; nobody has connected either yet, and we will say so until somebody has.
What it is not
Software is sold under this heading with large claims attached, and a site evaluating any of it — ours included — should hold the vendor to the boundary.
- Amberhold does not predict failures, diagnose causes or calculate OEE. It gives the people who do those things the operator record they have been working without.
- It is not an alarm, a protection system or a process-control system. Your plant's alarms are unchanged. A reading beyond a site limit is flagged at the point and opens an attention item; that is a comparison with your own numbers, not a verdict on the plant.
- It does not turn an observation into a work order. Other rounds products do. We think the work order belongs in the maintenance system, raised by somebody who has read the finding.
- It does not certify compliance or make a plant safe. It supports the people who do.
For the operator
None of this works if the round gets harder. Digital rounds should not make the operator's job harder just to give management a better record. A programme that adds data entry to a shift and gives the operator nothing back will be walked badly within a month, and the record will show it. Amberhold has to do both: a round that is simpler to do properly on a phone, and a record the maintenance side can use. If it is not simpler for the operator, the second half never arrives.
Questions we actually get asked
- Is operator-driven reliability the same as autonomous maintenance?
- They overlap and are often run together, but the emphasis differs. Autonomous maintenance, one of the pillars of Total Productive Maintenance, has operators doing light maintenance on their own equipment: cleaning, inspecting, lubricating, tightening. Operator-driven reliability has operators watching, measuring and reporting, so that the maintenance and reliability side can decide what to do. On most sites the same round carries both, and the record question is identical: did what the operator found reach anyone who could act on it?
- Does Amberhold raise notifications or work orders in our CMMS?
- No. Amberhold does not raise work orders and writes nothing into your CMMS. A flagged reading or a finding is recorded against the equipment, and a manager or site administrator records what was decided about it. Raising the work in SAP PM or Maximo stays with the people whose job that is, and the completion of that work is recorded there, not in Amberhold.
- Can our reliability engineer trend the readings?
- Yes, in the tools they already use. Readings come out as CSV or through a read-only API with the same columns, into Excel, Power BI or anything that reads REST, each reading carrying the limit it was judged against at the time. Amberhold itself shows a trend for each point, including the windows that were missed. The CSV and the API carry the readings that were taken; the gaps are shown in the trend view.
- Does Amberhold integrate with SAP PM or Maximo?
- Both can read the same Readings API that Power BI and Power Automate have been connected to on a live site. The contract is published and the API is read-only, so nothing in your maintenance system is touched. Nobody has connected SAP PM or Maximo yet, and we will say so until somebody has. Amberhold records against the equipment names and functional locations your plant already uses, so what comes out lines up with what your CMMS already knows.