PERSPECTIVE 003
The System
What else changes?
Technology changes systems. Leadership changes organisations.
When organisations decide to automate, the discussion often begins in the same place.
Labour.
Reduce labour.
Reduce cost.
Improve productivity.
Improve quality.
The proposal usually looks convincing.
The return on investment appears straightforward.
Technology becomes the solution.
I have spent much of my career implementing technology.
One programme in particular taught me that the technology itself was only part of the problem.
As COO, I led the industrialisation of a global Heating, Ventilation & Air-Conditioning (HVAC) programme for a major electric car company.
Five highly automated production lines were to be deployed across our manufacturing facilities in China, the United States and Slovakia.
Each was expected to produce approximately 5,000 HVAC assemblies every week.
The customer wanted greater automation.
The Board wanted the investment to make commercial sense.
The factories needed stable production.
Engineering had to make it work.
Suppliers had their own solutions.
Everyone had a perspective.
And viewed from where they stood, most of them made sense.
My responsibility was different.
I could not optimise one part.
I had to understand what happened when all those parts met each other.
So whenever a proposal was placed on the table, I found myself returning to the same question.
What else changes?
Automating a process did not simply change the process.
It could change cycle time.
Quality.
Traceability.
Maintenance.
Packaging.
Logistics.
Engineering capability.
The people required to operate the line.
And sometimes something that looked like an improvement in one part of the system created a problem somewhere else.
That did not make automation wrong.
It meant we had to understand the consequences of the change.
We automated a great deal.
Conveyors moved assemblies between stations. Robots handled components. Fastening was automated and torque monitored. Leak testing, machine vision, traceability and automatic quarantine became part of the production system.
At roughly one assembly every minute, the five lines together represented a considerable manufacturing system.
And yet, some operations remained manual.
Foam seals.
Heater cores.
Evaporators.
Some awkward fasteners and retaining clips.
Even unloading the completed HVAC assembly.
None of these decisions was made because we believed automation was bad.
In most cases, they could have been automated.
The question was whether doing so made the whole system better — and at what cost.
Sometimes the answer was yes.
Sometimes it was no.
And sometimes it was:
Not yet.
That distinction became important.
“Not yet” did not mean resisting technology.
It meant asking whether the product, process, equipment and organisation were ready to depend on it.
We did not rely on assumptions.
We tested them.
We looked at cycle times.
We ran Failure Mode and Effects Analyses (FMEAs).
We reviewed designs.
We challenged suppliers.
And sometimes we asked them a question I have always found useful:
Help us understand what we do not yet know.
The objective was not to prove ourselves right.
It was to discover where we might be wrong before the production line discovered it for us.
When the system met reality
Design reviews can tell you a great deal.
Production tells you more.
We were operating close to just-in-time production.
We carried only around four hours of safety stock, while the customer operated a milk-run collection cycle of roughly two to three hours.
A stopped line therefore mattered.
There were significant penalties calculated by the minute when production stopped.
A problem on the line could very quickly become more than a manufacturing problem.
And problems did happen.
A robot that performed perfectly during commissioning could stop because of a sensor.
A vision system could work perfectly for most of the day, then begin rejecting parts at a certain time because sunlight was shining onto the station.
Even components that individually met specification did not guarantee a defect-free assembly.
When we looked at Design Quality Engineering (DQE) at system level, the interaction of components and processes still produced a statistical probability of defects, measured in Defect Per Million Opportunities (DPMO).
None of these things meant the technology was bad.
They meant the system had to be designed for reality.
This was why failsafe mattered.
On a manual production line, contingency is normal.
If an operator is absent, the line leader may step in.
If there are not enough people, a manufacturing engineer may find himself working on the line.
It is not elegant.
It keeps production running.
Yet there is sometimes a strange assumption that once we automate something, the need for contingency disappears.
As though robots never stop.
Sensors never fail.
Software never misbehaves.
We did not design on that assumption.
Where the consequence of prolonged downtime justified it, automated stations had manual modes and manual fallback capability.
Not because we expected the automation to fail.
Because we knew that eventually, something would.
The objective was not to duplicate everything.
It was to make sure a failure did not unnecessarily become a stopped production line.
That experience left me with another question I still ask today:
What happens when this stops working?
Not because I expect failure.
Because I expect reality.
From Commissioning to Mass Production
Getting the lines commissioned was one milestone.
Getting them ready for mass production was another.
A commissioned line could produce parts.
That did not mean it could yet produce thousands of assemblies, day after day, at the required cycle time, quality and reliability.
Robot paths were refined.
Vision systems were recalibrated.
The control logic in the Programmable Logic Controller (PLC) changed.
Movements were shortened.
Line balancing improved.
Some problems appeared immediately. Others only emerged after thousands of assemblies had passed through the line.
And even after mass production began, we continued to improve.
The production system was never really static.
People
People had to change too.
Operators worked differently.
Line leaders supervised differently.
Maintenance teams needed new capabilities.
Engineers had to deal with increasingly interconnected mechanical, electrical, controls and software problems.
The changes reached beyond the production floor.
Different parts of the organisation had to think differently about investment, capability, risk and what automation was supposed to achieve.
Some people embraced the change.
Others did not.
I knew then that this was a people issue.
Automation reduced certain kinds of manual work, but increased the need for capability elsewhere.
People did not disappear from the system.
What we needed from them changed. Whether they knew it or not.
And in this particular programme, it did not stop at the production floor.
The change reached further into the organisation than I think most initially expected.
Technological change is organisational change.
Looking at the same question again
Today, much of the conversation has moved from industrial automation to artificial intelligence.
I hear familiar questions.
Can Artificial Intelligence (AI) do this?
Can we automate that?
How many people will we need?
How much more productive can we become?
They are reasonable questions.
But they are not where I would begin.
My first question remains:
What else changes?
If AI changes the way work is done, what else changes with it?
What capability do we still need inside the organisation?
What happens when the system is wrong?
Can someone recognise that it is wrong?
Can they intervene?
Can the work continue without it?
And are the people, processes and governance around the technology changing with it?
I do not ask those questions because I am sceptical of technology.
Quite the opposite.
I have spent much of my career implementing it.
I ask because I have seen what happens after the presentation ends and implementation begins.
Sometimes the answer is yes.
Sometimes it is no.
And sometimes it is:
Not yet.
Because the question is not simply whether the technology can do it.
It is whether the system around it is ready to change too.