OEE is measured per machine and output is set by the constraint. Those two facts are the reason most OEE programmes disappoint.
Because OEE is a per-machine measure, it invites a programme that lifts every machine’s number. Teams are assigned, losses are attacked, and the numbers go up. Output does not, because the machines that improved were never limiting anything.
This table is the prioritisation argument. Every row is a real loss and only some of them cost output, and which ones depends entirely on where the machine sits relative to the constraint.
Note the quality rows: quality loss is the one category that costs the same wherever it occurs, which is why it usually deserves attention first.
Limited visibility into manufacturing performance
Performance known by shift report and by inference from output. Workable with an experienced supervisor and not comparable across lines, shifts or sites.
Inconsistent OEE calculation methods across plants
The definitional argument in full is on the Operational & Production Analytics page, which owns it. The position here is simply that this page will not benchmark across plants until that work is done, because the comparison would be false.
Manual production and downtime reporting
Recorded at the end of a shift from memory, which systematically loses the short stops and rounds the long ones.
Incomplete machine availability data
The largest practical obstacle. Availability requires knowing what the machine was doing for every minute, and most plants have the long stops and not the rest.
Difficulty identifying production performance losses
Because the composite hides the components, which is the second position on this page.
Fragmented production, quality and maintenance data
Three systems and three identifiers. Joining them is the engineering work and it is what makes a loss explainable rather than only countable.
Limited visibility into changeover and idle time
Changeover is frequently recorded as one category with no start and end definition, which makes it both large and unanalysable.
Delayed production performance reporting
A monthly figure supports a review and not an improvement. Improvement needs the event, which is the third position on this page.
Inconsistent shift and line performance measurement
And a sensitivity: shift comparison is subject to the employee relations constraint in section 7, which applies on this page more directly than on most.
Limited root cause analysis of manufacturing losses
Which is a data model problem. Causes are in the event stream and most OEE implementations store the aggregate.
Stage three below is the one that distinguishes this work. Without it the output is a ranked list of losses in minutes, which looks actionable and sends effort to the wrong machines.
Step 1
Manufacturing performance assessment
What is measured today, from what data, and which decisions currently use it. Usually fewer than expected.
What is measured today, from what data, and which decisions currently use it. Usually fewer than expected.
Step 2
Production process and KPI discovery
The flow, the buffers and the measures in use. Definitions follow the agreed set owned by your reporting layer, per the Operational & Production Analytics page.
The flow, the buffers and the measures in use. Definitions follow the agreed set owned by your reporting layer, per the Operational & Production Analytics page.
Step 3
Constraint identification per product mix
Where output is actually limited, and how that moves with mix. This is the stage that determines where improvement effort is worth spending and it is absent from most OEE programmes.
Where output is actually limited, and how that moves with mix. This is the stage that determines where improvement effort is worth spending and it is absent from most OEE programmes.
Step 4
OEE calculation and metric definition
Including the scheduled time basis, which is a choice rather than a fact. We use your agreed definitions and we state them on every report.
Including the scheduled time basis, which is a choice rather than a fact. We use your agreed definitions and we state them on every report.
Step 5
Production and equipment data source mapping
MES, SCADA, historian, ERP and quality, with the joins on asset, order, product and time. The connectivity itself belongs to the Industrial IoT pages.
MES, SCADA, historian, ERP and quality, with the joins on asset, order, product and time. The connectivity itself belongs to the Industrial IoT pages.
Step 6
Machine state and downtime data validation
Validated against observation on the line for a period. A state model that disagrees with what a person sees will be rejected by the plant, correctly.
Validated against observation on the line for a period. A state model that disagrees with what a person sees will be rejected by the plant, correctly.
Step 7
Manufacturing analytics data modelling
Event-level, not aggregate. Every stop as a record with duration, reason, product, order and what preceded it, because that is where causes live.
Event-level, not aggregate. Every stop as a record with duration, reason, product, order and what preceded it, because that is where causes live.
Step 8
OEE dashboard and reporting development
Composite with its three components always visible, and losses expressed in output at the constraint as well as in minutes.
Composite with its three components always visible, and losses expressed in output at the constraint as well as in minutes.
Step 9
Performance loss and root cause analytics
Pattern analysis on the event stream: recurrence by product, by shift pattern, by preceding changeover, by time since maintenance.
Pattern analysis on the event stream: recurrence by product, by shift pattern, by preceding changeover, by time since maintenance.
Step 10
Continuous optimisation and plant rollout
By line, with the constraint re-identified at each, since the constraint is a property of the line and the mix rather than of the plant.
By line, with the constraint re-identified at each, since the constraint is a property of the line and the mix rather than of the plant.
The limit is named for each, because most disappointment in this category comes from a measure being asked a question it was not built to answer.
Overall equipment effectiveness dashboards
The composite with its three components. Tells you: whether performance moved. Does not tell you: why, or whether it mattered to output.
Equipment availability analytics
Running time against the agreed scheduled basis. Tells you: how much time was lost. Does not tell you: whether that time was on the constraint.
Production performance analytics
Actual rate against the agreed rate. Tells you: speed loss. Does not tell you: whether the agreed rate is realistic, which is a separate argument owned elsewhere.
Quality loss analytics
Scrap and rework as an effectiveness component. Tells you: the yield cost. This is the loss that costs the same wherever it happens, which is why it ranks highly.
Downtime and stoppage analysis
Stops as events with duration and reason. Tells you: where time went. Depends entirely on the reason coding, which is a governance matter.
Manufacturing loss categorisation
Losses grouped into an agreed taxonomy. The taxonomy itself is owned by your reporting layer, per the Operational & Production Analytics page, and is consumed here rather than redefined.
Changeover and setup time analytics
Duration by product pair and by crew. Tells you: where sequencing could recover time. Most valuable at the constraint and frequently free elsewhere.
Production throughput analytics
Output at each stage and at the constraint. Tells you: what the line actually produced, which is the figure OEE is a proxy for and the one worth reporting beside it.
Bottleneck and constraint analysis
Where output is limited, per mix. Tells you: where effort is worth spending. The attribution difficulty is covered on the Production Monitoring & Optimization page.
Shift and production line performance reporting
Comparison across lines and shifts. Subject to the employee relations constraint in section 7, and only valid once definitions are common.
Multi-plant OEE benchmarking
Comparison across sites. Deliberately listed last, because it is only valid after the definitional work owned by Operational & Production Analytics is complete. Attempted first, it is a false comparison with a board audience.
Six of these can be answered from aggregates. Four cannot, and those four are where the explanations are. That split decides the data model, which is the third position on this page.
OEE monitoring by machine and production line
The composite and its components over time.
Production target versus actual reporting
Output against the plan by line and period.
Shift performance comparison
Output and loss by shift.
Scrap and rework impact analysis
Quality loss in output and material terms.
Multi-plant performance benchmarking
Comparison across sites.
Manufacturing loss analysis by category
Losses ranked by the agreed taxonomy.
Unplanned downtime analysis
Why the machine stopped and whether it recurs.
Production speed loss identification
Where and when the line ran below rate.
Changeover performance monitoring
Duration by product pair, crew and shift.
Bottleneck and constraint analysis
Where output is limited and how it moves.
The architectural decision on this page is to store production events and derive every aggregate from them, rather than storing the aggregates. It costs more in storage and it is the difference between a reporting system and an improvement system.
Manufacturing analytics reference architecture
Event ingestion, a conformed event layer, a governed semantic model holding the measure definitions, and views per audience.
MES, SCADA, historian and ERP data integration
Machine state and counts from the plant, order and product context from the enterprise. The connectivity work belongs to the Industrial IoT & OT Integration page.
Equipment state and production event data models
The event record above, versioned, with the state model and the taxonomy under change control because a change to either changes history.
OEE calculation and semantic models
Measures computed once, centrally, from the agreed definitions, so the plant screen and the monthly report cannot disagree. The definitional argument is owned by Operational & Production Analytics.
Time-series manufacturing data processing
At a resolution fine enough to separate a micro-stop from a slow period, which is a requirement rather than a preference per section 5.
Data warehousing and lakehouse platforms
Selected against your existing commitments and your team’s operating capability.
Microsoft Fabric and Power BI
Named in the brief. We work with these where the client already runs them. The choice follows the estate and the operating model, and we state no partner or certification status.
Industrial IoT and edge data ingestion
Where existing systems do not expose what is needed. The infrastructure and the disconnection behaviour are covered on the Industrial IoT & Edge Computing page.
Event-driven manufacturing analytics
Events published once and consumed by reporting, by real-time response and by this analytics layer independently, so one collection serves three purposes.
Manufacturing dashboards and visualisation
Plant, line and executive views on one model. A shop-floor screen is a different product and is covered on the Smart Factory Solutions page.
Governance defines who may change a definition, a state model or a reason code, how disputes get resolved, and how the figures stay comparable over time. Everything below serves one of those three.
Performance measures are compared to themselves over time, so a definition change is also a retrospective change to every figure anybody has quoted. The control that matters most is that such a change is deliberate, recorded and announced.
OEE calculation standards and definitions
One definition set, owned, versioned, and stated on every report. The definitions themselves are agreed in your reporting governance, per the Operational & Production Analytics page, and consumed here rather than set here.
Planned versus unplanned downtime classification
A classification rule rather than a judgement made per event, since the split moves OEE substantially and is the most commonly contested boundary.
Production loss reason code governance
A short taxonomy with an owner, the unclassified share monitored as a measure, and changes to the code set treated as a reporting change.
Production event and equipment state data quality
Validated against observation periodically, not only at build. A state model drifts out of truth as the line changes and nothing alerts you.
Performance KPI ownership and accountability
A named owner per measure who can defend its definition and authorise a change to it.
Manufacturing data reconciliation
Analytics output reconciled to the production records and to finance where output drives cost. A performance figure that does not tie to the production count will be dismissed.
Data lineage and calculation transparency
Every figure traceable to the events behind it, and the calculation visible rather than embedded. An OEE number nobody can decompose will be disputed and then ignored.
Multi-plant KPI standardisation
A precondition for benchmarking rather than an outcome of it. Until it exists this page reports per plant and declines the comparison.
Role-based plant performance analytics access
By role and plant, with individual-level data restricted per the constraint below.
Analytics platform security and reliability
A named owner, pipeline monitoring including feeds that stop silently, and freshness visible on every view.
OEE is a proxy. Output is the thing. Reporting the ratio without the output alongside it allows a programme to show improvement while the plant produces less, which happens whenever the mix changes.
Production throughput
The primary measure, at the constraint and at the line. Everything below explains movements in this.
Overall equipment effectiveness
The composite, always published with its three components and with the definition set stated.
Equipment availability
Against the agreed scheduled basis, with planned and unplanned separated and changeover separated from both.
Production performance rate
Actual against agreed rate, with startup loss separated from steady-state speed loss per section 5.
Quality rate
First-pass yield as the effectiveness component, with rework distinguished from scrap since they have different costs.
Unplanned downtime
By asset and reason, and valued in output at the constraint as well as counted in minutes.
Mean time between failures
Per asset class, from the event history. Useful as a trend and meaningless as a single plant figure.
Mean time to repair
Split into waiting for the trade, waiting for the part and working, since the improvement is almost never in the third.
Changeover duration
By product pair and crew, with a defined start and end. Prioritised at the constraint, where it is direct output loss.
Scrap and rework rates
By operation, product and cause, joined to the production conditions at the time.
Manufacturing loss reduction
Against the measured baseline, expressed in output at the constraint rather than in minutes saved, which is the whole argument of this page in one measure.
OEE improvement tracking
With the constraint position recorded alongside, so an improvement on a non-constraint machine is visible as what it is.
Improved manufacturing performance visibility, which is the precondition rather than the benefit
Consistent and trustworthy OEE measurement, which depends on the definitional work owned by your reporting governance being done first
Faster identification of production losses, and more importantly the ability to explain one, which requires the event-level model
Better equipment utilisation insight, with losses valued against the constraint so effort is aimed where output responds
Reduced manual production reporting, measured by whether the shift report spreadsheet actually stopped
Improved plant-level performance management, reported as output alongside the ratio so a mix change cannot be mistaken for an improvement
If OEE has improved across your plants and output has not, the effort went to machines that were not limiting anything. Identifying the constraint per line takes days and it changes where the next year of improvement work is spent.
CaliberFocus aims OEE analytics at the constraint. We identify where output is limited under each product mix, value every loss in output rather than in minutes, always report availability, performance and quality separately, and store production events rather than aggregates so causes can be found rather than only counted.
- The constraint identified per line and per product mix
- Losses valued in output at the constraint
- The three OEE components always reported separately
- An event-level model that can explain a loss
Security & Compliance
