# OEE **URL:** https://kaizumi.com/dictionary/oee **Description:** OEE is the share of planned time an asset ran at full speed making good units. On the shift carved here, 298 of 400 minutes, or 74.5%. **Category:** tpm **Tags:** metrics, equipment, foundational ## The multiplication | Why 90% × 90% × 90% is 73% OEE If you have three scores of `90`%, your overall result is not `90`%. It is `72.9`%. That is because OEE multiplies the three numbers together. Each loss reduces what is left from the step before it. OEE stands for Overall Equipment Effectiveness. It tracks how well one piece of equipment ran over one span of time. It looks at three questions: 1. Availability: Did the machine run when you planned to run it? 2. Performance: When it was running, did it run as fast as it was designed to run? 3. Quality: How much of the output met standards on the first try? Imagine your equipment is running for `90`% of your planned time. While running, it operates at `90`% of its ideal speed. And `90`% of what it produces is good. On its own, each of those three numbers looks acceptable. ```kz-tiles lead: OEE tile: Each factor | 90.0 | % tile: Their average | 90.0 | % tile: OEE | 72.9 | % ``` ```kz-callout tone: note title: Do not average the three factors. p: Average them and you get `90`. Multiply them and you get `72.9`. Each factor divides by what the factor before it left, not by the whole shift, so the losses stack. ``` ```kz-figure id: compounding caption: Each bar keeps a share of what the bar over it handed on. Nothing counts twice. The losses just stack. wide: true ``` You can see this clearly if you follow the minutes. Out of `100` planned minutes, Availability leaves you with `90` minutes of run time. Performance keeps `90`% of those `90` minutes, which is `81` minutes. Quality keeps `90`% of those `81` minutes, which leaves `72.9` minutes. No single factor lost more than ten points. Together they put the result seventeen points below `90`%. In real operations, the three factors are rarely identical. Here is how a real eight-hour shift on a filling line looked. ```kz-tiles lead: OEE tile: Availability | 85.0 | % tile: Performance | 90.0 | % tile: Quality | 97.4 | % tile: OEE | 74.5 | % ``` When you multiply `85.0`% by `90.0`% by `97.4`%, you get `74.5`%. Two of those three numbers would pass a review on their own. The combined score still sits ten and a half points below the `85`% mark that people call world class. This is why OEE is useful. It shows how small losses across different areas combine into a larger total loss. ## The shift ledger | Where OEE goes in 480 minutes It helps to think of OEE as an account of your time. You start with the total minutes on the shift clock. Then you subtract losses step by step until you are left with only the minutes that produced good output at full speed. Here is an eight-hour shift on a filling line, totaling `480` minutes. You can apply the exact same breakdown to a CT scanner in a hospital, a sorting machine in a warehouse, or a document processing system in an office. Only the names of the cuts change. | Cut | Minutes | What is left | |---|---|---| | The shift on the clock | — | `480` | | Breaks | `30` | `450` | | Hours with no demand | `50` | `400` planned production time | | Breakdowns and changeovers | `60` | `340` run time | | Speed loss and short stops | `34` | `306` net run time | | Rejects | `8` | `298` **fully productive** | ```kz-figure id: shift-ledger caption: The same 480 minutes, drawn to scale. The two dashed blocks never enter the sum. The three grey blocks are the losses OEE charges to the asset. wide: true ``` ```kz-callout tone: note title: The ledger has to close. p: `30` + `50` + `60` + `34` + `8` + `298` = `480`. Every minute of the shift sits in one bucket and one only. If your own ledger does not close, you are counting a loss twice or missing it. That is a bookkeeping fault, not an equipment fault. ``` To build this record for your own equipment, you need four basic pieces of information: 1. The planned start and end time of the shift. 2. The duration of every downtime stop. 3. The total number of units produced. 4. The number of good units that passed quality checks. A supervisor can collect all four during one shift with a clipboard. Notice that the first two items in the table are removed before calculating OEE. Scheduled breaks and periods with no work scheduled are not equipment problems. If you counted them against the machine, your score would not tell you anything useful about how the machine actually ran. That one decision moves the final number more than any other choice you make. ### How the three OEE factors nest Here is how the three factors work out from the table: - [Availability](/dictionary/availability) is `340` ÷ `400` = `85.0`%. - Performance is `306` ÷ `340` = `90.0`%. - Quality is `298` ÷ `306` = `97.4`%. Notice the numbers in the fractions: the top number of one fraction becomes the bottom number of the next fraction. When you multiply them together, those middle numbers cancel out: `340`/`400` × `306`/`340` × `298`/`306` = `298`/`400` This leaves you with `298` divided by `400`, which equals `74.5`%. Multiplying the three factors gives you the exact proportion of planned time that was fully productive. That is why you multiply these numbers rather than averaging them. ```kz-formula expr: OEE = A × P × Q expr: = 298 ÷ 400 = 74.5% var: A | **Availability.** Run time ÷ planned production time. Here `340` ÷ `400` = `85.0`%. It carries breakdowns and changeovers. var: P | **Performance.** (Ideal cycle time × total count) ÷ run time. Here `306` ÷ `340` = `90.0`%. It carries speed loss and short stops. var: Q | **Quality.** Good count ÷ total count. Here `5,960` ÷ `6,120` = `97.4`%. It carries defects and start-up scrap. var: 400 | **Planned production time**, in minutes. The shift, minus breaks, minus time you never meant to run. var: 298 | **Fully productive minutes.** Good count × ideal cycle time. The only minutes all three factors let through. ``` ### The short OEE formula You can also calculate OEE directly in one step without working out the three individual factors first. Take the total number of good units produced and multiply by the ideal cycle time. Then divide that by the total planned production time. In our example, `5,960` good units multiplied by an ideal [cycle time](/guides/cycle-time-vs-takt-time-vs-lead-time) of `3.0` seconds gives `17,880` seconds of productive work. The planned time of `400` minutes equals `24,000` seconds. Dividing `17,880` by `24,000` gives `74.5`%. It gives the exact same result because it uses the same underlying data. Five raw inputs drive every number in this example: - Planned production time: `400` minutes - Unplanned downtime: `60` minutes - Ideal cycle time: `3.0` seconds per unit - Total units produced: `6,120` - Good units produced: `5,960` ### The six big losses behind OEE | Factor | The two losses it carries | Where to take it next | |---|---|---| | Availability | Breakdowns; setup and changeover | [Changeover](/dictionary/changeover) and [SMED](/dictionary/smed) | | Performance | Short stops and idling; slow running | [Minor stops](/dictionary/minor-stops) and [speed loss](/guides/oee-in-manufacturing) | | Quality | Defects in the process; start-up scrap | [First-pass yield](/dictionary/first-pass-yield) and the [six big losses](/dictionary/six-big-losses) | ```kz-callout tone: warn title: A Performance over 100% is an input error. p: It means the ideal cycle time you divide by is slower than the asset really runs. Or nobody logged a stop. Fix the input. Cap the output at `100` and you hide the fault while your OEE stays wrong. ``` ```kz-photo src: /guides/andon/team_leader_responds.webp alt: A man in an orange hard hat and blue high-visibility vest walks the aisle of a vehicle assembly line while operators in green vests work on a car body behind him. caption: **A stop counts only if someone writes it down.** Every minute in the ledger came from a log. Where people record stops by hand, the short ones go missing and OEE reads high. width: 1200 height: 896 ``` If you adjust any of the five inputs, you will see how it affects the different factors. You can see this step by step in the [interactive guide to OEE](/guides/oee-overall-equipment-effectiveness). ## Denominators | OEE vs OOE vs TEEP OEE, OOE, and TEEP all measure the exact same `298` productive minutes. The only difference between them is the total time you compare those productive minutes against. The top number of the fraction stays the same. The bottom number changes depending on what scope of time you want to evaluate. | Metric | What you divide by | Arithmetic | Result | |---|---|---|---| | OEE | Planned production time, `400` min | `298` ÷ `400` | `74.5`% | | OOE | The scheduled shift, `480` min | `298` ÷ `480` | `62.1`% | | TEEP | The calendar day, `1,440` min | `298` ÷ `1,440` | `20.7`% | ```kz-figure id: denominator-family caption: One blue block of 298 productive minutes, held against three different spans. The gap between 74.5% and 20.7% is a scheduling choice, not an equipment fault. wide: true ``` Because of how they are calculated, these three metrics will always rank in the same order for any given machine: OEE will be the highest, followed by OOE, followed by TEEP. If you increase the total time in the denominator while keeping productive minutes the same, the percentage naturally goes down. If your OEE goes up while your TEEP stays unchanged, it means the machine ran better during the hours it was scheduled, but total output across the full day did not increase. Each metric helps you answer a different practical question: - OEE tells you how effectively you used the time you actually intended to run. This is a maintenance and operations question that your team can address directly on the shift. - TEEP (Total Effective Equipment Performance) shows how much total capacity you have across all 24 hours of the day (`1,440` minutes). In this example, the machine was not scheduled to run for `960` minutes of the day. No amount of maintenance work recovers those minutes. Check TEEP before deciding whether to buy additional equipment, because it shows how much unscheduled time is still available on the machines you already have. Looking at both metrics gives a complete picture. A low OEE with a high TEEP means your machine is running frequently, but running poorly. A high OEE with a low TEEP means your machine runs very well when scheduled, but sits idle for most of the day. Those two problems need different fixes, and only one of them is a maintenance job. Note that definitions of OOE (Overall Operations Effectiveness) can vary between organizations. In the table above, OOE divides productive time by the full scheduled shift, including breaks. Whenever you share an OOE or OEE number, always make sure everyone understands which total time you are using as the denominator. If someone tells you a line runs at `85` percent, ask what they divided by before you compare that number to anything. ```kz-qa q: How is OEE calculated? a: Multiply Availability by Performance by Quality. On the filling-line shift that is `340` ÷ `400`, times `306` ÷ `340`, times `298` ÷ `306`. The middle terms cancel, leaving `298` ÷ `400` = `74.5`%. The method comes from [Total Productive Maintenance](/dictionary/total-productive-maintenance), where it was built to expose the six big losses on one machine. q: What counts as planned production time? a: The scheduled shift, minus the time you never meant to run: breaks, meetings, and hours with no demand. On the filling line that is `480` minus `30` minus `50` = `400` minutes. Unplanned stops stay in, because they are what OEE is there to measure. q: What is a good OEE score? a: The `60`% typical and `85`% world-class figures are rules of thumb, not measured benchmarks. An asset running twelve changeovers a day cannot post the same honest number as one running a single product all week. Compare your asset to its own trend instead. q: Why do the three OEE factors multiply instead of averaging? a: Because each factor divides by the one before it. Average three factors of `90`% and you get `90`. Multiply them and you get `72.9`. Only `72.9`% of planned time survived all three, so `72.9` is the true answer. q: What is the difference between OEE and TEEP? a: The clock, not the method. Both count fully productive minutes. OEE divides by planned production time: `298` ÷ `400` = `74.5`%. TEEP divides by every minute in the calendar day: `298` ÷ `1,440` = `20.7`%. q: What should I do if Performance comes out above 100 percent? a: Fix an input, never the output. A Performance over `100`% means the ideal cycle time you divided by is slower than the asset really runs, or nobody logged a stop. Cap the figure at `100` and you hide the fault while the OEE stays wrong. ``` ## Same score, two lines | What one OEE number hides Two different production lines can have the exact same OEE score of `74.5`%, while running in completely different ways. One of them scraps five and a half times as much material as the other. Both lines ran the same product at the same hour. Both had `400` minutes of planned production time, an ideal cycle time of `3.0` seconds, and shipped `5,960` good units. ```kz-pass title: Line A — the shift carved in the ledger step: Availability = 340 ÷ 400 = **85.0%** step: Performance = 306 ÷ 340 = **90.0%** step: Quality = 5,960 ÷ 6,120 = **97.4%** step: OEE = 0.850 × 0.900 × 0.974 = **74.5%** out: `160` units rejected. **298** fully productive minutes. ``` ```kz-pass title: Line B — same shift, same hour step: Availability = 380 ÷ 400 = **95.0%** step: Performance = 342 ÷ 380 = **90.0%** step: Quality = 5,960 ÷ 6,840 = **87.1%** step: OEE = 0.950 × 0.900 × 0.871 = **74.5%** out: `880` units rejected. **298** fully productive minutes. ``` Line B had only `20` minutes of downtime, while Line A had `60` minutes. Looking only at uptime, Line B seems much better. However, Line B had to produce `6,840` units to get `5,960` good ones, scrapping `880` units. Line A only scrapped `160` units. Line B used `720` more units of raw material to deliver the exact same amount of finished product. The overall OEE percentage alone cannot show you this difference. Quote OEE on its own and you lose the part that tells you what to work on next. That is why you should always look at Availability, Performance, and Quality together alongside the final OEE score. ### Which OEE factor to fix first Improving one factor will have a bigger effect on your total OEE than improving another, depending on where they currently stand. Here is what happens if you improve each factor on Line A individually: - Improving Availability by five points (from `85.0`% to `90.0`%) raises OEE to `78.9`%. - Improving Performance by five points (from `90.0`% to `95.0`%) raises OEE to `78.6`%. - Improving Quality to a perfect `100`% (a gain of `2.6` points from `97.4`%) raises OEE to `76.5`%. A five-point gain in Availability adds `4.4` points to overall OEE. A five-point gain in Performance adds `4.1` points. Quality is already at `97.4`%, so there are only `2.6` points available to gain, which adds at most `2.0` points to OEE. As a general rule, focus your improvement efforts on the lowest factor first. A factor that is already near `100`% offers very little room for overall gains. ## Limits | What an OEE score cannot prove OEE is a tool for identifying where equipment losses occur. It is not designed to measure individual employee performance. | | What the number proves | What people read into it | |---|---|---| | Scope | How much of one asset's planned time was fully productive | How hard the crew worked | | Diagnosis | Which factor sits furthest from its own ceiling | A pass or fail against an `85`% bar | | Comparison | One asset's trend, measured one way, over time | A league table across machines, shifts and sites | | Cause | That you lost time | Why you lost it | **Target numbers are only general guidelines.** The standard figures of `60`% for a typical operation and `85`% for world-class performance are rules of thumb. No published measurement stands behind them. They travel because they are easy to repeat. A machine that requires twelve product changeovers per day will naturally have a lower OEE than a machine that runs the same product all week without stopping. If you compare those two machines directly, you are mostly measuring the difference in scheduling, not how well the equipment was maintained. The most meaningful comparison is tracking how a single machine performs against its own past record over time. **Manual logs often overestimate OEE.** Paper logs usually show higher OEE scores than automated tracking systems. When operators record stops by hand, [minor stops](/dictionary/minor-stops) lasting only a few seconds or a minute often do not get written down. If your OEE score drops right after you install automated sensors, your equipment did not suddenly get worse; you simply started capturing the short stops that were previously missed. **Maximizing OEE on non-bottleneck machines can create waste.** If you push a machine to `95`% OEE when it is not the [bottleneck](/dictionary/bottleneck-analysis) in your process, it will simply produce work faster than the next step can handle. This leads to [overproduction](/dictionary/muda), which ties up space and working capital. A very high OEE can also mean you have used up your spare capacity. When the bottleneck stops, you have nothing left to catch up with. Focus your OEE improvement on the bottleneck process. For non-bottleneck equipment, focus on reliability and uptime so it runs when needed; see [MTBF](/dictionary/mtbf). **Counting reworked items as good inflates the Quality score.** The Quality factor is meant to measure items that are good on the very first pass. If an item comes off a process defective, gets repaired, and then passes inspection, it consumed extra time and capacity. If you count reworked units as good on the first pass, you hide both the defect rate and the time lost to rework. If your Quality factor never moves, check the counting rule before you congratulate anyone. For more on this, see [first-pass yield](/dictionary/first-pass-yield) and [jidoka](/dictionary/jidoka). ```kz-callout tone: warn title: OEE was built to diagnose one machine. p: Teams routinely run it as a plant-wide KPI, rolled up across assets that share nothing but a site. That is the misuse that makes people game it. A gamed OEE is worse than no OEE, because it survives review. ``` To take action on your findings, use the framework in [Total Productive Maintenance](/dictionary/total-productive-maintenance) to organize your improvement work, and review the [six big losses](/dictionary/six-big-losses) to categorize and address specific causes of downtime. Source: https://kaizumi.com/dictionary/oee Licence: free to quote and cite with attribution to Kaizumi.