In almost every production facility that starts working with OEE, the first phase unfolds the same way. The formula is clear: availability times performance times quality. The three components are calculated, the results are presented, and then the real problem begins. Line 2 reaches 71 percent and line 5 reaches 84 percent, but the operations manager who sees both lines every day is not convinced that the 13-percentage-point gap reflects operational reality. His instinct is right. He just cannot explain why.
Three components, ten definitions
Availability is the component that leaves the most room for interpretation. Does a planned changeover count as an availability loss? Is waiting for raw material a technical stop or a logistics stop? Is a brief power interruption of three minutes treated differently from a machine breakdown lasting thirty? The answers to those questions determine the availability score just as much as the actual downtime, and when two lines answer them differently, their scores are not comparable, even though they look like two numbers with the same unit.
Performance has a similar problem. The performance component compares actual output against the theoretically maximum output at nominal speed. But which nominal speed? A line processing two product families with fundamentally different cycle times needs a different reference value for each family. A system using one fixed target speed for all products calculates a performance score that is systematically too low for fast products and too high for slow ones, without the line doing anything other than its work.
What is structurally needed for comparable OEE
Uniform OEE calculation across lines requires four things that are technical but begin organisationally. First, a shared definition of every downtime category, documented and not open to local interpretation. Second, a product-linked target speed serving as a performance reference, connected to the product code running on the line at a given moment. Third, a consistent mechanism for quality registration, where rejection data is not entered manually at the end of the shift but logged event-driven at the moment of rejection. Fourth, a data layer that brings all those elements together at the right time resolution, so downtime events, cycle times and rejection counts are available within the same time window.
State change detection is the mechanism that makes this technically possible. A system that continuously tracks machine status based on PLC signals, whether running, stopped or in changeover, registers every state transition with a timestamp and a duration, without operator involvement. That is the basis for reliable availability calculation and for the historical loss analysis that later reveals which type of stop occurs most frequently and which lasts longest.
What the production leader and the process engineer gain
The production leader wants an OEE number he trusts and that is comparable across his lines, not as proof of how well or poorly his team performs, but as a navigation instrument to decide where to direct his improvement effort. He gets that number only when the definitions are consistent and the data is reliable.
The process engineer wants the details behind the number: which stop lasted longest, which product generates the most rejects, at which point in the shift does rejection peak. Those details are his tools for root-cause analysis.
The role of Capture
Capture provides the contextual data layer that makes OEE comparable, trustworthy and operationally useful. The platform does not treat availability, performance and quality as isolated dashboard values, but connects them to the definitions and events that determine whether the number actually means anything. Downtime categories, product-linked target speeds, machine states, rejection events, batch context and shift boundaries all become part of the same structured data model.
That matters because OEE only works as a steering instrument when teams trust both the number and the logic behind it. A production leader needs one score that can be compared across lines without hidden local interpretation. A process engineer needs the details behind that score: which stop lasted longest, which product generated the most rejects, which shift showed a recurring loss pattern. Capture supports both levels. It calculates OEE on top of consistent definitions while preserving the underlying detail required for root-cause analysis. The result is not just an OEE percentage, but a shared and searchable loss model that teams can use to improve production.