Measuring OEE and downtime without lying to yourself

The math, briefly and precisely

OEE is availability times performance times quality. Availability: run time divided by planned production time. Performance: actual output divided by theoretical output at ideal cycle time for the time run. Quality: good units divided by total units. Multiply the three and you get the fraction of planned time that produced sellable product at rated speed. An 85 percent OEE — the commonly cited world-class benchmark for discrete manufacturing — means fifteen percent of planned capacity still evaporated.

The definitions hide the politics. 'Planned production time' is where numbers get negotiated: exclude enough — changeovers, breaks, meetings, 'scheduled' cleaning that is actually recurring failure recovery — and availability climbs without anything improving. The discipline is to publish written definitions of what counts as planned downtime, freeze them, and change them only with a documented restatement of history. An OEE trend measured against shifting definitions is fiction with decimal places.

Also resist the single-number trap. A composite OEE of 65 percent tells you something is wrong but not what. The three factors point at different owners: availability problems belong mostly to maintenance and changeover process, performance losses to equipment condition and minor stops, quality losses to process control. Report the factors, always, alongside the composite.

Why manual downtime logs fail

Manual downtime logging fails for structural reasons, not lazy operators. Short stops — the two-minute jam, the sensor re-home, the starve from upstream — are the majority of events on many lines, and nobody logs a two-minute stop while restarting a machine. Studies comparing manual logs with automatic capture routinely find manual logs missing a large share of total downtime, with the gap concentrated in exactly these micro-stops. Your log shows the big breakdowns; your losses hide in the events too small to write down.

Categorization decays too. End-of-shift entry produces reasons remembered hours later, filtered by what is easy to type and safe to say. 'Mechanical fault' becomes a bucket holding jams, starvation, and one genuine bearing failure. Downstream, maintenance analyzes a fiction: Pareto charts of downtime reasons that reflect logging habits rather than physics.

The honest test of your current data: pick one machine, watch it for a full shift with a stopwatch, and compare what you saw against what the log says. Most teams that run this experiment stop defending their manual data the same day.

Instrumenting capture: cheaper than the meeting about it

Automatic run-state capture requires surprisingly little: a signal that distinguishes running from stopped. A current transformer on the drive, a vibration sensor detecting run state, a Modbus or OPC-UA read from the PLC, or a simple digital output — any of these, through an edge gateway, timestamps every stop and start with no human involvement. Duration and frequency become facts. Only the reason still needs a human, and only for stops above a threshold you choose.

The workable division of labor: machines record that and how long, people record why — through a two-tap reason picker on a tablet or phone at the line, prompted only for stops over, say, five minutes. Short-stop reasons come later from pattern analysis, not from interrupting operators sixty times a shift. Keep the reason tree shallow: a dozen well-chosen categories beat a taxonomy of eighty that everyone answers with 'other.'

Connect capture to the maintenance system from day one. A downtime event on a critical asset should be creatable as a work order in one tap, carrying the timestamp and run-state context with it. When downtime data and work history live in the same system, the question 'what did our top ten downtime causes cost us and what work fixed them' becomes a query instead of a quarterly archaeology project.

From measurement to action: the loss tree

Measurement earns nothing until it changes the work plan. The tool for that is a loss tree: take total planned time and decompose every lost hour into named categories — breakdowns, changeovers, minor stops, speed loss, startup rejects — with a cost per hour attached. Review it weekly at the line level with operations and maintenance in the same room. The agenda writes itself: the top two losses get an owner and a countermeasure; last week's countermeasures get checked against the data.

Expect the first weeks of honest data to be uncomfortable. Automatic capture almost always reveals more downtime than anyone reported, and OEE typically drops on paper before it improves in fact. Leadership needs to hear this in advance: the number went down because the measurement got honest, and the previous number was unusable. Teams that frame this correctly get a baseline. Teams that do not get a mandate to make the number look like the old one.

Benchmarks, used carefully

Benchmark folklore says 85 percent OEE is world-class, 60 percent is typical, and 40 percent is common for unmeasured lines. Use these as orientation, not targets. OEE is not comparable across dissimilar processes — a high-mix packaging line and a continuous extruder live in different mathematical universes — and chasing a benchmark invites definition games. The benchmark that matters is your own line, last quarter, measured the same way.

Set improvement targets on the loss tree instead: cut changeover time on line 2 by a third, halve minor stops on the filler, lift availability on the worst actor five points. These are concrete, ownable, and immune to definitional creep. Sustained OEE improvement is the sum of dozens of such fixes — measured honestly, worked weekly, and compounded quietly over quarters. There is no other mechanism.