Real-Time Production Data: Management Cadence & OEE

What real-time production data actually is — and why the hard question is not the latency, but what happens in the thirty seconds after the number appears on the screen

Real-time production data is the continuous stream of machine states, quantities, cycle times, process values, quality signals, and operator confirmations, delivered with end-to-end latency short enough that a human or automated system can act on the data during the event rather than after it. In a shop-floor context, "real-time" almost always means near-real-time: updates in the one-to-five-second range, sufficient for an operator at an andon, a shift supervisor at a live dashboard, or an alarm rule at an MES engine to intervene while the event is still unfolding. True hard real-time — sub-millisecond, deterministic — is the domain of the PLC and the drive, and belongs to a different engineering problem entirely. When a plant manager says "I want real-time data," the answer they actually need is two seconds, not two milliseconds.

The technical architecture that delivers this — acquisition at the machine, integration at the platform, visualisation at the dashboard — is well-covered in the two companion articles on production data acquisition (how the signal leaves the machine) and machine data integration (how the signal becomes canonical in the platform). This article is the third and final piece of that trilogy: what happens after the data arrives on the screen. Because the most consequential failure mode in real-time production data — the one I have seen at least a hundred times in twenty-five years across four continents, at Johnson Controls, Visteon, Dürr, iTAC, and now at SYMESTIC — is not that the data is wrong, late, or missing. It is that the data is correct, timely, and visible, and nothing happens with it. The screen is green. The supervisor walks past. The decision is made later, from memory, in a conference room, against a monthly report. The real-time infrastructure is engineered perfectly and operates in a cultural vacuum. This article is about how to close that gap — because closing it is where 80 % of the return on a real-time production data programme actually lives.

The five latency regimes — why "real-time" means five different things depending on who is reading the screen

The first discipline of real-time production data is recognising that "real-time" is not a single thing. Every production decision has a natural latency budget — the maximum delay at which a decision is still actionable rather than post-mortem. Below that budget, faster data adds no value; above it, slower data adds no value either, because the decision window has closed. The five regimes that matter in mid-market manufacturing, and the decision owners that live in each:

The failure mode that this table predicts, and that I have named The Latency Mismatch, is what happens when data at one latency regime is used to drive decisions that belong in another. A COO who tries to run plant strategy from a five-second dashboard spends all day chasing micro-stops and none of the day on capacity planning — because the data is arriving faster than the decision frame can accommodate. A shift supervisor who receives nightly OEE reports instead of a live dashboard misses every opportunity to intervene during the shift — because the data arrives after the decision window has closed. Matching data latency to decision latency is the core discipline of production-data management, and it is almost entirely a cultural problem disguised as a technical one.

The trilogy of production data — where real-time utilisation fits

Real-time production data is one of three distinct engineering disciplines that together form the data foundation of a modern factory. The temptation — especially among vendors — is to conflate them under one marketing label. The practical reality, visible in every factory I have implemented MES in over the last two decades, is that they are separable, serially dependent, and solved by different people with different tools:

Real-time production data is where utilisation lives, and utilisation is where most of the return on a data programme is actually captured or lost. My experience in global MES rollouts at Johnson Controls and Visteon was unambiguous on this: the factories that captured the expected OEE gains were not the factories with the best acquisition or the cleanest integration — they were the factories with the disciplined management rhythm on top of the data. Conversely, the factories that implemented MES "perfectly" on the technical layer and saw no improvement were the factories where the shift supervisors had not changed their behaviour on a Tuesday morning at 6:45 a.m. The technology was necessary; the management discipline was what made it sufficient.

Andon — the original real-time production data pattern, and still the most instructive

Toyota's andon (行灯) system, developed in the 1950s and codified in the Toyota Production System, is the earliest and still the most instructive real-time production data pattern. The andon cord or button on the line gives every operator the authority to stop the line and illuminate a visual signal — red, yellow, green — that every supervisor in the area can see within seconds. The system predates computers by thirty years and operates on first principles that remain valid today:

