Many Smart Factory initiatives begin with a technology in search of an operational justification.
A new analytics platform becomes available, and the organisation starts looking for suitable use cases. A supplier demonstrates computer vision, and inspection processes are immediately reframed as potential artificial intelligence projects. A digital twin is proposed before anyone has defined which operational decision it should improve.
This sequence may appear innovative, but it reverses the logic of industrial transformation.
In a factory, technology should not determine the agenda. A relevant operational problem should create the demand for an appropriate technological capability.
More precisely, transformation should begin with a problem that affects performance, identify the decision that must improve, clarify the process and governance conditions surrounding that decision, and only then determine whether technology can materially change the outcome.
This distinction determines whether a digital initiative becomes an operational capability or remains an isolated technical demonstration.
Technology-First Thinking Creates Artificial Demand
Technology-first initiatives commonly begin with questions such as:
- Where can we apply artificial intelligence?
- Which machines should we connect?
- What could we display on a new dashboard?
- Where could augmented reality be deployed?
- Which process might justify a digital twin?
These questions are legitimate for technology scouting. They are weak foundations for operational transformation.
They encourage organisations to search for situations that fit a tool rather than to determine which operational problems warrant intervention. The resulting portfolio may contain technically sophisticated pilots while producing little change in day-to-day execution.
A production supervisor does not need “more AI”. The supervisor may need to understand why micro-stoppages increase during specific product variants and why the corresponding corrective actions are not sustained.
A maintenance planner does not need “more connectivity”. The planner may need sufficiently reliable evidence to decide which intervention can be postponed without creating an unacceptable risk to production, quality or safety.
A quality engineer does not need a digital twin in the abstract. The engineer may need to assess whether a proposed parameter change will reduce defects without compromising cycle time, process capability or equipment stability.
The operational requirement is specific. Technology is only one possible response.
Begin with the Decision That Is Failing
A credible Smart Factory initiative should begin by examining an operational decision that is repeatedly delayed, inconsistently executed, poorly informed or systematically wrong.
Consider a production area in which OEE declines every week, while the daily management meeting produces little sustained improvement.
The plant may already possess PLC data, a historian, an MES, maintenance records and multiple dashboards. Nevertheless, the team may continue debating whether the dominant loss arises from equipment instability, material shortages, changeover execution, process variation or operator availability.
The problem is not necessarily a lack of data.
The underlying conditions may be that:
- downtime events are classified inconsistently;
- short stops are absorbed into cycle-time variation;
- production and maintenance use incompatible asset structures;
- schedule context is absent from loss analysis;
- abnormalities are identified but not assigned to an accountable owner;
- corrective actions are recorded without verifying whether they prevent recurrence.
Another platform will not resolve these conditions automatically.
The stronger starting questions are:
Which operational decision must improve? Who has the authority to make it? What evidence is currently missing or unreliable? What prevents the organisation from acting effectively today?
Only after answering these questions should the organisation determine whether it requires better standards, clearer accountability, redesigned workflows, improved master data, system integration, analytics, automation or artificial intelligence.
In some cases, advanced technology will be justified.
In others, the principal requirement will be basic operational discipline.
Senior transformation leadership depends on the ability to distinguish between the two.
Technical Feasibility Is Not Operational Value
Technology scouting, experimentation and external collaboration remain necessary. Factories cannot request capabilities they have never encountered, and operational teams may not immediately understand what computer vision, process mining, simulation or generative AI could make possible.
However, exploration and implementation must not be confused.
A pilot can establish that a technology is technically feasible without demonstrating that it is operationally usable. It can be operationally usable without proving that it improves performance. These are different levels of validation:
- Technical feasibility: the capability functions under defined conditions.
- Operational usability: it can be integrated into actual roles, workflows and constraints.
- Operational effectiveness: it improves the targeted decision or outcome in a sustainable manner.
Many digital pilots validate only the first level and are nevertheless presented as transformation successes.
A disciplined pilot should test an explicit operational hypothesis:
- Can earlier detection of process drift prevent a quality escape?
- Can contextualised machine data reduce the time required to diagnose recurring failures?
- Can virtual validation identify assembly risks before physical trials?
- Can process mining reveal recurring execution paths that standard reports fail to expose?
- Can an expert assistant help technicians retrieve approved knowledge without bypassing maintenance standards or engineering authority?
Each question connects technological possibility to an operational consequence.
Without this connection, a pilot may prove that the technology works while failing to prove that the factory needs it.
The Problem Must Be Understood at the Gemba
Operational problems are rarely as simple as they appear in project presentations.
“Excessive downtime” may be a combination of frequent minor stops, delayed escalation, unavailable spare parts, unstable restart practices and production priorities that repeatedly defer permanent corrective action.
“Poor traceability” may not result from the absence of a system. It may arise from unstable material identification, undocumented substitutions, inconsistent rework routes or master data that no longer represents the physical process.
“Operator error” may be a convenient classification concealing ambiguous instructions, poor ergonomics, uncommunicated engineering changes, badly designed interfaces or process conditions outside the approved standard.
Smart Factory design must therefore remain connected to shopfloor reality.
Before defining the digital solution, the team should observe the process, examine abnormalities and exceptions, speak with the people performing the work, and understand how decisions are made when time, information and resources are constrained.
A formal process map describes how work is expected to occur.
The gemba reveals how the process actually survives variation, pressure and uncertainty.
Technology designed exclusively around the first may digitise assumptions rather than improve operations.
Predictive Quality without Operational Pull
Consider a plant proposing a predictive quality model for a critical manufacturing process.
The concept appears attractive. The model would analyse process parameters and warn the team when defect risk increases.
Yet essential operational questions remain unresolved.
What action should follow the warning? Is the operator authorised to adjust the process, or is engineering approval required? Is the prediction contextualised by material batch, product variant, tooling condition and recipe version? What happens when the model recommendation conflicts with an approved control plan? Who investigates false alarms? How is the final decision recorded? How will the organisation determine whether an intervention actually prevented a defect?
Without clear answers, the model produces a probability but not an operational capability.
A problem-driven approach would begin differently.
The plant might establish that defects are detected too late, after additional processing has already generated scrap, rework or containment effort. It would then identify the decision requiring improvement: whether to continue, adjust, contain or stop the process when specified conditions arise.
The team would define:
- the process variables and contextual data required;
- the roles authorised to act;
- the permitted response for each risk level;
- the escalation route for uncertain or conflicting cases;
- the evidence required for traceability;
- the mechanism for reviewing outcomes and improving the decision rule.
Only then would the predictive model become part of a controlled decision process.
Its value would not come from predicting a defect in isolation.
It would come from enabling earlier, safer, more consistent and more traceable action.
Operational Pull Creates Architectural Clarity
Beginning with the operational problem also leads to better industrial architecture.
When organisations begin with technology, they frequently accumulate overlapping applications. One platform monitors equipment, another generates alerts, another stores quality information, and a fourth provides dashboards. Each addresses a fragment of the problem, but the operational workflow remains disconnected.
A well-defined problem makes architectural requirements more concrete.
If the objective is to reduce recurring changeover losses, the required capability may depend on:
- production orders and product context from ERP or MES;
- machine states and parameters from PLCs or historians;
- standard changeover sequences and expected durations;
- equipment condition and outstanding maintenance restrictions;
- quality approval status;
- reason codes and operator observations;
- an accountable daily-management and escalation routine.
The architecture should therefore be designed around the information flow and decision cycle, rather than around the product boundaries of individual technologies.
It must preserve operational context: asset hierarchies, order and product information, equipment states, recipe versions, authorised actions, decisions taken and resulting outcomes.
Industrial integration is not merely the movement of data between systems. It is the construction of a reliable information chain through which people can interpret conditions, exercise decision rights, act and learn.
This prevents the Smart Factory from becoming a collection of applications that are individually capable but collectively incoherent.
Governance Must Protect the Connection to Value
Even well-designed initiatives can lose their operational focus over time.
A project that begins with a genuine problem may gradually become dominated by technical milestones: interfaces completed, sensors installed, models trained, screens configured and users registered.
These deliverables matter, but none of them independently demonstrates operational value.
Governance should repeatedly return to a limited set of questions:
- Is the original problem still relevant and sufficiently important?
- Has the targeted decision improved in speed, consistency, quality or traceability?
- Are people acting differently because of the new capability?
- Are standards, ownership, escalation routes and decision rights clear?
- Are unintended consequences being identified and controlled?
- Can the capability be sustained without continuous project-team intervention?
- Is the solution sufficiently valuable to standardise and scale?
These questions should support explicit decisions to scale, redesign, contain, integrate into the operating standard or withdraw the initiative.
Stopping a pilot that does not improve the targeted decision is not a failure of innovation.
Continuing to fund it because the technology remains impressive may represent the more serious failure of governance.
Smart Factory Maturity Is Visible in Technology Selection
Immature organisations often measure digital progress by the number of tools deployed, machines connected, dashboards created or pilots launched.
More mature organisations are selective.
They recognise that every new capability introduces integration requirements, cybersecurity exposure, master-data dependencies, training obligations, lifecycle costs, support requirements and governance responsibilities.
They therefore ask more demanding questions before introducing technology:
What operational behaviour should change? Which existing capability is insufficient? What information context is required? Who owns the process and the solution after implementation? How will the organisation respond when the system is unavailable, uncertain or wrong? Which standard will be modified if the capability proves effective?
This discipline does not slow transformation.
It prevents transformation from being consumed by technical noise, fragmented ownership and an expanding portfolio of unsupported applications.
The most advanced factory is not necessarily the one with the greatest quantity of technology. It is the one that can repeatedly translate operational problems into explicit hypotheses, appropriate capabilities, disciplined execution and better decisions.
The Meaning of Pull-Driven Transformation
Pull-driven digitalisation is not a rigid linear method. Problem definition, process observation, data analysis and experimentation will often develop iteratively.
The essential discipline is that every iteration remains connected to a verifiable operational hypothesis.
The organisation must:
Understand the operational condition.
Clarify the decision that must improve.
Identify weaknesses in process design, data, ownership and governance.
Determine which information and capabilities are genuinely necessary.
Select the simplest intervention capable of changing the outcome.
Validate it under real operating conditions.
Standardise and scale only when operational value has been demonstrated.
Technology remains essential throughout this process. However, it must serve the industrial operating system rather than attempt to replace it.
That is the difference between deploying digital tools and developing a Smart Factory capability.
A factory becomes digitally mature not when technology is present everywhere, but when technology is introduced selectively, governed rigorously and connected directly to better operational decisions.
Questions for Reflection
- How many digital initiatives in your organisation began with a clearly defined operational decision rather than with an available technology?
- When a pilot is technically successful but fails to change shopfloor behaviour, who has the authority to stop, redesign or withdraw it?
- Which operational problem in your factory genuinely requires better technology, and which one first requires stronger standards, accountability or process discipline?
#SmartFactory #OperationalExcellence #ManufacturingExcellence #IndustrialAI #MES #IndustrialMaintenance #ProcessMining #AssetManagement #DigitalTransformation