OEE the shop floor actually believes

The number is right and nobody uses it

A plant we can all picture: the monthly review deck says OEE is 82%, up two points. The line is behind on shipments, the supervisor knows exactly which four things went wrong last week, and none of them appear anywhere in the deck. Nobody in the room disputes the 82%. Nobody acts on it either. It has become a number that gets reported rather than a number that gets used, and those are different objects that happen to share a name.

This is the normal outcome, and it is not caused by bad math. Availability times performance times quality is arithmetic a supervisor can do on a napkin. The failure is upstream of the arithmetic, in four definition choices that are usually made by whoever configured the software, in an afternoon, without the people who will be measured by them.

Four definitions decide the whole number

What counts as scheduled time. Availability is run time divided by scheduled time, and everything depends on what goes in the denominator. Some plants use all 168 hours in the week. Some use only staffed shifts. Some subtract planned maintenance, some subtract planned changeovers, some subtract lunch and some do not. None of these is wrong. All of them produce different numbers for an identical week, which is why cross-plant OEE comparison is mostly an exercise in comparing configuration files.

Our preference for an internal number is a narrow denominator: the time you intended to make parts. Then no-demand time is excluded rather than punished, because a line that was not scheduled did not fail at anything. But whatever you choose, write it in one sentence, put that sentence on the report, and never change it quietly. A definition change halfway through a year makes the entire year uncomparable and the floor will notice before the deck does.

Who sets the ideal cycle time. Performance is actual output against what the machine could theoretically have produced in the running time, and the theoretical rate is a choice. Take it from the equipment nameplate and it is often a number from a sales brochure describing conditions that do not exist in your plant with your material. Performance then sits permanently in the seventies, the floor concludes the metric is unfair, and they are correct.

The alternative is a demonstrated best rate: the fastest sustained rate this machine has actually achieved on this part, verified over a real run, per part number rather than per machine. It is a lower bar and a far more useful one, because a gap against it is a gap somebody can close. Record where the number came from, in the same table as the number, and re-verify when the process changes.

Where the losses are counted. A part scrapped at final inspection was usually made wrong three operations earlier. Most systems charge the loss to the operation that discovered it, which is the one place it definitely did not happen. If the data can carry it, attribute scrap to the operation that created it and let the discovering operation record the find. If it cannot, at least say so out loud, so nobody builds an improvement plan around a station whose only crime is having a gauge on it.

What happens to rework. Quality is usually good units over total units, and rework sits awkwardly between the two. A unit that was reworked and shipped consumed extra capacity, extra labor and extra material, and counting it as good erases all of that. Counting it as scrap overstates the loss. The workable answer is to count first-pass units in the quality factor and track rework hours as a separate line, because rework hours are the number a plant manager can actually act on.

Micro-stops and the threshold nobody discusses

Most downtime systems ignore stops shorter than some threshold, because otherwise operators would be prompted for a reason code every few minutes and would stop answering entirely. That is a reasonable engineering decision with an unreasonable side effect.

A forty-second jam that happens forty times a shift is roughly twenty-seven minutes of lost production, and with a one-minute threshold it does not appear anywhere as downtime. It surfaces instead as a performance loss with no cause attached, and performance losses with no cause attached are the reason people describe OEE as a number that tells you something is wrong without telling you what.

Set the detection threshold low, so short stops are captured as data, and set the prompting threshold higher, so humans are not interrupted constantly. Then report short stops as an aggregate with a duration total. “Two hundred and forty short stops this week, eleven hours” is a sentence a maintenance planner can act on. A performance factor of 91% is not.

Every minute goes in exactly one bucket

The structural rule that makes an OEE system defensible is that the time buckets sum to the clock. Every minute of the shift is running, or setup, or planned down, or unplanned down, or blocked, or starved, or not scheduled — exactly one, no overlaps, no gaps. If the buckets sum to less than the shift, something is being dropped. If they sum to more, something is being double counted.

Which means unaccounted time deserves its own bucket, displayed on the report, rather than being quietly folded into whichever category the software defaults to. Nobody enjoys showing a number that says “we do not know what happened here,” and that discomfort is exactly why it works. Unaccounted time is the honest measure of how well your collection system is functioning, and watching it fall is the clearest evidence that the system is being adopted.

Reason codes: fewer than you want, in their words

Reason codes are the only part of this that a machine cannot supply. No sensor knows the truck was late, the tooling was still in the crib, or the operator was pulled to another cell. That information exists only in a person's head for a few hours and then it is gone.

Two rules get it captured. Keep the list short — roughly eight to twelve at the top level, structured so a rare cause lands under a common parent rather than adding a thirteenth top-level option. And write them in the words the floor already uses. If the crib is called the crib, the code says crib. An engineer's taxonomy is precise, complete, and quietly abandoned within a month, at which point everything lands under “Other.”