• The signal is visible to the decision-maker within the decision window. Not "on a report at 16:00"; right now, across the line, from the supervisor's normal walking path.
• The signal triggers a specific, rehearsed response. When the andon goes yellow, the team leader responds in 60 seconds. When it goes red, the shift supervisor responds in 180 seconds. The response is not optional, and it is not improvised.
• The signal is local, specific, and attributable. A generic "something is wrong" andon is useless; the classical andon shows station, fault class, and escalation level at a glance.
• The data is physical and persistent until acknowledged. You cannot ignore a red light flashing over your head; you can ignore an email. The medium is part of the protocol.

Every modern real-time MES dashboard is, at its core, a digital andon. The question to ask of any such dashboard is whether it preserves the four properties above or discards them. The most common failure — and this is the failure mode I call The Dashboard Graveyard — is a wall-mounted 55-inch screen that shows 42 gauges in tiny fonts, scrolls a live data stream, and is bright-green in colour 95 % of the shift because it aggregates across twelve lines and hides any individual fault. Operators stop looking after two weeks. Supervisors stop looking after four. By month two, the screen has become ambient wallpaper, and the only person who still reads it is the consultant who installed it. The data is real-time; the behaviour is not. Toyota's andon would have failed for the same reason if it had been designed that way; the reason it succeeded is that it was designed for a single line, a single team, and a specific, rehearsed response.

The shop-floor management cadence — how real-time data actually changes behaviour

The German Shop Floor Management methodology (Shopfloor-Management, codified by practitioners and loosely aligned with VDI 2870) formalises what Toyota's andon implied: a deliberate management rhythm that operates at multiple latency regimes simultaneously, with each regime owning a distinct class of decisions. A mature real-time data programme implements this rhythm explicitly. A programme that treats real-time data as a screen to look at, rather than as a cadence to follow, gets a fraction of the return:

The critical observation, drawn from years of running these cadences across automotive plants on four continents: each tier consumes data at its own latency regime, and each tier's data set is a deliberate aggregation of the tier below. The tier-1 standup does not look at monthly trends; the monthly review does not look at the last 15 minutes of cycle time. Mixing the regimes is the fastest way to render any of them useless. The Six Sigma Black Belt principle here is precise: use the data appropriate to the question being asked, and no other data at all. Extra data is noise, and noise is how management rhythms die.

DMAIC on real-time data — the difference between Six Sigma in 1995 and Six Sigma in 2026

When I earned my Black Belt certification in the Johnson Controls Automotive programme in the late 1990s, the "Measure" phase of a DMAIC project consumed weeks. A Black Belt would scope a problem, build a measurement plan, run manual data collection through tally sheets and Excel, run Gauge R&R studies by hand, and then argue with operators for three months about whether the measurement was representative. The "Analyse" phase consumed another month. By the time the "Improve" phase could begin, the problem had often changed; by the time "Control" was reached, the new baseline had drifted. Six Sigma in 1995 worked, but it worked slowly, because the data foundation was slow.

Six Sigma in 2026, on a modern cloud-MES platform with real-time production data, operates on a fundamentally different clock. The Measure phase is typically hours, not weeks — the data is already being collected; what a Black Belt does in the first week is specify the slicing, attach the right context, and run the Pareto. The Analyse phase is days — regression, stratification, and interaction analysis run against live data streams with correct timestamps and correct attribution. The Improve phase is weeks — implement the counter-measure, and observe its effect in real time on the same dashboards that established the baseline. The Control phase is permanent — the real-time alarm rule that enforces the new specification is part of the MES configuration and fires automatically on every deviation.

A DMAIC project that previously took nine months now takes nine weeks. The constraint has moved from data availability to organisational capacity for counter-measures. This is the most significant shift in Six Sigma practice I have observed in my career, and it is a direct consequence of real-time production data infrastructure done properly. It is also the reason I tell every plant manager starting an MES programme that their bottleneck in year two will not be the software; it will be the number of trained Black Belts or Green Belts available to turn the new data visibility into structured improvement projects. The factories that staff this capacity alongside the MES rollout capture the OEE gains; the factories that do not, do not.

