What Is OEE?

Back to Blog

How OEE Is Calculated

OEE multiplies three factors, each a ratio between 0 and 1. Availability is the share of scheduled time the equipment was actually running, penalizing downtime and changeovers. Performance is how fast it ran versus its ideal cycle time, penalizing slow cycles and minor stops. Quality is the fraction of output that met spec, penalizing scrap and rework. Multiply the three and you get OEE.

Because the factors multiply, OEE is unforgiving: 90% availability, 90% performance, and 90% quality yields only 73% OEE, not 90%. A widely cited benchmark treats 85% as world-class for discrete manufacturing, though the right target depends heavily on the process. The real value is diagnostic - a low OEE points you to which of the three factors is dragging, so improvement effort lands where it matters.

OEE Beyond the Factory

OEE was born on the discrete-manufacturing floor, where scheduled run time, cycle time, and good-versus-scrap parts are all well defined. That is exactly where it works best. Applying it to continuous or process operations requires care, because "cycle time" and "good parts" do not map cleanly onto a flowing process - which is why OEE is best understood as a manufacturing metric rather than a universal one.

In oil and gas, operators more often track uptime, deferred production, and equipment availability directly rather than a formal OEE score, though the availability idea clearly overlaps. What every version of this analysis depends on is accurate downtime and run-status data captured from the field. A monitoring platform provides that raw material: Merobix records run status and downtime from field devices over Modbus, DNP3, and other protocols, so the availability side of any effectiveness metric is grounded in real data rather than guesswork.

A Worked Example in Symbols

The cleanest way to internalize OEE is to walk the arithmetic once with symbols. Take a planned production time P for the shift, after subtracting whatever breaks and planned maintenance your site's convention excludes. The machine was down for unplanned stops totalling D, so run time is R = P - D and availability is A = R / P. During the run it produced a total count N of parts against an agreed ideal cycle time c, so performance is F = (c x N) / R - the fraction of run time that pure ideal-speed production would have needed. Of the N parts, G were good, so quality is Q = G / N.

Multiply the three factors and something satisfying happens: the intermediate terms cancel. OEE = A x F x Q = (c x G) / P. In words, OEE is the time that would have been needed to make only the good parts at ideal speed, divided by the time you planned to spend. That collapsed form is a useful cross-check on any OEE report: if the published score does not equal ideal cycle time times good count divided by planned time, the calculation has a definitional problem somewhere, usually in what counts as planned time.

Where the Six Big Losses Land

Lean practice pairs OEE with the six big losses, and the mapping explains why the metric is split into three factors rather than reported as one opaque number:

Factor	Losses it absorbs
Availability	Breakdowns; setup and changeovers
Performance	Minor stops; reduced-speed running
Quality	Startup rejects; production scrap and rework

The split tells you where to send effort. An availability problem is a maintenance and changeover problem. A performance problem is a minor-stop and rate problem, and minor stops are usually invisible without automated event capture because nobody writes down a stoppage that clears itself. A quality problem points at process stability and startup practice. Chasing OEE as a single number without decomposing it first throws away most of the diagnostic value the metric was designed to deliver.

The Data That Has to Exist First

OEE is only as honest as its inputs, and each factor has a concrete data dependency. Availability needs a reliable run/stop signal and timestamped downtime events with reason codes, which is exactly what runtime and downtime tracking provides; manual downtime logging chronically underreports short stops. Performance needs a trustworthy production count taken from the machine and an ideal cycle time that engineering and operations have genuinely agreed on, because that single constant scales the whole factor. Quality needs good and reject counts captured at the machine, not reconstructed from end-of-line inspection a shift later.

The common failure is asymmetry: automated availability data combined with a guessed ideal cycle time and hand-entered scrap numbers. The resulting score looks precise and is not. Before publishing OEE to a dashboard, it is worth auditing the three inputs separately and stating explicitly which are measured and which are declared, so nobody optimizes a number that is half assumption.

Ways the Number Gets Gamed

Because OEE is a ratio of definitions, it can be improved without improving anything. Reclassifying unplanned downtime as planned shrinks P and lifts availability. Setting the ideal cycle time near the machine's average speed instead of its best demonstrated speed flatters performance permanently - a performance factor that never moves is usually a sign of exactly this. Excluding changeovers from planned time hides the loss that lean practice most wants visible. None of these are fraud so much as drift, which is why the definitions belong in a written standard that does not change without review.

A related trap is comparing OEE across machines or plants that use different definitions. The availability rate alone can be computed against calendar time, scheduled time, or planned production time, and each choice yields a different score from the same shift. Within one site tracking one machine over time, OEE is a solid improvement metric; as a league table across dissimilar operations, it mostly measures whose definitions are the most generous.

Frequently Asked Questions