OEE, OTIF & Scrap — Data-Driven Plant Operations

Operations leaders do not lack KPIs. They have too many. Thirty-seven metrics on a dashboard that nobody looks at, and the supervisor still finds out about the line stoppage from the shift WhatsApp group — not the system.

The question is not "do we have data?" The question is: does the right data arrive before the decision closes?

On a manufacturing or FMCG production line, the numbers that matter to the P&L are a short list. OEE — Overall Equipment Effectiveness — tells you how much of your theoretical production capacity you are actually using. OTIF — On Time In Full — tells you whether what the plant produces is reaching the customer when promised. Scrap rate tells you what percentage of production input you are paying for but not selling.

These three numbers are not independent. OEE drift causes OTIF misses. High scrap rate signals a quality or setup problem that also reduces effective OEE. A plant with 72% OEE and 4% scrap and 91% OTIF has a different problem from a plant with 85% OEE and 1.5% scrap and 87% OTIF. The pattern matters as much as the number.

Most plants have some version of these metrics. The problem is the lag. A weekly OEE report tells you what went wrong last week. A shift-end scrap report tells you what to write off this morning. By the time the data is visible, the shift is over, the crew has changed, and the production schedule has moved on.

Real-time visibility — not near-real-time, not next-day — is the only version that lets a supervisor act within the decision window.

This is the architecture that connects the plant floor to the decision-maker without a data science team in the middle.

**SCADA and MES** are the originating systems. SCADA captures equipment signals — cycle time, temperature, pressure, downtime events — via OPC-UA or MQTT depending on the age of the equipment. MES captures production orders, job completions, quality results, and material consumption. These systems generate the raw signal. They are not designed for cross-shift analytics or management reporting.

**Azure Data Factory** ingests from both. The ADF pipeline runs on a cadence appropriate to the decision — typically every 5–15 minutes for operational data. It handles schema differences between equipment types, normalises the OPC-UA tag structure, and lands the data in OneLake as Delta Parquet. The transformation logic sits in Microsoft Fabric — not in the SCADA system, not in the MES, and not in a series of Excel macros on the production office PC.

**Microsoft Fabric** models the operational data. OEE is calculated from availability, performance, and quality components. OTIF is assembled from production order completion timestamps cross-referenced against customer delivery commitments. Scrap rate is calculated from material consumption versus output quantity. The semantic model in Fabric is the single definition — everyone from the shift supervisor to the COO is looking at the same calculation.

**Power BI Direct Lake** surfaces the result to the floor screen, the shift leader's tablet, and the operations manager's phone — simultaneously, with no import refresh delay. The floor screen shows current-shift OEE, current downtime reason, and cumulative scrap versus target. The shift leader's view adds OTIF risk flags — orders that are at risk of missing the despatch window based on current line rate. The COO's view shows plant-level trends across the week.

**Power Apps** captures the shift handover. The outgoing shift leader records the top three issues, the root cause logged for each downtime event, and any machine that needs attention before the next run. That capture feeds back into the Fabric model. It becomes part of the operational record — not a verbal handover that evaporates when the shift ends.

The shift supervisor knows the line is running 12% below target OEE before the shift is half over — not at the 7 a.m. production meeting the following morning. She can call the maintenance technician now, while the evidence is fresh and the equipment is still in the state that caused the problem.

The despatch controller sees — at 2 p.m. — that a production order scheduled for a 4 p.m. cut-off is tracking 40 minutes late based on current line speed. She has time to reroute a lorry or call the customer before the window closes, not after it has already been missed.

The operations manager reviews scrap by product code at the end of each shift, not at the weekly quality meeting. A scrap spike on a specific SKU in Tuesday's afternoon shift is visible in time to check the Wednesday morning setup before it repeats.

These are not theoretical improvements. They are the direct consequence of data arriving before the decision, instead of after it.

Faster line-restart time — because the downtime reason is captured and visible rather than reconstructed from memory. Fewer mis-picks — because the WMS and the production schedule are reading from the same OneLake source rather than separate systems with a 24-hour sync lag. Real-time scrap visibility before the shift ends — because the calculation runs off live MES data, not a morning batch report.

Before real-time signal matters at all, the definition has to be settled — and this is where most OEE programmes quietly fail. Ask three shift supervisors how they calculate availability and you will often get three answers: one counts planned changeover as downtime, one excludes it, one is not sure. When the number means something different per shift, a "12% OEE drop" might be a genuine loss or just a different person doing the arithmetic. The dashboard cannot move a metric nobody computes the same way twice.

The fix is a governed definition, not a better chart. OEE, OTIF, and scrap each get one calculation encoded once in the Microsoft Fabric semantic model — availability net of agreed planned stops, performance against the standard rate for that specific material and operation, quality from MES results — and every surface from the floor screen to the COO's view reads that single definition. Reclassifications (an operator recoding a stop reason) are logged with an audit trail, so the number is not just consistent but defensible. That governed semantic model is the thing that turns OEE from a debate into a metric.

This is why "our OEE numbers have not moved" is usually a governance problem wearing an analytics costume. Real-time signal on a contested definition just delivers the disagreement faster. Settle the definition first, in the model, and the live signal finally has something trustworthy to be live about.

A governed number arriving in real time is necessary but still not sufficient — the third lever is whether anyone owns the response. A dashboard that shows OEE dropped, with no named owner for the fix, is a scoreboard, not an operating system. The metrics that actually move are the ones wired to a person: this downtime reason class is the maintenance lead's; this OTIF-risk flag is the despatch controller's; this scrap spike by SKU is the shift leader's. The system routes the exception to the owner, at the line, in the window — not to a 7 a.m. meeting the next morning.

Power Apps closes the loop by capturing the intervention as part of the record. The shift handover logs the top issues, the root cause for each downtime event, and the action taken — feeding back into the Fabric model so the next shift inherits context rather than a verbal handover that evaporates. Over weeks that builds an audit trail of what was tried and what worked, which is what turns a Pareto of stop reasons from a chart into a maintenance programme. The action becomes data, and the data improves the next action.

That is the difference between visibility and operations. Governed definition, real-time signal, named owner with a logged response — the three together are what shift the number. Drop any one and OEE stays a slide people present rather than a metric people move.

A Power BI dashboard does not run the plant. The supervisor does. If the process discipline is not there — if downtime events are not logged in the MES, if shift handovers are informal, if setup parameters are not recorded — the data model has nothing to work with. Data visibility amplifies process discipline; it does not create it.

If the SCADA system is older than fifteen years and does not support OPC-UA or MQTT, the data extraction layer becomes a significant engineering project before any analytics work can start. That is a feasibility conversation to have early, not after the Power BI licence has been purchased.

This model works best when the plant has a functioning MES and a SCADA system that can expose a data feed. If production is still managed primarily through paper job cards and manual shift logs, start with a Power Apps digitisation programme first.

A Discover → Prototype engagement picks one production line, connects the MES and SCADA feed via Azure Data Factory to OneLake, and builds the OEE and scrap scorecard in Power BI Direct Lake. In six weeks, you have a live floor screen showing current-shift OEE with downtime reason tracking. That is the proof of concept that earns the investment for the full plant rollout.