Consenso

Questo sito utilizza servizi di terze parti che richiedono il tuo consenso. Scopri di più

Vai al contenuto
Back to top

Real-time visibility: Data as an operational flow

The information on the website is updated in good faith but may contain errors and is subject to change without notice. The use of such content is entirely at the user’s own risk. More info

Two approaches to data

Historical data and operational data: two different functions

Information systems do not all serve the same purpose, and for a long time they had a clear role: describing what has already happened—reports, extracts, dashboards updated at regular intervals.

There are also systems designed to support what is happening.

This is not an evolution from one to the other, but two different logics, built for different purposes.

The point is understanding when one is needed and when the other is.

Two approaches to data

Historical data and operational data: two different functions

Information systems do not all serve the same purpose, and for a long time they had a clear role: describing what has already happened—reports, extracts, dashboards updated at regular intervals.

There are also systems designed to support what is happening.

This is not an evolution from one to the other, but two different logics, built for different purposes.
The point is understanding when one is needed and when the other is.

The time factor in operational processes

When time becomes a critical variable

There are processes where the difference is not knowing what happened yesterday or 10 minutes ago, but knowing what is happening right now. And others where data is not used for analysis, but to coordinate an ongoing activity.

In the first case, every moment counts: where a resource is, what state it is in, what it is doing, and which operational variables it is dealing with.

And above all: being able to know this without querying the system or realigning information, without refreshing a page or waiting for processing.

The second case occurs, for example:

  • in fleet or mobility service management, where it is necessary to know in real time where vehicles are and whether they are on schedule;

  • in shipment or delivery tracking, where every status update prevents delays or inconsistent communication;

  • in managing reports or operational tickets, where it is essential to know who has taken charge of what, to avoid duplication or uncovered tasks.

In all these cases, the problem is the same: knowing who is doing what, where, and in what state, while the process is still ongoing.
If this information is not updated and shared in real time, the system generates more work instead of reducing it.

Coordinating people and information

The real issue: alignment

When multiple people work on the same operational flow, the challenge is not just collecting data, but keeping everyone aligned.

Those coordinating need a complete and up-to-date view; those working in the field must be able to send information immediately; and those making decisions must rely on consistent data, without having to request or verify it every time.

If this alignment is not automatic, the system breaks down, with the risk that information becomes duplicated, inconsistent, or requires continuous manual handoffs—and the time gained through technology is lost in communication, causing the system to stop being supportive.

From visualization to operations

Not a dashboard, but a real-time reactive system

In these cases, the point is not to build a traditional dashboard, but to design a system where data is:

  • collected from different sources,

  • synchronized in real time,

  • continuously available.

Up to the point of transforming the interface into something different: no longer a consultation tool, but a window onto an ongoing process—a shared operational surface, an environment where every update becomes immediately available, without refresh, without explicit requests, and without perceived latency.

Customization and design method

Specific by nature, repeatable in method

These types of systems are often characterized by being highly specific.

They are built around precise operational flows, with rules, exceptions, and constraints that are difficult to standardize, and needs that are rarely replicated exactly elsewhere.

And that is as it should be, because the value does not lie in making the system reusable, but in making the method used to build it repeatable, namely:

  • analysis of operational flows,

  • identification of relevant events,

  • design of synchronization between actors.

System architecture and management

The hidden complexity

Behind an apparently simple visualization—a system that “updates itself,” that allows everything to be seen in real time—there is much more complex work:

  • integration of different sources,

  • real-time event management,

  • synchronization across different clients,

  • design of interfaces focused on the operational context.

Added to this are less visible but equally critical aspects such as:

  • access and information control, because not everyone should see everything;

  • scalability management (dozens or hundreds of simultaneous elements);

  • resource optimization, because every update has a cost.

This is a complexity that should not be visible, but it is what makes the system reliable and usable in everyday operations.

From static data to continuous flow

When data becomes flow

The main difference, therefore, lies in building systems capable of keeping up with operational reality, not in “displaying data.” Because when data becomes a continuous flow, information no longer needs to chase itself, manual alignment is no longer required, and decisions do not arrive late.
Decisions stop being reactive and finally become simultaneous with what is happening.