Production-loss analysis engine for plant managers and CI engineers: full OEE = Availability × Performance × Quality decomposition with time-equivalent loss waterfall (unplanned downtime, speed loss, quality loss), TEEP against calendar time, world-class 85 % benchmarking, what-if recovery potential at target OEE, and data-consistency blocking when the numbers cannot be physical. Every report with the full audit trail — ready to paste into the morning meeting deck.
OEE multiplies three independent factors, each answering one question about the same period:
Availability asks: of the time we planned to run, how much did we actually run? Performance asks: while running, how close to the ideal rate did we stay? Quality asks: of everything we made, how much was sellable the first time? Because the factors multiply, OEE is brutally honest: 90 % × 90 % × 90 % is only 73 %.
The ideal cycle time must be the design or demonstrated best rate — not a padded standard. Padding the cycle inflates Performance, hides speed loss, and is the most common way OEE programs deceive themselves.
The waterfall converts every loss into minutes so losses compare on one scale. Unplanned downtime (breakdowns, changeover overruns, material waits) hits Availability directly. Speed loss = Run time − Ideal cycle × Total count captures slow cycles and minor stops under the downtime threshold. Quality loss = Ideal cycle × Rejects is the time spent making parts nobody can sell. What remains is value time — the minutes that actually became good product.
Improvement priority follows the waterfall: attack the largest bar first. A plant with 15 % downtime loss and 2 % quality loss that launches a quality program is working on the wrong bar.
85 % is the classic world-class line (A ≥ 90 %, P ≥ 95 %, Q ≥ 99.9 %); 60 % is typical for discrete manufacturing without a CI program; below 40 % the bottleneck is usually systemic — planning, materials or maintenance strategy, not the operator. TEEP scales OEE by calendar loading (planned time / calendar time) and exposes the structural reserve: a single-shift operation can rarely exceed ~33 % TEEP even at perfect OEE — the honest argument for a second shift or a new line.
8 h shift, 30 min planned stops, 20 min unplanned downtime, 11.5 s ideal cycle, 2 100 pieces with 25 rejects: planned production time = 450 min, run time = 430 min → A = 95.6 %. Ideal run time = 402.5 min → P = 93.6 %. Q = 98.8 %. OEE = 88.4 % — above the world-class line, with speed loss (27.5 min) as the largest remaining bar. Push downtime to 47 min and the verdict flips below target at 75.6 % — the waterfall immediately shows why.
Performance came out above 100 % — is that good? It is impossible by definition and means the data is lying: the "ideal" cycle is padded, the counter overcounts, or downtime is under-recorded. The engine blocks the report until the inconsistency is fixed — an OEE above 100 % in any factor destroys the credibility of the whole metric.
Should changeover be planned or unplanned? Consistency matters more than doctrine, but best practice: planned changeover time sits in planned stops, changeover overruns and waiting sit in unplanned downtime. SMED then attacks the planned part transparently.
How do I aggregate a week? Sum the minutes and pieces across shifts first, then compute OEE once — never average daily OEE percentages (a zero-output day drags a simple average below any honest number).
What OEE should the sales team quote? The audited one. OEE is an improvement metric, not a marketing metric — quoting 85 % while running 60 % prices capacity you do not have.
