How to Improve OEE: A Loss-First Playbook

To improve OEE, attack the biggest loss bucket first, not the headline percentage. Break OEE into its three factors, find which one is dragging it down (usually Availability), then work the specific losses inside that factor. Chasing the overall number without decomposing it is how plants burn effort on the wrong problem.

OEE improvement fails when it is treated as a single dial to turn up. It is not one number; it is three factors, each hiding a family of losses, and the fastest gains come from the one factor that is worst on your line. This guide gives a loss-first sequence: decompose the score, size the losses, fix the biggest, and lock the gain. It assumes you already know the OEE calculation; here the focus is what to do once you have the number.

Why attack the biggest loss bucket first?

Because OEE's factors multiply, so the lowest factor has the most leverage. A line at 85% Availability, 90% Performance, and 99% Quality scores about 76% OEE, and the cheapest point back is Availability, the factor furthest from 100%. Pushing Quality from 99% to 99.5% barely moves the product; recovering ten points of Availability moves it a lot. The math of multiplication means the worst factor is almost always where the next hour of effort pays best.

This is why "raise OEE by five points" is a bad instruction and "cut changeover losses in half" is a good one. The first tells nobody what to do; the second names a loss, a factor, and a countermeasure. Improvement lives at the loss level, and the six big losses are the map: breakdowns and setups (Availability), minor stops and reduced speed (Performance), and startup and production rejects (Quality). Every real OEE gain traces to shrinking one of those six.

How do you find which factor to fix?

Decompose the OEE score into its three factors and rank them by distance from their realistic ceiling. The steps are quick:

1. Split OEE into A, P, and Q. Pull the three factors separately for the line and period. If you only have the overall number, you cannot target anything, this split is non-negotiable.
2. Compare each to a realistic ceiling. Not 100%, but the best this line credibly runs: perhaps 92% Availability, 95% Performance, 99.5% Quality. The gap to that ceiling, not to 100%, is the real opportunity.
3. Rank the gaps by lost time. Convert each gap into minutes or units lost per shift, so a small Performance gap on a fast line can outrank a big Quality gap on a slow one. Time lost is the honest ranking.
4. Drill into the losing factor's losses. For the worst factor, break it into its two of the six big losses and use a Pareto of reasons to find the top one or two causes.
5. Pick one loss and one countermeasure. Commit to a single loss with a named owner and a target, rather than spreading effort thin across all three factors at once.

This is where honest data matters most. If Availability is understated because downtime is logged from memory, or Performance is inflated by a soft ideal cycle time, the ranking points at the wrong factor and the whole effort misfires. Fix the measurement before trusting the priority.

How do you improve Availability?

Improve Availability by cutting the two losses that live there: breakdowns and setup/changeover time. Breakdowns respond to maintenance discipline, shifting from run-to-failure toward planned and condition-based work so stops are scheduled rather than sudden. Even simple autonomous-maintenance basics (operators cleaning, inspecting, and catching small issues) head off a real share of unplanned stops before they cascade.

Changeovers are usually the faster win, because setup-reduction methods can cut changeover time sharply with little capital, separating internal steps (done only while stopped) from external steps (prepared while running), then converting internal to external. On many lines, changeover is the single most improvable loss, which is why excluding it from OEE (a common mistake) hides the best opportunity on the floor. Attack the frequent, medium-length stops too, not just the dramatic breakdown, a dozen five-minute stops a shift often outweighs the one big failure everybody remembers. The reason this works is arithmetic: Availability is run time over planned time, so every minute of stop you remove goes straight back into the numerator, and the frequent stops add up to more minutes than the rare catastrophe. Order the fixes by total minutes recovered, and the priority sorts itself out.

How do you improve Performance?

Improve Performance by killing minor stops and closing the gap to ideal speed. Minor stops, jams, misfeeds, brief blockages under a couple of minutes, are invisible to manual logs, so they silently drain Performance where nobody can see them. The fix is automatic detection from machine signals, then eliminating the top recurring cause: a specific sensor, a worn guide, a material variation. You cannot improve a loss you cannot see.

Reduced speed is the other half: the line running below its ideal cycle time from wear, conservative settings, or material issues. Closing it starts with a trustworthy ideal cycle time, the true best repeatable rate, not a soft standard, because Performance measured against a padded target looks fine while real speed loss hides inside it. Once the ideal is honest, the gap between it and actual speed becomes a concrete, workable target rather than a vague sense the line "could go faster." A useful habit is to split Performance loss into the two sources and size each: how many units were lost to minor stops versus to a slower-than-ideal steady rate. On most lines the minor stops dominate and hide in plain sight, so automatic stop detection tends to unlock more than a speed tune-up, but sizing both first keeps you from guessing.

How do you improve Quality?

Improve Quality by attacking the defects at their source, especially startup rejects. Startup and changeover rejects, the scrap made while a process settles after a stop, shrink as changeovers get more repeatable, which is why Availability and Quality work often overlap. Steady-state rejects need root-cause work: root cause analysis on the top defect, mistake-proofing so the error cannot recur, and tighter process control.

The measurement discipline here is strict counting: a reworked part is not good, and counting it as good erases the Quality signal (see good count vs total count). Because Quality is usually already high, often 98%+, it is rarely the biggest OEE lever, but it compounds with the others and, unlike a slow cycle, a defect wastes all the time and material already invested in that unit. Fix the defect that recurs most, not the one that is most visible, and confirm the fix held before moving on, a defect that returns two weeks later was contained, not solved, and it quietly erases the Quality gain you booked.

What does the data say about OEE benchmarks?

Two context numbers help set realistic targets, both worth citing with their provenance so nobody mistakes folklore for an audited standard.

The 85% "world-class" figure, roughly 90% Availability × 95% Performance × 99% Quality, traces to Seiichi Nakajima's TPM work and is a commonly cited reference point, not a certified benchmark. The Federal Reserve's G.17 release put U.S. manufacturing capacity utilization at 75.7% in May 2026 a reminder that real plants run well below theoretical maximums. And ISO 22400-2:2014 standardizes the A×P×Q definitions (standard listing) so improvements are measured consistently. Aim your line at its own trend, not at 85%, more in what is a good OEE score.

How do you lock in the gain?

Lock in an OEE gain by standardizing the fix and watching the factor that moved, so it does not quietly slide back. Every countermeasure that works should become standard work, the new changeover sequence, the sensor check, the maintenance routine, because an improvement that depends on memory decays within weeks. Then keep the decomposed A, P, Q on the board, not just the headline OEE, so a slipping factor is visible before it erases the gain.

Frequency is the multiplier. A monthly OEE number is an autopsy; a live, per-shift number the crew can see and act on is a tool while it still counts. That is the practical case for computing OEE from machine signals at the source rather than end-of-shift estimates, the input games disappear and the losing factor is obvious in real time, which is exactly what Harmony does from PLCs and sensors on the floor (see the platform), shown in the CLS case study. Start by putting your line's real numbers through the OEE calculator to see the factor split, then work the sequence above, and track the result against adherence to plan so a higher OEE actually shows up as more units shipped.