Low OEE almost always comes down to two or three specific losses. To find them, split OEE into availability, performance and quality, then check your stop reasons, your short stops and the ideal cycle time behind the calculation. In many plants the largest loss turns out to be one nobody was recording, usually short stops or a line running below its rated speed.
What does a low OEE number actually tell you?
OEE (Overall Equipment Effectiveness) multiplies three ratios. Availability is the share of planned production time the machine actually runs. Performance compares the real output with what the machine would make at its ideal cycle time. Quality is the share of parts that are good the first time.
OEE = availability × performance × quality.
Illustrative example: a line is planned for 450 minutes in a shift and runs for 405, so availability is 90%. At an ideal cycle time of 1 minute it should make 405 parts in that time but makes 324, so performance is 80%. Of those 324 parts, 314 are good, so quality is about 97%. OEE is 0.90 × 0.80 × 0.97 = about 70%.
The single number hides the useful part. Two lines can both show 70% while one loses its time to breakdowns and the other to slow running. Always look at the three factors before you look for causes.
A common reference point is 85%, often called world-class OEE. It comes from Seiichi Nakajima, who introduced TPM and OEE in the early 1970s and published the targets of 90% availability, 95% performance and 99% quality in his 1984 book. Most manufacturers today score closer to 60% [1]. A low score is common, so the useful question is which loss sits behind it.
Which of the six big losses is eating your OEE?
Nakajima grouped the time a machine loses into six big losses [1]. Each one lands in one OEE factor, and each one looks different on the shop floor.
| Loss | OEE factor | What you see on the floor | Data that confirms it |
|---|---|---|---|
| Breakdowns | Availability | Machine stopped, maintenance called | Stop log with reason codes and duration |
| Setups and adjustments | Availability | Long changeovers, trial runs after a product change | Changeover start and first good part time |
| Short stops | Performance | Jams, sensor trips, operator clears and restarts | Machine state signal; manual logs usually miss these |
| Reduced speed | Performance | Line runs, but output per hour is lower than rated | Actual cycle time against ideal cycle time |
| Start-up rejects | Quality | Scrap in the first parts after a start or changeover | Rejects by time since start or changeover |
| Production rejects | Quality | Scrap and rework during stable running | Rejects by defect code, shift and product |
Breakdowns and setups are the losses people remember. Short stops and reduced speed are the ones they do not, because the line never stops long enough for anyone to write it down. If your availability looks fine and performance is low, start there.
Why does spreadsheet OEE hide the real causes?
Most plants first calculate OEE by hand: operators write stops on a sheet, someone types them into Excel at the end of the shift. This gives a number, but it is weak at finding causes for three reasons.
Short stops disappear. A stop of 40 seconds is cleared and forgotten. Sixty of them in a shift add up to 40 minutes, longer than many breakdowns, and nobody writes them down. The reason field fills up with “other”. When half the lost time has no clear reason, a Pareto chart of causes shows the wrong top item. The ideal cycle time is often a guess, a value from years ago or from the slowest product, so performance looks better than it is.
Automatic collection of machine states fixes the first problem. The other two need clear rules: a short list of stop reasons, chosen at the machine, and an agreed ideal cycle time for each product. The DBR77 IIoT knowledge base covers both in more detail: live OEE compared with OEE from a spreadsheet and why machine data needs downtime reasons and a state model.
How do you find the cause of low OEE in two weeks?
A focused two-week check on one line usually shows the main cause.
- Pick the bottleneck. OEE on a machine that waits for parts says little. Measure the station that limits output of the whole line.
- Check the ideal cycle time. Agree it per product with production and engineering. Use the rated or best sustained speed, not the average of last month.
- Record every stop with a reason. Keep the list to 10 to 15 reasons, and make sure short stops are captured, not only stops over 5 or 10 minutes.
- Split the losses. After a week, sort lost minutes by the six losses, then by shift, product and reason.
- Go to the line. Take the largest loss and watch it happen. Ask the operators what they see; they often already know the cause.
- Confirm and act. Change one thing, measure for the second week, and check whether the loss actually went down.
See how machine signals turn into statuses and alerts. Open the DBR77 IIoT demo: a demo environment with sample data, dashboards, alerts and operator views, before you connect your own machines.
Which mistakes make OEE look better or worse than it is?
Check these habits before you trust the number:
- The ideal cycle time comes from the slowest product. Performance then looks high for every faster product.
- Changeovers are booked as planned time. Availability goes up on paper, but the time is still lost.
- OEE is averaged across lines or machines. A strong line hides a weak one.
- OEE is measured on machines that are not the bottleneck. Improving them does not add output.
- Good parts are counted before final inspection. Quality looks better until rework comes back.
Write the rules down: what counts as planned time, which cycle time is used, which machine is measured. Then OEE is comparable from week to week and between shifts. The international standard for manufacturing KPIs, ISO 22400-2, includes an annex on calculating OEE from a loss time model, which is a useful reference when you set these rules [2].
When is OEE the wrong question?
OEE shows how well a machine uses its planned time. It does not show whether the plant ships the right products on time. OEE can rise while deliveries slip, for example when a line runs well on products nobody ordered. If that is your situation, add a few measures next to OEE: output of the bottleneck, on-time delivery and first pass yield. The DBR77 IRIS knowledge base explains this in OEE is not enough.
Sometimes the cause sits in the layout: a buffer that is too small, a transport route that blocks, an operator who serves too many stations. You will see high losses spread across several machines with no single reason. In that case it helps to model the line and test changes before you move anything. See how to find production bottlenecks before they happen in the DBR77 Digital Twin knowledge base.
When you know which loss to fix, the next step is removing it. OEE Under the Microscope covers that, and Cycle time: the key to efficient production helps you set the ideal cycle time. If you prefer listening, the Factory on Air podcast has an episode on the causes of low OEE.
FAQ
What is a good OEE score?
85% is often called world-class for discrete manufacturing, based on 90% availability, 95% performance and 99% quality. Most manufacturers score closer to 60% [1]. Set your target as steady improvement on the bottleneck, step by step.
Should planned maintenance count against OEE?
Plants define this differently. Some leave planned maintenance out of planned production time, others count it as a planned stop that lowers availability. Pick one rule, write it down and use it on every line, and never book changeovers or waiting for material as planned time.
Can I calculate OEE without sensors on the machines?
Yes. You can calculate OEE from manual records of run time, stops, output and rejects. The number will usually miss short stops and slow running, so it often looks better than reality. Machine signals, even from older machines without a PLC, make these losses visible.
How long does it take to find the main cause of low OEE?
On one line, often about two weeks: one week of recording every stop with a reason, and one week to test a change. It takes longer if the ideal cycle times or the stop reasons first need to be agreed.
Ready to see where your OEE goes?
Find the loss nobody was recording. Try the DBR77 IIoT demo to see machine statuses, alerts and operator views on sample data, then talk to us about measuring the bottleneck on one of your lines.
