A factory can generate millions of data points every day and still struggle to answer a basic operational question:
What should we do now?
A PLC can report that a motor stopped.
A historian can preserve the temperature profile preceding the stop.
MES/MOM can identify the production order being executed.
CMMS/EAM can provide maintenance history and previous interventions.
QMS can identify the potentially affected batch.
ERP can expose demand, inventory, and customer priorities.
Each system contributes useful evidence.
Yet none of those observations, in isolation, determines whether the organisation should restart, inspect, contain, repair, reschedule, escalate, or continue production under controlled conditions.
That requires more than data availability.
It requires context, interpretation, decision rights, and action.
Plant data provides observations. Operational intelligence converts relevant observations into sufficiently contextualised evidence for better operational decisions.
The difference is not another sensor.
It is the decision system around the data.
Connected does not mean intelligent
Many Smart Factory programmes begin with connectivity.
Machines are connected.
Legacy signals become accessible.
OPC UA, MQTT, edge platforms, historians, and cloud services move information across the architecture.
Dashboards appear.
Historical data becomes easier to retrieve.
This can represent important progress.
But connectivity solves only one part of the problem.
A factory may now know that cycle time increased, temperature changed, downtime occurred, scrap rose, an asset changed state, a buffer is filling, or energy consumption increased.
The harder questions remain:
Is the cycle-time increase an abnormal loss or normal behaviour for the current product?
Does the temperature change require intervention, or does it remain within an authorised process envelope?
Does the downtime matter because it affected the bottleneck, or can available redundancy absorb it?
Does rising scrap indicate equipment degradation, material variation, tooling condition, operator method, process drift, or product mix?
The signal may be visible.
Its operational meaning may still be unclear.
Connectivity moves data. Intelligence reduces uncertainty around a decision.
Those are different capabilities.
Visibility is not the same as understanding
A familiar pattern appears in many digital programmes.
The organisation builds a dashboard.
Availability, OEE, scrap, throughput, energy, downtime, and quality indicators become visible almost in real time.
Leadership requests additional views.
By line.
By shift.
By product.
By asset.
By reason code.
Soon, the factory has dozens of screens.
Yet the daily management meeting still contains the same questions:
Why did this indicator change?
Is this condition really abnormal?
Who is investigating it?
Was maintenance involved?
Is quality exposed?
Should production stop?
Has this happened before?
The original problem was not simply lack of visibility.
It was lack of interpretive and decision structure.
A dashboard becomes operationally useful when the information contributes to a defined management response.
That normally requires at least:
- relevant operational context;
- trustworthy definitions and data;
- an accountable owner;
- meaningful thresholds or decision criteria;
- authorised response logic;
- a mechanism for recording the outcome.
Without those elements, visualisation can create more information without creating more control.
Context changes the meaning of the same signal
Consider increasing vibration on a production asset.
At signal level, the observation appears straightforward:
vibration is rising.
Operationally, its significance depends on much more.
Which asset is involved?
What function does it perform?
Is it a production constraint?
Does genuine redundancy exist?
Which product is currently running?
Has the pattern occurred before?
How quickly is the condition changing?
Is an intervention already scheduled?
Is an appropriate spare available?
Could continued operation affect product quality?
Is there an approved operating envelope?
When is the next viable maintenance opportunity?
What production demand remains?
The sensor provides an observation.
The organisation determines its significance by connecting that observation to the operating context.
This is also why predictive-maintenance programmes can disappoint despite technically capable models.
A model may estimate an abnormality or an increasing probability of failure.
It does not, by itself, determine the appropriate operational response.
Condition is only one component of the decision.
Asset criticality, production demand, redundancy, recovery capability, spare availability, quality exposure, maintenance opportunity, and current risk controls may all matter.
Prediction becomes valuable when it enters a disciplined decision process.
Operational intelligence requires process context
The same principle applies to production performance.
Consider a cycle time of 71 seconds.
Is it acceptable?
Without context, the number has limited meaning.
The expected cycle for Product A might be 68 seconds.
For Product B, 75.
The line may be in a controlled ramp-up after a changeover.
A temporary quality inspection may have been introduced.
The process may be deliberately slowed because the downstream operation is constrained.
Or 71 seconds may indeed represent an abnormal performance loss.
The number does not explain itself.
Its meaning depends on the expected operating condition against which it is interpreted.
Lean management has always relied on this principle.
A standard establishes an expected condition.
Deviation becomes informative because reality can be compared with that baseline.
Digital Operational Excellence should preserve the same logic.
The objective is not merely to digitise signals. It is to preserve the relationship between observed conditions and operational expectations.
Master data creates operational meaning
This is why apparently unexciting topics such as master data become strategically important.
If the organisation cannot reliably determine:
which asset is producing which product;
which material lot is being consumed;
which process or recipe version applies;
which standard cycle time is valid;
which specification applies to the operation;
which equipment hierarchy represents the physical installation;
which reason codes have consistent meaning;
then sophisticated analytics will struggle to produce trustworthy conclusions.
Industrial data requires semantics.
The temperature value must belong to the right asset.
The asset must belong to the relevant operation.
The operation must be associated with the correct product.
The product must be evaluated against the applicable process and quality requirements.
Without those relationships, analysis can be mathematically correct and operationally wrong.
A sophisticated model operating on weak contextual foundations can therefore be less useful than a simple analysis built on disciplined industrial data.
This is not primarily a data-science limitation.
It is an operating-model and information-governance problem.
Provenance matters as much as availability
Operational intelligence also requires an understanding of where important information came from.
Not every value displayed in a system represents a direct observation.
A value may have been:
- automatically measured;
- manually declared;
- calculated from other events;
- inferred from system state;
- copied from a production standard;
- inherited from the plan;
- imported from another authoritative application.
These mechanisms are not inherently good or bad.
But they have different evidential meaning.
If expected equipment is automatically copied into an “actual equipment” field, downstream analytics may assume an observation that never occurred.
If standard material consumption is used where physical consumption was not captured, a later cost or genealogy analysis may become misleading.
If AI consumes these records without understanding their provenance, it can amplify the ambiguity.
Operational intelligence depends not only on having data, but on understanding what the data actually represents.
Intelligence crosses system boundaries
Plant reality rarely exists inside one application.
ERP represents business demand, inventory, commercial commitments, and enterprise-level transactions.
MES/MOM provides manufacturing execution context.
SCADA and PLCs expose machine states and process behaviour.
Historians preserve time-series evidence.
CMMS/EAM contains asset structures, maintenance history, and work execution.
QMS governs inspections, non-conformance, and quality decisions.
WMS records material movements.
Analytics platforms can detect patterns across these domains.
The architectural challenge is not simply to connect every system to every other system.
It is to identify which combination of context is required for a specific operational decision.
Consider a recurring quality defect.
A vision system may detect the defect.
Understanding it may additionally require material genealogy, process parameters, tooling history, recipe version, equipment condition, previous defect patterns, environmental conditions, and product-specific specifications.
The useful question is not:
How many systems can we integrate?
It is:
What evidence is necessary to understand this condition well enough to make the next decision?
Integration without a decision purpose can easily become architecture theatre.
A highly integrated factory can still have a fragmented decision process.
Daily management is a useful test
Daily management provides a simple test of whether a factory has operational intelligence or merely digital reporting.
Suppose a production line misses its target by 7%.
A conventional dashboard displays the variance.
A stronger information environment may show that:
most of the loss occurred during one product family;
the dominant contribution came from repeated micro-stoppages at one station;
the behaviour intensified following a tooling change;
maintenance recorded a similar symptom two weeks earlier;
quality inspection frequency increased during the same period;
the next viable maintenance opportunity occurs later in the shift.
Now the discussion changes.
The team is no longer debating whether the KPI is red.
It can discuss the decision.
Should production continue under the current controls?
Should tooling be replaced?
Should maintenance intervention be brought forward?
Should volume be moved?
Should additional units be inspected?
Should the condition be escalated for reliability analysis?
That is a different level of digital capability.
The information does not merely describe performance.
It structures action.
Operational intelligence requires decision ownership
There is an uncomfortable organisational reality behind many digital systems:
excellent information does not guarantee good decisions.
Consider an abnormal-condition alert.
The analytical system detects the problem correctly.
The notification is issued.
Maintenance assumes production will determine whether continued operation is acceptable.
Production assumes maintenance will decide whether the equipment condition is serious.
Quality identifies potential exposure but does not own the asset.
Engineering becomes involved only after further deterioration.
Technically, the alert worked.
Operationally, the response system failed.
Every important information product should therefore have an operational purpose.
Who reviews it?
What decision is expected?
When does the condition require escalation?
Who has authority to act?
Who can accept temporary risk?
Which functions must be consulted?
What evidence must be considered?
How is the decision and its rationale recorded?
These questions are not peripheral to analytics.
They determine whether analytics produces control.
Operational intelligence is a socio-technical capability.
Information, people, processes, decision rights, and accountability must work together.
A useful alert reduces ambiguity
Factories increasingly suffer from alert inflation.
Connected equipment produces alarms.
KPIs generate notifications.
Condition-monitoring systems identify anomalies.
AI models produce recommendations.
Dashboards create threshold breaches.
Soon, hundreds of events compete for attention.
That is not greater intelligence.
It may simply be greater cognitive load.
A useful alert should help answer, directly or through linked context:
What happened?
Where?
Under which production conditions?
How abnormal is the condition?
What consequence could result?
Has it occurred before?
Who owns the next decision?
What response is expected?
Which evidence supports that response?
A system may not answer all of those questions automatically.
But those questions should shape the information design.
The objective should not be maximum alert generation.
It should be minimum ambiguity at the point where action is required.
AI does not eliminate the operating model
Industrial AI makes this distinction even more important.
A generative AI system may summarise maintenance history.
A predictive model may identify defect risk.
An agent may recommend changing a production sequence.
A simulation environment may evaluate alternative scenarios.
These capabilities can be valuable.
They do not remove the need for operational context.
Suppose an AI system recommends stopping an asset because degradation appears to be accelerating.
The recommendation may be technically defensible.
The operational decision may still depend on:
- safety exposure;
- product and customer risk;
- asset redundancy;
- available inventory or buffers;
- planned downtime;
- spare-part availability;
- repair duration;
- current production priorities;
- whether a controlled operating condition exists.
The AI contributes evidence or analysis.
The organisation still needs governance around the decision.
This becomes even more important as systems move from recommending actions towards executing them.
The more autonomy a technology receives, the clearer the organisation must be about boundaries, escalation, decision rights, and accountability.
Future Smart Factory architectures will therefore require more than advanced models.
They will require governed decision systems.
Digital twins depend on operational truth
The same principle applies to digital twins.
A model of an asset, process, or production line can provide substantial value.
But simulation quality depends on the quality of the operational state represented.
If the model receives incorrect equipment configuration, outdated master data, incomplete maintenance state, wrong product context, or invalid process assumptions, it can become a sophisticated representation of the wrong situation.
Technological sophistication cannot compensate indefinitely for weak operational truth.
This is why digital maturity should not be assessed purely by architecture complexity or advanced use cases.
A plant with fewer tools but stronger process discipline, data ownership, standards, and decision routines may be more operationally intelligent than a highly connected plant whose information cannot be trusted at the point of action.
Process Mining reveals behaviour, not meaning by itself
Process Mining exposes another version of the same challenge.
Event logs can reveal waiting, loops, rework, deviations, repeated activities, and alternative process paths.
That visibility can be extremely useful.
Interpretation still matters.
A long process duration may indicate waste.
Or it may contain a legitimate quality hold.
A repeated maintenance loop may reflect weak repair effectiveness.
Or it may represent an appropriate diagnostic sequence.
A deviation may indicate non-compliance.
Or it may show that the designed process never represented operational reality adequately.
The event log shows behaviour.
Operational intelligence explains the significance of that behaviour.
Digital tools can make patterns visible at a scale that manual analysis cannot.
They do not eliminate the need for process knowledge and shopfloor judgement.
Start with the decision, not the technology
A more useful Smart Factory maturity path is not:
sensor → cloud → dashboard → AI
It is closer to:
problem → process → context → evidence → interpretation → decision → action → learning
Technology supports that chain.
It should not define it.
Start with the operational problem.
Which decision are we trying to improve?
Who makes it?
What currently makes the decision difficult?
What evidence is required?
What operating context changes the interpretation?
What response is authorised?
How will the organisation know whether the decision was effective?
Only then should the discussion move towards which signals, systems, integrations, analytics, or AI capabilities are required.
This reverses the logic of many digital programmes.
Instead of asking:
What can we do with all this data?
ask:
Which recurring decisions materially affect safety, quality, delivery, cost, and reliability—and why are those decisions currently difficult?
That question produces very different technology priorities.
The “same” downtime event
Consider two production lines, each reporting 30 minutes of downtime.
A conventional dashboard may show an identical availability loss.
Operationally, the events may have almost nothing in common.
On Line A, the stop occurs during lower-priority production. Available buffers absorb most of the effect. Maintenance replaces a known wear component. The required spare is available. No quality exposure exists. The line returns to standard operating condition.
On Line B, the stop affects the plant constraint during an important customer order. The same failure symptom has occurred twice during the previous week. Maintenance applies another temporary correction because the required spare is unavailable. Quality has also observed process instability immediately before the stop.
Thirty minutes.
Thirty minutes.
Identical duration.
Completely different operational significance.
Which event deserves management attention?
Which requires reliability engineering?
Which creates future delivery exposure?
Which should trigger spare-parts action?
Which may justify immediate escalation?
The downtime value does not answer those questions.
The surrounding context does.
That is the difference between recording an event and understanding an operation.
Measure Smart Factory maturity through decisions
Digital programmes often measure progress through deployment:
number of connected machines;
number of dashboards;
number of sensors;
number of analytics use cases;
number of AI pilots;
number of applications deployed.
These metrics can describe implementation activity.
They provide limited evidence of operational value.
A more demanding test is:
Which important operational decisions are now materially better because of the transformation?
Can supervisors identify meaningful abnormalities earlier?
Can maintenance distinguish visible problems from significant risk more consistently?
Can quality connect defects with process conditions faster?
Can planning understand real manufacturing capability more accurately?
Can engineering compare standards with actual execution?
Can leaders distinguish chronic loss from isolated variation?
Can functions spend less time disputing whose data is correct?
Can the organisation learn systematically from previous decisions and outcomes?
Those capabilities are more difficult to implement than dashboards.
They are also much closer to the real purpose of a Smart Factory.
Operational intelligence is an organisational capability
There is unlikely to be one platform that turns plant data into intelligence by itself.
The capability is distributed across the operating model.
It depends on architecture.
But also on:
process definition;
master data;
operating standards;
data provenance;
ownership;
daily management;
problem-solving routines;
maintenance discipline;
quality governance;
IT/OT collaboration;
decision rights;
and increasingly, AI governance.
This is why Smart Factory transformation cannot be delegated completely to IT, automation, data science, or a central digital team.
Technology functions can provide the mechanisms.
Operational functions must define the meaning, consequences, and decisions.
The real objective
Industrial organisations rarely suffer from a simple shortage of data.
Many suffer from a shortage of trusted, contextualised, decision-ready information at the moment action is required.
That is a different problem.
Plant data tells us what systems have observed or recorded.
Operational intelligence connects relevant evidence to:
the process;
the product;
the asset;
the material;
the standard;
the operating condition;
the risk;
the business priority;
the accountable decision-maker;
and the available response.
That is when information begins to influence outcomes.
Smart Factory maturity should therefore not be judged primarily by how much the plant can see.
It should be judged by whether the organisation can understand operational reality more reliably, decide with less ambiguity, and act more effectively because of what its systems know.
That is the difference between a connected factory and an intelligent operation.
Three questions are worth asking:
How much of the information displayed in your factory materially changes an operational decision?
When an abnormality appears, does the organisation receive sufficient context to interpret it—or simply another signal?
Are your digital programmes optimising data availability, or deliberately improving decision-making capability?
#SmartFactory #OperationalExcellence #IndustrialData #MES #IndustrialAI #ManufacturingExcellence #AssetManagement #ProcessMining #IndustrialAnalytics #DigitalTransformation