OEEOverall Equipment Effectiveness

Overall Equipment Effectiveness is a productivity metric developed by Seiichi Nakajima as part of Total Productive Maintenance in the 1970s and refined since. It compresses three independent dimensions — Availability, Performance and Quality — into a single percentage that represents what fraction of the planned production time produced good product at the ideal rate.

It is the most widely used line-productivity metric in regulated manufacturing because it is comparable across products, lines and sites, and it points directly to the loss category that's hurting most. A single OEE number on its own is not useful; an OEE number with its three components broken out, and each component traceable to specific reason codes, is enormously useful.

Crucially, OEE is a measurement system, not a target. It exists to expose loss so it can be improved — not to justify a bonus or punish a shift. Sites that treat OEE as a scoreboard rather than a microscope tend to lose its diagnostic value within a year.

• Availability = Run Time / Planned Production Time. (Run Time excludes unplanned stops and changeovers.)
• Performance = (Ideal Cycle Time × Total Count) / Run Time. (Penalises small stops and slow cycles.)
• Quality = Good Count / Total Count.
• OEE = Availability × Performance × Quality.

Planned Production Time excludes scheduled downtime (no-demand, planned maintenance, planned breaks). That distinction matters — OEE measures how well you use the time you committed to producing, not the time the line existed.

Worked example. A line is scheduled to run a 480-minute shift. 30 minutes of unplanned stops and 30 minutes of changeover give 420 minutes of Run Time. Availability = 420/480 = 87.5%. The line produced 8,000 units against an ideal cycle of 3 seconds/unit, giving a Performance of (3 × 8,000) / (420 × 60) = 95.2%. Of 8,000 units, 7,920 passed QC and 80 were scrapped: Quality = 99.0%. OEE = 0.875 × 0.952 × 0.99 = 82.5%.

The six losses are deliberately exhaustive. Every minute the line is doing something other than making good product at full speed falls into exactly one bucket. That mutual exclusivity is what allows OEE to be summed, compared and trended without double-counting.

Nakajima's original 'world-class' benchmark, widely cited: Availability ≥ 90%, Performance ≥ 95%, Quality ≥ 99.9%, OEE ≥ 85%. In practice OEE of 60% is typical, 75% is good, 85% is world-class for discrete and batch manufacturing.

Regulated industries often run lower than world-class because changeovers (lot, product, allergen, line clearance) and in-process checks consume real time. That doesn't make 85% irrelevant — it makes year-on-year improvement meaningful even at lower absolute levels.

OEE is comprehensible enough that it is also gameable. Every common gaming pattern leaves a fingerprint and an honest review process catches them quickly:

• Planned downtime expanded to make Availability look better — fingerprint: a long-running asset with declining true throughput but rising OEE.
• Ideal cycle time set to the actual achieved rate, making Performance always ~100% — fingerprint: Performance never moves and Availability is the only dimension that varies.
• Rework counted as good, hiding Quality losses — fingerprint: rework labour rising while reported scrap remains flat.
• Small stops not captured because they're shorter than the threshold — fingerprint: real-world observation shows frequent micro-stops that don't appear in the data.
• Different lines computing OEE with different rule-sets, so cross-site comparisons are meaningless — fingerprint: identical assets show 20-point OEE differences with no operational explanation.
• Unplanned downtime re-classified as planned during the shift handover — fingerprint: downtime reason codes change category overnight.

An OEE programme without explicit definitions of cycle time, reason codes and stop thresholds is a number-generator, not a measurement system. The cure is a one-page rule-set agreed across sites, baked into the data capture, and reviewed quarterly.

FDA's 2011 process-validation guidance (Stage 3 — Continued Process Verification) expects on-going monitoring of CQAs and CPPs. EU GMP Annex 15 §11 expects equivalent continued process verification. OEE on its own isn't a CQA, but its Quality component (scrap, rework, in-spec rate) is — and trending it reveals process drift the same way SPC does.

Operationally, a sustained drop in Quality % feeds into NCR/CAPA. A drop in Availability feeds into preventive-maintenance review. A drop in Performance feeds into process engineering. OEE is therefore not a separate programme; it's the dashboard view of the quality management system from a productivity angle.

OEE has cousins. They use the same six-loss model but change the denominator:

• TEEP (Total Effective Equipment Performance) = OEE × Utilisation, where Utilisation = Planned Production Time / Calendar Time. Useful for boards and finance — answers 'are we leaving capacity on the table?' rather than 'are we executing well in the time we run?'.
• OOE (Overall Operations Effectiveness) — same formula as OEE but uses Operating Time (excludes only unplanned stops, includes planned stops) as the basis for Performance. Some sites prefer it for direct shop-floor improvement focus.
• OAE (Overall Asset Effectiveness) — an asset-management variant that includes maintenance availability as a factor; common in mining and heavy industry.
• FTQ (First-Time Quality) — the Quality dimension of OEE on its own. Often reported alongside.
• MTBF / MTTR (Mean Time Between/To Repair) — supports the Availability dimension by exposing reliability vs maintainability separately.

A typical mature programme reports OEE for line management, TEEP for capacity planning, and MTBF/MTTR for reliability engineering. They are complementary, not competing.

