Most companies don't have a dashboard problem. They have a graveyard.
Look at any mid-market operations team's BI tool and you'll usually find ten or fifteen dashboards — built by different people, for different audiences, at different times, in different states of repair. Two or three of them get used. The rest sit there, refreshing nightly, consuming licence seats and warehouse compute, accumulating broken links and stale assumptions. Nobody quite has the authority to delete them and nobody has the time to fix them, so they just exist.
When a new dashboard launches, it joins this graveyard faster than anyone expects. The pattern is depressingly consistent: enthusiasm in the first month, declining opens by month three, and by month six the planning team is back in the spreadsheet they were using before. The operations director stops opening it in meetings. The analyst who built it has moved on to the next request.
I've sat through enough of these post-mortems to spot the same four causes again and again. Each one is fixable. None of them are about the BI tool you chose.
Reason 01Too many metrics on one screen
The first version of any dashboard is almost always too dense. It happens because the build process is collaborative — three stakeholders sit in a requirements meeting, each asks for a few metrics, and the resulting wish list is ten or fifteen KPIs deep. The analyst, wanting to be helpful, fits them all on one screen.
The result is a wall of numbers. Fill rate, days of stock, inventory turns, perfect order, supplier OTIF, forecast accuracy, demand variability, backorders, write-offs, ageing inventory, and four trend lines layered on top of each other. Every number on its own is reasonable. Together they are noise.
What gets lost is the question the dashboard is supposed to answer. A planner who opens a screen with twelve metrics doesn't know which one to look at first. So they look at none of them, scroll past the top, and go check the one spreadsheet they trust. The dashboard didn't fail because the metrics were wrong. It failed because the user couldn't tell what the dashboard was for.
The clue is usually in how the dashboard was scoped. If the requirements doc says "we need visibility into inventory, demand, suppliers and service," you have four dashboards, not one. The mid-market temptation is to combine them to save licence cost or development time. The cost shows up later, in adoption.
One dashboard, one decision. Before anyone opens a BI tool, write down the specific decision the dashboard exists to support. Not "monitor inventory" — that's a topic, not a decision. Something like: "decide which SKUs to reorder this week" or "spot the next likely stockout before it happens."
Then constrain the metrics ruthlessly. Five to seven KPIs on the main view is the upper bound. Everything else goes to a drill-down tab or a separate dashboard. If a stakeholder wants a metric added, the question to ask is: "which existing metric does this replace?" If none, it goes on a different page.
Reason 02No clear owner
A dashboard without an owner is a dashboard waiting to be abandoned. This sounds obvious. It almost never gets done.
Here's the typical lifecycle: an analyst builds the dashboard at the request of an operations manager. The analyst hands it over. The operations manager isn't a daily user — she might check it weekly, at most. The actual users are the inventory planners and buyers on her team. They were consulted during the build, but they weren't asked to own it. When something breaks — a supplier name changes, an ERP field gets deprecated, a metric definition shifts — nobody is responsible for fixing it. The first broken filter goes unreported. The second one too. By the third, users have learned not to trust the numbers.
"Owner" here doesn't mean the person who built it. It means the person who is accountable for it being correct, useful, and current. That's usually a senior user, not the analyst. The analyst is a service provider; the owner is the customer who insists on getting what they paid for.
The other version of this failure is when "ownership" lives with a team rather than a person. "The planning team owns this dashboard." Nobody on the planning team thinks they own it. It becomes everybody's problem and therefore nobody's.
A named person, written into the documentation. The dashboard documentation should answer three questions on the first page: who owns this, what decisions does it drive, who is the analyst contact for changes. The owner's name goes in the dashboard header or a corner footer where users can see it.
The owner has two responsibilities: keeping the dashboard's purpose accurate (it might evolve), and escalating issues fast when something looks wrong. If the owner moves teams or leaves the company, ownership transfer is a deliverable, not an afterthought.
Reason 03Stale data, slowly losing trust
Trust in a dashboard erodes one bad number at a time. It rarely collapses in one event. What happens is more insidious: a user notices that the on-hand count is off by a few hundred units. They check the ERP — yes, the ERP is right, the dashboard is showing yesterday's number. The next week, the forecast view is missing a category they know launched last month. The week after that, the supplier scorecard still lists a vendor that was offboarded in March.
Each instance is small. Individually, they get explained away — "oh, the refresh failed last night," "yeah, we need to add that category." But cumulatively they teach the user a lesson: I can't make a decision based on this without double-checking. Once that lesson is learned, the dashboard becomes optional. The spreadsheet, with its known imperfections, becomes the primary source again because at least the user knows what they're looking at.
Two things tend to be at the root. The first is unmonitored refresh jobs. The pipeline fails silently, the dashboard shows a stale number, and the user is the first to notice. The second is undocumented metric drift. Someone changed how "fill rate" is calculated in the source query three months ago, the number quietly shifted, and nobody told the users. Both problems are about process, not technology.
Make freshness visible and make failures loud. Every dashboard should display, somewhere in the header, the timestamp of its last successful refresh. If a refresh fails, the dashboard should show that visibly — not silently fall back to yesterday's data without notice.
Refresh failure alerts should go to the analyst on duty, not into an inbox that's checked weekly. A simple Slack channel or email distribution that gets pinged when a job fails is enough — the goal is that somebody knows before the users do.
For metric definitions, version them. If you change how fill rate is calculated, update the metric definition in the documentation, note the change date, and tell the users. A two-line email is fine. The trust comes from the communication, not the perfection.
Reason 04No action triggers — just numbers
This is the subtlest failure, and the one that turns otherwise well-built dashboards into wallpaper.
Most supply chain dashboards display the current state of things. Here's your fill rate. Here's your days of stock by category. Here's your supplier OTIF for the quarter. The user looks at these numbers, nods, and… does what, exactly? The dashboard doesn't say. It shows the situation but it doesn't suggest the action.
A good dashboard doesn't just report — it triggers. It tells the user what to do next, or at minimum what to look at next. The best inventory dashboards I've built have a panel that says "27 SKUs need attention this week" with a sorted list and the reason for each. The worst ones show a 96.4% fill rate and let the user figure out where the other 3.6% went.
The distinction matters because dashboards compete for attention. A planner has fifteen tabs open and a queue of ad-hoc requests. If the dashboard doesn't surface what they need to act on today, they will not spend time hunting through it. They will go straight to the email or the spreadsheet that tells them what to do.
The other version of this failure is dashboards that report exceptions but don't make them actionable. "These five SKUs are below ROP" is useful only if the dashboard also tells me the supplier, the lead time, the suggested order quantity, and ideally a button or link to start the PO. Each step the user has to take outside the dashboard reduces the chance the action gets taken.
Lead with exceptions, not totals. The top of the dashboard should answer "what needs your attention?" before it answers "how are we doing overall?" Stockout risks, forecast misses, suppliers off target, SKUs needing reorder — whatever the equivalent is for the audience.
Wherever possible, make the action one click away. Link the SKU row to the ERP record. Surface the supplier contact. Include the calculated order quantity, not just the warning. Each piece of context that's already on the dashboard is one less reason for the user to leave it.
For high-impact issues, push the alert instead of waiting for the user to open the dashboard. A Slack message at 6am that says "3 critical stockout risks for today" reaches the planner before they've opened anything. The dashboard is where they go for context after the alert tells them something needs attention.
What working dashboards have in common
If you look at the dashboards that do get used — the ones that survive past the six-month mark and become embedded in how the team actually plans — they share a small set of traits. None of them are about the BI tool, the colour palette, or the chart library.
- They answer one clear question for one specific audience.
- They have a named owner who feels accountable, not just informed.
- Their data freshness is visible at a glance, and refresh failures are loud.
- They lead with what needs action, not with totals.
- They've been pruned at least once after launch — metrics that didn't drive decisions were removed, not added to.
That last point is worth dwelling on. The dashboards that survive are the ones that got smaller. The instinct after a year is to bolt more metrics onto something that works. The discipline is to keep removing what isn't earning its place. A dashboard with five metrics that all get acted on beats a dashboard with twenty metrics where seventeen are decorative.
None of this is exotic. It's mostly the same advice that applies to any internal tool: be clear about who it's for, what it's for, and who owns it. The reason supply chain dashboards seem to fail more often is that the surrounding processes — refresh monitoring, ownership clarity, exception triage — are harder than the dashboard itself. The build is the easy part. Keeping it useful is the work.
If your team has a dashboard graveyard, the fix usually isn't to build a better dashboard. It's to pick the most-needed one, scope it tightly around a real decision, give it an owner, make its data trustworthy and its exceptions loud — and then delete the rest.
If you'd like to talk through what's working and what isn't in your reporting stack, the free 45-minute audit is the easiest place to start.