The six latency pathologies — how real-time data programmes fail in ways the dashboard does not show

Data theater — when real-time production data becomes a prop

The most instructive antipattern in the whole category is not a technical failure; it is a cultural one. Data theater is what happens when real-time production data is deployed, visible, and operational — and its primary function becomes not informing decisions but performing the appearance of informed decision-making. The conference-room example, which I have seen at four different Tier-1 plants across three continents, runs as follows. A 75-inch screen in the plant-management conference room. Live OEE, live downtime, live order status. The monthly management review opens with a thirty-second glance at the screen. Someone says "the numbers look good." The agenda moves on. The screen remains illuminated throughout the two-hour meeting; nobody refers to it again.

The data is real; the use of the data is theater. The investment in the screen, the integration, the infrastructure was justified as "enabling real-time management"; the actual behaviour enabled was thirty seconds of acknowledgement per month. This is a worse outcome than not having the screen at all, because it consumes the organisation's appetite for data investment under the label of a solved problem. The discipline that prevents this — and it is a discipline, not a feature — is to refuse to deploy any real-time dashboard without a specific, scheduled, accountable decision attached to it. No standup, no screen. No responder, no alarm. No action within ninety days, the dashboard is retired. The 14:03 Test I teach every plant manager new to real-time data is precisely this: pick any moment during the working day — 14:03 on a Tuesday — and ask, for every real-time screen in the plant, the question "who is looking at this right now, and what decision would they make if the number changed?" Every screen that cannot answer both parts of that question is a candidate for retirement. Every screen that can is earning its keep.

From FAWER Johnson Controls, Changchun, China, 2006: I had been dispatched as an expatriate to bring a Chinese headliner-assembly plant to best-in-class OEE. The plant had, by 2006 standards, an impressive real-time infrastructure: wall-mounted andons over every line, a central control room with multiple screens showing live cycle data, a local historian that had been running for four years. The OEE numbers published monthly to Detroit were respectable — around 72 %, in a category where best-in-class was 78–80 %. The plant was considered a modest success; my brief was to close the last six points. What I discovered in the first month changed how I have thought about real-time data ever since. The "live" data on the control-room screens was not live. The plant's historian polled the PLCs on a 15-minute cycle, wrote to a local database, and the visualisation layer queried that database on its own 3-minute cycle. End-to-end latency, from a stopped line to a visible red indicator, was reliably between 12 and 18 minutes. This was not a secret; it was documented in the IT architecture binder in the plant-manager's office. Nobody had flagged it as a problem because nobody — not the plant manager, not the shift supervisors, not the maintenance team — had ever tried to use the dashboards for an active decision. The shift supervisors had long since learned that by the time the screen showed a problem, they had already heard about it by phone from the line team leader; they had rationally learned to ignore the screens and rely on voice calls. The historian-based "real-time" infrastructure was cultural wallpaper. It had been built in 2002 to look like best practice in a plant-tour binder; by 2006 it was running in a cultural vacuum. The intervention was almost embarrassingly simple: we replaced the 15-minute polling cycle with an event-driven stream off the PLCs (a primitive version of what is now standard OPC UA subscription), cut end-to-end latency to under 10 seconds, and — more importantly — we rebuilt the shift-handover and tier-1 standup protocols around the dashboards rather than around the phone calls. The supervisors initially resisted; the dashboards looked like extra work compared to a familiar voice call. Two months in, the tier-1 team leaders stopped calling and started pointing at the screen. Four months in, the andon-response time had dropped from an average of 14 minutes to an average of 90 seconds. Plant OEE moved from 72 % to 81 % over the following two quarters, and the improvement held. None of that was achieved by new sensors, new machines, or new capital. It was achieved by closing the gap between data latency and decision latency — by making the screens actually real-time, and then making them actually used. Twenty years later, in every MES evaluation I run, the first question I ask is not "what data can you collect?" — every modern system can collect everything. The first question is: "show me the latency from signal to supervisor, measured, not specified; show me the standup that uses the dashboard; show me what would happen at 14:03 on a Tuesday if a line stopped." The factories that can answer those three questions have a real-time production-data programme. The factories that cannot, have screens.

