Designing ERP Dashboards People Actually Use

I walked into a client's operations center in July and saw their ERP dashboard displayed on a 55-inch monitor. Nobody was looking at it. The team was gathered around someone's laptop checking an Excel file they'd built the day before. The irony was painful. They'd invested in a sophisticated BI tool and better data infrastructure, but they'd gone back to spreadsheets because the dashboard didn't help them see what they actually needed.

Most ERP dashboards fail for a simple reason: they display data instead of answering questions. They show charts because charts are available, not because the charts inform decisions. Every metric that gets displayed is one more thing competing for attention, which means nothing gets real attention.

After redesigning dashboards for fifteen clients, I've noticed a pattern. The dashboards that get used daily answer one of three questions: Are we on track? Where's the problem? What should we do next? Everything else is decoration.

The Metrics That Actually Matter

The mistake is thinking that more data equals better decisions. A CFO looking at revenue doesn't need fifteen charts of different revenue breakdowns. They need revenue against plan, an alert when it deviates beyond tolerance, and one level of drill-down to understand why.

With a manufacturing client, we rebuilt their production dashboard from scratch. The previous version had 14 charts on a single page. Weekly utilization by production line. Cost variance by department. Scrap rates. Quality metrics. Head count trending. It was technically comprehensive and practically useless. Everyone knew where to look—usually at the one chart their department cared about—and ignored the rest.

The new dashboard has three visualizations: machines currently down (with reason and estimated return to service), orders at risk of missing delivery (sorted by customer impact), and weekly cost tracking (comparing planned vs. actual). That's it. When production starts in the morning, the team looks at the dashboard because these three metrics tell them if anything is broken or off-track. If everything is green, they know it's a normal day. If something is amber or red, they know exactly where to focus.

The insight was that a good dashboard doesn't need to be comprehensive. It needs to be focused. It answers the question the user asks every morning: "Is everything okay?"

Designing for Behavior, Not Comprehensiveness

The second mistake is designing for executives who don't actually use the system while ignoring the operators who live in it. In most companies, the ops team rarely sees executive dashboards. They work in transaction-level systems or detailed reports. But the ops team's understanding of the business is deeper than anyone's.

We started involving frontline users in dashboard design, which sounds obvious but rarely happens. A warehouse manager immediately told us why a chart of "inventory by location" was useless—they needed "inventory coming in vs. going out today" because scheduling incoming trucks is their actual problem. A sales manager told us that revenue trends matter less than "deals closing this quarter" because that determines commission and hiring.

Good dashboards are built from the jobs people are actually trying to do, not from the data the system happens to make available. When we started designing backwards from problems instead of forwards from data, dashboards became useful.

The implementation matters too. We stopped building web dashboards that live in browsers and started building systems that can send alerts. If a metric crosses a threshold, the user gets an SMS or Slack notification. The dashboard exists as confirmation, not discovery. The user already knows something might be wrong and checks the dashboard to verify and understand.

That's a subtle but crucial difference. Pulling data from a dashboard is work. Being pushed alerts and then consulting the dashboard for context is behavior that scales.

Iterating on What Works

Another learning is that dashboards aren't static. A dashboard that's perfect for three months often becomes useless as business priorities shift. We build them now with quarterly reviews built in—"Are you using this chart? Could it be different?" Regular retrospectives catch dashboards that have drifted from actual user needs.

I once spent three weeks building a predictive inventory dashboard for a distributor—beautiful forecasting, multiple scenarios, really sophisticated. They used it for a month. Then procurement changed their ordering system and the data feeding the forecast became stale. Instead of updating the forecast, they went back to their spreadsheet. The dashboard became cargo cult—everyone knew about it, but nobody relied on it.

The lesson was brutal: a dashboard is only useful if the underlying data is trustworthy and recent. We now bake in data validation into every dashboard we build. If the data is questionable, the chart doesn't display. Red alert instead. Better to hide bad data than let it inform decisions.

For teams building dashboards in 2018, the principle is this: start with the decisions you want users to make. Design backwards to the metrics that inform those decisions. Display only those metrics, no more. Make it impossible to accidentally add "interesting" data that distracts from the signal. And treat a dashboard as a product that needs quarterly iteration, not an artifact that ships once and lives forever.