How to Design Manufacturing KPI Dashboards People Actually Use
A manufacturing KPI dashboard earns adoption when every metric on it maps to a decision someone makes on their shift. Most plant dashboards fail for the opposite reason: they display forty tiles pulled from whatever the ERP could export, refresh nightly, and get ignored within a month. The fix is design discipline. Decide the audience and their decision cadence first, pick five to nine metrics with agreed definitions, build one obvious drill path from summary to root cause, and instrument usage so you can retire tiles nobody opens.
Choose Metrics by Audience and Decision Cadence
Three audiences need three different dashboards, not three tabs on one. Line supervisors need shift-level signals refreshed every few minutes: OEE by asset, scrap rate, downtime reason Pareto, and jobs behind schedule. Plant and operations managers work on a daily and weekly cadence: on-time delivery, schedule adherence, WIP aging, labor efficiency against routing standards, and past-due work orders. Executives and CFOs need monthly trend and margin context: gross margin by product family, inventory turns, days of supply, and quality cost as a percentage of revenue. Mixing these audiences produces a dashboard that is too slow for the floor and too granular for the boardroom.
- Supervisor view: OEE, downtime Pareto, scrap percentage, and jobs at risk this shift
- Plant manager view: on-time delivery, schedule adherence, WIP aging buckets, and labor efficiency
- Supply chain view: inventory turns, days of supply, past-due purchase orders, and supplier OTIF
- Executive view: margin by product family, revenue versus plan, cost of quality, and cash tied up in WIP
Define Every Metric Before You Build a Visual
OEE is the classic trap. Availability, performance, and quality each have half a dozen defensible definitions, and two plants inside the same company will disagree about whether planned maintenance and changeover count against availability. Write a one-page definition for each KPI containing the plain-English meaning, the exact source tables, the calculation, the filters, the owner, and the target with its basis. On-time delivery alone forces four decisions: promise date or customer request date, ship date or delivery date, line level or order level, and whether partial shipments count. Publish these definitions next to the dashboard so debates happen once, in the definition, rather than every month in a review meeting.
Layout, Color, and the One-Screen Rule
Follow the reading path your users already have. Put the single most important number top-left at a size readable from three meters on a floor monitor, trend context immediately beside it, and breakdowns below. Restrict color to meaning: one accent for the metric, red and amber reserved exclusively for exception states, and grey for context. Avoid dual-axis charts, pie charts with more than four slices, and gauges that consume a quarter of the screen to show one number. Every summary tile needs one drill path to the underlying rows: OEE by line to downtime events to individual job transactions. If a user cannot reach the source record in three clicks, they will export to Excel instead and your governed model loses.
Refresh Rates, Latency, and Honest Timestamps
Match refresh cadence to decision cadence and say so on the screen. A floor andon board that updates every 60 seconds needs a streaming or micro-batch pipeline from machine data and ERP transactions. A monthly margin dashboard can run on a nightly warehouse load. Problems start when the two are mixed without labeling, and a supervisor acts on twelve-hour-old scrap numbers. Every dashboard should display the data-as-of timestamp and go visibly stale when a load fails rather than silently showing yesterday. Also separate refresh from recalculation: an executive margin page can cache pre-aggregated results and still render in two seconds, while a floor board reads a small, purpose-built table rather than recomputing OEE across a year of transactions on every tick.
- Show a data-as-of timestamp on every page and grey the page out when the pipeline is late
- Use 30 to 60 second refresh only where machine or transaction latency actually supports it
- Cache aggregates for executive views so a month of history renders in under three seconds
- Alert the data team, not the plant, when a load fails; users should never be the monitoring system
How Netray Delivers Dashboards That Survive Month Three
Netray runs a short discovery that observes actual shift-start and month-end meetings, then builds a metric dictionary before a single visual. Our AI agents generate the semantic model and DAX or SQL measures directly from your SyteLine, LN, or M3 schema, so a KPI such as schedule adherence traces to the exact job and transaction rows. We instrument dashboard telemetry from day one and hold a 60-day review that retires unused tiles. Clients typically go from roughly 30 legacy reports to 8 to 12 governed dashboards, with weekly active usage above 70 percent of the target audience and shift-start meetings running from the dashboard instead of spreadsheets.
Frequently Asked Questions
How many KPIs should a manufacturing dashboard show?
Five to nine primary metrics per audience is the practical limit for a screen someone scans in under ten seconds. Beyond that, attention scatters and no metric drives action. Additional detail belongs in drill-down pages reached from a summary tile, not on the landing view. If stakeholders insist on more, that is usually a sign you are serving two different audiences and need two dashboards.
Why do plant dashboards stop being used after a few months?
Three causes dominate: metric definitions were never agreed, so users argue with the numbers; refresh latency does not match decision cadence, so the data is stale when it matters; and no one owns the dashboard after go-live, so broken visuals persist. Fix these by publishing definitions, labeling data freshness, assigning a named business owner, and reviewing usage telemetry every quarter.
Should manufacturing dashboards pull directly from the ERP?
For a single-plant, low-volume site, a direct query against a read replica can work. At scale it does not: joins across job, transaction, and item tables slow the ERP and lock rows during month-end. A governed warehouse or semantic layer between the ERP and the dashboard gives consistent definitions, point-in-time history, and predictable performance while keeping the transactional system healthy.
Key Takeaways
- 1Choose Metrics by Audience and Decision Cadence: Three audiences need three different dashboards, not three tabs on one. Line supervisors need shift-level signals refreshed every few minutes: OEE by asset, scrap rate, downtime reason Pareto, and jobs behind schedule.
- 2Define Every Metric Before You Build a Visual: OEE is the classic trap. Availability, performance, and quality each have half a dozen defensible definitions, and two plants inside the same company will disagree about whether planned maintenance and changeover count against availability.
- 3Layout, Color, and the One-Screen Rule: Follow the reading path your users already have. Put the single most important number top-left at a size readable from three meters on a floor monitor, trend context immediately beside it, and breakdowns below.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
Manufacturing AI Readiness Assessment
Score your manufacturing operation's readiness for AI across data, systems, people, and governance, and get a prioritized roadmap for closing the gaps.
Free ToolAI Pilot-to-Production Readiness Assessment
Score your AI pilot against the ten gates that decide whether it reaches production, and get a prioritized list of the gaps blocking deployment.
Free ToolKnowledge Worker Time Savings Calculator
Estimate the realistic hours and dollars an AI assistant returns to your team after accounting for coverage, partial time reduction, and real adoption rates.
Terms used in this article
Ask Netray for a KPI dashboard design workshop that produces a metric dictionary and a working prototype from your ERP data in two weeks.
Related Resources
Self-Service Analytics for Manufacturing Teams
Self-service analytics for manufacturing teams: semantic layers, certified datasets, row-level security, and enablement that keeps plant reporting accurate.
AI & AutomationReal-Time Manufacturing Analytics
Real-time manufacturing analytics: streaming ERP and machine data with CDC, Kafka, and materialized views to deliver sub-minute shop floor visibility.
AI & AutomationModernizing Legacy ERP Reporting
Modernizing legacy ERP reporting: migrating Crystal Reports and SSRS off SyteLine and Infor LN to a governed BI stack without losing report fidelity.