Define the change
Moving from reactive to preventive maintenance does not mean scheduling every possible task. It means replacing selected after-failure work with planned work when there is a defensible reason to expect the task and interval to manage the relevant failure mode.
The US Department of Energy's current guidance describes reactive work as repair or replacement after failure, preventive work as scheduled time-based maintenance, predictive work as intervention informed by condition measures, and reliability-centred maintenance as a mix selected for the equipment and context. It does not prescribe one ideal planned-to-unplanned ratio or transition time.
Deliberate run-to-failure can remain appropriate where consequences are understood and acceptable. Statutory, safety and manufacturer requirements remain separate constraints. Write down those boundaries before deciding what to change.
Build an operation-specific case
A business case needs your own denominator and costs. Define the assets, sites, shifts, work categories and measurement period. Then record reactive event count, direct repair cost, downtime, emergency labour, repeat failures and deferred planned work.
Model the planned scenario separately: task labour, parts, consumables, service interruption, software, setup, training and recurring administration. Avoid counting downtime twice when it is already represented in another input. The maintenance savings calculator exposes a simple input-based scenario, including a planned-work allowance. It is not a benchmark, quote or forecast.
Published research can provide context, not a substitute for that baseline. A 2021 NIST-published observational study analysed 71 usable, self-reported responses from US discrete manufacturers. In that sample, the group characterised as less reactive reported 52.7% less unplanned downtime. The authors say this grouped comparison should be treated as anecdotal evidence and note limitations including the small sample and self-reported data. The association is not a causal estimate for your operation or a MapTrack outcome. Read the NIST publication with its scope intact.
Establish the baseline
Do not begin by setting a generic maturity score. Begin by making the current work visible. A useful baseline includes:
- An asset register with ownership, location and criticality.
- A consistent definition of planned, unplanned, emergency and deferred work.
- Failure modes and cause codes, including an honest “unknown” option.
- Work start, restoration and completion times with their source.
- Direct labour, parts and external service costs.
- Planned operating time, utilisation or another explicit denominator.
Preserve the raw baseline. If definitions or scope change during the programme, report the break rather than silently blending two different measures.
Select work by failure mode
Rank failure modes by consequence, recurrence, downtime and cost. For each material mode, ask whether a task can detect, delay or prevent it, what evidence supports that task and how the interval was chosen.
- Start with mandatory tasks and clear manufacturer requirements.
- Use your own inspection findings and failure history to test other tasks.
- Do not assume a time-based service will address an unrelated random failure.
- Record parts, skills, access, isolation and approval requirements before scheduling the work.
This selection step protects the programme from becoming a growing list of low-value tasks. It also gives technicians a clear reason for each planned intervention.
Configure and pilot
The sequence below is illustrative, not a promised calendar. Move to the next stage when the records, people and operating controls are ready.
- Configure: create the selected schedules, job steps, responsibilities and escalation rules.
- Prepare: confirm parts, competent people, access and time are available before the first due date.
- Pilot: use a bounded asset cohort and preserve a comparable baseline or comparison group where practical.
- Record: capture due, completed, overdue and deferred work, findings, failures, costs and service interruption.
A maintenance system can help create schedules, issue work orders and retain service records. It cannot choose the correct maintenance task, make missing operational capacity available or prove that the task caused an outcome.
Evaluate before scaling
Compare the pilot with the defined baseline using the same event definitions, asset scope and denominators. Report the distribution, not only an average: a few long events can dominate downtime while a high count of small events can dominate workload.
Review at least these questions:
- Was the planned task completed as designed?
- Did it find or affect the intended failure mode?
- What planned work, interruption and administration did it add?
- Did workload, asset use or operating conditions change?
- Were any new faults introduced during intervention?
- Is the evidence strong enough to expand, revise or stop the task?
A target is not an observed result. Keep the two fields separate in reports and business cases.
Sustain the control
Preventive maintenance remains useful only while the underlying task, interval and execution are reviewed. Assign an owner for every schedule and retain the evidence behind changes.
- Review overdue and deferred work with reasons, not just totals.
- Investigate repeat failures and ineffective tasks.
- Change intervals through a controlled review of requirements, findings and failure data.
- Retire tasks that add cost or intervention risk without a defensible benefit.
- Re-baseline transparently when the asset population or operating context changes materially.
The goal is not the highest possible share of planned work. It is a maintenance mix that manages the actual failure consequences at a cost and risk the operation can defend.
