I remember the first time we rolled out a real-time analytics dashboard on a factory floor. The plant manager was excited, the operators were curious, and I was convinced we'd built something that would change how they worked. It was a beautiful dashboard. Colorful charts updating every five seconds. OEE numbers, throughput rates, downtime alerts. We had a big screen mounted near the assembly line, and everyone gathered around to watch the launch.
Within an hour, the plant manager pulled me aside and said, "This thing is lying to me." He was right. The dashboard showed the line running at 92% efficiency. But on the floor, three machines were down for maintenance. The operators knew it. The supervisors knew it. The dashboard just didn't.
The problem was that we were pulling data from the MES and the PLCs, but we hadn't accounted for manual overrides. When an operator stopped a machine to clear a jam, they'd hit a local stop button that didn't trigger a formal downtime event in the system. The PLC kept sending "running" signals because the motor was still spinning, even though the line was effectively idle. We were showing real-time data, but it was real-time garbage.
That was the first lesson. Real-time doesn't mean accurate. You can have millisecond latency and still be completely wrong if your data model doesn't match the physical reality. We had to go back and instrument the machines differently. We added current sensors on the actual power feeds, not just the PLC outputs. We put in vibration sensors that could detect when a conveyor was empty but still moving. It took three months and a lot of bruised egos.
The second lesson was about what "real-time" actually means for a human. The dashboard updated every five seconds, but the operators couldn't react that fast. They'd see a red alert, walk over to the machine, and by the time they got there, the system had already recovered. They started ignoring the alerts. We ended up slowing the refresh rate to once per minute and adding a delay on alerts. The data was still captured at high frequency for analysis, but the dashboard showed a smoothed, actionable view that matched human reaction times.
The third lesson was the hardest. We built the dashboard for the plant manager. He wanted to see aggregate numbers and trends. But the operators on the floor needed something completely different. They didn't care about OEE. They cared about which specific tool on station 4 was wearing out. They needed a view that showed them, in plain terms, what to fix next. We ended up building two dashboards. One for the manager, with the pretty charts and historical comparisons. One for the operators, which was basically a prioritized list of issues with a map of where to find them.
That split felt wrong at first. Like we were admitting failure. But it was the right call. Different people need different information at different speeds. A real-time dashboard isn't a single artifact. It's a set of tools that match the rhythm of the work.
Now when I walk into a factory floor, I don't ask to see the dashboard first. I ask the operators what they're worried about today. Their answer is usually more useful than any chart I could build.