← Back to Field Notes

April 7, 2025 · The Bloomfield Team

How to Build a Manufacturing Dashboard People Actually Use

A contract manufacturer in Wisconsin spent $45,000 building a Power BI dashboard with 38 metrics across seven tabs. The project took four months. Three months after launch, the dashboard had two regular users: the plant manager and the IT director who built it. Everyone else had gone back to the spreadsheets they used before, or they walked to the floor and asked the foreman what was happening.

That result is common enough to be a pattern. Dashboards fail in manufacturing for reasons that have nothing to do with the software and everything to do with how the dashboard was designed, who it was designed for, and whether it answers the questions people actually ask during a shift.

Why Most Dashboards Die

The typical dashboard project starts in the wrong place. Someone in leadership decides the operation needs "visibility." An IT team or consultant builds a comprehensive display of every metric the ERP can generate. The result is a wall of numbers that answers questions nobody asked while ignoring the questions that get asked 20 times per day on the shop floor.

The production supervisor does not need OEE broken into 12 sub-components. She needs to know which machines are behind schedule right now, which jobs are at risk of missing their ship date this week, and whether the material for tomorrow's first setup is staged. Those are three questions. A dashboard that answers those three questions in under five seconds will get used every morning. A dashboard that requires clicking through four tabs and interpreting a waterfall chart to get the same answers will be abandoned.

The Five Traits of Dashboards That Survive

For a deeper look at how production visibility connects to broader operations, see our guide to production visibility.

One role, one view. The shop foreman needs different information than the estimator, who needs different information than the plant manager. A dashboard that tries to serve all three with the same screen serves none of them well. The dashboards that get used daily are role-specific. The foreman sees machine status, job progress, and upcoming setups. The estimator sees open RFQs, quote aging, and win rate trends. The plant manager sees on-time delivery, capacity utilization, and margin by customer. Three views built on the same data, each answering the questions that one person asks every day.

Five metrics or fewer per view. Research on decision-making under information load consistently shows that people make better decisions when presented with fewer, more relevant inputs. A production supervisor who sees five metrics she understands and trusts will act on them. A supervisor who sees 22 metrics will ignore most and default to her gut. The constraint forces hard choices about what matters, and those choices are where the real value of the dashboard project lives.

Numbers that update faster than the shift changes. A dashboard that shows yesterday's data is a report. A dashboard that shows what is happening now is a tool. The difference matters because manufacturing decisions happen in real time. If the supervisor learns at 2 PM that a machine has been down since 10 AM, the dashboard has failed even though the data is technically accurate. The update frequency does not need to be millisecond. It needs to be fast enough that the person reading it can still act on what they see.

Built around decisions, not data points. Every metric on the dashboard should connect to a specific action. On-time delivery percentage is useful only if the dashboard also shows which specific jobs are at risk, which makes it actionable. OEE is useful only if the dashboard breaks down which component (availability, performance, or quality) is dragging, which tells the supervisor where to look first. A metric without a decision attached to it is decoration.

The team helped build it. The dashboards that survive are the ones where the end users had input on which questions the dashboard should answer. The IT team builds the technical layer. The production team defines what information they need, when they need it, and in what format. When these two groups collaborate, the result is a tool that the production team trusts because they helped shape it. When IT builds alone, the result is technically impressive and operationally ignored.

A Starting Framework

For a shop that has never built a production dashboard, the fastest path to value is starting with three questions that the production supervisor currently answers by walking the floor, calling someone, or opening a spreadsheet. Build a dashboard that answers those three questions with live data. Deploy it on a monitor visible from the supervisor's desk. Run it for 30 days.

If the supervisor uses it, add two more questions. If the supervisor ignores it, find out why. The answer will be one of three things: the data is wrong, the refresh rate is too slow, or the information does not match how they actually make decisions. Fix that specific problem before adding anything else.

This iterative approach costs less, deploys faster, and produces dashboards with 80% retention rates versus the typical 18% retention rate on comprehensive dashboard projects. The discipline of starting small and adding based on usage data is what separates dashboards that work from dashboards that become expensive screensavers.

For shops ready to connect dashboard data with AI-powered analysis and decision support, the role-specific dashboard is the foundation. Get the dashboard right first. The intelligence layer amplifies whatever you build.