Manufacturing Dashboards: How to Build Live Production Visibility Over Your ERP

Your managing director should not be getting a spreadsheet on Friday afternoon that shows what happened this week. It is already wrong by Monday morning. The data it contains — utilisation rates, downtime totals, throughput figures — describes a version of the factory floor that no longer exists. Decisions made from that spreadsheet are decisions made about last week’s problems.

This is the reality at more UK manufacturing SMEs than you might think. The ERP holds rich production data. The shop floor generates it every second. But the two never quite connect in a way that lets anyone see what is happening right now.

This article is about how to fix that. Not by replacing your ERP. Not by installing a full MES you do not need. But by building a live production dashboard layer that pulls data from where it already lives and presents it in a form your team can actually act on.

The problem: ERP reporting is retrospective

Your ERP is designed to record what happened. It is not designed to show you what is happening. That is a structural distinction, not a feature gap.

A typical manufacturing ERP workflow looks like this:

• A production order is released.
• Operators record start and end times against operations.
• Quantity produced and scrapped is entered at the end of the shift or batch.
• Downtime is logged after the fact — often from memory or rough estimates.
• End-of-shift reports are generated overnight and available the next morning.

Every step in that chain introduces latency. The data that reaches management is hours or days old. In some cases it is batched weekly. The reporting is retrospective by design because that is what the ERP was built for: accurate, auditable records of what happened, not real-time operational intelligence.

The gap between the shop floor and the top floor is not a technology problem. It is an architecture problem. The data exists. It is in the PLCs, the SCADA historian, the ERP database, the Excel files operators fill in at the end of a shift. The problem is getting it from those sources into a single view fast enough to act on.

Production managers tell us they spend 30–40% of their day chasing data. Walking the shop floor to read OEE from individual machine displays. Calling supervisors for updates. Waiting for end-of-shift reports to confirm what they suspected at 10:00 AM. That is not managing production. That is administering information scarcity.

A live dashboard changes that. But only if it is connected to the right data sources and shows the right information for the right audience.

What a good manufacturing dashboard looks like

A good manufacturing dashboard is not a single screen. It is a family of views, each designed for a specific role, each drawing from the same underlying data.

The operator view

What does the person running the machine need to see? Their current job. The target quantity. The count so far. Scrap rate. Cycle time vs standard. Alerts if anything is trending out of spec. That is it. Three to five numbers, clear and large, on a screen mounted at the workstation. No navigation. No multi-tab reports. No Power BI drill-through.

The supervisor view

The supervisor needs to see every line or work cell in their area. OEE per machine. Downtime reasons. Labour allocation. WIP levels. Where is the bottleneck right now, not where was it at shift start. This view can have more data, but it should still fit on a single screen. Scrolling is not acceptable for a real-time operational view.

The plant manager view

The plant manager needs to see across all lines and shifts. Overall OEE. Yield by product family. Throughput trend over the last 24 hours, seven days, 30 days. Capacity utilisation. Unplanned downtime. This is where trend lines and comparisons become useful.

The executive view

The executive needs a summary. Five to seven numbers that tell them whether the plant is winning or losing. OEE, on-time delivery, first-pass yield, cost per unit, safety incidents. No drill-down required. If a number is off, they pick up the phone. They do not need to navigate a dashboard to find the root cause.

Every role gets a different view. Every view draws from the same data. That is the principle.

The data problem: where does production data live?

Production data in a typical UK manufacturing SME lives in four or more places:

The challenge is not that the data does not exist. The challenge is that it exists in four different systems, three of which were never designed to share data with each other. The ERP does not know what the PLC is measuring. The SCADA historian does not know which production order is running. The Excel downtime log lives on a shared drive that no one has cleaned up since 2019.

An interface layer solves this by connecting to each source, normalising the data, and serving it to a dashboard in a consistent format. The ERP API supplies the production order context. The SCADA historian supplies the machine-level data. The manual entries are replaced with structured inputs captured directly in the dashboard interface, eliminating the Excel step entirely.

Architecture: ERP + interface layer + live dashboards

The architecture for a live production dashboard is straightforward. It is not a greenfield MES implementation. It is an integration pattern:

The interface layer is the critical component. It is not a middleware product in the traditional sense. It is a purpose-built integration and presentation tier that:

• Polls or subscribes to data from each source at the appropriate frequency (sub-second for PLC data, seconds for ERP, on-input for manual entries).
• Normalises timestamps, units, and identifiers so a single dashboard can display data from multiple sources consistently.
• Calculates KPIs like OEE, yield, and throughput in real time, rather than requiring a separate analytics pipeline.
• Evaluates alert thresholds and pushes notifications when metrics go out of range.
• Serves role-specific views to web-based dashboards, TV displays in the factory, and mobile devices.

