Why manufacturing dashboards miss the decision

Almost every manufacturer we talk to has dashboards. Most have more than they can name. The screens are accurate, the refresh is overnight, and somebody built each one because a real question was being asked at the time. And yet the late order still surprises the business on a Monday morning.

That is not a data quality problem, and it is rarely a tooling problem. It is a design problem, and it comes from building for reporting when the actual need was deciding.

A dashboard answers a question nobody is asking at the time

The question a dashboard is built to answer is normally some version of how are we doing. On-time delivery this month. Scrap rate by cell. Stock turns by family. Those are reasonable management questions and the charts answer them well.

The question a planner has at nine on a Tuesday is different in kind. It is: this order is in trouble, what do I do about it, and what does each option break. That question has a deadline attached, it concerns one specific order rather than a population, and it needs the evidence sitting underneath the number rather than the number itself.

A chart showing 91 per cent on-time delivery is true and useless in that moment. The planner does not need the aggregate. They need the nine per cent, named, with the reason attached and the time remaining to act.

Aggregation destroys exactly the information you need

Aggregation is what makes a dashboard readable. It is also what removes the thing an operational decision depends on: the chain.

A late order is almost never caused by one event. A supplier confirmation moved by two days, which pushed a sub-assembly start, which compressed the window for inspection, which meant the consignment could not be built in time for the carrier cut-off. Five facts in four systems, each individually unremarkable, and each owned by a different person.

Roll those into a lateness percentage and the chain is gone. You are left with a symptom and an instinct about where to look, which is how most of these investigations actually run: somebody walks the floor and asks.

The useful unit is not the metric. It is the chain of dependencies behind one specific commitment.

The timing is wrong by design

A report describes a state that has already settled. That is what makes it reportable. By the time a figure is stable enough to put on a chart, the window in which an intervention would have changed the outcome has usually closed.

There is a straightforward test for this. For each of the last ten orders that went late, ask when the business could first have known, in principle, from data it already held. In most operations the honest answer is days, sometimes a week or more, before anyone actually knew. The information existed. Nothing was looking at it in combination.

What the alternative has to do

The difference between a report and an operational system is not the visual. It is four obligations the system takes on.

1. Be specificName the order, the asset or the part, not the category. A decision is made about one thing, so the output has to be about one thing.
2. Carry the evidenceShow the source records behind the risk. A planner who cannot see why will go and check, which costs more time than the warning saved.
3. State the time remainingAn issue that can still be fixed and one that cannot are different items with different urgency. Without that, everything looks equally red and attention is spent badly.
4. Offer moves, with consequencesExpediting, resequencing and re-promising all cost something somewhere else. The system that only flags risk has handed the hard part back.

This is not an argument against reporting

Management reporting is doing a different job and doing it fine. You need to know whether on-time delivery is improving, which product families lose money, and whether a corrective action worked. Keep those.

The mistake is expecting the same artefact to serve both purposes. A monthly on-time delivery chart cannot tell a planner what to do on Tuesday, and a live order risk queue is a poor way to run a board meeting. Different time horizons, different units, different readers.

A practical place to start

Pick one commitment that matters commercially and that you miss often enough to be annoying. Customer delivery dates are usually the honest answer. Then work backwards: what has to be true for that date to hold, which systems hold each of those facts, and who would act if they knew early.

If you cannot name the person who would act, the project is reporting, however it is built. If you can, you have the beginning of something operational.