Skip to content

Planned vs. Reactive Maintenance KPIs

By Martin Brandel · Last updated: April 2026

What the planned-vs-reactive KPI set actually measures — and why the number your CMMS shows is usually wrong

Planned-vs-reactive maintenance KPIs — Planned Maintenance Percentage (PMP), Schedule Compliance, MTBF, MTTR, and the reactive-work-order share — measure how much of a plant's maintenance effort is performed on a schedule the organisation controlled versus how much was forced on it by a breakdown. On paper, the ratio is simple: planned hours divided by total hours, times one hundred, target above 60–70 %. In practice, in more than three decades of commissioning automation and retrofitting brownfield plants — Simatic S5 through TIA, food and beverage, metal processing, paint lines in Eastern Europe and China — I have seen the CMMS-reported PMP number disagree with operational reality about four times out of five. The number is not lying because the CMMS is broken. It is lying because the CMMS records work-order closure, and work-order closure is the weakest link in the data chain — the place where an overworked technician can make the metric look good by ticking a checkbox while the underlying work was never done. This article is the engineering view of what these KPIs really mean, where they break, and why the only reliable version of them is the one computed from the intersection of CMMS work-order data and MES machine-event data — not from the CMMS alone.

The terminology layer — DIN EN 13306, EN 15341, ISO 14224, VDI 2890

Four standards define the vocabulary that any useful conversation about maintenance KPIs has to respect. They are not interchangeable, and the benchmark numbers you read in industry press typically assume one of them without saying which:

Standard What it defines Why it matters here
DIN EN 13306 Maintenance terminology — preventive, corrective, predictive, condition-based. Clarifies what counts as "planned" and what does not. Condition-based maintenance is planned; emergency corrective is not. Most internal disputes about PMP trace back to this line.
EN 15341 Maintenance Key Performance Indicators — 71 KPIs in three groups (economic, technical, organisational). The European reference for how PMP, Schedule Compliance, MTBF, MTTR are formally calculated. When a benchmark says "PMP 70 %", it should mean EN 15341 O.01 or equivalent.
ISO 14224 Reliability and maintenance data collection model (originally petroleum industry; now cross-sector). The definitive data model for what a failure event looks like, what a maintenance action is, and how they link. This is the schema the CMMS should (but rarely does) use natively.
VDI 2890 German engineering guideline for planned maintenance of technical systems. Particularly relevant for the DACH mid-market — defines the structure of preventive maintenance plans that a German auditor expects to see.

The practical implication: before any argument about "our PMP is 72 %" can be had usefully, the participants need to agree which standard they are using and whether condition-based maintenance is counted as planned (EN 13306 says yes; some internal CMMS configurations implicitly say no). I have walked into several customer sites where the PMP dispute between maintenance manager and plant manager turned out to be a definition dispute, not a data dispute.

The work-order typology — five buckets, not two

The "planned vs. reactive" framing is a useful simplification that breaks under load. In reality, maintenance work falls into at least five categories, and the honest PMP calculation requires that each category is tagged correctly in the CMMS and matched against what the MES saw happen on the machine:

Work-order type Trigger Counts as planned? MES signature
PM — Preventive Maintenance Time- or usage-based schedule (every 500 h, every quarter). Yes Planned-stop downtime class, scheduled in advance, matches MES maintenance window.
PdM — Predictive Maintenance Condition indicator (vibration, temperature, current signature) crosses threshold. Yes Planned-stop downtime class; MES holds the condition trigger.
CM — Corrective Maintenance (planned) Known defect, fix planned into next scheduled window. Yes — if the deferral is documented and the risk accepted. Planned-stop class, but the MES record should show the defect was tolerated for some hours before the window.
BD — Breakdown / Emergency Corrective Unplanned failure, production stopped. No — pure reactive. Unplanned-stop class; alarm signature before downtime start.
OT — Operator Care (TPM / Autonomous Maintenance) Operator-executed cleaning, inspection, lubrication per TPM standard. Separate bucket — neither CMMS PM nor CM. Typically outside the CMMS entirely; tracked in MES operator check-sheets.

