Power BI for manufacturers: the shop floor number nobody trusts, and how to fix it

The plant says 82% OEE and finance says the line lost money. Both are reading real data. How manufacturers build one model where production and cost agree.

Two true numbers that disagree

A production manager walks into the monthly review with 82% OEE on line three, the best quarter in two years. The finance director has the same line losing money on cost per unit. Both are right. The OEE comes from the MES, counts good units against planned run time, and does not know what the units cost. The cost per unit comes from the ERP, allocates labour and overhead by a rule set three years ago, and does not know the line ran a short shift. They are reading different systems with different definitions, and the meeting spends forty minutes on which one to believe.

This is the shape of almost every manufacturing reporting problem we see. The data is not missing. It sits in the MES, the SCADA historian, the ERP and the quality system, and each is correct about its own world. What is missing is one model where they meet. Our Power BI for manufacturing page describes the engagement; this post is about what has to be true inside it.

The four sources and what each one knows

The MES or SCADA historian knows what happened on the line: run time, stops, counts, speeds, often at second-level granularity. It does not know the order, the customer or the cost. The ERP knows the works order, the bill of materials, the standard cost, the stock movement and the invoice. It does not know why the line stopped at 14:20. The quality system knows the hold, the rework and the scrap reason. The maintenance system knows the breakdown and the planned work.

A Power BI model for a manufacturer is the place where a works order, a time window on a line, a scrap reason and a cost meet on one row. That join is the whole job. Get it right and OEE, yield, downtime by reason, cost per unit and on-time delivery all come from the same place and reconcile. Get it wrong, or skip it and point Power BI at each system separately, and you have rebuilt the argument in nicer colours.

The three reports that earn trust

Downtime by reason, by line, by shift. Not OEE first. OEE is a ratio of ratios and arguing about it is a sport. Downtime by reason is a list, it comes straight from the MES, and the people on the line recognise it. When the top reason on line three turns out to be changeovers rather than breakdowns, the conversation changes from whose number is right to what to do about changeovers. Build this first and refresh it every shift.

Yield and scrap reconciled to stock. Good units out against material in, by product and line, with scrap by reason from the quality system, and the total reconciled to the ERP stock movement for the period. The reconciliation is the trust. If the model's good output does not match what the ERP booked into stock, the report says so on the page and someone fixes the cause, which is usually a late or missing booking rather than a data error.

Cost per unit from actuals. Labour hours from the time system, material from the ERP issue, energy where it is metered, overhead by the agreed rule, divided by the reconciled good output. The important word is agreed. The overhead allocation rule has to be written down and signed off by finance and operations together, once, before the first report. We have seen more manufacturing dashboards die on an allocation argument than on any technical fault.

OEE comes after those three, built from the same downtime and count data, with availability, performance and quality shown separately so a change in the headline number can be explained in ten seconds.

Why multi-site is where it usually breaks

A group with four plants has four MES configurations, four ways of coding a stop reason, and four opinions about what counts as a changeover. Benchmarking them is impossible until the reason codes are mapped to one set, and that mapping is a business decision, not a data task. We do it in a workshop with the plant managers, write the mapping into the model as a dated table, and leave the local codes untouched so each plant still sees its own language. That is what multi-site benchmarking means in practice: one definition, applied consistently, with local detail preserved.

What the platform looks like

For most mid-market manufacturers this is a Fabric lakehouse or Azure SQL layer taking MES and historian data at the grain it arrives, ERP data through the standard connectors or mirroring, and quality and maintenance extracts on a schedule. The semantic model on top defines the measures once. Power BI serves the shift wallboard, the daily production review and the monthly finance pack from the same model, so the number on the wall at 06:00 is the number in the pack on the 5th. From site telemetry to a number the board trusts walks through a build of this kind, and our data platform and warehouse page sets out the phases.

Refresh matters more here than in most sectors. A shift wallboard that is three hours old is ignored. Direct Lake on a Fabric lakehouse, or a frequent incremental refresh on a well designed model, keeps the wallboard within minutes without a capacity bill that frightens finance; sizing Fabric capacity covers how we keep that in check.

Where to start

Pick one line and one month. Build downtime by reason from the MES, reconcile good output to the ERP for that month, and show both to the production manager and the finance director in the same room. If the two of them agree on that one line's figures, you have the pattern for the plant and then the group. If they do not, you have found the definition that needs settling, which is cheaper to find now than after a dashboard rollout. Our free audit is a reasonable first step if you want help choosing the line.

Related reading

From site telemetry to a number the board trusts

Your pipeline succeeded. That doesn't mean the data is right

Design the report before you build it

Data warehouse, data lake or lakehouse: which one your business actually needs