The key principle: the ERP stays as the system of record. All transactions, all costing, all reporting for compliance and audit purposes still happens in the ERP. The interface layer is read-mostly — it can write back lightweight data (operator entries, scrap recordings, labour bookings) to reduce double-entry, but it never replaces the ERP as the authoritative source. That is what keeps the project low-risk and quick to deploy.

Approach comparison: how to build your production dashboard

There are several routes to a production dashboard. Here is an honest assessment of each:

The important distinction: Power BI is an excellent analytics tool. It is not a real-time operational dashboard platform. If your production manager needs to see OEE change when a machine stops, Power BI is the wrong tool. The refresh latency alone makes it unsuitable for live operations. It is also expensive at scale — at £10–20 per user per month for Premium Per User licences, a dashboard accessible to 50 shop floor staff costs £500–1,000 per month before any development costs.

A custom dashboard app or interface layer can achieve the same result at a fraction of the ongoing cost, with sub-second update capability, and with role-specific views that do not require training.

Key KPIs to track on your production dashboard

Not all KPIs are created equal. The following are the metrics that matter most for discrete manufacturing operations at UK SMEs. If you track nothing else, track these:

Do not try to display all of these on a single dashboard. The operator view should show only what is relevant to that role. The executive view should show a subset. Trying to surface everything everywhere is how dashboards become noise.

Build approach: start small, prove value, expand

The most common mistake we see in production dashboard projects is scope creep. Someone decides they want a comprehensive view of everything, the project takes six months, and by the time it delivers, the requirements have changed and half the data sources were harder to integrate than expected.

The better approach is iterative and surgical:

Step 1: Pick one production line or cell

Choose the line that produces your highest-volume or highest-margin product. This is where the business case is strongest and the impact of improvement is most visible. Do not try to instrument the entire factory at once.

Step 2: Identify what data is already available

Can you get machine states from the PLC? Are production orders and targets in the ERP API? Do operators already enter counts somewhere? Identify what you already have before deciding what you need to add. You might discover that 80% of the required data is already accessible and you can deliver a valuable dashboard in weeks without any additional sensors or hardware.

Step 3: Build the operator and supervisor views first

These are the views that drive real-time decision-making. If the operator can see their target and current count, and the supervisor can see OEE and downtime across their lines, you have already closed the most critical visibility gap. Executive dashboards can come later.

Step 4: Add manual entry for what cannot be automated

Not everything needs a sensor. Downtime reasons, quality inspection results, and shift handover notes can be entered directly into the dashboard interface. The key is that these entries replace the Excel spreadsheet, not duplicate it. If you still need the Excel file, you have not solved the problem — you have added a data entry burden.

Step 5: Prove value with a before-and-after comparison

Measure OEE, throughput, and downtime on your pilot line before the dashboard goes live. Measure them again after four weeks of use. The improvement numbers — typically 5–15% OEE improvement from visibility alone — will justify expanding to the rest of the factory.

Step 6: Expand line by line

Once the pilot is proven, replicate the pattern to the next line, then the next. Each one gets faster because the integration patterns, dashboard templates, and alert configurations are already built.

This approach delivers value in weeks, not months. It builds internal buy-in through visible results. And it avoids the capital expenditure and risk of a large MES implementation.

Real-world example: production gauge dashboard in practice

We recently built a live production dashboard for a precision engineering client in the Midlands. The client runs Business Central as their ERP, a mix of CNC machines with varying levels of connectivity, and a workforce that had been filling in paper shift reports for the last 15 years.

The pilot was a single production cell: four CNC machines producing a high-value aerospace bracket. Before the dashboard, the cell was running at an estimated 55–60% OEE based on end-of-week manual calculations. After four weeks of live visibility, the measured OEE was 78% — and climbing.

Here is what the gauge dashboard for that cell looks like:

The dashboard revealed something the end-of-shift reports had been hiding for years: a significant portion of downtime was disguised as production time. Operators were logging time against jobs while the machine was waiting for material, because the ERP did not distinguish between running and waiting. Once that distinction was visible, the underlying causes — material shortages and tooling availability — became actionable.

Within six weeks of the dashboard going live, the cell had reduced unplanned downtime by 22% and increased throughput by 15%. The client is now rolling the same pattern across three additional production cells.

Frequently Asked Questions