Automation encodes whatever it finds
A process that has accumulated workarounds over a decade does not become efficient when it is automated. It becomes fast, permanent and much harder to change.
Before automating, it is worth asking a blunt question: if we were designing this today with no history, would it look like this? The answer frequently reveals that several steps exist only to compensate for a system limitation that no longer applies.
Three cases where automation is the wrong answer
First, when the step should be eliminated. A reconciliation that exists because two systems disagree is better solved by fixing the disagreement.
Second, when volume does not justify it. A process running twenty times a month rarely repays the cost of building and maintaining automation around it.
Third, when the process is about to change. Automating something scheduled for replacement produces two migrations instead of one.
Measure the process before changing it
Most organisations have opinions about where operational time goes and limited data. Instrumenting a process — volumes, cycle times, touch counts, exception rates and causes — for even a few weeks usually reorders the priority list.
It also creates the baseline needed to demonstrate whether a change worked, which is what makes the second phase of a programme easier to fund than the first.
Sequence for evidence, not for ambition
The most reliable transformation sequences deliver something measurable early, use that evidence to build confidence, and take on structural work once the organisation trusts the direction.
Programmes that start with the hardest, most visible process tend to consume their political capital before they produce a result.
Written by
The EXSTRONIX team
Perspectives drawn from the AI, engineering, finance and operations work we deliver. General in nature and not a substitute for advice specific to your circumstances.