A dashboard is not digitalisation

One of the most common end points of industrial and energy digitalisation is an impressive dashboard. The meters are connected, the data is flowing, the charts are moving, and at the project handover everyone looks at the big screen with satisfaction.

Then, a few weeks later, it turns out that the way the company operates has essentially not changed at all.

Faults are still reported by phone. Deviations in energy consumption are noticed by someone every now and then. Tasks are assigned by email. The outcome of an intervention is not linked to the original event. And the dashboard slowly turns into expensive wallpaper.

This does not mean that visualisation is unnecessary. A good dashboard matters. It is just not digitalisation itself – it is one of its interfaces.

The chart answers – if someone asks the right question

A dashboard is essentially a passive tool. It shows information to whoever opens it, knows what they are looking for, interprets what they see correctly, and then has the time and the authority to act.

That is a lot of conditions at once.

If the energy consumption of a cooling system is slowly rising, the chart can show the trend. On its own, however, it does not decide:

• how large a deviation counts as abnormal;
• which operating state the value should be compared with;
• who is responsible for the investigation;
• within what deadline a response is required;
• what happens if no action is taken;
• how we measure whether the intervention was effective.

The dashboard makes the problem visible. It is the job of the operational system to deal with it as well.

The real chain: from measurement to a closed-loop process

In a mature digital solution, the chain does not end at the chart:

measurement → interpretation → event → decision → task → execution → verification.

Take a simple example. A submeter shows that the night-time base load of a process area has been above its usual level on three consecutive days.

A dashboard can display this. A working system, however:

1. compares the value with the baseline for the relevant period and operating state;
2. creates an event;
3. assigns the affected site and equipment to it;
4. notifies the person responsible;
5. opens a task or a work order;
6. records the outcome of the investigation and the intervention;
7. measures again whether the base load has returned to normal;
8. reports the excess consumption that was avoided.

At this point we are no longer talking about displaying data, but about an operational process that can be executed digitally.

Data is worth nothing without an owner

One of the most important questions – and yet one that is regularly skipped – is: who owns the event?

The alert may be the most accurate in the world, but if the message lands in a shared mailbox, or ten people receive it at once in the hope that someone will respond, nobody owns it. An alert without an owner usually turns into noise.

In a good process, the following can be defined:

• the owner of the event;
• the escalation rule;
• the response deadline;
• the required documentation;
• the condition for closure;
• how approval and follow-up verification are carried out.

This is the point where OT data meets business operations.

Context matters more than chart resolution

A load of 20 kW may be normal or abnormal. It depends on which machine we are talking about, in which production state, on which shift, at what outdoor temperature and with what history.

That is why data must be linked to the company’s real objects: an asset, a location, a cost centre, a customer, a contract, a maintenance event or a production task.

Without this link, the system stores a great deal of data but creates little knowledge.

OrigSmart’s shared data and process model bridges exactly this gap. Measurement data does not remain a separate time series; it becomes part of the physical and business environment. The same event can therefore appear for the technical operations team, the energy manager, finance and management – for each role in the form it needs for its own decisions.

A good dashboard is designed for action

A dashboard is useful when it does not try to show all the data at once, but supports the decision.

Someone who has to intervene immediately needs a different view from someone who analyses monthly costs. Operators need the current status, priorities and a concrete next step. Managers need trends, risks, deviations and business impact. Maintenance staff need the asset history, related documents and a work order they can close.

In OrigSmart, the dashboard is therefore not a product in its own right. It is a role-specific window into the same system that also handles the source data, the event, the permissions and the executable process.

The measure of digitalisation is not the number of screens

A project’s success is not shown by how many charts were built, but by things such as:

• how much the response time has been reduced;
• how many events were given an owner and closed;
• whether unplanned downtime has decreased;
• whether energy or cost savings can be demonstrated;
• whether a manual data collection or coordination step has been eliminated;
• whether auditability has improved;
• whether an automatic feedback loop has been established.

That is why OrigSmart does not start even a typical pilot by “dashboarding” the entire company. We start from a defined data source, a concrete problem and a measurable success criterion. A pilot can of course include a dashboard and alerts, but at least one traceable action must also come out of it.

Because data creates value when it changes something in the way the business operates.

Sources

• OrigSmart – Web-based business operating system
• NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security