The bottom line
OEE, OTIF and scrap shift when three things happen: governed definitions, real-time signal at the line, and actions logged against named owners. The dashboard is the venue, not the intervention. Built on Microsoft Fabric with Power BI Direct Lake, 6 weeks to first signal.
In This Article
Introduction
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?
Three numbers that actually move the P&L
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.
The live operating model
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.
What actually changes when the data arrives on time
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.
Where this approach doesn't fit
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.
Six weeks to first value
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.
OEE on a dashboard nobody acts on is theatre. OEE wired to a named owner, with real-time signal at the line and an audit trail of every reclassification, becomes the metric that moves. The data foundation decides which one you get.
Free Assessment
Where does your operation sit on the data maturity curve?
8 questions. 3 minutes. You get a scored breakdown across data infrastructure, analytics readiness, and automation potential — with a specific next step for your industry.