What OEE actually measures, and why it matters
Overall Equipment Effectiveness is the most widely used productivity KPI in manufacturing because it answers one deceptively simple question: of all the time we planned to be making product, how much of it actually produced good product, at the right speed?
Most operations teams think they already know the answer. They don't. Once OEE is measured properly - with real downtime data, real cycle times and real quality data joined together - the number is almost always lower than the plant manager guessed. The gap between what people think is happening and what is actually happening is exactly the opportunity OEE reporting is designed to expose.
Whichever platform the business uses to surface OEE - Microsoft Power BI, in our experience, is the most cost-effective fit for Australian manufacturers - the discipline is the same: measure honestly, define consistently, refresh often, and put the result in front of the people who can act on it.
The three components of OEE in plain English
OEE is one number, but it is made up of three multiplicative factors. Reporting only the headline figure tells you that you have a problem; reporting the three components tells you where to look.
1. Availability
Availability is the percentage of planned production time that the line was actually running. It captures unplanned downtime (breakdowns, material starvation, jams) and planned but avoidable stops (changeovers, scheduled cleaning that runs over). It excludes time the plant deliberately wasn't running (the night shift you didn't roster).
2. Performance
Performance is the percentage of the rated speed the line actually achieved while it was running. It captures the losses people rarely notice: micro-stops under 60 seconds, slow cycles, idling between parts. Performance is almost always the most underestimated of the three because the line looks like it's running fine.
3. Quality
Quality is the percentage of units produced that meet specification first time. Anything reworked, scrapped, downgraded or rejected reduces this number. Quality losses are particularly expensive because every defective unit consumed the same labour, energy, material and machine time as a good one.
How to calculate OEE without fooling yourself
The maths is trivial. The hard part is being honest about the inputs. Every plant we've worked with has at least one definitional disagreement that, once fixed, moves the number by several percentage points.
- 1
Define planned production time
Start with calendar time, subtract scheduled non-production (no shift, planned shutdown, planned maintenance windows). Whatever's left is your planned production time - the denominator for Availability.
- 2
Calculate Availability
Availability = Run Time / Planned Production Time. Run Time is planned production time minus all unplanned stops AND changeovers. World-class is ~90%.
- 3
Calculate Performance
Performance = (Ideal Cycle Time x Total Units Produced) / Run Time. This catches speed losses and micro-stops automatically. World-class is ~95%. Anything over 100% means your 'ideal cycle time' is wrong, not that you're a hero.
- 4
Calculate Quality
Quality = Good Units / Total Units Produced. Good = first-pass conformance, not reworked-then-passed. World-class is ~99%.
- 5
Multiply them together
OEE = Availability x Performance x Quality. 90% x 95% x 99% = ~85%, the recognised world-class benchmark for discrete manufacturing.
- 6
Report by line, shift and product
A plant-wide OEE number is interesting but rarely actionable. The same calculation broken down by line, by shift, by SKU and by changeover-vs-run is where the improvement opportunities live.
The six big losses that erode OEE
Most plants don't actually need an OEE number first - they need an OEE loss tree that classifies every minute the line wasn't producing perfectly. The standard framework, used in TPM (Total Productive Maintenance) since the 1970s, organises everything under six headings:
- Breakdowns - unplanned equipment failures (Availability loss)
- Setup and adjustments - changeovers, tool changes, format changes (Availability loss)
- Idling and minor stops - jams, sensor trips, brief operator interventions (Performance loss)
- Reduced speed - running below rated cycle time (Performance loss)
- Startup defects - scrap produced during warm-up and stabilisation (Quality loss)
- Production defects - scrap and rework during normal running (Quality loss)
Categorising every lost minute against these six buckets is what turns OEE from a vanity metric into an improvement programme. The bucket with the biggest loss in dollar terms is where your next continuous-improvement project should be.
How to visualise OEE so people actually act on it

