Overall Equipment Effectiveness (OEE) and the Eight Losses

Learning objectives

Before you start

Nothing heavy—this lesson is arithmetic plus careful definitions. It helps if you are comfortable with percentages, the idea of a bottleneck operation, and basic shift documentation: downtime logs, production counts and scrap records.

The three factors

OEE asks one question in three parts: of the time we planned to make good parts, how much actually produced good parts at full rate?

Two definitions do most of the work, and nearly every argument about OEE is really an argument about one of them:

• Planned Production Time is all time minus time you genuinely did not intend to produce—no orders, unstaffed shift, planned shutdown. It is not "all time minus everything that went wrong".
• Ideal Cycle Time is the fastest sustainable rate the equipment has actually demonstrated for that product. Use the nameplate figure and performance will read artificially low forever.

Terminology and calculations

Interactive: OEE calculator

Change any input and all three factors move. The bar underneath converts every loss into the same currency—minutes—which is the single most useful habit in OEE work. The verdict line runs three consistency checks on your numbers.

Interactive: the eight losses

Nakajima's TPM framework names eight equipment losses. Six are the familiar "six big losses"; the full eight split out tool changes and planned shutdown, which matters because those are where disputes start. Select any loss to see where it lands and why.

Interactive: count versus minutes

The same shift, ranked two ways. Toggle between how often each loss happened and how many minutes it cost. Watch minor stops swap ends of the chart—this is precisely why you run the Minitab Pareto twice, and why a minutes-only report hides the most actionable problem on the line.

The two arguments that never end

Two losses account for most misclassification. Both feel obvious—and both feel obvious in the wrong direction.

Small stops feel like availability, but they are performance

A jam is a stop. The machine is not moving. Every instinct says availability. So why is loss 5 a performance loss?

Because of how the data are collected. Most downtime systems only capture stops above a threshold—commonly five minutes, sometimes two. A thirty-second jam that an operator clears by hand never becomes a downtime record. Nobody writes it down.

That has a direct arithmetic consequence. If the stop is not logged, it is not subtracted from run time. The clock keeps counting the machine as running. But no parts came out during those thirty seconds. So at the end of the shift the machine is credited with 370 minutes of run time and produced only 320 parts against an ideal of 370. The shortfall has nowhere else to go: it lands in performance.

Setup feels like performance, but it is availability

During a changeover the machine is far from idle. Operators jog the drive, run test pieces, tweak guides, make a part, measure it, adjust again. It looks like a machine running badly. Every instinct says performance.

But setup has something small stops do not: a clean start and a clean end. The changeover begins when the last good part of the old order comes off and ends when the first good part of the new order is confirmed. That is a bounded, recordable event—and it goes into the downtime log as a single entry. Logged time comes out of run time, so it reduces availability.

The test pieces made during setup are not counted as production. They were never sellable parts; they were part of the changeover.

The trick: logged or lost?

You do not need to memorise eight rows of a table. One question resolves every case, including both of the hard ones above.

Run the two hard cases through it:

• Setup and adjustment. Does it have a recorded start and end? Yes—every changeover does. Logged → availability. That the machine moves during setup is irrelevant; movement was never the test.
• Minor stoppages. Does a thirty-second jam have a recorded start and end? No. Lost → performance. That the machine stopped is irrelevant; stopping was never the test either.

Interactive: the logging threshold

This shift contained sixty minor stops lasting between 12 and 48 seconds, totalling 30 minutes. Drag the threshold to change the shortest stop your system records. Watch availability and performance trade places—and watch OEE refuse to move.

Interactive: classification drill

Ten shift-floor scenarios in random order. Decide the factor, then read the reasoning. Try to answer using the logged-or-lost test rather than recognition—the exam will not reuse these words.

How to calculate OEE for a shift

1. Fix the boundary. Write down planned production time first. Subtract only periods you never intended to produce. Do this before looking at any loss data, so the denominator is not quietly negotiated later.
2. Establish ideal cycle time. Take the fastest rate the line has actually sustained for that product, evidenced from run data. Record where the number came from.
3. Pull the downtime log. Total the logged stops. This is your availability loss, in minutes.
4. Classify every entry. Apply logged-or-lost to each reason code. Confirm nothing is counted twice.
5. Count production. Total count, then good count. Reworked parts are not good count.
6. Convert to minutes. Compute performance loss and quality loss as minutes, not percentages.
7. Reconcile. The four buckets must sum to planned production time. If they do not, stop and find the error before reporting anything.
8. Calculate twice. A × P × Q, then the one-line formula. They must agree.

Calculation shortcuts

1. Put everything in minutes

Percentages are hard to reason about and easy to mis-multiply. Minutes are not. Convert every loss into lost minutes and the whole shift reconciles on one line:

• Availability loss = logged downtime
• Performance loss = Run Time − (Total Count × Ideal Cycle Time)
• Quality loss = (Total Count − Good Count) × Ideal Cycle Time
• Fully productive time = Good Count × Ideal Cycle Time

If those four do not add to planned production time you have a data error—usually a stop counted twice, or an ideal cycle time that does not match the product mix.

2. The one-line OEE

You never actually need the three factors to get OEE:

This is the best check you have. Compute OEE both ways; if A × P × Q disagrees with the one-line version, something is double-counted. In an exam it takes fifteen seconds and catches arithmetic slips.

3. Attack your weakest factor first

Because the three multiply, the gain from improving one factor by a point is the product of the other two:

The lowest factor always has the highest product of the other two, so it always returns the most OEE per point. That is a mathematical result, not a rule of thumb—and the next interactive lets you confirm it.

4. Respect the multiplication

