Your OEE number is probably wrong — here is how to tell

A plant reports 78% OEE on the board by the canteen. The constraint machine, measured properly, runs nearer 58%. Both numbers describe the same shift.

Nobody lied. The gap is an instrument problem, and it is almost always the same instrument: a human being reconstructing a shift from memory at 14:00, on a paper sheet, while wanting to go home.

The missing minutes are the whole argument

Manual and paper downtime logging captures roughly 60–70% of the minutes a machine was actually stopped. Stops under five minutes are skipped almost entirely, because writing one down takes longer than the stop did.

Micro-stops and reduced-speed running together account for something like 5–15% of production time on a typical discrete line. None of it reaches the sheet. The result is that manually-derived OEE is commonly overstated by 10–25 percentage points.

Automated capture from the machine should exceed 95% of stopped minutes, with unattributed time — logged stops carrying no reason code — held under 5% of planned production time. That pair of numbers is the actual specification for a downtime system. Not “real-time visibility”: 95% and 5%.

A composite number is built to hide which loss you have

OEE is Availability × Performance × Quality, measured against planned production time. Seiichi Nakajima’s world-class 85% is the product of 90% × 95% × 99.9%, a benchmark set on Japanese discrete automotive assembly in the 1970s and 80s. oee.com’s own dataset notes there are more companies scoring below 45% than above 85%; typical discrete plants sit at 45–65%.

Now take 62%. It could be 95 × 70 × 93 — a machine that runs whenever you ask but never at rate. It could be 70 × 95 × 93 — a machine that runs at rate but keeps stopping. It could be 88 × 95 × 74 — a machine that runs fine and makes scrap.

Three different plants, three unrelated interventions, one identical headline. A composite that averages a reliability problem with a rate problem and a scrap problem cannot direct spending. Read the three factors separately, or do not read them at all.

There is a second reason to split them: Quality inside OEE quietly absorbs rework. If a part is reworked and then shipped, it is a good part by most plants’ counting rules — and the labour to rework it has vanished from the number entirely. Track scrap and rework as separate lines, always.

Performance is where the number lies most quietly

Availability failures announce themselves — the line is stopped, people are standing around. Performance loss is silent.

A line running an entire shift at 85% of rated speed logs zero downtime events and loses 15% of its output. And if no actual rate is recorded against an ideal cycle time, Performance does not report 85%. It defaults to 100%, because the calculation has nothing to divide by.

So the single most useful question about any OEE figure is: where did the ideal cycle time come from, and when was it last re-baselined? If the answer is the machine nameplate, the number is soft in one direction. If it is a cycle time that was “adjusted to be realistic” during a previous improvement programme, it is soft in the other, and Performance has been flattering the plant ever since.

Re-baseline it from a timed capability run under known-good conditions, write down the date, and treat any later change to it as an event that has to be signed off.

When the measurement improves, the number falls — and that is the success condition

Here is the thing that kills these projects in week three.

Automate downtime capture on a line that was reporting 78%, and the first honest week comes back at 58–66%. Nothing got worse. The stops that were always happening are now being counted. But the plant manager has just watched their headline metric fall 12 points in the month they approved the spend, and somebody upstairs is going to ask.

That drop has to be sold before the sensors go on, in writing, to the person who owns the number. Frame it as a baseline restatement with a stated date, keep the old series visible beside the new one for a quarter, and never quote a before-and-after that crosses the instrument change. A result produced by a different method than its baseline is not a result.

We have had this cost us. On an email-marketing automation engagement for a beauty brand, the roughly 60% reduction in outreach time is the client’s own number, measured by the client’s method — we did not freeze a baseline instrument before the build. We quote it because it is theirs and they stand behind it. We cannot defend it the way we would defend a number we had instrumented on both sides, and we say so rather than rounding it into a case-study claim.

OEE deliberately hides the capacity you are not selling

OEE measures against planned production time. Schedule loss — the unstaffed third shift, the weekend, the machine that only runs Tuesdays — is excluded by definition, which is correct for an efficiency question and misleading for a capacity one.

TEEP is OEE multiplied by schedule loading, and it usually lands 20–40 points below OEE. It is the number that belongs in the conversation when someone is proposing to buy a second machine. A plant at 65% OEE and 38% TEEP does not have a capacity problem; it has a staffing and changeover problem wearing a capex costume.

A brownfield line can be instrumented without touching the PLC program

The objection is always the same: the machines are twenty-five years old and have no data. Mostly untrue, and the useful part is that none of the following requires opening the controller program.

• Stack-light phase taps — a wired input per lamp gives running / stopped / faulted state on almost anything with an andon tower.
• Current transformer clamps on the main feed, which separate running from idle from off on machines with no controller access at all.
• Existing proximity and photo-eye counters for cycle count, which is what Performance actually needs.
• IO-Link masters and serial ports that are already fitted and already talking.

Where a PLC is genuinely reachable, add an external read over OPC UA, S7comm, Modbus TCP or EtherNet/IP — but check scan-time headroom first and find out who owns change management on that controller. A badly-configured subscription eats into the PLC scan and gets you removed from the production network, once, permanently.

Normalise everything at an edge gateway and publish it as MQTT Sparkplug B with ISA-95 context — site, area, line, cell, asset — so a metric means the same thing on line 3 as on line 7. The Sparkplug specification is about 80 pages against OPC UA’s 1,200-plus across its parts; for a downtime feed, that is the whole argument for it.

And if the honest assessment on a specific machine is that the retrofit costs more than the data is worth, that belongs in the report as a recommendation not to instrument it.

The charter is the deliverable; the dashboard is a by-product

ISO 22400 — not a vendor blog — is the international standard that defines OEE and the rest of the operations KPI set. It is what you cite when two sites disagree, and they will.

Before any hardware, freeze in writing: what counts as planned production time; whether a changeover is planned or unplanned (pick one, apply it to every line); the micro-stop threshold, conventionally 2 minutes; the source and date of every ideal cycle time; and a reason-code list that starts at 8–12 codes per asset area, not 40.

Then publish two hygiene metrics beside the OEE itself. The share of downtime minutes sitting in “Other” must stay under 10–15% — above that, a Pareto built from the data is arithmetic, not evidence, and the fix is fewer and better codes rather than more of them. One furniture line’s set ran at 22% “Other”. And unattributed time gets its own tile, because a rising “Other” bucket is usually the first visible sign that operators have decided the system is a stopwatch pointed at them.

Where this stops applying

Two boundaries worth stating plainly.

OEE gains on a non-constraint station are worth nothing. If the line’s throughput is set by the press and you recover eleven points on the packer, you have improved a number and shipped exactly as many parts as before. Identify the constraint first, measure it hardest, and be suspicious of any plant-wide OEE scoreboard.

And OEE must stay out of individual performance appraisal. Tie it to shift reviews and you will get recoded changeovers, unlogged micro-stops and a growing “Other” bucket — you will have spent the capex to make the data worse. Operator-linked productivity records are personal data under GDPR, which makes the works council conversation a legal step, not a courtesy.

One last boundary, about us. Palamed has not instrumented a production line. Our four deliverable engagements are a European car marketplace, a platform for an AI automation agency, the Ministry of Education and Science dictionary at beron.mon.bg, and the email automation above. Everything in this article is the published pattern and the standard it rests on — the ISO 22400 charter, the 95% capture bar, the drop you should expect at go-live. If someone tells you they have delivered fifty of these, ask them which line, which constraint, and what the number did in week one.