The fifth bucket — operator care — is the one most commonly missed in PMP calculations, and it distorts the ratio in both directions. Plants with strong TPM cultures undercount their planned maintenance because operator care sits outside the CMMS; plants with weak TPM cultures overcount because maintenance staff end up doing operator-level tasks and booking them as PM.

PMP calculation — the formula, the fine print, and the benchmark

The canonical formula per EN 15341 organisational indicator O.01:

PMP = (Planned Maintenance Hours / Total Maintenance Hours) × 100

Where "planned maintenance hours" includes PM + PdM + CM-planned, and "total maintenance hours" adds BD (breakdown corrective). The SMRP equivalent metric — Proactive Work — is close but not identical; it additionally requires that the work order existed in the CMMS at least 7 days before execution (some definitions use 14 days), which tightens the definition in a way EN 15341 does not. When you are benchmarking against SMRP industry averages, the 7-day rule matters materially: a plant that tags a CM as planned because it was booked the morning of the shift satisfies EN 15341 but fails SMRP.

The benchmark numbers that any industrial organisation should know by heart:

KPI Weak Average Best-in-class
PMP (EN 15341) < 40 % 50–65 % > 75 %
Schedule Compliance < 60 % 70–85 % > 90 %
Reactive WO Share > 40 % 20–35 % < 15 %
MTBF trend (12-month slope) Flat or declining Modest positive +15 % YoY or better

The Reactive Ratio Trap — why a high PMP is not the same as a healthy maintenance organisation

The pattern I call The Reactive Ratio Trap is the most common misread of these KPIs. A plant reports PMP 72 %. The maintenance manager circulates the number at the monthly review. Everyone is satisfied. Six weeks later, a critical bearing fails on a main compressor, production stops for eight hours, and the post-incident review discovers that the preventive inspection that should have caught the bearing had been signed off in the CMMS three months earlier without the technician actually being on the machine that day. The PMP did not lie in the narrow sense — the work order closed on schedule, the hours were booked. It lied in the operational sense — the planned maintenance it purported to measure had not happened.

Three structural reasons this happens, every one of which I have seen multiple times in brownfield deployments:

  1. Closure-based measurement. PMP counts hours booked against closed work orders. It does not count whether those hours were spent on the asset. A technician under time pressure, with five more orders to clear, is incentivised to close the quick ones on paper and work on the urgent ones in reality.
  2. No cross-check against machine state. The CMMS does not know whether the machine was actually stopped during the preventive window. If the machine produced parts during the hour the "inspection" was supposedly performed, the inspection did not happen — but the CMMS cannot see that.
  3. Schedule compliance reported independently. PMP and Schedule Compliance are reported side by side without reconciling against the underlying event stream, so high PMP with 92 % schedule compliance looks exemplary on paper even when 30–40 % of those "compliant" orders were paper closures.

The Phantom PM — the specific failure mode in gated CMMS environments

A close relative, but distinct enough to name separately, is what I call The Phantom PM — the preventive maintenance order that exists, is scheduled, is assigned, is closed on time, earns a green mark in the CMMS dashboard, and whose actual execution is either partial, delegated to the wrong person, or simply did not occur. The Phantom PM is particularly common in three situations:

  • End-of-month closure pressure. The maintenance team's bonus depends on schedule compliance. Twenty-seven orders are open on the 28th of the month. Everyone works until midnight. Some orders close honestly. Some close with "visual inspection complete, no action required" as the default note because the clock ran out.
  • Cross-shift handoff gaps. A 4-hour PM starts on late shift, is not completed, is handed off to night shift, who did not get the full brief, who close the order in the morning with a boilerplate comment.
  • Remote plants without on-site supervision. A satellite plant with three maintenance staff and no supervisor on weekends. The CMMS cannot enforce what happens physically on a Sunday afternoon.

The only structural defence against the Phantom PM is independent verification from an external system — and in industrial plants, the only always-on external witness to what actually happened is the MES. This is the architectural point on which the rest of the article hinges.

