Operations BI Dashboard Problems: The 7 That Waste the Build, and How to Avoid Them

Why does the request for one dashboard for everyone go wrong so often?

Three people ask for a dashboard in the same meeting and nobody notices they asked for three different things. The plant manager wants throughput per line against target, refreshed while the shift is still running. The finance director wants cost per unit, which cannot be computed until labour hours are posted and the month is nearly closed. The shift lead wants their own area, their own five tiles, nothing else. What gets specified is a single screen with everything on it.

This is worse in operations than in finance because operational metrics have different half lives. A throughput number is worthless an hour late. A cost per unit number is meaningless an hour early, because the inputs have not landed. Putting both on one canvas forces a single refresh policy, and whichever policy you pick, half the tiles are wrong for their purpose. Then someone adds a tile for the safety committee and another for the quality manager, and the screen has forty tiles that nobody reads because reading it takes longer than walking the floor.

The fix is unglamorous and it happens before any charting. Write down, per tile, who looks at it, what decision it drives, and how stale the number is allowed to be before that decision goes wrong. Tiles that answer no decision get cut. Tiles with different staleness tolerances go on different screens with different refresh policies. Role based views are not a nice extra in operations, they are the thing that stops the project sprawling.

What goes wrong when your ERP, WMS and line data disagree on what a unit is?

The enterprise resource planning system counts cases because that is what gets invoiced. The warehouse management system counts eaches because that is what gets picked. The manufacturing execution system or the line controller counts cycles, and a cycle might be one unit or four depending on the tooling fitted that week. All three are correct inside their own boundary. Joined naively, they produce a throughput figure that is off by a multiple nobody spots because it looks plausible.

Time makes it worse. The enterprise system posts a production order when it is confirmed, which might be the following morning. The line telemetry stamps the event when it happens. A shift that ends at 22:00 gets counted partly in one day and partly in the next, and the daily total that the dashboard shows never quite matches the daily total the supervisor writes on the board.

The fix is a written definition for every metric before any pipeline is built: the exact source field, the exact conversion, the exact time boundary, and the exact treatment of rework, scrap and partial cases. Then validate against a number the operation already trusts, which usually means a hand count over one full shift on one line. If your figure and the supervisor's figure disagree, the model is wrong, not the supervisor. Fixing that before launch costs a week. Fixing it after launch costs the project.

Why do the ERP, WMS and telemetry integrations break after launch?

Because none of them were built to be read by you. A modern system with a documented interface is stable enough. The connections that break are the ones that were never really connections: a nightly file drop from a legacy enterprise system, a direct read against a warehouse database, a tag list on a line controller.

The failure patterns are specific and repetitive. A vendor upgrade adds a column to the export, and a positional parser silently shifts every field one place to the right. A line is re-commissioned and the tags get renamed, so the throughput tile shows zero and everyone assumes the line stopped. A scheduled job fails at 02:00 on a bank holiday and nobody notices for four days because the tile still shows the last number it had, which is the worst possible behaviour. Stale data that looks live is more dangerous than no data.

Three fixes cover most of it. First, validate at ingest against an expected schema and reject the whole file rather than loading a shifted one. Second, put a freshness stamp on every tile and grey the tile out when the underlying source is older than its allowed staleness, so a broken feed is visible instead of invisible. Third, name an owner for each source, in your organisation, not the vendor's, and give them the alert. An operations dashboard without a maintenance owner degrades within two quarters regardless of how well it was built.

What happens when a red tile has nobody attached to it?

A dashboard shows a line dropping below target at 14:20. Nobody is looking at the screen at 14:20. The line runs under target for two hours and the shortfall is discovered the next morning in the daily report, which is exactly where it would have been discovered without the dashboard. The build delivered visibility and no intervention, which is the most common way these projects fail to pay back while technically working.

The same gap appears on drill down. A tile turns red and the manager has no way to get from the tile to the cause, so they walk the floor or phone someone, which is what they did before. If getting from a red number to the responsible order, machine or shift takes more than two clicks, the dashboard is a report with animation.

The fix has three parts and none of them are visual. Threshold alerting that pushes to whatever the team already reads, which is usually a messaging tool on a phone rather than an email. Escalation, so an unacknowledged alert reaches a second person after a defined interval, because a single alert to a single person who is in a meeting is not a control. And drill down from every red tile to the transaction level, so the person who receives the alert can see the cause before they start walking. Sites that get this right catch a dropping line while it is still recoverable, which is the whole business case.

Should you build custom or configure the BI (Business Intelligence) tool you already own?

A large share of readers should configure what they have and stop. If your operations data lives substantially in one system, if a daily or hourly refresh is genuinely acceptable, and if the metrics you need are ones that system already computes, then Power BI, Tableau, Looker or Metabase will get you there in weeks for licence cost and a competent analyst's time. Buying a custom build to reproduce what a licensed tool does natively is a poor trade, and any developer who does not say so early is selling.

The honest split for everyone else is that you should still buy the front end and build only what sits under it. Nobody should be hand coding chart components. What no licensed tool will do for you is reconcile five operational systems that disagree, hold the conversion and time boundary logic for your metric definitions, or compute a joined figure like cost per unit that exists in none of the sources. That is a data modelling and integration job, and it is where the money and the difficulty are.

So the practical answer is usually: licensed tool on top, custom pipeline and semantic model underneath, and your own analysts able to add a tile without raising a purchase order. Fully custom front to back is justified by a real latency requirement, streaming telemetry at sub second intervals or an unusual display environment, and by very little else.

How do hidden costs get into an operations dashboard quote?

Four line items account for most of the overrun, and all four are invisible in a proposal that quotes per dashboard.

• Live refresh treated as a toggle. Streaming a sub minute throughput signal is a different architecture from a nightly pull, not a setting. If the quote does not state which tiles are live and which are batch, the difference will appear later as a change request or, worse, as a lag nobody mentioned.
• Historical backfill. A trend tile needs history, and loading three years out of a legacy system whose exports only go back ninety days is a data project with its own timeline.
• Joined metric modelling. Cost per unit has no source system. Reconciling labour and machine hours against output across sites is engineering that has nothing to do with the front end and is routinely priced as if it were a chart.
• Ongoing pipeline maintenance. The pipeline is a running system. Budget for it annually or accept that it will decay.

Ask for the quote to be broken down by source, with the connection method named for each and the batch or streaming decision stated per tile. A vendor who cannot produce that breakdown has not audited your systems and is quoting from a template.

What separates a dashboard that gets used from one that gets ignored?

The parallel run. Before cutover, the new dashboard runs alongside the existing reports and spreadsheets for two to three weeks, and every disagreement gets chased to a root cause rather than explained away. This phase is the first thing compressed when a project runs late and it is the thing that determines adoption, because the operation adopts a number it has personally checked and rejects a number it has been told to believe.

Three other things separate the builds that stick. The source audit at the start, where every system is named, every connection method confirmed, and every metric defined down to the join, which is the phase that stops scope doubling in month three. Ownership, meaning you hold the pipeline code, the model and the cloud accounts, and your own analyst can add a metric without a statement of work. And tiered freshness agreed up front, so nobody is paying streaming prices for a monthly cost figure or waiting overnight for a throughput number.

The pattern across operations dashboard work is consistent: the charts are the easy fifth of the job, the pipeline and the definitions are the other four fifths, and the parallel run is what converts a technically correct system into one the floor actually uses.