Automation is faithful. Hand it a process that takes nine steps, three of which exist because of a decision made in 2014 by someone who has left, and it will perform all nine steps perfectly, for ever, at speed.
There is a sequence that plays out often enough to be predictable. A process is slow and everybody knows it. Software is bought to fix it. The software is configured to reflect how the work is currently done, because that is the fastest route to go-live and the people who know the process best are the people currently doing it. Six months later the process is faster and no better, and a good deal harder to change than it was on paper.
The failure is not the software. It is that digitisation was treated as a technology decision when it is a design decision that happens to involve technology.
The starting condition is worse than most boards assume
It is easy to imagine that manual, paper-driven working belongs to a previous decade. The survey data is less flattering: a reported 82% of organisations still route tasks manually, on paper or through spreadsheets. That is the substrate most digitisation programmes are laid over.
82%
of organisations still rely on paper-based or manual routing of tasks, typically supported by spreadsheets
The significance is not that manual work is embarrassing. It is that manual processes accumulate undocumented judgement. A person routing work by hand makes dozens of small decisions a day — this one is urgent, that one needs the other team to look first, this customer always wants the call before the email. None of it is written down. All of it is load-bearing.
Digitise the visible steps and you capture the sequence while discarding the judgement. The process then runs faster and produces worse outcomes, and the people who used to supply the judgement are now working around the system to reinsert it. That workaround is the thing that becomes permanent.
Why the redesign gets skipped
Nobody decides to skip it. It disappears for structural reasons.
It has no deliverable. Software has a demo. Process design has a diagram, and diagrams do not create the sense of momentum that a steering group wants at week six.
It surfaces disagreements. Mapping a process properly reveals that two departments believe different things about who owns a decision. That disagreement was survivable while the process was manual, because people negotiated around it daily. It has to be resolved before it can be encoded, and resolving it is a management task nobody scheduled.
Nobody knows the current process. Not fully. Each person knows their portion. The end-to-end version exists only as a composite that has never been assembled. Only around a quarter of organisations use process mining to establish what actually happens, as distinct from what is believed to happen — so most programmes design against the believed version.
The map of a process drawn in a workshop and the log of what the systems actually did are rarely the same document. The gap between them is where the programme goes wrong.
The sequence that works
Deloitte’s 2026 guidance puts it about as plainly as it can be put: redesign, do not just automate. The practical version is an order of operations, and its virtue is that each step makes the next one cheaper.
Observe before you ask. Establish what the process does now from system evidence — timestamps, handoffs, rework loops — rather than from description. People describe the intended process, honestly and inaccurately. The instrumented version is where the surprises are, and the surprises are the point.
Remove before you improve. The cheapest step in any process is the one no longer performed. Most long processes contain steps that exist to compensate for a problem that has since been fixed, approvals whose threshold has not moved since it was set, and checks that duplicate a check three steps earlier. Deleting those is free and immediate, and it happens before anyone buys anything.
Decide the disagreements. Where two functions disagree about ownership, settle it. Explicitly, in writing, with a name against it. This is the step that most needs a leader rather than a consultant, and the one most often deferred into the configuration phase, where it gets settled by whoever is in the room.
Then automate what remains. By this point the process is shorter, the exceptions are understood, and the judgement that used to be invisible has been made explicit enough to encode or deliberately leave with a person. Automation now amplifies something worth amplifying.
Five questions before configuring anything
- Have we established what this process actually does from evidence, or only from how people describe it?
- Which steps exist to solve a problem that no longer exists, and what happens if we simply stop doing them?
- Where do two functions disagree about who decides, and who is going to settle that before it gets encoded?
- What judgement do the people currently doing this apply that is nowhere written down — and are we encoding it, or removing it?
- What number will be different afterwards, and are we measuring it now so we can tell?
What good looks like from outside
There is a tell that distinguishes the two versions, and customers notice it before anybody internal does.
A digitised-but-not-redesigned process is faster right up to the point where something unusual happens, at which point it stops entirely and a person has to intervene by email. The customer experiences a system that is brisk and then inexplicably silent. A redesigned process handles the same exception with a defined route, because the exception was identified during design rather than discovered in production.
That is the whole difference, and it does not show up in the go-live report. It shows up three months later in the volume of manual intervention, which nobody forecast because the business case only modelled the happy path.
None of this is an argument for slower digitisation. Automating processes returns real money — reported averages sit around $51,000 a year per organisation, and for a mid-market business the operational benefit usually matters more than the saving. It is an argument that the four weeks spent understanding the process before configuring it is the cheapest four weeks in the programme, and the one most reliably cut when the timeline tightens.