Actionboards, Not Dashboards

Most plants are drowning in dashboards. Wall screens nobody reads. BI tools with eleven tabs. A KPI page that looks impressive in the morning meeting and changes nothing by afternoon. Over the past decade, reporting grew enormously in most manufacturing organizations. Deciding did not grow with it.

We banned the word "dashboard" inside our own practice, and the replacement is more than a rebrand. An Actionboard is a screen built backward from a decision. Its purpose is behavior at the console, and every element on it has to justify itself against that purpose.

Every visualization must answer three questions: what action, by whom, and are they trained and equipped to take it?

Those three questions sound simple. Applied honestly, they eliminate most of what plants currently display, and what survives becomes far more powerful.

Where the dashboard era went wrong

The dashboard boom had good intentions. Data was finally accessible, visualization tools were finally affordable, and every function wanted visibility. So plants instrumented everything they could see, charted everything they instrumented, and mounted televisions in every hallway to show the results.

The problem is that visibility was treated as the finish line. A chart of yield by hour tells you what happened. It stays silent on what to do, who should do it, and whether the drift on the screen is worth reacting to at all. Faced with that ambiguity, people default to their existing routine, and the screen becomes wallpaper within a month. If you want to test this in your own plant, stand near a wall-mounted dashboard for a shift and count how many people stop and change what they were about to do because of it. The number is usually zero.

There is a second cost that gets less attention. Every chart on a screen makes a claim on the viewer's attention, and attention on a production floor is a scarce, safety-critical resource. A display with forty tiles trains the crew to ignore the display. This is the same failure mode as alarm flooding, migrated from the control system to the reporting layer, and it deserves the same discipline in response.

What separates an Actionboard from a dashboard

The distinction shows up in four design choices, and each one is testable.

• A dashboard describes the past. An Actionboard recommends the next move: trim the setpoint, schedule the inspection, hold the batch. History appears only when it changes what happens next.
• A dashboard is built for meetings. An Actionboard is built for the console, in the operator's language, at the operator's pace, sized for the glance a running line actually allows.
• A dashboard measures everything available. An Actionboard watches the few variables that matter for the decision it serves and stays silent otherwise. Silence is a feature, because it makes the moments the board speaks worth trusting.
• A dashboard has viewers. An Actionboard has owners, decision rights, and a place in the shift routine. Someone is accountable for responding to it, and the response is standard work.

Notice that none of these choices requires new technology. Most plants could build Actionboards with the visualization stack they already own. The gap is design discipline, and the willingness to delete.

The 2 a.m. test

Here is the test we apply to every screen we build. It is 2 a.m., the process is drifting, and the most experienced operator on the crew is on vacation. Does the board tell the person on shift what is happening, what to do about it, and whether they have the authority to do it?

Every clause of that test carries weight. The 2 a.m. part removes the day-shift safety net of engineers down the hall. The drift part demands early signal, before the excursion becomes scrap. The vacation part is the most important: the board has to encode the judgment of your best people so that the newest qualified operator can act on it. A screen that only makes sense to the person who built it fails the test, however beautiful the charting library.

The test also exposes the authority gap, which sinks more analytics projects than any modeling error. If the board says the reactor is trending toward a quality hold and the operator has neither a standard response nor the authority to intervene, you have produced anxiety, and anxiety at 2 a.m. converts into ignored screens by the end of the quarter. Decision rights are part of the design, and settling them is management work that no software can do for you.

How to build one

Building an Actionboard is a design process that starts in the plant, away from any software.

• Start from the decision and work backward to the data. Name the decision, the role that makes it, the trigger condition, and the standard response. Only then ask which tags and models are needed to support it.
• Co-design with the crew that will use it. Operators know which signals they trust, which instruments lie, and what a workable response looks like at line speed. A board built with the crew gets adopted; a board delivered to the crew gets audited for flaws and then abandoned.
• Rationalize the alarms first. If the control system already floods the console, a new screen is one more voice in a shouting match. Cleaning up alarm load is unglamorous, and it is the single best predecessor project an Actionboard can have.
• Tie every recommendation to a live tag, a named role, and a standard response. A recommendation with no owner is a suggestion, and production floors run on ownership.
• Measure adoption like a process KPI. Track whether the board is used, whether recommended actions are taken, and whether outcomes improve. Review it in the same cadence as OEE, and revise the board when the numbers say so.

Expect the first version to be wrong in instructive ways. Thresholds will need tuning, a trusted signal will turn out to be noisy, and the crew will ask for something nobody in the design room anticipated. That feedback loop is the project. Boards that ship as version one and never change are dashboards with better intentions.

A composite example from our work shows the shape of the payoff. A process line had a wall display with thirty tiles and a chronic problem with late-detected moisture drift. The redesign came down to one board: a single SPC view of the four variables that predicted the drift, a recommended adjustment tied to each out-of-control rule, and the shift lead named as the responder. The crew helped set the thresholds and rejected two signals they knew were unreliable, which probably saved the project. Within a quarter, drift events were being caught early enough to correct in-line, and the thirty-tile display came down without anyone asking where it went.

What changes when it works

The visible change is a quieter, more decisive floor. Fewer surprises reach the end of the batch, because drift gets caught while it is still an adjustment instead of a deviation report. Shift handovers get shorter and sharper, because both crews are looking at the same few variables and the same open actions.

The less visible change is cultural, and it is the one that compounds. When operators see that the screen respects their time, speaks their language, and is right often enough to trust, they start bringing it problems. That is the moment analytics stops being a corporate initiative and becomes part of how the plant runs. Trust built at the console is also what makes the next, more ambitious use case land faster, because the crew has seen the pattern work.

Our clients often arrive believing they need more data, more sensors, or a bigger model. Walking the floor usually shows something different. The signal is already there, buried under displays that describe instead of direct. Operators do not need more data. They need the next right action, at the moment it matters, from a system they had a hand in building. That is what an Actionboard is for, and it is the fastest payback we know of in industrial analytics.