The dashboard was a genuine advance. It is also where a lot of operations got stuck. Observation is not understanding, and adding another chart does not close the gap between them.
The dashboard was a real advance. Before it, the state of an operation lived in clipboards, control panels, and the memory of whoever happened to be on shift. Pulling that onto one screen was a genuine step forward. The industry then treated the dashboard as the destination rather than a waypoint, and a lot of operations have been stuck there ever since.
What follows is not an argument that screens are bad. It is an argument that a screen is a model of the operation, built by somebody who has usually left, and that reading a model is not the same as understanding the thing it describes. Every example below comes from a session on a running floor.
A Screen Is a Set of Bindings, Not a Window
A supervisory display is a collection of bindings. This tile reads that address. This color expression watches that bit. Those bindings were authored at commissioning, against a plant that has changed since.
An operator once copied four faulted tag names off a screen and asked why all four zones were down. None of those four names existed in the controller. They were display aliases pointing at a zone fault word, mapped years earlier by somebody else, and reconciling them back to real controller objects was the first work of the session. The screen was supposed to have saved that work.
The same drift turns a live element into decoration. A conveyor flashing red against a data point the running system no longer maintains can sit in three separate configuration layers at once, and the shift learns to ignore that corner of the display. Scanning that site's display returned seventeen references to the conveyor. Exactly one zone was genuinely orphaned and five were wired into working color expressions, which is why the floor's instinct to delete the whole conveyor would have taken out a working line. The graphic was still rendering. It had stopped carrying information a long time before.
The Screen Cannot Tell You Which of Its Own Facts Are False
Observation gives you readings. It does not rank them, and it cannot flag the ones that are stale.
In that four-tile session, the premise of the question turned out to be wrong. A read-only connection to the running controller covered sixteen live structures at good quality and found one active fault bit in the entire set. Three of the four tiles the operator was watching had nothing faulted anywhere in the controller. The fourth had a real motor connection error to go chase at the cable and connector.
The operator had no way to make that distinction from the display, and neither did the display. Both showed four red tiles. The difference came from going underneath the screen to the layer that actually decides.
More Views Is the Reflex, and It Compounds
The instinct when an operation has a blind spot is to add a view. Another dashboard, another alert, another report. Each one is locally reasonable. The cumulative result is a plant where any given fact is technically visible somewhere, and finding the relevant one under time pressure is its own skill.
A dashboard answers "what is the value of this thing." The operator's actual question is "what is going on, and what should I do." No quantity of additional charts turns the first answer into the second.
Watch experienced people route around this. They glance at the screen, then they go reason. They pull the live values together with what they know about the logic and what they remember about how this machine behaves, and they produce an understanding the display could not give them. That reasoning is unaided, and it happens under pressure. During a five hour palletizer stop, the operator's own decision to cycle the controller mode was reasonable and it quietly created a second root cause, which then went unnoticed for thirty-eight minutes because nothing on any screen reads out pallet counts until moves start succeeding again.
The Definitions Live Below the Screen
The harder problem is that the words on a dashboard are defined somewhere else entirely.
When an engineer asked how a conveyor's OEE state is calculated, the answer was not in the routine they were reading. It sat inside three vendor add-on instructions among 148 in the export, and the rule separating blocked from faulted was a single alarm-code threshold. A jam, a motor fault, or a power fault sits below that threshold and drives the conveyor to Faulted. Downstream full sits above it, so it leaves the state at Stopped with an alarm attached. That pairing is the site's real definition of blocked, and nothing on any screen states it. The availability and starved percentages the engineer actually cared about are not computed in the controller at all. They come from a performance service that the vendor instruction's own comment names.
Same story one layer up. Four destacker lanes were physically switched off and kept scoring as available in OEE, because the metric's running signal reads a zone run-enable bit rather than a motor, a photo eye, or throughput. The tile was not broken. It reported exactly what it was wired to report, which was not what anyone reading it believed.
A dashboard number is only as meaningful as the definition underneath it, and the definition is almost never on the dashboard.
A Message That Blames the Wrong Side
The expensive version of this is a screen that is confidently wrong about causation.
A robotic palletizing cell sat stopped for five hours and forty-one minutes showing "waiting on a host assignment." The host was healthy. It had dispatched four fresh assignments during the stop, and the controller rejected every one of them silently, with the rejection reason sitting in a tag the entire time. Not one bit was set in any of the cell's five alarm words, because that waiting message is a plain output coil rather than a fault.
Everyone looking at that screen was reading a true statement pointed in the wrong direction. Another view of the same message would not have helped. What resolved it was reading the rungs, the live values, and the physical state of the pallets together, and neither of the two root causes was visible in any two of those three sources.
The Board That Did Work, and Why
"Dashboards are not enough" is not the same claim as "screens are useless," so the counterexample matters.
At a sortation site, a chute jam used to be found when somebody walked the line or happened to catch it on a supervisory screen covering hundreds of chutes. A live board fed by a read-only collector polling each chute controller once a second changed that. A jam now lands on the board within a second of the controller latching it, and first pass yield climbed 6.76 points across the four weeks that followed.
That board earns its place for reasons that have little to do with it being a board. It carries a specific mechanism: jams surface immediately instead of being found on foot. It refuses to lie about its own health, because a stale feed renders as its own operator-facing state and never as "no jams." And the site put a person on the repeat-offender table, which is where the understanding actually happens. The yield attribution is correlational, one site with no holdout, and the case study says so plainly.
What Comes After the Dashboard
The step that has been slow to arrive is the one from observation to comprehension. Software that holds a model of how the operation works, reads control logic and live values and documentation as one connected picture, and explains what the readings mean instead of displaying them faster. That is our Operational Intelligence research, and Nexus is where it gets tested against real controllers rather than a notebook.
None of this makes the dashboard obsolete. People need to see their operation, and a well-built board changes behavior on the floor. It means the dashboard should be the floor rather than the ceiling.
Visibility was the question of the last decade, and dashboards answered it. Comprehension is the question of this one. The consistent finding across these sessions is that the information needed to resolve the fault was already inside the control system every single time. Somebody just had to go read it.