Track the share of downtime coded “Other” as a metric in its own right. When it climbs, the code list has stopped matching reality, or the entry interaction has become too slow, and both are fixable. When someone tells you the reason codes are useless, they are almost always telling you that the list does not contain the thing that actually happened.

The trap: OEE up, output down

This happens often enough that it is worth understanding rather than treating as a paradox. A plant improves OEE on three machines, and shipments do not move. The three machines were not the constraint. Making a non-constraint faster produces inventory in front of the constraint, not output, and sometimes it produces less output, because the extra work in process lengthens queues and hides problems.

So measure OEE where the constraint is, and treat every other machine's OEE as diagnostic information rather than a target. A machine that is deliberately idle because the constraint is slower is doing the right thing, and an incentive to raise its OEE is an incentive to build inventory nobody ordered.

The related trap is the plant-level average. Averaging OEE across dissimilar equipment produces a figure that cannot be acted on and cannot be compared honestly to anyone else's. If corporate requires one, publish it and keep working from the constraint-level number. And treat the 85% figure that circulates as a world-class benchmark with care: it comes from the total productive maintenance literature and is built from component targets of roughly 90% availability, 95% performance and 99% quality. It describes one context. A high-mix job shop hitting 55% may be running an extremely good operation, and a continuous line at 85% may be leaving a great deal on the floor.

The one thing that permanently destroys the data

Do not use OEE for pay, for ranking individuals, or in a disciplinary conversation. Not once.

The reason is mechanical rather than sentimental. Nearly every input that makes OEE trustworthy is supplied voluntarily by the people being measured — the reason code, the start of setup, the honest scrap count. The moment those entries can be used against them, they will be optimized. Downtime gets coded to whichever reason looks least like the operator's fault. Setup starts late and ends early. Scrap goes in the bin instead of the count. None of this is dishonesty; it is a rational response to a system that takes something from you and returns nothing.

And the loss is permanent in practice. Once the floor has learned that the data is used against them, restoring honest entry takes far longer than it took to destroy, because trust is repaid on a slower schedule than it is spent. Use OEE to find the biggest loss on the constraint and go fix it. That is the entire job.

Latency is a feature, not a nicety

A number that appears the following morning is a report. A number that appears during the shift is a tool. The difference is not technical — both are the same query — but it changes what the number is for. Within the shift, a supervisor can act: chase the missing tooling, move an operator, call maintenance while the machine is still down. The next morning, the only available action is explaining.

Which is why an hourly board at the machine outperforms a monthly deck by a wide margin. Target for the hour, actual for the hour, and one line of what happened. It fits on a screen, it fits on a whiteboard, and it produces conversations at the machine rather than in a conference room. Build the boards first and the monthly deck second, even though the deck is what was asked for.

The mistakes we see

• Definitions set by whoever configured the software, without the supervisor who will be measured by them
• Nameplate rates as ideal cycle time, which caps performance permanently and teaches the floor to ignore it
• Thirty reason codes, of which four are used and one is “Other”
• Micro-stops below the threshold, reappearing as an unexplained performance loss
• Unaccounted time absorbed silently into whichever bucket the software defaults to
• Plant-average OEE as the headline, when only the constraint's number affects shipments
• OEE in a performance review, after which none of the inputs can be trusted again

What we would do in the first month

• Pick one line, ideally the constraint, and leave the rest of the plant alone
• Write the four definitions on one page and have the supervisor and the plant manager both sign it
• Automate availability from machine state so nobody is reconstructing stops from memory
• Start with eight reason codes, written in the floor's own words, and expect to change them
• Show unaccounted time on the report from day one, and watch it fall
• Verify the demonstrated best rate on a real run before publishing any performance figure
• Warn everyone that the first number will be lower than what people believed

That last one is not a courtesy. The first honest OEE number is almost always well below the number the plant has been quoting, because the old number came from a system with generous defaults and invisible losses. If that lands as a surprise, the instinct will be to attack the measurement. Said in advance, it becomes the point of the exercise instead of an accusation.

When you do not need us

If you run one line on one shift, you do not need software to start. A clipboard at the machine, a stopwatch, and two weeks of a supervisor writing down every stop longer than a minute will tell you the top three causes of lost time, which is the same answer a system would give you and the answer you would act on anyway. Do that first. If the top three causes turn out to be obvious and fixable, fix them and skip the project entirely.

Software earns its place when there are too many machines and shifts for a person to observe, when the causes are distributed rather than concentrated, or when the losses are short and frequent enough that a human with a clipboard cannot catch them. Until then, a system mostly automates a question you have not asked yet.

Bottom line

OEE is arithmetic over four contested definitions, and the definitions matter far more than the formula. Choose a scheduled-time denominator and write it down. Use a demonstrated best rate rather than a brochure number. Count first-pass quality and report rework hours separately. Make every minute land in exactly one bucket and show the unaccounted one. Keep the reason codes few and in the floor's language. Measure the constraint. Put the number in front of people while they can still act on it. And never use it in a pay conversation, because the day you do is the day the inputs stop being true.

Frequently asked questions