The Autonomous Factory: Can a Machine Order Its Own Spare Part?

Over the course of this series, we have followed a chain that starts with a machine and gradually extends far beyond it:

• Part 1 – From Maintenance Schedules to AI: We explored how predictive maintenance evolved from traditional reliability methods towards AI-supported prediction.
• Part 2 – Predictive Maintenance Gives You 30 Days. Now What?: We looked at what needs to happen after an early warning, from identifying the correct spare part to checking availability and supplier lead times.
• Part 3 – How Does a Machine Know It’s About to Fail?: We examined how sensors, condition data and AI can identify changes in machine behaviour before failure.
• Part 4 – Robot Dogs, Drones and Smart Sensors: We explored how mobile inspection technologies are changing the way manufacturers collect condition data.
• Part 5 – From Predictive Maintenance to Predictive Spare Parts Planning: We asked whether information about expected maintenance demand could also make inventory planning more forward-looking.

Together, these developments lead naturally to one final question.

If a system can detect that a component is deteriorating, estimate when an intervention may be required and determine that a spare part will be needed, could the machine eventually trigger the entire process required to get that part where it needs to be?

In other words: can a machine order its own spare part?

Some of the Automation Already Exists

The idea sounds futuristic, but individual parts of this process are already standard functionality in industrial software.

In SAP S/4HANA, for example, material components can be assigned to maintenance orders. For stock materials, the system can automatically generate a reservation; for non-stock materials, it can generate a purchase requisition for external procurement. Depending on the configuration, SAP can also automatically determine a source of supply for a non-stock component.

The automation therefore does not need to start with a machine independently deciding what to buy. Industrial systems already know how to translate a confirmed maintenance requirement into subsequent material and procurement processes.

The more difficult challenge comes earlier in the chain: Can we establish with sufficient confidence what is needed, when it will be needed and whether purchasing it is actually the right response?

Before You Order the Part, You Need to Know Which Part

Imagine that condition monitoring identifies increasing vibration in a motor and analysis indicates that a bearing is likely to require replacement.

For an autonomous process to continue from there, the system first needs to connect that physical component to the correct material record.

That sounds straightforward until we consider the reality of industrial material data. The same physical part may exist under different descriptions or material numbers across sites. Manufacturer information may be missing, descriptions may be inconsistent and duplicate records may exist in the ERP.

Maintenance BOMs can help establish the relationship between technical objects and their spare parts; SAP explicitly describes spare-parts assignment and materials planning as core purposes of maintenance BOMs. But the usefulness of that relationship still depends on the underlying master data being accurate.

This is where SPARROW.Clean becomes relevant to the autonomous-maintenance story. Clean, standardised and deduplicated spare-parts data is not simply an efficiency initiative for master-data teams. It becomes part of the foundation required for reliable automation.

A human maintenance technician can sometimes recognise that two badly described material records refer to the same bearing. An automated process needs that ambiguity to have been resolved before it acts.

Before You Buy It, You Need to Know Whether You Already Have It

Correctly identifying the spare part still does not mean it should be ordered.

The required bearing might not be available in the plant where the intervention will take place, but ten units could be sitting in another warehouse within the same organisation.

An autonomous process that checks only local inventory could therefore create a purchase order while usable stock already exists elsewhere. The transaction would technically be automated, but the decision behind it would not necessarily be intelligent.

This is why network-wide stock visibility becomes increasingly important as manufacturers automate more of their maintenance and materials processes.

With SPARROW.Stock, organisations can create greater transparency over spare-parts inventory across locations, while SPARROW.Pool supports the use of parts across sites rather than treating every plant as an isolated inventory environment.

The relevant question therefore changes from “Does this plant have the part?” to “Does our organisation already have the part, and can it be made available where it is needed in time?”

That is a much better basis for deciding whether external procurement should begin.

Before You Replenish It, You Need to Know Whether You Should Stock It

There is another decision hidden behind the transaction.

Suppose the only available bearing is transferred from another site and used for the planned intervention. Should it now be replenished?

A simple inventory rule might say yes because stock has fallen below a predefined minimum. A more sophisticated planning process would consider why the part was consumed, how critical the assets using it are, how often it is required, how long replenishment currently takes and whether suitable inventory remains elsewhere in the network.

This is the role of SPARROW.Plan. Rather than treating historic min/max parameters as permanently valid, planning recommendations can reflect factors such as historical usage, criticality and supplier lead times and can be recalculated when the underlying situation changes.

As we explored in Part 5, future integration with condition and maintenance information could make that decision even more dynamic. If the organisation already has evidence that another intervention involving the same component is becoming likely, that information could eventually contribute to the decision about whether and when inventory should be replenished.

The important distinction is that automating a purchase transaction is relatively easy; automating a good inventory decision is considerably harder.

The Autonomous Chain Depends on Data

This reveals something important about the autonomous factory.

The most visible technologies are often the ones closest to the machine: sensors, AI models, computer vision, drones and robots. But a large part of the infrastructure required for autonomous maintenance is much less visible.

The system needs to know which physical component corresponds to which material. It needs reliable master data, visibility of inventory across locations, current information about supplier lead times and a way to distinguish between parts that should be purchased, transferred, replenished or perhaps not stocked at all.

Without this foundation, adding more automation can simply allow poor decisions to happen faster.

This is why data quality and spare-parts optimisation should not be viewed as separate from the development of increasingly autonomous maintenance processes. They are part of the infrastructure that makes those processes trustworthy.

Where Should Humans Stay in the Loop?

Even with excellent data, complete autonomy will not always be desirable.

A predicted failure carries uncertainty. A replacement may require a shutdown that has to be coordinated with production. A high-value component may require purchasing approval, while transferring a scarce critical spare from one plant to another may shift operational risk rather than eliminate it.

SAP's own maintenance functionality illustrates this distinction. In S/4HANA Cloud, planners can determine whether a reservation or purchase requisition should be created immediately, when the maintenance order is released, or not yet at all. SAP even gives the example of a motor that may need replacement: procurement can deliberately be held back until the requirement has been verified.

That is a useful model for thinking about autonomy more broadly.

The future may not be one in which humans disappear from the process. Instead, systems could increasingly handle decisions where the data is reliable, the rules are clear and the operational consequences are limited, while escalating ambiguous or high-risk decisions to people.

The question is therefore not simply whether a machine can order a spare part, but under which conditions we are comfortable allowing it to do so.

From Prediction to Prevention

At the beginning of this series, we looked back at the history of predictive maintenance and saw that the ambition itself is not new. Maintenance teams have always tried to understand failure patterns early enough to intervene before production stops.

What is changing is the amount of information available and the speed at which organisations can act on it.

A sensor can identify a change in machine behaviour. Analytics can assess whether that change indicates deterioration. Maintenance can determine when an intervention is likely to be required. Reliable material data can connect the physical component to the correct spare part. Network-wide inventory visibility can show whether that part already exists somewhere in the organisation, while dynamic planning can help determine whether it should subsequently be replenished.

Procurement can then become the outcome of that chain rather than its starting point.

The autonomous factory will therefore not emerge from one AI model, one robot or one software platform. It will depend on connecting machine condition, maintenance, material data, inventory planning and sourcing closely enough for information to move reliably between them.

For manufacturers, the opportunity is not necessarily to remove people from spare-parts decisions. It is to remove the manual searches, disconnected data and static processes that prevent people and systems from acting on predictive information while there is still time to make a difference.

Because ultimately, predicting a failure is not the goal. Preventing its operational impact is.