A live production dashboard shows what is happening on the floor right now: output against plan, line status, downtime, and quality, updated as events occur. It is fed by operator entries and machine signals, not by end-of-shift paperwork, so the numbers on the screen match the floor at this minute.
That last part is the whole test. Plenty of plants have screens on the wall. Far fewer have screens that are actually live. A dashboard fed by yesterday's spreadsheet is a poster, not an instrument. This post covers what belongs on a live dashboard, where the data has to come from for it to deserve the word live, how to stand one up without ripping anything out, and the failure modes that turn good screens into wallpaper.
What is a live production dashboard?
A live production dashboard is a display, on a wall, a desk, or a tablet, that answers one question continuously: are we on plan right now, and if not, why not. The core elements are current output versus target, line and machine status, active downtime with reasons, and the quality signals that matter for the product being run. The defining property is latency. If an operator logs a stop or a machine drops offline, the screen should reflect it in seconds to minutes, not after someone compiles a report.
That distinction matters because a dashboard's job is to trigger action during the shift. A number you see at 10:15 about a line that fell behind at 10:05 is actionable. The same number seen tomorrow at the morning meeting is history. We covered that gap in depth in real-time visibility vs. reporting; the short version is that reports describe the past while a live dashboard gives you a chance to change the present.
How is a dashboard different from a report?
A report is compiled; a dashboard is fed. A report summarizes a closed period, a shift, a day, a week, and exists to explain and to record. A dashboard covers an open period, the shift you are standing in, and exists to prompt intervention. Both matter. The mistake is using one to do the other's job: running the floor off reports means every problem ages overnight before anyone acts on it, and burying a live screen in month-to-date trend charts means nobody can find the number that needs attention now. Production reporting still has a place. It just should not be the only way anyone finds out what happened.
What belongs on the screen for each role?
Different roles need different screens, because the action each role can take is different. A single giant dashboard for everyone usually serves no one.
- Operators need their station: current job, count against takt, the next changeover, and whether their line's upstream or downstream neighbor is down. Think of it as an andon plus a scoreboard.
- Supervisors need the whole line or area: which stations are running, active downtime with reason and duration, attainment for the shift so far, and open quality holds. Their screen should surface exceptions first.
- Plant managers need the floor at a glance: line-by-line status, shift attainment, the day's biggest loss so far, and anything that threatens a shipment.
- Planners need schedule reality: which jobs are ahead or behind, and which downstream orders are now at risk.
Good screen design is its own topic; shop floor dashboard design covers layout, contrast, and glanceability. The design rule that matters most: a passerby should absorb the state of the area in five seconds.
Where does the data come from?
A dashboard is only as live as its inputs, and a real plant has three kinds. First, operator entries: counts, downtime reasons, quality checks, and changeover confirmations captured on a tablet at the station instead of on paper. Second, machine signals: run state, counts, and rates pulled from PLCs and sensors through machine monitoring. Third, context from existing systems: the schedule, the job, the spec, usually from the ERP.
You do not need all three on day one. A dashboard fed only by digital operator entries is already live in the way that matters, because the data exists the moment the event happens instead of at the end of the shift. Machine connections then remove the manual counting and catch the micro-stops nobody writes down. This is the standard progression we describe in real-time factory visibility: digitize the paper first, connect machines second, and never rip out the systems that already work. Harmony AI is built around exactly that sequence; the live factory visibility module sits on top of whatever combination of operator capture and machine data a plant has today.
How do you stand up a live dashboard?
The path is shorter than most teams expect, because the hard part is not screens. It is data capture. Here is the sequence that works.
- Pick one line and one question. Usually: are we on plan, and what is stopping us. Resist the urge to boil the plant.
- Digitize capture at the stations on that line. Move the paper log to a tablet form that takes seconds per entry. If the form is slower than paper, fix the form.
- Define a short downtime reason list. Eight to twelve reasons an operator can pick in one tap. You can refine later from real data.
- Put the screen where the action is. On the line for the crew, on the supervisor's tablet, in the manager's office. Same data, role-shaped views.
- Wire the dashboard into a rhythm. The supervisor checks it at a set interval and acts on the top exception. A screen nobody is accountable for reading changes nothing.
- Add machine signals where they pay. Start with the constraint machine, so counts and stops flow in without anyone typing.
Notice what is not on the list: replacing the ERP, a plant-wide sensor project, or a data warehouse. A live dashboard is a capture problem and a habit problem before it is a technology problem. The habit half is why we walk the floor with the crew during rollout instead of shipping licenses and a manual; the screens only matter if the people in front of them trust the numbers and know what to do with them. For the fuller build checklist, see building a production dashboard.
Why do production dashboards fail?
Dashboards fail for predictable reasons, and almost never because the software drew the charts wrong.
Stale data. If the screen is fed by a nightly spreadsheet upload, everyone learns within a week that it does not describe the present, and they stop looking. Latency is credibility.
Vanity metrics. Month-to-date OEE on a floor screen prompts no action from anyone standing in front of it. Show the shift, the gap, and the current blocker. Aggregate views belong on management screens, and even there the number should trace to real events, which is why OEE calculated from source data beats OEE estimated in a spreadsheet.
No owner, no rhythm. A dashboard that is not attached to a standard reaction, who looks, when, and what they do about the top exception, is decoration. The plants that get value treat the screen the way they treat an andon: a signal that obligates a response.
Manual double entry. If operators write on paper and someone retypes it into the system, the dashboard lags by hours and the crew resents the duplicate work. Capture once, at the station, digitally. Plants replacing whiteboards with live boards hit this immediately: the board only beats the marker if nobody has to feed it by hand twice.
Anchor your dashboard to standard definitions
- ISO's ISO 22400-2 defines standard KPIs for manufacturing operations management, including availability, throughput, and quality rates, so the numbers on your screens mean the same thing across lines and plants.
- When you cost out the losses a dashboard surfaces, use loaded labor rates from your own payroll and sanity-check them against sector wage data from the U.S. Bureau of Labor Statistics manufacturing pages. Present savings as ranges, not invented precision.
What does this look like in practice?
CLS, a specialty decorator of premium glass bottles in Chattanooga, ran on thorough paper capture for years. The data was good; it just was not visible until the following morning's report. After Harmony AI digitized capture at the point of work, supervisors could watch output, downtime, and disruptions as they happened, and problems that used to surface in a morning report started getting handled inside the shift that caused them. The daily report still exists, and it now builds itself from the same shift data. The full story is in the CLS case study.
That is the honest promise of a live dashboard. It does not run the line for you. It shortens the distance between something going wrong and someone who can fix it finding out. If you want to put a number on what that distance costs today, start with the downtime cost calculator and your own rates.