OEE vs TEEP vs OOE: Which Effectiveness Metric to Report

Three shifts into a new plant dashboard rollout, someone asks why Line 3’s blow-molder “effectiveness” is 76% on the shift report, 71% on the operations weekly, and 24% on the capacity-planning slide — and all three numbers are computed from the exact same eight hours of data. This is the recurring confusion this page under OEE formula validation exists to resolve: OEE, TEEP, and OOE are not three competing formulas, they are the same Availability × Performance × Quality structure evaluated against three different time bases, and the base you choose determines both the number and the audience it is honest to show it to. Report OEE to the line and ask them to defend TEEP, and you will get a confused shift supervisor; report TEEP to a capacity-planning committee and call it OEE, and you will get a plant that looks unfixably underutilized when the real story is a deliberate single-shift schedule.

The one shift, three time bases #Permalink to this section

Take Line 3’s blow-molder on an 8-hour shift that runs inside a 24-hour day where only that one shift is scheduled — the other 16 hours the asset is simply not staffed. Within the shift: 30 minutes (1,800 s) of scheduled changeover and break time, 45 minutes (2,700 s) of unplanned breakdown, 4,500 units produced at an ideal cycle time of 4.8 s/unit, and 4,275 of them good.

$\begin{aligned} \text{All Time} &= 86{,}400\ \text{s} \quad \text{(24h calendar day)} \\ \text{Available/Scheduled Time} &= 28{,}800\ \text{s} \quad \text{(the one 8h shift)} \\ \text{Planned Downtime} &= 1{,}800\ \text{s} \quad \text{(break, changeover)} \\ \text{Planned Production Time (PPT)} &= 28{,}800 - 1{,}800 = 27{,}000\ \text{s} \\ \text{Unplanned Downtime} &= 2{,}700\ \text{s} \\ \text{Run Time} &= 27{,}000 - 2{,}700 = 24{,}300\ \text{s} \end{aligned}$

Performance and Quality are identical inputs to all three metrics — only the Availability-equivalent factor’s denominator changes:

$\text{Performance} = \frac{4{,}500 \times 4.8}{24{,}300} = \frac{21{,}600}{24{,}300} = 0.8889 \qquad \text{Quality} = \frac{4{,}275}{4{,}500} = 0.95$

OEE: effectiveness against Planned Production Time #Permalink to this section

OEE answers “given the time we scheduled this asset to run, how effectively did we use it?” Its Availability factor excludes planned downtime from the denominator entirely — changeovers, breaks, and preventive maintenance are treated as time the asset was never supposed to be producing, so they cannot count against it.

$A_{\text{OEE}} = \frac{\text{Run Time}}{\text{Planned Production Time}} = \frac{24{,}300}{27{,}000} = 0.9$

$\text{OEE} = A_{\text{OEE}} \times P \times Q = 0.9 \times 0.8889 \times 0.95 = 0.76 \;\Rightarrow\; 76.00\%$

This is the number the line supervisor and the maintenance team should see every shift: it measures losses they can actually act on — breakdowns, speed loss governed by threshold tuning for microstops, scrap — without penalizing them for a changeover schedule set by production planning. The exact formula and its clamping/Decimal discipline are specified in OEE formula validation; this page assumes those factors are already validated and asks only which denominator to wrap around them.

from decimal import Decimal

run_time = Decimal("24300")
planned_production_time = Decimal("27000")
performance = Decimal("0.8889")
quality = Decimal("0.95")

availability_oee = run_time / planned_production_time
oee = (availability_oee * performance * quality).quantize(Decimal("0.0001"))
# availability_oee = 0.9000, oee = 0.7600

OOE: effectiveness against the scheduled shift, planned downtime included #Permalink to this section

OOE (Overall Operations Effectiveness) answers a stricter question: “given that the asset was staffed and scheduled at all, how effectively did we use that entire window, including the time we deliberately spent on changeovers and breaks?” The distinguishing rule is that OOE folds planned downtime back into the denominator instead of excluding it — a long changeover now costs the operation something on paper, which is exactly the pressure some plants want on their changeover discipline.

