First factory dashboard project was a disaster. We built this beautiful Power BI thing with live OPC UA feeds from the PLCs. Looked gorgeous in the office. On the floor, nobody used it. The HMI was too slow, the screens were too small, and the shift supervisors just ignored it. Six months of work, zero adoption.
The mistake was building for managers, not operators. Managers want KPIs and trend lines. Operators need to know right now if Line 3 is about to jam. Two completely different problems.
Second attempt, we changed everything. Skipped the fancy BI tools entirely. Used a lightweight web stack pulling directly from the MQTT broker the SCADA team already had. Built simple cards — big numbers, red or green, no charts. Cycle time, reject rate, machine status. That is it. Ran it on cheap Android tablets mounted at each station.
Adoption hit 80 percent in two weeks. Not because it was pretty. Because it answered one question fast: is my line healthy right now?
The hard part was never the dashboard. It was the data pipeline. Our PLCs spit out data every 200 milliseconds. The MQTT broker could handle it, but the database behind the dashboard could not. We were writing 50,000 rows per minute to a PostgreSQL instance that choked after four hours. Switched to TimescaleDB with continuous aggregates and the problem vanished. Compression ratio was about 12 to 1 on the raw telemetry.
Another gotcha: network segmentation. The OT team had their VLAN locked down tight, which is correct. But our dashboard server sat on the IT side. We ended up deploying a small edge gateway — a Dell Edge Gateway 5000 — right on the factory floor. It pulled from the PLCs locally, aggregated the data, and pushed only summaries to the cloud. Latency dropped from 800 milliseconds to under 50.
One thing I wish we had done sooner was involve the maintenance team from day one. They had tribal knowledge about which sensor readings actually predicted failures. We were tracking everything and surfacing nothing useful. After sitting with a maintenance tech for one afternoon, we narrowed the dashboard to six signals that mattered. Bearing vibration on the spindle motor, hydraulic pressure on the press, coolant temperature on the CNC. Those six signals caught a spindle bearing failure three days before it would have gone catastrophic. Saved roughly forty thousand dollars in downtime.
The lesson I keep coming back to is this: a dashboard is not a data project. It is a decision project. If the person looking at it cannot act on what they see within ten seconds, you built the wrong thing. Every pixel should either confirm normal or trigger a response. Anything else is noise.
We are now on the fourth iteration. Added predictive overlays using a simple random forest model running on the edge gateway. It flags anomalies about thirty minutes before they become alarms. The operators trust it because we never hid the logic. They can tap any card and see the raw signal behind the number. Transparency builds trust faster than accuracy ever will.
If you are starting this, do not begin with the tool. Begin with the question. Walk the floor. Ask the operator what they wish they knew five minutes earlier. Build that. Nothing else.