The six disciplines of a working real-time production data programme

Across Johnson Controls, Visteon, and now in my SYMESTIC implementations, the factories that capture the promised value of real-time data consistently do six things, and the factories that do not, consistently do not. The list is short enough to put on a wall, and rigorous enough to serve as the audit checklist for any real-time data programme, old or new:

Cross-reference — where real-time production data sits in the platform stack

Real-time production data is the visible, behavioural surface of a stack whose invisible layers are covered by adjacent glossary articles. Reading them as a trilogy is the most efficient way to understand the full problem:

• The acquisition layer — how the signal leaves the machine, the protocols involved, brownfield strategies, and the timestamp discipline that makes latency measurable — is the subject of the companion production data acquisition article by Martin.
• The integration layer — how the signal becomes canonical across the platform, the Unified Namespace, OPC UA/MQTT topology, tenant isolation, and the cloud-native architecture that enables fleet-wide consistency — is the subject of the machine data integration article by Mark.
• The utilisation layer — the management cadence, the standups, the DMAIC loop, the latency pathologies — is the subject of this article.

The three articles are deliberately a trilogy rather than a hierarchy. A plant that invests heavily in acquisition and integration but skips utilisation produces green dashboards that nobody uses; a plant that invests heavily in utilisation but neglects acquisition produces disciplined standups against incorrect data; a plant that invests in integration without acquisition or utilisation produces a beautiful canonical model of nothing in particular. Real value requires all three.

FAQ

What is real-time production data in one sentence?
Real-time production data is the near-real-time stream of machine, process, quality, and context signals delivered to shop-floor roles with latency short enough to enable intervention during the event — typically one to five seconds for visualisation and alarms, with millisecond control reserved for the PLC layer.

How real-time does real-time actually need to be?
It depends on the decision. For operator intervention at a line, 1–5 seconds. For shift-level management, 1–30 minutes is sufficient. For plant-level management, hourly-to-daily works. For strategic capacity decisions, weekly-to-monthly is correct. The common mistake is over-specifying latency for decisions that live in a slower regime; faster data above the decision window adds cost, not value.

What is the difference between real-time production data and production data acquisition?
Production data acquisition is the engineering discipline of getting the signal out of the machine — protocols, gateways, timestamps. Real-time production data is the operational discipline of using that signal, at the correct latency, by the correct decision-maker, with a rehearsed response. One is the plumbing; the other is what the plumbing is for.

What is The Dashboard Graveyard?
The failure pattern in which real-time dashboards are deployed, illuminated, and ignored — typically wall-mounted, aggregated above the level of any real decision-maker, and untied to any scheduled standup. The data is technically real-time; the behaviour is not. Prevented by never deploying a dashboard without a scheduled standup that consumes it and a 90-day retirement rule for any screen that does not drive decisions.

What is The 14:03 Test?
An operational audit I apply to every real-time data programme. At an arbitrary moment — 14:03 on a Tuesday — walk through the plant and ask, for every dashboard, "who is looking at this right now, and what decision would they make if the number changed?" Screens that cannot answer both parts of the question are candidates for retirement; screens that can are earning their keep. The test exposes data theater in about ten minutes.

What is The Latency Mismatch?
The failure mode in which data at one latency regime is consumed by decision-makers who belong to a different regime — a COO chasing 5-second cycle times, a shift supervisor reviewing monthly reports. Both behaviours produce the wrong decisions at the wrong clock. Corrected by matching each tier's data surface to the decision window the role actually owns.