The CMMS-MES Handshake — the architectural pattern that makes these KPIs honest

The positive counter-pattern is what I call The CMMS-MES Handshake — the bidirectional sync between the maintenance management system and the manufacturing execution system that binds every work order to an observed machine-event stream, and refuses to let a work order close if the events disagree:

Direction What is exchanged What the receiving system does with it
CMMS → MES Planned maintenance windows (asset, start, end, WO number). MES pre-tags the upcoming downtime as "planned maintenance" and expects a corresponding machine stop.
MES → CMMS Unplanned stop events with duration, alarm code, operator reason. CMMS auto-creates a reactive (breakdown) work order; no human creation step.
MES → CMMS (verification) Machine state during planned window (stopped vs. producing). Work-order closure blocked if machine was producing during the planned maintenance window.
CMMS → MES (closure) Completed work order with root cause, parts consumed. MES enriches its downtime record with maintenance details for reliability analysis.

Under this handshake, PMP becomes a reconciled number. A closed PM work order whose planned window overlaps with a period the MES recorded as "producing" is either auto-flagged for review or outright rejected. The MTBF calculation draws on the MES event stream for failure counts, not on the CMMS's record of what it was told was a failure. MTTR draws on MES-observed downtime duration, not on technician-reported hours. The result is a KPI set that cannot be gamed by work-order discipline alone — the physics of the machine is co-signing every number.

Implementing this handshake is not as hard as most plants assume. The CMMS side needs a standard API (REST or OPC UA) for work-order exchange — SAP PM, IBM Maximo, Infor EAM, proAlpha IH, and most mid-market CMMS products support this out of the box. The MES side needs downtime classification with enough granularity to distinguish planned from unplanned stops — which any serious MES has had since the mid-2000s. The actual integration effort is typically 2–4 weeks for a pilot and 6–10 weeks for a multi-plant rollout, and the resulting KPI credibility is the single most valuable output of the maintenance-digitalisation programme.

MTBF, MTTR, and the Interpretation Gap that breaks most reliability programmes

The two headline reliability KPIs — Mean Time Between Failures and Mean Time To Repair — are useful when their denominators are honest and dangerous when they are not. The pattern I call The MTBF Interpretation Gap is the space between what the formula returns and what decision-makers think it says:

  • MTBF is an average, not a floor. An MTBF of 140 hours does not mean the asset runs 140 hours before failing. It means that across some sample of failures, the mean interval was 140 hours. If the distribution has a long tail, half the failures may occur within 50 hours.
  • MTBF is asset-specific, not fleet-specific. Aggregating MTBF across a fleet of mixed assets produces a number that is mathematically correct and operationally meaningless. Two 200-ton presses with MTBF 300 and a 1990s conveyor with MTBF 20 produce a fleet MTBF that reflects neither asset.
  • MTTR includes wait time, not just wrench time. A proper MTTR measures from failure detection to production resumption. It includes diagnosis, spare-parts logistics, technician travel, documentation. Plants that report MTTR as wrench-time only systematically understate the cost of failures.
  • Both depend on failure definition. A "failure" counted per ISO 14224 includes only events that required corrective action. Micro-stops under five minutes that the operator cleared by restart are typically excluded — but some plants include them, which drives MTBF down dramatically and makes cross-plant benchmarking impossible.

The practical discipline: report MTBF and MTTR per asset class, with the failure definition explicit, with the sample size shown, and with a confidence interval where the sample is small. A plant that reports "MTBF 140 h" without this context is producing a number, not an insight.

The Brownfield Reactive Lock-In — why aged plants cannot simply decide to be more planned

