7 Things Worth Looking At When Assessing Whether Operational Data Is Ready for Automation

Automation depends on a digital representation of what is happening in the physical world. A system may decide where to send a vehicle, whether equipment is available, whether a process step has been completed or whether another action can safely start.

The challenge is that data being available does not mean that this representation is correct. A position can be accurate but outdated. An equipment status can be technically valid but no longer reflect the physical state. Events can be missed, duplicated or arrive in the wrong order. Different systems may simply disagree about what happened.

The technically relevant question is therefore not only whether the required data exists. It is whether the data represents reality reliably enough for the particular decision being automated.

Here are seven areas I would look at when assessing whether operational data is ready for automation.

For technical due diligence in industrial technology companies, these questions help assess system architecture, product maturity and technical risk across connected hardware and software environments.

Start with the decision, not with the available data

A common starting point is to look at the data already available and ask what could be automated with it. I would usually approach this from the opposite direction.

First define the operational decision. What exactly is the system expected to decide or trigger? Which facts about the physical world does it need to know to make that decision correctly?

Dispatching a vehicle may depend on its location, availability and current job. Granting access may depend on identity and authorization. Automatically completing a process step may depend on evidence that a physical event has actually happened.

Only after these dependencies are clear does it make sense to assess whether the available data is sufficient.

This also prevents a common problem: automating a process because the interfaces and data already exist rather than because the underlying information is actually suitable for the decision.

The digital state has to represent the physical state

Automation never directly acts on reality. It acts on a digital representation of reality.

A machine can physically be stopped while the system still shows it as available. An asset can be in one location while the backend believes it is somewhere else. A process step can be completed physically while its digital state remains unchanged.

The important question is therefore how the digital state is created and how it can diverge from the physical one.

Direct sensor measurements, PLC states, inferred information, manually entered data and backend calculations have very different failure modes. The more transformations and intermediate systems involved, the more opportunities there are for reality and its digital representation to separate.

Understanding this reality gap is probably one of the most fundamental aspects of assessing operational automation.

Identity is part of data quality

It is possible to measure the correct information and still associate it with the wrong physical object.

This becomes relevant wherever containers, vehicles, tools, machines, products or people move through a system and need to be identified consistently across different technologies.

RFID, NFC, barcodes, positioning systems, equipment IDs, manually entered identifiers and mappings between different IT systems can all establish identity. They can also introduce ambiguity, duplication or incorrect associations.

An accurate position assigned to the wrong asset is not useful data. Neither is a correct machine status associated with the wrong equipment ID.

Identity therefore should not be treated as something separate from data quality. Before trusting any property of an object, the system first needs sufficient confidence that it knows which object it is actually observing.

Missing, delayed and reordered events can change the story

Operational systems are often event driven. Something moves, starts, stops, connects, disconnects or completes, and a digital event is generated.

The difficult cases are not necessarily incorrect values. They are events that never arrive, arrive too late or arrive in a different order from which they happened physically.

A communication interruption may buffer messages locally and upload them later. A gateway may temporarily be offline. Different systems may use different clocks. A backend timestamp may represent reception time rather than the time at which the physical event occurred.

Individually, every message may therefore be valid while the resulting interpretation of the process is wrong.

For automation, completeness, latency, sequencing and timestamp semantics have to be understood together. A current value alone may not be sufficient if the decision also depends on knowing how the system reached that state.

A “single source of truth” does not automatically mean physical truth

Industrial systems often contain several representations of the same reality.

A machine controller may know one state, an IoT platform another, and an ERP, MES or terminal operating system may contain a third. Some systems receive information directly from equipment while others obtain it through several integration layers.

Defining a single source of truth can simplify the architecture, but it does not by itself solve the underlying problem.

The authoritative database can still contain stale or incorrect information.

What matters is where the information originates, how it is propagated, what happens when sources disagree and whether conflicting observations can be detected.

In some cases the most useful source may even depend on the decision being made. The official business record and the source closest to the physical process are not necessarily the same thing.

Reliability has to be assessed in terms of the decision

There is no useful universal definition of “good enough” data quality.

A position that is accurate within ten metres may be sufficient for one application and completely unusable for another. A machine status updated every five minutes may be adequate for reporting but unsuitable for real-time dispatching.

The same applies to errors.

An incorrect value used in a management report may have almost no operational consequence. The same error used to trigger physical equipment, authorize access or change an operational sequence can be significantly more important.

Data quality therefore needs to be connected directly to the decision being supported.

The relevant questions are how wrong the information can be, how often it can be wrong, how quickly errors are detected and - most importantly - what happens when the automated system makes the wrong decision because of it.

The required confidence should follow from the consequence, not from a generic data-quality target.

Robust automation has to work with uncertainty

Perfect operational data is an unrealistic design assumption.

Sensors fail. Networks disconnect. Devices restart. Systems disagree. Messages disappear. People make mistakes.

A mature automation system should therefore not only define what happens when all inputs are valid. It should also define what happens when the available evidence becomes uncertain.

This can include stale-data detection, plausibility checks, comparison between independent signals, detection of contradictory states, confidence measures or explicit handling of missing information.

Eventually there also needs to be a fallback.

The system may continue with reduced functionality, request confirmation, generate an exception, defer the decision to a human or move into a safe state.

The real capability is therefore not simply automated decision-making. It is automated decision-making with explicit boundaries around when the underlying information can and cannot be trusted.

Assessing Operational Data Readiness for Automation

More sensors, more integrations and more available data can enable automation, but they do not automatically make automation reliable.

The important questions remain operational ones: What decision is being made? Which physical facts does it depend on? How are those facts observed? Can important events be missed? How current is the information? What happens when systems disagree? And what is the consequence when the data is wrong?

The same dataset can be perfectly suitable for reporting, useful for operational planning and completely inadequate for an automated physical action.

Automation-ready data therefore does not need to be perfect.

It needs to be reliable enough for the decision being made, its uncertainty needs to be understood, and the system needs to know what to do when that confidence is no longer sufficient.

For investors and engineering leaders, this assessment also provides evidence of scalability and engineering execution capability. It connects operational data quality to investment decision support and the realism of the product roadmap.