OEE that nobody believes
Availability, performance and quality are each calculated from a different source with different assumptions about planned downtime, so the headline figure gets argued about instead of acted on.
Manufacturing
Shift-level OEE, downtime analysis and cost per unit reconciled across ERP, MES and historian data.
Manufacturers usually have more data than almost any other sector and less ability to use it, because the data lives in three different worlds: the ERP that knows the order, the MES that knows the run, and the historian that knows what the machine was doing by the second. Each uses a different notion of time, a different product identifier and a different idea of a shift.
- OEE accepted as the single operational measure across sites
- Downtime causes ranked accurately enough to direct engineering effort
- Cost per unit available within days of production, not weeks
- Group-level site comparison without manual adjustment
Our work is largely the unglamorous reconciliation of those three worlds into a model where a downtime event, a quality reject and a cost variance can be examined together. Once that exists, OEE stops being a monthly slide and becomes a shift-level operational tool.
We work with discrete and process manufacturers, automotive and aerospace suppliers, food and beverage, chemicals, pharmaceuticals and industrial engineering, across single plants and multi-site groups that need comparable numbers between sites.
What goes wrong
Recurring failure modes in manufacturing
Downtime reasons that explain nothing
Operators pick from a list where sixty per cent of events land on "other" or "minor stop". Without a disciplined reason taxonomy the Pareto analysis is noise.
Costing that lags reality by a month
Standard costs updated annually, variances posted at month-end, so by the time a margin problem is visible the production run is long finished.
Sites that cannot be compared
Each plant defines shift patterns, product hierarchies and scrap categories its own way. Group reporting then requires manual adjustment, which hides exactly the differences management needs to see.
Metrics
Metrics and their definition errors
Each metric with its definition and the error that most often distorts it. If our reading is wrong for your business, that disagreement is a productive starting point.
| Metric | Definition | The trap |
|---|---|---|
| OEE | Availability × performance × quality, measured against planned production time. | The definition of planned production time is where the number is won or lost. Fix it once in the model, document it, and stop every site redefining it. |
| Mean time between failures | Operating time divided by the number of failure events in the period. | Only unplanned failures count; mixing planned maintenance into the event set makes the metric flatter and useless. |
| First pass yield | Units passing inspection first time, over units started. | Rework must be excluded from the numerator, and the unit of measure has to be consistent across batch and discrete processes. |
| Cost per unit produced | Fully absorbed cost over good units produced in the period. | Absorption base and the treatment of scrap and rework drive the number more than material price does. Make both explicit. |
| Schedule adherence | Production completed to plan within the planning window, over planned production. | Define whether partially complete orders count proportionally or not at all. Both are defensible, mixing them is not. |
Use cases
What we typically build
Shift-level OEE and downtime Pareto
One model joining historian events, MES runs and ERP orders, with a disciplined downtime reason taxonomy and drill-through from plant to line to event.
Quality and scrap analytics
Defect analysis by product, line, shift, batch and supplier, with cost of poor quality attached so engineering and finance argue from the same figure.
Maintenance analytics
Work-order history, failure modes, spare-parts consumption and MTBF trends; condition-based alerting where sensor coverage supports it.
Supply chain and inventory
Supplier on-time-in-full, inbound quality, stock cover, slow-moving and obsolete stock, and the working-capital consequence of each.
Energy and emissions reporting
Consumption per unit produced by line and site, with the data structure needed for emissions disclosure rather than a separate parallel exercise.
Multi-site group reporting
Conformed dimensions for product, plant, shift and reason code so site comparison is legitimate, with local detail still available underneath.
Integration
Source systems we connect to
- SAP ERP / S/4HANA
- Microsoft Dynamics 365
- MES platforms
- Plant historians (OSIsoft PI, Aveva, Wonderware)
- OPC UA and IoT gateways
- CMMS / maintenance systems
- Quality management systems
- Warehouse management systems
Regulatory context
Regulatory context by market
- EU: CSRD sustainability reporting and the data lineage it requires for emissions figures
- UK: SECR energy and carbon reporting, UK ETS where applicable
- Germany: Energiemanagement under ISO 50001, Lieferkettensorgfaltspflichtengesetz supply-chain due diligence data
- Switzerland: CO2 Act reporting obligations for in-scope operators
- Sector: IATF 16949 traceability in automotive, GMP data integrity in pharmaceutical manufacturing, HACCP records in food
- Cross-cutting: product traceability and recall readiness, machine data retention for warranty claims
Questions
Manufacturing: common questions
Usually yes. Historians expose data through SQL interfaces, OPC UA, REST APIs or scheduled extracts, and MES platforms almost always have a reporting database. The engineering challenge is less access than volume and time alignment: second-level sensor data has to be aggregated to a usable grain, and historian timestamps, MES run boundaries and ERP posting dates have to be reconciled to one time dimension.
Keep the raw grain in the lakehouse and serve aggregated grains for analysis. Typically we land event-level data, build a run-level and a shift-level fact for reporting, and allow drill-through to raw events for investigation. Aggregating at ingestion to save space is a decision people regret the first time they need to investigate a specific event.
Where the data supports it. Predictive maintenance needs sufficient sensor coverage, labelled failure history and enough failure events to learn from. Many plants lack the third. Where that is the case we start with condition-based rules and solid failure analytics, which deliver most of the value, and revisit prediction once there is a labelled history worth modelling.
Yes, and it is usually the right design: one model with conformed dimensions, site as a dimension, row-level security so each plant sees its own detail, and group roles seeing everything. The hard part is political rather than technical, agreeing shared definitions for shift, downtime reason and product hierarchy. We run that as a structured workshop series with a documented decision per definition.
Services that apply here
Next step
Analytics work in manufacturing
A 45-minute working session with an engineer rather than a sales call. You describe the problem; we set out what we would build, in what order, and what it is likely to cost.
Answered within one working day, by the engineer who would do the work