By Steven Gallagher
Most plants measure output, utilisation and downtime well. Very few can explain variance without somebody joining the data by hand, which means the explanation usually arrives after the decision has been taken.
Most of the manufacturers we work with can tell you what happened on the line last week in detail that would have been unthinkable a decade ago. Output by shift. Utilisation by machine. Downtime broken down by reason code, logged and reported without anyone chasing it. On measurement, the job is largely done.
Ask why the line underperformed and the room changes. Somebody will get you an answer. It will take a few days, it will involve pulling exports out of two or three systems and joining them in a spreadsheet, and it will usually arrive after the decision it was meant to inform has already been taken.
Observing performance and explaining it are different capabilities, and only one of them changes an outcome. Manufacturers have invested heavily in the first and barely at all in the second.
That is the gap I would put in front of any board. Most plants measure output, utilisation and downtime well. Very few can explain variance without somebody joining the data by hand.
Where the gap came from
Nobody chose this arrangement. That is the part worth understanding before anyone gets blamed for it.
The systems that hold the answer were bought at different times, by different people, to solve different problems. The ERP went in to run the business. Machine and production logging arrived later, often plant by plant, sometimes as part of a line replacement rather than as a deliberate data decision. Maintenance records sit somewhere else again, frequently in a system chosen by the engineering function for engineering reasons. Quality data often lives closest to the shop floor and travels the least.
Each of those decisions was sensible on its own terms. None of them were taken with the others in view. Having spent a fair amount of time with manufacturers on exactly this, I have yet to walk into a plant where somebody sat down and designed the current arrangement. It accumulated, in the way most things in a growing business accumulate.
The consequence is that the systems can each describe their own slice of a shift, and none of them can describe the shift. Joining them is possible, which is why it keeps happening manually. It is just that the joining lives in somebody’s head and in somebody’s spreadsheet rather than anywhere the business owns.
The cost is decision latency
Executives rarely feel this as a data problem. They feel it as timing.
Decisions get taken on last month’s numbers because last month’s numbers are the most recent ones that have been properly explained. The raw figures are current, the understanding of them is not, and it is the understanding that people act on. In practice that means a plant can be operating on a picture of itself that is several weeks old while believing it is operating on live data.
Improvement work gets aimed at symptoms. If the cause analysis takes days, the improvement plan gets built from the observation instead. A line shows recurring downtime, so the downtime becomes the target. Whether that downtime is a maintenance scheduling issue, a materials availability issue or a changeover issue is the question that would actually direct the effort, and it is often the question that arrives last.
Capital gets allocated on an incomplete picture. This is the one I would flag hardest. A line that underperforms consistently makes a strong internal case for investment. Sometimes that case is correct. Sometimes the underperformance sits in how the line is scheduled and supplied rather than in the asset, and the business finds that out after the money has gone.
You might reasonably say that a few days is not a long time, and that the analysis does eventually arrive. In our experience the delay is not really the cost. The cost is the questions people stop asking, because they know roughly what it takes to get an answer. Nobody submits a request that will take three days to satisfy a mild curiosity, so the mild curiosities go unexplored, and some of them were the important ones. That is a hard thing to see on any report, and it is usually the largest item.
There is a governance point sitting underneath all of this too. When the explanation depends on one person’s manual process, the business has a single point of failure that appears nowhere on a risk register.
What changes when the data sits in one model
The alternative is less dramatic than it sounds. Production, downtime and maintenance data modelled together, once, with agreed definitions of a shift, a machine, a line and a reason code, so that the join happens in the model rather than in a spreadsheet at the point of the question.
What that buys is not a better looking report. It is that variance analysis stops being an exercise somebody runs on request and becomes a standing view that is simply there. Somebody notices output was down on Tuesday nights, and the maintenance history and the changeover pattern for those shifts are already in the same place, already conformed, already reconciled. The question takes a minute rather than three days, so it actually gets asked.
This is the work behind Power BI for manufacturing at Metis BI, a UK consultancy specialising in Power BI and Microsoft Fabric, and I will be candid about where the effort goes. The modelling takes most of the time. The reporting on top of it takes very little. That ratio surprises people, and it is usually the first thing I try to reset in early conversations.
I would add one caveat, since this is where these programmes tend to go wrong. Agreeing what a reason code means across three plants is often harder than any technical part of the work. It is also the part that determines whether the answer is trusted once it exists.
Why more dashboards have not solved it
The instinct after a difficult quarter is to commission another report. It is a reasonable instinct and it rarely helps here, because the problem sits underneath the reporting layer.
Every new report built directly on top of disconnected sources has to re-implement the joins and the definitions on its own terms. Do that four or five times and the organisation has four or five quietly different versions of utilisation, all defensible, none reconciled. The reporting estate grows, confidence in it falls, and the manual spreadsheet survives precisely because people trust the person who maintains it more than they trust the reports.
I always tell clients that this is a modelling problem rather than a dashboard problem. That distinction sounds academic in a board meeting and it is not. It is the difference between spending again on the visible layer and spending once on the layer that everything else depends on.
Summary
Measurement is largely a solved problem in manufacturing. Explanation is not, and in most plants it still depends on somebody joining data by hand, which is why the explanation tends to arrive after the decision.
That gap sits in the way the underlying data is modelled, so it does not close by adding reports on top. It closes when production, downtime and maintenance stop being separate accounts of the same shift.