1. Pick one line. Don't roll OEE site-wide on day one — pilot, learn, then scale.
2. Agree the rule-set. Cycle time per SKU, reason codes (20–30 max), stop threshold (typically 1 minute), what 'planned' means. Document and approve before any data is captured.
3. Automate the capture. Manual OEE entry decays within 90 days as operators lose patience. Capture starts, stops, scrap and reasons at the kiosk or controller.
4. Visualise the losses, not the OEE number. The number is the conversation starter; the loss breakdown is the conversation.
5. Build the daily standup around the top three losses, not around hitting a target.
6. Run a quarterly rule-set review. Cycle times drift, reason codes accumulate, new SKUs appear — keep the definitions clean.
7. Tie improvements to CAPA and engineering changes — close the loop, don't just visualise.

Sites that follow this sequence still see OEE in active use five years later. Sites that skip the rule-set step or rely on manual entry typically see the dashboards quietly stop being opened around month six.

V5 treats OEE as a derived metric on top of the events the operator generates as part of running the floor. There is no separate OEE entry workflow.

• Cycle time per SKU is stored on the routing / formula and used as the ideal-rate baseline.
• Start / pause / resume / stop events flow from the kiosk and from connected PLCs where available.
• Downtime reason codes are a controlled list per work centre, with a configurable threshold below which stops are auto-classified as micro-stops.
• Scrap is recorded with reason code and disposition; rework is captured separately and not double-counted as good.
• Changeover and sanitation are first-class event types, classified as Availability loss with their own reason code so SMED programmes can target them directly.
• OEE, Availability, Performance, Quality, TEEP and MTBF are computed per line, asset, shift, product and time window — drillable to the underlying events.
• Trend dashboards expose drift; alerts can fire on a Quality dimension drop sustained over N lots, automatically opening an investigation record.
• Year-on-year, month-on-month and shift-on-shift comparison are first-class, with a clear definition badge that warns if the rule-set has changed across the period.

An OEE number on its own is a vanity metric. The discipline that makes OEE actionable is the loss tree — a hierarchical decomposition of every minute of Planned Production Time into either Productive Time or one named loss. The tree usually has three levels: dimension (Availability / Performance / Quality) → loss family (changeover, breakdown, minor stop, speed loss, start-up reject, in-process reject) → root cause (specific failure mode tied to an asset and a reason code). Every minute lost is owned by exactly one leaf — no orphaned time, no 'other / unknown' bucket greater than 2% (anything above is itself a measurement defect to fix).

From the loss tree comes the Pareto: stack-rank the loss families by dollarised minutes lost over a rolling 8-week window, then attack the top three. The mistake most programmes make is launching ten kaizens at once across every loss family; the discipline is to lock the top three and refuse to start a fourth until one of the three retires. This is how a programme moves OEE 5–10 percentage points per year instead of 0.5.

Dollarise every loss family monthly — minutes × throughput × contribution margin — and post the dollar Pareto next to the percentage Pareto. The two often disagree because a 10-minute changeover loss on a high-margin SKU dwarfs a 30-minute breakdown on a commodity line. Improvement effort follows the dollar Pareto, not the minute Pareto.

OEE quality is bounded by the quality of the underlying minute-by-minute capture. Three tiers exist, and almost every site runs a mix:

• Automated — PLC / SCADA / OPC-UA tag reads every 1–5 seconds with state machine (Running / Stopped / Starved / Blocked / Faulted) derived from cycle pulses, fault codes and infeed/outfeed sensors. Best for high-speed packaging, tablet press, capsule fill, bottling.
• Semi-automated — equipment provides on/off + cycle count; operator confirms reason code on every stop ≥ a threshold (typically 3 minutes). Best for mixers, granulators, sterile-fill lines where state inference is ambiguous.
• Manual — operator logs run-time + downtime + reason against a paper or kiosk-form shift report. Lowest fidelity, but the only option for manual workstations and many older assets. Use only with discipline: reason-code dictionary capped at ~12 entries (longer lists collapse into 'Other'), kiosk validation that total minutes equal shift minutes, and supervisor sign-off before shift end.

The most common architectural mistake is mixing tiers within a single OEE number without flagging it — a line that's 70% automated and 30% manual capture will under-report minor stops by 30–60% because operators systematically miss sub-5-minute interruptions. Either flag the manual-capture portion, or invest in semi-automated capture for the manual stations before publishing the unified number.

Latency matters too. OEE captured in real time (sub-minute) drives operator behaviour; OEE captured at end-of-shift drives reporting only. For improvement programmes to bite, the operator must see live OEE on an andon or kiosk while the shift is in progress — not the day after.

OEE moves the needle when it's embedded in the daily-management cadence: a 10-minute shift-handover huddle in front of an andon showing yesterday's OEE, the three largest losses, the open improvement actions and their owners. Sites that publish OEE only in a monthly steering deck see no behavioural change; sites that visualise it at the shift huddle see week-over-week improvement within a quarter.

1. Shift huddle (10 min, daily) — yesterday's OEE per line, top 3 losses with dollars attached, status of the 3 open kaizens.
2. Tier 2 daily-management meeting (15 min) — production / maintenance / quality cross-functional, escalate anything the shift couldn't resolve, assign owners and dates.
3. Tier 3 weekly steering (30 min) — review the loss-tree Pareto for drift, retire completed kaizens, queue the next.
4. Monthly executive review — dollarised loss trend, OEE vs target, capital decisions (e.g. is the bottleneck loss now permanent without re-tooling?).

The cadence is more important than the meeting structure. Two failure modes kill it: skipping shift huddles when production is behind (which is exactly when the data is most valuable) and letting the loss-tree Pareto drift unaddressed for more than two weeks because the top kaizen stalled. Both signal that OEE has slipped back to a reporting artefact instead of an operational instrument.