A point that is easy to make at a conference and harder to make at a plant: the target of PMP above 70 % is achievable on a fleet of modern assets with good instrumentation, a populated CMMS history, and a stable production rhythm. It is structurally much harder — sometimes close to impossible — on a fleet that includes 1990s Simatic S5 machines, paper-based maintenance history, and the kind of ad-hoc production scheduling that mid-market manufacturers live with. The pattern I call The Brownfield Reactive Lock-In describes what happens when those constraints compound:

  • Failure data is thin. Without several years of recorded failures per asset class, PM intervals have no empirical basis and are set by manufacturer recommendation or vendor guess. Under-maintenance and over-maintenance both occur, and both drive up the reactive share.
  • Condition monitoring is absent. PdM requires sensors the old machine does not have. Retrofitting vibration, temperature, and current monitoring is possible — I have done hundreds of these retrofits — but it is an explicit project, not a CMMS configuration change.
  • Spare parts are long-lead-time. An S5 replacement card may have a six-week lead time. A failure of that card necessarily produces a long unplanned outage, no matter how well the CMMS was planned.
  • Production rhythm is unpredictable. If the plant runs 2-shift one week and 3-shift the next, pre-scheduling maintenance windows two weeks out is impossible — and the PM calendar becomes aspirational rather than operational.

The honest conclusion for brownfield mid-market operations: a realistic first-year target is PMP above 55 %, not above 70 %. The improvement trajectory matters more than the absolute number, and the trajectory is enabled by exactly the two things most brownfield plants resist: retrofit instrumentation on the critical assets, and the MES-CMMS handshake that makes the existing numbers honest. Only after those two foundations are in place does the >70 % target become a realistic 24–36-month project.

From a mid-size beverage filling operation in southern Germany, 2021: The customer was a regional beverage bottler running two filling lines and a CIP plant in a plant that had grown through acquisitions — roughly 220 employees, EUR 85 m annual revenue. They had been on SYMESTIC for OEE monitoring for two years and had just renewed their CMMS contract with a mid-market vendor widely used in the food and beverage segment. The maintenance manager — whom I had worked with on the original OT retrofit in 2019 — called me during a site visit to raise what he framed as a "weird observation". The CMMS dashboard had reported PMP 78 % for the previous quarter, Schedule Compliance 91 %. By any industry benchmark, this was exemplary. At the same time, his maintenance team was working permanent overtime, the plant manager was complaining about unplanned stoppages, and the line 2 filler — a 1998 KHS rotary filler that had been retrofitted with modern servos in 2016 — had gone down three times in the previous month on the same centering station. I asked him to pull the CMMS work-order export for the last 180 days and let me cross-reference it against the SYMESTIC MES downtime data for the same period. The reconciliation took an afternoon and produced the following picture. The CMMS had recorded 847 completed preventive maintenance orders across the two lines and the CIP in the period. For each, I checked whether the SYMESTIC MES had recorded the corresponding asset as stopped during the planned window. For 512 of them — 60 % — the match was clean: machine stopped, duration approximately matching the PM booking, no production during the window. For another 189 — 22 % — the machine had been stopped at some point during the broader day, but not precisely during the PM window booked in the CMMS; this was forgivable and reflected normal operational variability. For the remaining 146 orders — 17 % — the MES showed the machine was actively producing during the entire planned maintenance window. These were Phantom PMs in the strict sense: the CMMS said the work was done, the machine record said the work could not have been done. The centering-station failure root cause turned out to be one of them. A quarterly bearing inspection had been signed off three consecutive quarters without the line being stopped; the bearing was beyond its designed life and finally failed. Presenting these numbers to the maintenance manager was — and I say this with full respect for somebody who was a good engineer under difficult constraints — the most uncomfortable conversation I had that year. The technicians were not dishonest. They were managing a 15-year-old CMMS that demanded monthly closures, a 5-person maintenance team covering a 3-shift operation across two lines plus CIP, and a plant manager who tracked PMP as the single maintenance KPI that mattered. Phantom PMs were the path of least resistance through an impossible workload. The fix we built over the following two quarters had three elements. First, the SYMESTIC-CMMS handshake was implemented — planned maintenance windows from the CMMS pushed into the MES downtime classification, and a verification check that blocked CMMS work-order closure if the MES had seen the asset producing during the entire planned window. Second, the reactive-work-order creation was fully automated — any unplanned stop longer than 10 minutes auto-generated a CMMS ticket, removing the human booking step that had been a second-order source of under-reporting. Third, we reset the PM calendar against observed MES runtime — assets that ran 80 % of the time got more frequent preventive intervals; assets that ran 30 % of the time got fewer. The results over the following 18 months, measured in reconciled KPIs: honest PMP fell from the reported 78 % to a verified 41 % in the first reconciliation month, then rose through focused preventive-work investment to 62 % by month 18. MTBF on line 2 rose from 68 hours to 140 hours. Unplanned downtime on the filler fell 44 %. Overtime hours in the maintenance department fell 31 %. The reported numbers went down before they went up, and the plant manager — to his credit — accepted that this was progress, not regression. The lesson I have repeated at every mid-market customer since is that an unreliable high KPI is worse than an unflattering honest one. The high number produces decisions that assume a reality that does not exist; the honest number produces decisions that can actually change reality. In maintenance specifically, the distinction is the difference between a plant that is getting better and one that is merely getting comfortable with its firefighting.