How does real-time production data change Six Sigma?
The Measure phase of a DMAIC project collapses from weeks to hours when the data infrastructure is already capturing the required signals with correct context. Analyse compresses from a month to days. Improve becomes observable in real time on the same dashboards that defined the baseline. Control becomes an automated alarm rule rather than a manual audit. A nine-month DMAIC cycle becomes a nine-week cycle; the bottleneck moves from data availability to organisational capacity for counter-measures. This is the single largest productivity shift in Six Sigma practice since the methodology was formalised.

How does real-time production data relate to OEE?
Real-time data is the continuous feed; OEE is the calculation sitting on top of it. Availability requires run-time and planned-production-time signals in real time; performance requires live cycle-count and cycle-time baselines; quality requires live good-part and scrap signals. Without real-time data, OEE becomes a monthly retrospective; with real-time data, OEE becomes a live management instrument. The difference is the difference between a speedometer and an annual fuel receipt.

Can I deploy real-time dashboards without a full MES?
Technically yes — standalone OEE tools exist. Practically, the moment you need to link live machine data to order context, shift structure, quality results, or cross-site aggregation, you have rebuilt half of an MES and missed the other half. Most mid-market manufacturers who started with a standalone dashboard end up migrating to an integrated cloud-MES within 18–24 months. Starting with the integrated platform is usually the cheaper and faster path.

What do I do if my plant already has the technology but the behaviour has not changed?
This is the most common situation in manufacturing today, and the answer is almost always a management-rhythm intervention, not a technology investment. Rebuild the shift-handover protocol around the dashboards. Mandate dashboard use in tier-1 and tier-2 standups. Audit the 14:03 Test quarterly. Retire orphan screens. Match latency regimes to decision regimes. The technology is usually already there; what is missing is the rehearsed, scheduled, accountable use of it. That is a culture change, not a capital project.

Related: MES: definition, functions & benefits · OEE · OEE software · Production data acquisition · Machine data integration · MDE (machine data acquisition) · BDE (operator data acquisition) · Cloud MES vs. on-premise · MES software compared · Audit trail · E2E traceability · Industrial data historian · Control plan in automotive · Finite scheduling vs. APS · Downtime reason catalog · Schedule adherence · Shop floor control · Alarm management · Digital shift log · A3 problem solving · Recipe management · MES RFP · MES requirements specification · Change control · Composable MES · MESA-11 · Process documentation · Production metrics · Process data · Alarms · Production control · For COOs & plant managers · For production managers · For operational excellence. External references: ISA-95 / IEC 62264 · VDI 2870 Shop Floor Management · VDI 5600 MES reference architecture · VDMA 66412-1 MES KPIs · Toyota Production System · ASQ Six Sigma reference.

About the author

Christian Fieg

Head of Sales at SYMESTIC. Previously iTAC, Dürr, Visteon, Johnson Controls. Six Sigma Black Belt certified in the Johnson Controls Automotive programme. 25+ years in manufacturing, starting 1998 as a maintenance engineer at Johnson Controls Rastatt; three years as Six Sigma Black Belt on headliner lines; 2006 expatriate assignment to FAWER Johnson Controls in Changchun, China, bringing a headliner plant to best-in-class OEE; Team Leader Business Analyst at Johnson Controls Automotive Electronics with global MES and traceability responsibility for 900+ machines, 750+ users, 30+ manufacturing processes across China, Mexico, USA, Tunisia, Macedonia, France, Russia; Manager Center of Excellence at Visteon Corporation for end-to-end global MES deployment; Sales Manager MES (DACH) at iTAC Software; Senior Sales Manager at Dürr AG. At SYMESTIC since 2021. Author of „OEE: Eine Zahl, viele Lügen" (2025) — the story of a manufacturing engineer who discovers that OEE values in her plant are being systematically gamed. Expertise: MES, OEE, shop-floor digitalisation, Six Sigma Black Belt, traceability, Smart Factory, production data acquisition, PLC programming, JIT/JIS, automotive production, global MES rollouts, cloud MES, real-time production data and management cadence. · LinkedIn · Buch: OEE – Eine Zahl, viele Lügen