“Line 3 is at 62% OEE. Budget target is 75%. The review runs forty minutes. Everyone leaves with the number in their head, and nobody knows which machine to touch on Monday morning.”
A metric you have tracked for three years that has never triggered a single action is not a management metric. It is a ritual.
OEE is probably the most displayed and least acted-upon number in manufacturing. It gets calculated, projected onto a shop-floor screen, compared to budget, compared to the plant next door. Then nothing. It does not tell you what to do, and that is not a flaw in the metric: it was never designed to.
When Seiichi Nakajima formalised TPM in the late 1980s, the output of the calculation was not the percentage. It was the breakdown into six big losses. The percentage exists only to verify that the breakdown adds up — it is a checksum, not a conclusion. The inversion happened for a very mundane reason: a percentage fits in a dashboard cell and compares across sites, six losses do not. So the industry kept the number and threw away the reasoning.
Article #1 in this series showed how MTBF, MTTR and availability lie about the measurement itself. OEE has a different and more awkward problem: it does not lie. It is arithmetically correct and operationally unusable, because the form in which it is displayed has destroyed the information you needed in order to decide.
Three blind spots explain the gap between an OEE that is diligently tracked and an action plan that never arrives. At the end, a five-minute test will tell you which of the three applies to you first.
The composite destroys exactly what you are looking for
OEE = Availability × Performance × Quality. Three numbers go in, one comes out. That is a lossy compression: from “60%” nobody can recover the three factors. And the three factors are where the only thing a plant manager actually cares about lives — what to do on Monday.
Three plants report the same 60%. Look at what sits behind it.
| Avail. | Perf. | Quality | The actual work | |
|---|---|---|---|---|
Plant A | 62% | 98% | 99% | Reliability and changeovers: the machine sits idle a third of planned time |
Plant B | 96% | 64% | 98% | Minor stops and under-speed: the machine runs, just not at the rate it should |
Plant C | 95% | 96% | 66% | Settings, material and start-ups: a third of output is scrapped or reworked |
Same score. Three action plans with not a single line in common. Plant A needs a reliability programme and SMED; Plant B needs a minor-stop hunt; Plant C needs work on settings and incoming material. Anyone who reports only “60%” has destroyed the one piece of information that made the call possible — and nobody notices, because the number looks complete.
The mirror trap: 95 × 95 × 95 = 85.7%
Nakajima's world-class threshold was never a single target. It is a triplet: roughly 90% availability, 95% performance, 99% quality — whose product lands near 85%. A plant hitting 85% by running 95 / 95 / 95 is therefore not world-class in the TPM sense: it has three open projects, including a quality gap four times wider than the target. The composite rewards balance, not excellence — and it congratulates you while you lose five points on each of three factors.
The fix is one rule, and it costs nothing: never publish an OEE without its three factors beside it. Not in an appendix, not on request — on the same row, in the same table, on the same shop-floor screen. An OEE on its own is not an incomplete metric, it is an unusable one.
The denominator is a decision, not a measurement
Availability divides run time by planned production time. The whole argument lives in that denominator, and it is not measured — it is decided. Breaks, changeovers, scheduled preventive work, no-demand periods, team meetings, mandated test runs, end-of-shift cleaning: every exclusion mechanically raises the score, and every one of them can be defended honestly in a meeting.
The same shop floor, the same week, the same real output can therefore report anywhere from 45% to 92% depending on where the line is drawn. None of those numbers is a lie. That is precisely the problem.
Two names in English, three in the French standard
English practice recognises two rungs on this ladder: OEE against planned production time, and TEEP against all calendar time. The French standard NF E60-182 is more explicit and names three, distinguished only by their denominator — and the middle rung is the one worth knowing about, because English has no common word for it.
| Indicator | Denominator | The question it answers |
|---|---|---|
| TRS = OEE | Planned production time the time you decided to run | “When I run, am I any good?” |
| TRG no common English name | Opening time + no-demand periods, planned maintenance | “Is my open shop floor being used?” |
| TRE ≈ TEEP | Total calendar time + closures, nights, weekends | “Is my capital being used?” |
The confusion is not a semantic detail. On a shop floor running two shifts out of three, the middle indicator lands at roughly two thirds of the OEE for the very same week of production. Two people quoting “our OEE” without saying which denominator they used are having a conversation about nothing — and that is the single most common reason a group-wide OEE comparison produces a ranking nobody trusts.
Maintenance knows the same distinction under another name: ISO 14224 §3.51 establishes that operating time is not calendar time. This is why a serious CMMS derives the denominator from the asset operating schedule — a 5×8 asset and a 7×24 asset do not have the same planned time — instead of counting raw calendar hours. Comparing their availability without that correction is meaningless.
Worse than a wrong denominator: a moving one
Add a shift, move preventive work to Saturday, reclassify a changeover as a “planned stop”: OEE goes up without one single thing changing on the floor. The time series then becomes a blend of real performance and convention changes, and nobody can separate the two any more. Freeze the definition of planned production time in writing, date it, and treat any amendment as a break in the series — exactly like a change of accounting method.
The direct consequence is uncomfortable: cross-site benchmarking is folklore until planned production time is written down. The site “doing 82%” against your 68% may simply have a more generous definition. Before concluding anything about industrial performance, ask for the definition. In most groups, it exists nowhere in written form.
The Six Big Losses never turn into an action
Nakajima's six losses are the real contribution of TPM. They pair up two by two under each of the three factors, and each one calls for a completely different kind of work.
| Factor | Loss | How it gets captured |
|---|---|---|
| Availability | Breakdowns and unplanned stopsThe equipment stops, a repair starts | Automatic as soon as a work order takes the equipment down |
| Availability | Setup and adjustmentA deliberate stop to switch from one product to another | Must be declared: arithmetic cannot tell a changeover from a breakdown |
| Performance | Idling and minor stopsJam, sensor, waiting on material — a few minutes, never logged | Must be observed: without sensors, a tally sheet over two or three shifts |
| Performance | Reduced speedThe machine runs below its nameplate rate | Automatic: it is run time minus ideal cycle time × units produced |
| Quality | Defects and rework in steady stateNon-conforming parts produced mid-shift | Automatic once good and total counts are entered |
| Quality | Start-up and yield lossesThe first parts after a restart or a changeover | Must be timestamped, otherwise it blends into ordinary scrap |
Three of the six measure themselves. The other three do not.
This is the structural trap, and it is barely discussed. The totals per factor fall out of the arithmetic for free: availability loss is planned time minus run time; performance loss is run time minus ideal cycle time times units; quality loss is ideal cycle time times rejects. Three subtractions, no extra data entry.
But those are three factor totals, not six losses. To separate a breakdown from a changeover, somebody has to declare it. To separate a minor stop from slow running, you need a counter or an observation. To separate start-up scrap from steady-state scrap, you need a timestamp. Without that, the tool files everything into the most likely bucket and you end up with a three-bar Pareto — which looks complete, is not, and whose three missing bars are exactly the ones Lean handles best: SMED, the minor-stop hunt, and start-up yield.
An undeclared minor stop does not vanish. It changes bucket.
On a typical line, roughly 60% of stoppages last under fifteen minutes and never cross the work-order threshold — that was the subject of article #1. The consequence here is sharper, and nastier. Because the line was never declared down, run time stays high while output stays low: the lost time reappears as a performance loss. Your Pareto then points at “reduced speed”, and you send someone to check the rate settings on a machine whose real problem is that it jams four times an hour.
Even a correct Pareto is still just a picture
Suppose the split is right. One thing is still missing, and it is the only thing that turns a measurement into a result: a chain linking the loss to a named improvement project, the project to a root-cause analysis, the analysis to a dated action, and the action to a re-measurement. Without it the Pareto gets presented every month, it is correct, and it stays identical for two years.
- • The Pareto is projected at the monthly review
- • The loss stays a percentage
- • The action lives in meeting minutes
- • Nobody re-measures the bar next month
- • The top bar becomes a named project, with an owner
- • The loss becomes an analysed cause (5 Whys, Ishikawa, A3)
- • The action has a date, an owner, a register
- • The bar gets re-measured: that is the proof
The chain that has to exist
Break one link and OEE reverts to what it is almost everywhere: a number people comment on.
What the tool has to carry (and what it cannot)
None of the above requires a budget. But four things have to be carried by the tool, otherwise they rest on somebody's personal discipline — and personal discipline does not survive a retirement.
Availability is read, not re-entered
The downtime is already captured: every time a work order took a piece of equipment out of service, that span exists in the database. It should be summed over the shift window and offered, not retyped from memory on Friday evening. Downtime reconstructed from memory is precisely the subject of article #3 in this series.
Planned time comes from the operating schedule, not the calendar
A 5×8 asset and a 7×24 asset do not share a denominator, and the gap is not marginal — it is a factor of three. The operating schedule is a property of the equipment, so it should be applied automatically (ISO 14224 §3.51), never left to whoever is filling in the box.
The three factors are never frozen in the database
If you correct a downtime record three days later, history has to correct itself with it. An OEE stored at calculation time stays wrong forever — and that is worse than having no OEE at all, because nobody knows it is wrong. The factors should be recomputed on read, from the raw inputs.
Every loss carries a button, not just a bar
The Pareto bar should open an improvement project already linked to the equipment concerned. This is the most frequently missing link: between the chart and the action register there is almost always a manual copy-paste that nobody performs.
The honest limit, here as anywhere else
In FreeMaint, availability is pre-filled from downtime already captured and planned time is derived from the asset operating schedule; the three factors are recomputed on every read, never stored; and each Pareto loss opens a Kaizen already linked to the equipment. On the other hand, ideal cycle time and the good / total count are still entered by hand: they come from production, not from maintenance. And until losses are itemised explicitly, the Pareto shows the three factor totals rather than the six losses. That is the limit of any CMMS not wired into a supervision layer, and it is better known than discovered: the six losses do not split themselves.
Key takeaways
The percentage is not the deliverable. Never publish an OEE without its three factors on the same row.
The denominator is a decision. Write down the definition of planned production time, date it, and treat any change as a break in the series.
OEE, the middle indicator and TEEP are not synonyms (NF E60-182). Always state which one you are quoting, especially across sites.
Three of the six losses fall out of the arithmetic, three require deliberate capture. A three-bar Pareto is not a complete Pareto.
An undeclared minor stop does not disappear: it is reclassified as a speed loss and sends you looking in the wrong place.
Without the chain loss → project → cause → action → re-measurement, the best OEE in the world is still a number people comment on.
The five-minute test, to run this week
Take three people who regularly talk about OEE: the plant manager, the production lead, the controller. Ask each of them to write down, separately and without conferring, what is excluded from planned production time. Then compare the three sheets.
If they differ — and in the large majority of plants they do — your OEE is an opinion rather than an indicator, and no action plan can come out of it. The good news: the half hour of discussion that follows will be the most useful of your quarter, and it costs nothing.
References
- • NF E60-182 — Manufacturing systems, performance indicators: overall equipment effectiveness (TRS), overall equipment performance (TRG), total effective equipment performance (TRE)
- • Seiichi Nakajima (1988) — TPM: An Introduction to Total Productive Maintenance, the historical reference on the OEE breakdown and the Six Big Losses
- • ISO 14224:2016 §3.51 — operating time, distinct from calendar time
- • SEMI E10-0814 — Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM), for a finer equipment-state taxonomy
More in this series
Your downtime is already captured. Use it.
FreeMaint pre-fills availability from the downtime your work orders already recorded, derives planned time from each asset operating schedule, and turns every Pareto loss into an improvement project. Free to start.
Frequently asked questions
What is the difference between OEE and TEEP?
Only the denominator. OEE divides valuable operating time by planned production time, meaning the time you decided to run: that is Availability × Performance × Quality. TEEP divides the same numerator by all calendar time, weekends and closures included, so it answers a capital question rather than an operations one. Use OEE to steer a line day to day, and TEEP when you are deciding whether to add a shift or buy another machine. The French standard NF E60-182 is more explicit and names three indicators instead of two, adding a middle one, TRG, measured against opening time. That middle rung has no common English name, which is exactly where most cross-site confusion lives.
What is a good OEE?
The famous 85% world-class threshold comes from Nakajima, but it was never a single target: it is a triplet, roughly 90% availability, 95% performance and 99% quality, whose product lands near 85%. A plant reaching 85% through 95 / 95 / 95 is therefore not world-class in the TPM sense, it has three open improvement projects. Beyond that, an OEE is only comparable to itself over time, on a fixed scope with a written definition of planned production time. A good OEE is one that improves, not one that beats the plant next door.
How do you measure minor stops without sensors?
Without automated monitoring, direct observation over a short window is still the only reliable method: an operator or technician ticks every stop on a sheet across two or three full shifts, with the cause in three words. It is a sample, not a permanent measurement, and a sample is enough because the goal is a Pareto, not an accounting record. The clue that you need to run it: a large performance gap while availability looks excellent, which is the classic signature of minor stops that were never declared.
Do you need an MES to calculate OEE?
No to get started, yes to split the six losses properly. A monthly OEE per line needs four numbers you already have: planned production time, downtime, ideal cycle time, and good versus total count. A CMMS supplies the downtime already captured by work orders plus each asset operating schedule. An MES or SCADA layer becomes necessary when you want to separate minor stops from reduced speed automatically, or timestamp scrap to isolate start-up losses. Start without one, and add automated capture exactly where the Pareto tells you it will pay off.