The seven disciplines of trustworthy planned-vs-reactive KPIs

# Discipline Operational test
1 Work-order typology explicit (PM / PdM / CM / BD / OT). Every open and closed order has one of the five tags, enforced at CMMS creation.
2 PMP calculation per EN 15341 with standard declared. Dashboard footnote states which standard and which inclusion rule is in use.
3 CMMS-MES Handshake operational with closure verification. No PM order can close if MES shows the asset was producing throughout the planned window.
4 Reactive WO auto-creation from MES events. Unplanned stop > configured threshold → CMMS ticket; no manual creation step.
5 MTBF / MTTR reported per asset class. No fleet-level averaging across mixed asset types.
6 Schedule Compliance reconciled against MES runtime. Apparent compliance excludes Phantom PMs; trend reports honest compliance.
7 Brownfield realism in target-setting. First-year PMP target reflects asset age and instrumentation maturity, not generic 70 %.

FAQ

What is the difference between planned and reactive maintenance KPIs?
Planned maintenance KPIs — Planned Maintenance Percentage (PMP), Schedule Compliance, MTBF trend — measure maintenance activity that was scheduled and resourced in advance. Reactive maintenance KPIs — reactive work-order share, MTTR, breakdown downtime — measure maintenance forced on the organisation by unplanned failures. The gap between the two sets of numbers is the gap between a maintenance organisation that controls its workload and one that reacts to it.

What is a realistic PMP target for a mid-market brownfield plant?
First-year target 50–55 %, two-year target 60–65 %, three-year target above 70 % — contingent on retrofit instrumentation on critical assets and an operational CMMS-MES handshake. Plants that set a first-year target above 70 % without these foundations in place typically achieve the number on paper only, via the Phantom-PM mechanism described above.

What is The Reactive Ratio Trap?
The pattern where a plant reports an apparently healthy PMP (typically 70–80 %) while the maintenance organisation operates in continuous firefighting mode. The trap exists because PMP measures work-order closure rather than work-order execution, and closure can be gamed under time pressure. The defence is the CMMS-MES handshake — binding every closure to an independent machine-event witness.

What is a Phantom PM?
A preventive-maintenance work order that exists in the CMMS, is scheduled, assigned, and closed on time — but whose actual execution was partial, delegated wrongly, or did not occur. Phantom PMs are not the result of dishonest technicians; they are the result of CMMS workload pressure combined with the absence of an independent verification layer. They are the single most common reason reported PMP overstates reality.

How do MTBF and MTTR interact with PMP?
A rising PMP should, with a typical lag of 6–12 months, produce a rising MTBF (fewer failures because preventive work actually happened) and a falling MTTR (fewer emergencies, so repairs happen under controlled conditions with correct spares). If PMP rises without MTBF following, the PMP increase is almost certainly Phantom-PM inflation. This three-way triangulation is the most reliable test of maintenance data honesty.

