See which OEE loss actually constrains the system.

Calculate OEE from stable definitions

Availability measures whether the process ran during planned production time. Performance measures whether it ran at the ideal rate while running. Quality measures the share of first-pass good output. Multiplying the three factors expresses the share of planned time used to make good product at the ideal speed.

Before comparing lines or shifts, align the definitions of planned production time, stop thresholds, ideal cycle time, total count, and good count. Performance above 100% is a warning that the ideal cycle time or data boundary is wrong—not exceptional productivity.

Translate the score into an actionable loss tree

The top-level percentage tells you that productive time was lost, not what to change. Break Availability into failure, setup, material, and other stop reasons; Performance into slow cycles and small stops; and Quality into startup rejects, scrap, and rework. Keep schedule loss outside OEE unless you are deliberately analyzing utilization or TEEP.

Use duration and lost-good-count views together. A large number of short stops can be hidden by coarse downtime logging, while one long planned changeover may dominate the time view. Pareto charts are useful, but verify reason codes at the process.

• Availability: unplanned stops, planned stops, changeover, waiting for material
• Performance: slow cycles, idling, jams, brief stops, rate restrictions
• Quality: startup loss, scrap, rework, off-spec material
• Data checks: clock alignment, duplicate events, missing counts, product-specific ideal cycle times

Do not confuse a local OEE gap with the system constraint

OEE is equipment-centered. Customer output is system-centered. A machine with low OEE may have enough capacity and buffer protection that its losses do not reduce shipments. A machine with higher OEE may be the constraint, so a small loss there can have a much larger effect on total flow.

Map starvation, blocking, buffers, rework loops, product mix, and changeover sequence. Attribute lost system throughput to the event that originated it, not only to the station that was idle when the effect arrived.

Test loss-removal scenarios before committing

Create a baseline that reproduces observed throughput, WIP, queues, and OEE factors. Then test realistic interventions: higher mean time between failures, faster repair, reduced changeover, corrected ideal speed, improved first-pass yield, a buffer rule, different staffing, or a revised product sequence.

State the investment and operating assumptions. Compare expected throughput, service, WIP, labor, quality, and confidence across scenarios. Stress-test demand and failure variability so the preferred option is not dependent on one favorable week.

1. Clean the loss data

   Reconcile planned time, counts, ideal cycles, stop events, and reason codes.

2. Locate the constraint

   Use flow, queues, blocking, starvation, and demand—not OEE alone.

3. Convert loss to system impact

   Estimate lost good output and downstream consequences.

4. Model interventions

   Test maintenance, speed, quality, buffer, staffing, and sequence changes.

5. Run a controlled Kaizen

   Verify the prediction with an owned experiment and review window.

Prioritize with impact, feasibility, confidence, and risk

Rank opportunities by incremental customer or business outcome, not by the size of the OEE gap alone. Include implementation effort, safety and quality risk, confidence in the causal evidence, time to learn, and whether the change shifts the constraint.

Use AI and machine learning to detect recurring patterns, changing failure signatures, or relationships across sensor and operational data. Use simulation to test their system consequences. Keep every recommendation traceable to data, assumptions, and a human decision.