$A_{\text{OOE}} = \frac{\text{Run Time}}{\text{Scheduled Time}} = \frac{24{,}300}{28{,}800} = 0.84375$

$\text{OOE} = A_{\text{OOE}} \times P \times Q = 0.84375 \times 0.8889 \times 0.95 = 0.7125 \;\Rightarrow\; 71.25\%$

Note that Scheduled Time here (28,800 s) equals Planned Production Time plus planned downtime — the asset was staffed for the full shift, so OOE’s base is everything within that staffed window, not just the portion planning intended for production. OOE sits between OEE and TEEP by design: it does not punish the asset for hours it was never staffed at all (that is TEEP’s job), but it does count every staffed minute, planned or not.

scheduled_time = Decimal("28800")  # the full 8h shift, staffed and available

availability_ooe = run_time / scheduled_time
ooe = (availability_ooe * performance * quality).quantize(Decimal("0.0001"))
# availability_ooe = 0.8438 (rounded), ooe = 0.7125

TEEP: effectiveness against all calendar time #Permalink to this section

TEEP (Total Effective Equipment Performance) answers the capacity-planning question: “given every hour that exists, how much of the asset’s theoretical output did we actually capture?” It is OEE multiplied by a Utilization factor that accounts for the hours the asset was never even scheduled — nights, weekends, or, in this case, the 16 hours of the day this single-shift line simply was not staffed.

$\text{Utilization} = \frac{\text{Planned Production Time}}{\text{All Time}} = \frac{27{,}000}{86{,}400} = 0.3125$

$\text{TEEP} = \text{OEE} \times \text{Utilization} = 0.76 \times 0.3125 = 0.2375 \;\Rightarrow\; 23.75\%$

A TEEP of 23.75% is not a verdict on the shift crew — it is a statement about schedule, and specifically about whether adding a second or third shift would be more valuable than continuing to chase Performance losses on the one shift already running. Reporting this number to a shift supervisor as if it were their OEE will read as an accusation of failure for a scheduling decision they do not control; reporting OEE to a capacity-planning committee will hide the unscheduled 16 hours that a second shift could recover, which is the reasoning rolling up OEE from line to plant has to account for once TEEP is aggregated across assets with different shift counts.

all_time = Decimal("86400")  # full 24h calendar day

planned_production_time = Decimal("27000")
utilization = (planned_production_time / all_time).quantize(Decimal("0.0001"))
teep = (oee * utilization).quantize(Decimal("0.0001"))
# utilization = 0.3125, teep = 0.2375

All three computations must draw from the same validated, shift-boundary-resolved Run Time, Performance, and Quality — the only new input each successive metric needs is a wider window definition (Scheduled Time for OOE, All Time for TEEP), never a different measurement of what actually happened on the floor.

Gotchas & anti-patterns #Permalink to this section

• Reporting TEEP on a shift dashboard. Operators cannot fix a scheduling gap during their shift; showing them TEEP where they expect OEE manufactures a demoralizing number that is not actionable at their level.
• Comparing OEE across assets with different shift counts. A single-shift cell and a 24/7 line can post identical OEE while representing wildly different total output; TEEP is the metric that makes that difference visible, not OEE.
• Averaging OOE and OEE as if they measure the same loss. They differ specifically in whether planned downtime counts against the asset — averaging them produces a number with no defined meaning.
• Forgetting that Utilization needs its own audit trail. Utilization depends on the shift schedule, not on telemetry; a bug in the shift calendar corrupts TEEP even when Availability, Performance, and Quality are all correct.
• Using TEEP’s calendar-time base without normalizing to a facility’s actual operable hours. A facility legally closed on Sundays should exclude those hours from “all time” or TEEP conflates a closed day with a lost production opportunity that never existed.

Quick reference #Permalink to this section

Related #Permalink to this section

• OEE Formula Validation — the validated Availability, Performance and Quality factors every metric here reuses.
• Shift Boundary Logic — the materialized shift calendar that defines Scheduled Time and Planned Production Time.
• Rolling Up OEE from Line to Plant with Weighted Aggregation — aggregating these metrics across assets with different shift schedules.