How to Build a Real-Time Operations Dashboard

Most operations dashboards are abandoned within a year. The usual explanation is that people did not adopt them. The actual reason is nearly always that a number on the screen was wrong in a meeting once, and after that nobody trusted any of the others.

So the discipline that makes a dashboard succeed has almost nothing to do with visualisation. It is about where the numbers come from.

Rule 1 — Nothing manual on the dashboard

Every figure must be computed from a transaction that someone recorded as part of doing their work. If a tile is fed by a spreadsheet that a person updates, it will be stale, and its staleness will discredit the tiles either side of it.

This has an uncomfortable implication: if a number you want cannot be produced from a transaction yet, it does not belong on the dashboard. Fix the capture first. Building the tile anyway just displays the problem more quickly and more expensively.

Rule 2 — One written definition per metric

On-time delivery against which date — the original commitment or the revised one? Yield on which basis, and including which stages? Pending order value at order price or current price?

Write each definition down, agree it once, and compute it the same way everywhere it appears. Without this, the dashboard becomes one more thing to argue about, and the arguments are unwinnable because everybody is right.

Rule 3 — Exceptions at the top, averages below

A monthly average hides the four orders that are about to be late. Management needs the exceptions today, not the mean at month end.

So the top of the screen should be a list of things that need attention — approvals past their SLA, orders at risk with the reason, lines below plan, stock below reorder, jobs stalled at a stage. Totals and trends belong further down, where they inform rather than distract.

Rule 4 — Every number must open

Any figure should be clickable down to the documents behind it. A number that can be checked is a number that gets used — and the first time someone questions a figure in a meeting, being able to open it there and then is what preserves trust in the whole screen.

Rule 5 — Show how fresh each number is

Some data is live to the second because it is captured at the machine. Some is current to the shift because it is recorded once per shift. Some is from yesterday because it comes from an overnight integration.

Label each one on the screen. The worst kind of dashboard error is not a wrong number — it is a stale number that looks live, and a confident decision made on it.

Rule 6 — Different roles, different dashboards

A dashboard that suits the owner, the plant head and the sales head equally will suit none of them. Build role-based views on top of one shared set of definitions. The definitions are what must be common; the layout is not.

On mobile, be ruthless. In practice owners want three things on a phone: exceptions, today's numbers, and approvals waiting for them. Lead with those and leave the rest for the desktop.

Rule 7 — Alerts are for being told, dashboards are for looking

A dashboard requires someone to open it. Conditions that genuinely need attention should also push: an order becoming at risk, a line drifting below plan during a shift, an approval breaching its SLA.

Then review which alerts are actually acted on. An alert nobody acts on should be deleted rather than tolerated — because tolerating it teaches people to ignore the whole channel, including the alerts that matter.

What to put on it, for a manufacturing business

• Orders: open, in production, ready, dispatched, and at risk with the reason.
• Production: output against plan by line and shift, with reason codes on shortfalls.
• Inventory: stock, ageing, below reorder, and blocked material.
• Purchase: pending requests, open POs and overdue receipts.
• Approvals: what is waiting, with whom, and for how long.
• Delays: what is late, who owns it, and what is blocked behind it.