90 %, 90 % and 90 % do not average to 90 %. They multiply to 72.9 %. Three respectable numbers make one poor one. The widely quoted "world class" 85 % is 90.0 × 95.0 × 99.9—note how little quality loss it tolerates.

5. Points, not percent

Moving availability from 80 % to 82 % is two percentage points, and a 2.5 % relative improvement. "We improved availability by 2 %" is ambiguous and will be challenged in any serious review.

6. Performance above 100 % means your ideal is wrong

Performance is capped at 1.0 by definition. If you compute 104 %, the ideal cycle time is too slow, the part count includes rework passes, or run time is understated. Fix the input; never cap the output.

Interactive: where to improve first

Set any three factors and the panel calculates what one percentage point of improvement is worth on each. The winner is always the weakest factor, and now you can see why rather than take it on trust.

Worked example

A single shift on a packaging line. These are the calculator defaults, so you can follow along above.

Check with the one-line formula:

Check with the time buckets:

Note what the buckets reveal that the percentages hide. The largest single loss is not the breakdown everyone talks about—it is the 50 minutes of performance loss, which nobody logged and nobody raised at the morning meeting. It is invisible precisely because it never reached the downtime report.

Common mistakes

• Using nameplate speed as ideal cycle time. Performance is then permanently depressed and no improvement ever shows.
• Counting rework as good. Quality means good first pass. A part needing a second operation is a quality loss even if it eventually ships.
• Moving unplanned events into planned stops. Reclassifying a breakdown as "planned downtime" inflates OEE and hides the problem. Planned means you intended it before the shift started.
• Comparing OEE across different machines. OEE compares a machine to itself over time. Cross-machine league tables reward whoever set the softest ideal cycle time.
• Double-counting a logged small stop. Once it is in the downtime log it is an availability loss. Counting it again as performance loss breaks the reconciliation.
• Optimising OEE on a non-bottleneck. Running a non-constraint at high OEE builds inventory, not throughput.
• Reporting OEE without the loss breakdown. A single percentage tells nobody what to do next. Always publish the four buckets alongside it.

Statistics implementation: Excel & Minitab

Excel functions

Excel use cases

• Reason-code roll-up. With stop reasons in column B and minutes in column C, =SUMIFS($C:$C,$B:$B,"Setup") gives setup minutes. Repeat for all eight losses and confirm the total equals your logged downtime—if it does not, reason codes are missing or overlapping.
• Frequency versus duration. Put =COUNTIFS($B:$B,"Minor stop") beside =SUMIFS($C:$C,$B:$B,"Minor stop"). This separates "one long jam" from "sixty short ones", which demand completely different countermeasures and look identical in a minutes total.
• How much is invisible? =COUNTIFS(durations,"<"&$B$1) against your threshold in B1 counts the stops your system never records—the Excel equivalent of the threshold interactive above.
• Demonstrated ideal cycle time. Instead of arguing about nameplate speed, take =PERCENTILE.INC(cycle_times, 0.05) across clean runs. The fifth percentile of observed cycles is a defensible "fastest sustained" figure.
• Reconciliation column. Add =PPT-(down+perf_loss+qual_loss+productive). It should read zero on every row. Any non-zero cell is a data problem, and finding it here is far cheaper than in a review meeting.
• Mixed-model shifts. =SUMPRODUCT(part_counts, ideal_times) gives total ideal minutes when several products with different cycle times ran in one shift.

Minitab navigation

Exam tips

• Classification is the question. CSSBB and CQE items normally list shift events and ask for OEE. The arithmetic is trivial; the marks are in bucketing each event. Apply logged-or-lost to every line before calculating.
• Watch for planned time traps. A stem mentioning "two 15-minute breaks and a 30-minute unplanned stoppage" is testing whether you subtract the breaks from planned production time and leave the stoppage as an availability loss.
• Rework is a quality loss. If a stem says parts "required rework before shipping", they are not good count. One of the most common single-mark errors.
• Know the one-line formula. Faster than three divisions and it self-checks. Learn it as the primary method and use A × P × Q to confirm.
• OEE versus TEEP. If a question introduces total calendar time or unstaffed shifts, it is testing utilisation: TEEP = OEE × Utilisation.
• Reclassification questions. If a stem changes the logging threshold and asks what happens to OEE, the answer is "nothing"—availability and performance move in opposite directions by design.
• In the real world. Expect to defend your ideal cycle time more than your arithmetic. Bring the demonstrated-rate evidence; "the nameplate says so" will not survive review.

Try it yourself

Use one real shift from your own line, not a prepared dataset. The friction you hit is the lesson.

Check your understanding

Final summary

• OEE = Availability × Performance × Quality, and the one-line form (Good Count × Ideal Cycle Time ÷ Planned Production Time) gives the same answer as a check.
• The eight TPM losses map to three factors. Breakdown, setup, tool change and planned shutdown are availability; minor stops and reduced speed are performance; defects and start-up losses are quality.
• Logged or lost resolves any classification. Recorded time reduces availability, time that vanishes inside run time surfaces as performance, unsellable output is quality.
• Minor stops are a performance loss because nothing records them, not because of anything physical. Setup is an availability loss because it is recorded, not because the machine is still.
• Run time cancels in A × P, so classification never changes total OEE. It changes which improvement project you start—which is why it matters.
• Reconcile every shift in minutes. The four buckets must sum to planned production time.
• Improve your weakest factor first. The marginal gain is the product of the other two.

References and further reading

1. Nakajima, S. Introduction to TPM: Total Productive Maintenance. Productivity Press.
2. ASQ Certified Six Sigma Black Belt Body of Knowledge—Lean tools and process metrics.
3. ASQ Certified Quality Engineer Body of Knowledge—quality systems and continuous improvement.
4. Hansen, R. C. Overall Equipment Effectiveness. Industrial Press.