70% of IT budgets in APAC banks go to maintaining legacy infrastructure. Three years and multiple automation pilots later, most still cannot produce a credible ROI number from a completed automation programme. The problem is not the AI. It is the order of operations.
Automating a bad process gives you an automated bad process. This consensus is forming across operations teams in 2026. It is what your ops team has been saying for two years. It is what the AI automation roadmap ignores.
The sequencing problem
AI automation and process improvement are not alternatives. They are sequential. The companies stuck in pilot purgatory are the ones that skipped the sequence.
When you automate before improving:
- The broken process now runs at machine speed. The 20 unnecessary handoffs still exist.
- Root causes are obscured behind AI outputs. The system does what it was told, faster.
- ROI is unattributable. "How do we know the automation specifically benefited us?" Nobody can answer this.
- Pilot purgatory: the automation works technically, produces wrong outcomes operationally, and never scales.
When you improve before automating:
- A clean, measured baseline exists. Every step is mapped, timed, and costed.
- Non-value-adding steps are already eliminated. The process has fewer steps, shorter cycle time, lower error rates.
- Automation ROI becomes attributable: the process improvement saving is measured first, then the automation saving is measured incrementally on top.
- Kuwait bank outcome: 139 days improved to 57 days (59% reduction) through process improvement alone. The automation layer deploys on the improved process, not the broken one.
The IT vs Operations tension
Your IT team thinks AI automation and process improvement are alternatives. Your operations team knows they are sequential. This is not a disagreement about tools. It is a disagreement about where the problem lives.
IT sees the problem as manual effort. The solution: automate the manual steps. Budget: $2M for an RPA platform, 6-month implementation, projected 40% labour saving.
Operations sees the problem as process design. The solution: remove the unnecessary steps first, then automate what remains. Budget: $0 for the improvement work (the team already exists), $200K for the automation of a clean process.
Both teams are correct about what they see. The difference is sequencing. When the IT team wins the argument, the automation investment comes first. The result: $2M spent automating 47 steps when 12 of those steps should not exist. The bank is now paying to maintain automation for steps it should have eliminated.
65-80% of large technology programmes exceed planned budget or timeline. The process-first sequence does not prevent this. But it does ensure the automation investment targets the right steps when it eventually deploys.
The banking example that explains pilot purgatory
An APAC bank's IT team proposes RPA for loan origination. The process has 47 steps with 20 handoffs between departments. RPA automates the handoffs. They now happen at machine speed.
The 20 unnecessary handoffs still exist. The loan still takes 22 days. The approvals still queue. The rework still happens. The RPA investment is $2M. The process improvement cost would have been $0.
The automation made the wrong things happen faster. That is not an automation failure. That is a sequencing failure.
Compare this with the Kuwait bank approach. The procurement team did not start with automation. They started by mapping the process: 23 steps, 139 days, 8 approval layers (3 of which approved the same risk threshold). They applied DMAIC over 14 weeks. Result: 12 steps, 57 days, 59% cycle time reduction. No technology investment required for the improvement phase.
The automation conversation happened after the improvement was measured and stabilized. The automation business case was credible because the baseline data existed. The ROI was attributable because the process improvement saving was already documented separately.
80% of Black Belt time goes to documentation rather than improvement. When the documentation overhead is removed (ESSAM captures a process baseline in 40 minutes through structured AI conversation), the improvement work can happen before the automation investment, not after.
What pilot purgatory actually costs
The term "pilot purgatory" sounds abstract. The cost is not.
A bank running 3 automation pilots simultaneously at $500K-$800K each is consuming $1.5M-$2.4M in capital expenditure that produces no measurable operational outcome. The pilots work technically. They do not scale because the underlying processes were never improved.
Meanwhile, the processes continue to cost 30% of annual revenue in waste. For a $500M bank, that is $150M per year in process cost that remains unaddressed while the automation programme searches for ROI.
The opportunity cost: that same 14-week period could have produced 3-5 process improvements at $0 technology cost, each delivering 40-70% cycle time reductions with measured, auditable savings. Kuwait bank's procurement improvement alone saved $334K per year. Multiply that across 5 processes and the annual saving exceeds the total automation pilot budget.
The exit from pilot purgatory is not better AI. It is the correct sequence: improve first, automate second.
The process readiness checklist
Before any automation investment, run these 5 checks:
-
Is the current cycle time measured? If no: establish a baseline first. You cannot attribute automation ROI without a measured starting point.
-
Have non-value-adding steps been identified and removed? If no: apply the E-S-S-A-M framework (Eliminate, Simplify, Standardize, Automate, Migrate) to the process first. Automating waste produces faster waste.
-
Is the SOP stable and followed by more than 80% of staff? If no: stabilize the process first. Automating a process that staff deviate from creates two systems running in parallel.
-
Is the process error rate below 5%? If no: reduce variation first. Automating a high-error process scales the errors.
-
Would automating this process give you a faster version of a good outcome? If yes: the process is ready for automation. If no: improve the outcome first.
If you answered "no" to any of the first four questions, process improvement comes before automation investment. This is not a philosophical position. It is an ROI protection measure.
Why "AI replaces process improvement" is wrong
A senior operations leader who tried AI automation described the outcome: "So far there has been very little use for AI and machine learning and it usually goes back to process improvement." This is not an AI failure story. It is a sequencing discovery.
AI automation and process improvement solve different problems:
| Process improvement | AI automation | |
|---|---|---|
| Solves | Waste, unnecessary steps, waiting, overprocessing, variation | Manual repetition, data entry, rule-based decisions |
| Requires | Understanding of the current process, root cause analysis | A clean, stable process to automate |
| Produces | Shorter cycle time, fewer errors, lower cost per execution | Faster execution of existing steps, reduced manual effort |
| Fails when | Applied without baseline data or shared urgency | Applied to a process that has not been improved first |
| Banking example | Kuwait bank: 23 steps reduced to 12, 139 days to 57 days | Post-improvement: 8 of 12 remaining manual steps automated |
The relationship is not "either/or." It is "first/then."
The sequence that gets automation out of pilot
The Kuwait bank did not start with automation. They started with process improvement. The ROI case built itself from the process data.
Step 1 — Baseline the process (week 1) Map the current state. Measure cycle time per step, error rate per step, and cost per execution. Document every handoff, approval, and queue. Identify who owns each step and how long each step takes (touch time vs. total elapsed time). ESSAM does this in 40 minutes through structured conversation with the process owner. The output: a complete process map with time and cost data attached to each step.
Step 2 — Improve the process (weeks 2-14) Apply DMAIC. Use the baseline data to identify non-value-adding steps. Eliminate overprocessing (approval layers that do not match risk level). Consolidate handoffs (3 departments reviewing the same document can become 1). Parallel-path steps that currently run sequentially without dependency. Kuwait bank result: 23 steps reduced to 12, approval layers from 8 to 4, cycle time from 139 days to 57 days. Cost: team time only. No technology investment.
Step 3 — Stabilize (weeks 15-18) Deploy the improved SOP. Track staff adoption (ESSAM WhatsApp deployment: 78% acknowledgment week 1, 94% by week 2). Monitor for drift at 30, 60, and 90 days. If the improvement holds at 90 days with less than 10% regression, the process is stable enough to automate.
Step 4 — Automate the improved process (week 19+) Now the process is clean, measured, and stable. The automation investment targets the remaining manual steps in a process that already works correctly. Typical automation targets at this stage: data entry between systems, rule-based routing decisions, notification triggers, document generation from templates. The ROI is attributable: process improvement saving (measured at step 2) + automation saving (measured incrementally at step 4). Both numbers are independently defensible.
The compounding effect Kuwait bank's process improvement delivered $334K annual saving. The subsequent automation of 8 remaining manual steps delivered an additional $89K. Combined annual saving: $423K. The automation ROI alone ($89K) would not have justified a $2M RPA platform investment. But deployed on a clean process with targeted scope, the automation cost was $45K (ESSAM subscription + configuration). Payback: 6 months.
The result: automation that scales because it automates a good process, not a broken one. And the total programme cost was a fraction of the automation-first approach.
7 signs your automation programme needs process improvement first
If any of these describe your current state, the process needs improvement before further automation investment:
-
The automation works but outcomes have not improved. Cycle time, error rate, and cost per execution are the same as before automation. The automation is executing the wrong steps faster.
-
You cannot produce an ROI number the CFO accepts. If the business case for the automation programme relies on projected savings that have not materialized, the attribution problem exists. Baseline data is missing.
-
Staff are working around the automation. The process has deviated from what was automated. Staff created manual workarounds because the automated process does not match reality. This is a process stability problem, not a technology problem.
-
The same errors keep recurring despite automation. Automation does not fix root causes. If the error rate is unchanged, the process design is producing the errors. Automation just routes them faster.
-
Multiple pilots, no scale. If you have 3+ automation pilots that have been running for 12+ months without scaling to production, the underlying processes are not ready for automation. They need improvement first.
-
The process has more than 30 steps. Any process with 30+ steps almost certainly contains non-value-adding steps that should be eliminated before automation. Automating a 47-step process locks in the complexity.
-
Nobody can explain why certain steps exist. If the process contains steps that no current team member can justify, those steps are candidates for elimination, not automation. Automating institutional legacy without understanding it is expensive preservation of waste.
If 3 or more of these apply, pause the automation investment. Run the process readiness checklist. Improve first, then return to automation with a clean target.
The CFO conversation
The automation-first pitch to the CFO: "We believe this RPA investment will save time and reduce manual effort." The CFO asks: "How will we measure that?" No credible answer exists because no baseline was established.
The process-first pitch: "This process currently costs $567K per year in constraint-cost. We reduced it to $232K through process improvement (59% reduction, measured and auditable). The automation layer on the improved process will reduce it further to $165K. Total combined saving: $402K per year, every number traceable to source data."
One pitch gets approved. One stays in pilot.
What AI automation actually does well (when sequenced correctly)
This is not an anti-automation argument. AI automation is powerful when applied to the right target:
What automation solves: Manual data entry between systems, rule-based decision routing, document classification and extraction, notification and escalation triggers, report generation from structured data.
What automation does not solve: Unnecessary process steps, approval layers that do not match risk level, and handoffs that could be consolidated. It also cannot fix waiting time caused by process design or variation caused by unclear SOPs.
The diagnostic is straightforward. If the problem is "humans are doing repetitive work that follows clear rules," automation is the answer. If the problem is "the process itself is producing wrong or slow outcomes," improvement is the answer.
Most banking processes need both. The question is not "which one?" The question is "which one first?" The answer is always improvement, then automation. The improved process gives automation a clean target. The clean target gives the automation programme a credible ROI.
The 30% revenue number and where it hides
$3 trillion in global process inefficiency. 30% of annual revenue lost to broken processes in the average mid-size bank. These numbers persist year after year because the automation programmes target the wrong layer.
Automating a loan origination process that takes 47 days does not address the $150M in annual process waste for a $500M bank. It addresses the labour cost of the manual steps within that process. Those manual steps might represent 10% of the total waste. The other 90% is waiting, overprocessing, unnecessary approvals, and rework that automation cannot touch because the process design creates them.
Process improvement addresses the 90%. Automation addresses the 10%. The correct sequence captures both. The wrong sequence captures neither credibly.
Frequently Asked Questions
Should we automate before or after improving processes?
After. Automating before improving means you are automating waste, unnecessary steps, and broken handoffs at machine speed. The 5-question process readiness checklist determines whether the process is ready for automation. If any of the first four checks return "no," improve first.
Can AI automation replace process improvement entirely?
No. They solve different problems. Process improvement eliminates waste, reduces variation, and creates flow. AI automation executes remaining manual steps faster. A process that has not been improved first will produce the same wrong outcomes, just faster. The relationship is sequential, not substitutional.
How do we know when a process is ready to automate?
When it passes all 5 readiness checks: cycle time is measured, non-value-adding steps are removed, the SOP is followed by more than 80% of staff, and error rate is below 5%. The final check: automating would produce a faster version of a good outcome. Failing any of the first four means improvement comes before automation.
What is the difference between RPA and process improvement?
RPA (Robotic Process Automation) automates existing manual steps without changing the process design. Process improvement changes the process design itself, eliminating steps, reducing waiting, and removing waste. RPA makes the current process faster. Process improvement makes the current process better. The optimal sequence: improve first, then automate what remains.
Why are APAC banks stuck in automation pilot purgatory?
Because they automated processes that needed improving first. The automation works technically but produces wrong outcomes operationally. The ROI is unattributable because no baseline was established before the automation investment. The exit from pilot purgatory: baseline the process, improve it, stabilize it, then automate the improved version.
Related reading: