How to improve OEE
Improve OEE by working the factors in order: measure honestly, fix availability first, then performance, then quality - and prove each gain against live data.
To improve OEE, work the three factors in order - availability first, then performance, then quality - and prove every change against live data before you move on. Scattering effort across all of them at once is how improvement programmes stall. This is the playbook that actually moves the number.
Step 1: Measure honestly before you change anything
You can't improve what you can't see, and a flattering number is worse than no number. Get a trustworthy baseline first: capture every stop automatically, set the ideal cycle time to the real nameplate rate, and count rework as a quality loss. If your data is built from end-of-shift clipboards, fix that before anything else - it hides exactly the losses worth chasing. (See how to calculate OEE.)
Step 2: Fix availability first
Availability is usually the biggest and most visible loss, so it's where the early wins are. Rank your stops by total time lost, attack the top few causes at the root, and tackle changeover separately with SMED. The method is its own guide: how to reduce unplanned downtime.
Step 3: Then recover performance
Once the line stays up, find the speed it's losing while running - minor stops and reduced speed. These are invisible on a downtime report and are often the single largest loss. Compare actual rate to the ideal cycle time, hunt the micro-stops, and remove the small frictions (jams, misfeeds, cautious manual speeds) that quietly cap throughput.
Step 4: Then tighten quality
Quality is usually the highest of the three factors, but it compounds: a defect wastes the availability and performance that produced it. Attack scrap and rework at the source with process control and mistake-proofing, and stabilise startups after changeovers to cut yield loss.
Step 5: Prove it, then sustain it
After each change, watch that line's OEE and the targeted cause for the next few days. Banked a gain? Standardise it. Nothing moved? You learned cheaply. Running structured plan-do-check-act cycles against live OEE is what separates real, defensible improvement from a hunch - and keeps the gains from creeping back.
Key takeaways
- Baseline honestly first - automatic capture, real cycle time, rework counts as a defect.
- Improve your weakest factor next; availability is usually first, then performance, then quality.
- Rank causes by total time lost and fix the vital few at the root.
- Prove each gain against live OEE, standardise what works, and keep measuring to sustain it.