What is the CMMS-MES Handshake?
The bidirectional integration between the maintenance management system and the MES that binds every work order to observed machine-state data. Planned maintenance windows flow from CMMS to MES as downtime pre-classifications; unplanned stops flow from MES to CMMS as auto-created reactive work orders; work-order closure is verified against MES machine state during the planned window. This handshake converts PMP from a closure-based metric into an event-reconciled metric — the single architectural decision that separates trustworthy maintenance KPIs from paper KPIs.

Which standards define these KPIs?
Four. DIN EN 13306 defines the maintenance terminology (preventive, corrective, predictive, condition-based). EN 15341 defines 71 maintenance KPIs including PMP (O.01), MTBF, MTTR, and Schedule Compliance. ISO 14224 defines the reliability-data model — what a failure event is, what a maintenance action is, how they link. VDI 2890 is the German engineering guideline for planned-maintenance structures. Any serious KPI conversation should declare which standard's definitions are in use.

Does PMP work for operator-led TPM activity?
Not directly. Operator care — autonomous maintenance in TPM terminology — is a fifth work-order bucket that sits outside the CMMS and outside the PMP calculation. Plants with strong TPM cultures should track operator care separately (via MES operator check-sheets) and report it alongside PMP, not folded into it. Combining the two produces a metric that obscures both.

How does the reactive maintenance share relate to OEE?
Reactive maintenance is the primary driver of the availability component of OEE. A plant that reduces its reactive share from 35 % to 15 % typically sees availability improvements of 4–8 percentage points over 12–18 months, depending on asset mix. The effect is larger on older assets and smaller on already-reliable assets. The MES that holds the OEE data is the same system that feeds the reactive work orders into the CMMS — the handshake makes both improvements measurable from the same source of truth.

Can a plant skip the CMMS-MES integration and just improve CMMS discipline?
In principle, yes. In practice, no. I have not seen a plant sustain an honest PMP above 65 % without the integration. The workload pressure on maintenance staff and the reward pressure from management both push toward Phantom-PM closure unless there is an independent witness that cannot be gamed. The MES is that witness, and it is already present in any plant that has operationalised OEE monitoring. Not using it for maintenance KPI verification is leaving the most valuable piece of the data infrastructure unused.


Related: MES: definition, functions & benefits · OEE · Downtime monitoring · Machine data integration · Production data acquisition · Real-time production data · Predictive maintenance · Condition monitoring · TPM — Total Productive Maintenance · Alarm management · Shop floor control · Industrial data historian · Audit trail · Schedule adherence · Energy monitoring · Composable MES · Production metrics · Alarms · For metal processing · For food & beverage manufacturers · For maintenance managers · For COOs & plant managers. External references: ISO 14224 — Reliability & maintenance data collection · DIN EN 13306 — Maintenance terminology · EN 15341 — Maintenance KPIs · VDI 2890 — Planned maintenance · SMRP Best Practices · Plant Engineering — Maintenance industry reference.

About the author
Martin Brandel
Martin Brandel
MES Consultant & Project Lead at SYMESTIC GmbH. Over 30 years in industrial automation. Dipl.-Ing. Nachrichtentechnik. Career path: Automation engineer at Ing. Büro Jürgen Albert 1991–1995 (Simatic S5, material-flow control, COROS visualisation systems), automation engineer at Hermos AG 1995–2000 (large-scale projects in Eastern Europe and China — conveyor systems, process engineering, paint lines), Head of Automation at ODEVIS GmbH / SYMESTIC 2000–2018 (built and led the department for eleven years, developed the software standard for process-engineering installations in the beverage and wood industries, retrofit projects Simatic S5 to S7 and TIA). Since 2019 MES Consultant and Project Lead — from initial inquiry through go-live: machine-park analysis, connectivity strategy, data capture setup, KPI configuration, operator training. Expertise: machine data acquisition (MDE), operational data acquisition (BDE), PLC programming (Simatic S5, S7, TIA Portal), retrofit engineering, OPC UA, IoT gateway integration, brownfield connectivity, process control systems, material-flow control, CE conformity, MES project management, CMMS-MES integration, maintenance KPI architecture. · LinkedIn
Start working with SYMESTIC today to boost your productivity, efficiency, and quality!
Contact us
Symestic Ninja