A good OEE dashboard answers four questions in under five seconds: (1) where are we now, (2) against what target, (3) which factor is hurting us, and (4) what has changed. The pattern we use on almost every Power BI manufacturing dashboard is:
- Headline OEE card with current vs. target and a sparkline of the last 30 days
- Availability / Performance / Quality breakdown as a three-up tile so anyone can see which component is the problem
- Pareto of downtime reasons for the selected period - the 80/20 chart that drives action
- OEE waterfall from theoretical max down to actual, with each loss type labelled in minutes and units
- Trend by shift, line and product so improvements (or regressions) become visible within a day
- Drill-through to event-level data for the engineer who needs to know exactly which downtime event at 03:14 caused the problem
Power BI makes this kind of layered dashboard straightforward to build and easy to share - the operator on the shop floor, the plant manager on a tablet and the executive on a phone all see versions of the same view tailored to their device, fed from the same underlying data model. Drill-through, mobile layouts and row-level security are built in, so you don't end up maintaining a separate report for every audience.
Where the data comes from - and why this is the hard part
Calculating OEE looks like an arithmetic exercise. In practice it is an integration exercise. The numerators and denominators live in different systems, owned by different teams, on different time zones and at different levels of granularity:
Where each OEE input typically lives
| Input | Common system of record | What SolveBI typically does |
|---|---|---|
| Planned production time | ERP shift calendar or planning spreadsheet | Pull shift patterns and planned downtime from ERP (SAP / Dynamics / NetSuite) into Power BI |
| Run time and downtime events | MES, SCADA, PLC tag history, manual log sheets | Ingest tag history via OPC-UA or REST; reconcile with operator-coded reasons |
| Units produced | MES, counter on the line, ERP confirmations | Use the highest-fidelity counter as truth, validate against ERP at shift end |
| Good vs. scrap units | Quality system (LIMS), MES, inspection sheets | Pull first-pass conformance directly from QMS; map scrap codes to OEE loss categories |
| Ideal cycle time | Engineering master data, vendor spec sheet, tribal knowledge | Re-baseline against observed best in a stable window and store as governed master data |
Once these sources are joined together in a properly modelled Power BI dataset, the OEE calculation itself collapses to a handful of well-tested measures. The hard work is everything that happens before the formula - and the discipline Power BI brings is that every dashboard, every drill-down and every executive report is built on the same definitions.
Linking OEE to Lean, TPM and your continuous improvement programme
OEE was originally developed inside Total Productive Maintenance and remains a core metric of every serious Lean programme. It is the bridge between what the shop floor sees minute-by-minute and what the executive sees on the monthly scorecard. Used well, the same number anchors:
- Daily start-of-shift huddles - last shift's OEE, top 3 downtime reasons, today's countermeasure
- Weekly continuous-improvement reviews - which line moved, by how much, why, and what's next
- Kaizen and A3 project prioritisation - dollarised loss tree picks the project with the highest ROI
- Capital expenditure cases - quantified evidence for new equipment, sensors or training
- Executive operational reporting - the same OEE number, rolled up by plant and region
The litmus test for an OEE programme is whether the operator running the line and the CEO reading the monthly pack are looking at the same number, computed the same way. When they are, decisions speed up. When they aren't, time gets wasted reconciling figures that should have been identical.
Power BI is what makes this practical at scale. The same OEE number is one click away for every audience through shared Power BI workspaces and Microsoft Teams; row-level security ensures each plant or shift sees only its own slice; and the daily, weekly and monthly cadences all run from a single dataset rather than from separate reports that need to be reconciled.
Common OEE reporting mistakes - and how to avoid them
OEE is simple in concept and easy to get wrong in practice. The five mistakes we see most often in Australian plants are:
- Excluding inconvenient downtime. If breakdowns, changeovers and minor stops are all excluded 'because they're not really losses', the OEE number is meaningless and improvement becomes impossible.
- Setting the ideal cycle time too slow. A conservative cycle time hides Performance losses and inflates the headline. Re-baseline from observed best, not from the manual.
- Reporting plant-wide OEE only. A single number averages away the actionable detail. Always report by line, shift, product and changeover-vs-run.
- Manual data collection. Operator-keyed downtime logs are well-meaning but slow, partial and biased. If you're serious about OEE, the data has to come from the equipment itself.
- No link to financial impact. OEE of 62% means nothing to a CFO. The same data expressed as 'lost capacity worth $1.4m a year, half of it changeovers' gets a capital budget approved.
OEE in practice across different manufacturing sectors
Although the OEE formula is universal, what it exposes is very industry-specific. A few examples from sectors we work with:
Automotive and metal fabrication
Changeover time and tool changes typically dominate Availability losses. OEE reporting often makes the business case for SMED (single-minute exchange of die) programmes that cut changeovers from hours to minutes.
FMCG, food and beverage
Micro-stops, jams and minor speed losses on high-speed lines usually dominate Performance. OEE reporting brings these previously invisible losses into focus and is often the first time the plant has a dollarised view of them.
Plastics, packaging and converting
Startup scrap and grade transitions are the biggest Quality losses. OEE reporting tied to scrap reason codes is what allows the plant to prioritise process-control or recipe-tuning projects with confidence.
Mining, minerals processing and heavy industry
Availability dominates because unplanned breakdowns are catastrophic and changeovers are infrequent. OEE here is almost a proxy for asset reliability, and the data conversation rapidly extends into condition monitoring and predictive maintenance.
From spreadsheet OEE to a governed, real-time platform
If your plant currently calculates OEE in Excel - or doesn't calculate it at all - the upgrade path is shorter and less expensive than most operations leaders expect. Most engagements with SolveBI follow the same pattern: a short discovery to confirm the data sources and definitions, an integration sprint that pipes the relevant signals into a Power BI data model, and a live Power BI OEE dashboard in front of operators within weeks, not quarters.
The result is a single, governed, automatically refreshing OEE number that the entire business agrees on - and a loss tree the continuous-improvement team can finally use to pick its battles.
From guesswork to a single OEE number everyone trusts.
Book a free 30-minute consultation with a Microsoft-certified SolveBI consultant. We'll map your current data sources, define a clean OEE calculation, and quote a phased Power BI deployment you can budget against.



