Bad processes cost the average organization an estimated 30% of annual revenue—yet robotic process automation (RPA) has been sold as the primary cure for nearly a decade. The gap between that promise and those costs tells you something important about the category.
RPA means software that mimics user-interface actions: clicking, copying, pasting, and submitting data across applications without integrating those applications at the code level. A bot watches what a human operator does and repeats it at machine speed. That is the honest definition. It is narrower than most vendor pitches suggest.
The distinction matters in banking operations. Singapore and Malaysian banks have deployed thousands of bots across KYC onboarding, reconciliation, trade confirmation, and loan-servicing workflows. Most teams report initial wins. Most teams also report a maintenance problem that emerges 12 to 18 months in—one that grows until it consumes the budget that was supposed to fund new automation.
This post defines what RPA actually is, where it fits inside a structured improvement methodology, and what happens when organizations automate before they engineer.
The category error at the center of most RPA programs
RPA captures the current state of work at the interface layer. It records which fields a human fills in, in which order, using which applications. What it does not capture is why those steps exist, whether they add value, or whether the process they belong to is well designed.
When a bank deploys a bot on a poorly designed process, the bot executes the poorly designed process faster. Throughput metrics improve. The underlying inefficiency stays, now moving at machine speed. Exception rates persist. Compliance flags accumulate. The rework that used to happen slowly now needs to happen quickly.
RPA programs running 50 or more concurrent bots typically see maintenance costs climb significantly after year one. Teams spend engineering capacity fixing bots that break when upstream systems change, rather than building improvements. A new vendor portal, a renamed data field, a regulatory-driven form update: each one is a bot outage.
Process mining platforms—tools that analyze historical system event logs to show where processes deviate from their intended paths—address the diagnostic side of this. That is useful work. But diagnostic tools tell you what is broken; they do not redesign it. Bots execute the current state; they do not improve it.
The category that does fix process problems is process engineering: structured analysis, redesign, and standardization of how work flows—before any automation is applied. This is the step most RPA programs skip.
What RPA does well and where it stops
RPA is suited to work that is high volume, low variance, rules-defined, and stable. Interface-layer access to legacy core banking systems, older insurance platforms, and government regulatory-reporting portals is often not available via API. Bots fill that gap at a cost that is difficult to match with custom integration work.
RPA breaks down when process variance is high, when upstream systems change frequently, when the process contains embedded waste, or when judgment is required mid-process. Bots cannot evaluate context; they execute instructions. When a case falls outside the script, the bot stops and raises an exception.
The line between those two conditions is where most banking operations sit: partial automation wins alongside persistent exception queues and rising maintenance overhead. Recognizing which side of that line each process belongs on is an engineering question, not a technology question.
There is a third failure mode. When a bank deploys RPA before standardizing the process, the bot locks in whatever variance, workarounds, and undocumented exceptions currently exist. The process cannot be improved without decommissioning the bot first. The automation becomes a barrier to the very improvement it was supposed to support.
The E-S-S-A-M framework: where RPA fits in the sequence
The E-S-S-A-M framework—which stands for Eliminate waste, Simplify & Standardize, Automate, Migrate low-value work—is a five-stage framework for process improvement. Each stage has a distinct function, and the sequence is not arbitrary.
Eliminate is the starting point. Before any automation discussion, the team maps what actually happens in the process—not what the standard operating procedure says happens, but what operators do in practice. Duplicate approvals, redundant data entry, handoffs that exist for historical rather than business reasons: all of these are removal candidates. Eliminating waste requires no technology. It requires accurate documentation and the authority to act on it.
Simplify & Standardize follows. Processes operated by different teams over different years develop variance—workarounds, informal paths, exceptions that became routine. Simplifying means reducing that variance before it is automated. Standardizing means documenting the agreed path so that every operator follows the same steps, in the same order, using the same decision rules. A standardized process is an automatable process.
Automate is the third stage—and only the third. When a process has been stripped of waste and standardized, automation is applied to what remains. The automation might be RPA, workflow triggers, API integrations, or agentic systems depending on the nature of the work. The point is that automation is locking in a clean, engineered process, not a fragile one.
Migrate addresses the residual. Low-value judgment tasks—status checks, simple escalation decisions, look-up routines—are moved toward systems that handle them adaptively rather than through fixed scripts.
RPA belongs in the Automate stage. It is a valid and cost-effective tool there. It is not a substitute for the Eliminate and Simplify & Standardize stages that must precede it.
When organizations jump straight to Automate—as many do, because it is visible, measurable, and well-supported by vendors—they automate the current state, waste included. The bot works. The process still costs 30% more than it should. Vendors rarely flag this, because their revenue is tied to deployment volume, not process outcomes. The sequencing discipline has to come from inside the organization.
Evidence: what process engineering achieved before any new bots were deployed
A Kuwait bank's procurement approval process averaged 139 days from requisition to vendor payment. The team had automation tools in place at several steps. Cycle time remained well above industry norms because the automation was sitting on top of an unengineered process.
Abdulla Al-Awadi, founder of ESSAM and former Chief Strategy Officer at that bank, led a structured process engineering engagement. The team applied Eliminate and Simplify & Standardize before deploying any additional automation. What they found: 14 approval stages, several reviewing the same information already cleared at earlier stages; 6 redundant data-entry points; no standardized vendor onboarding path, so each new supplier relationship generated a fresh set of exceptions.
After removing the waste and standardizing the remaining process, cycle time fell from 139 days to 57 days. That is an 82-day reduction—a 59% decrease. The overall efficiency improvement measured 106.9%.
No new bots produced that result. The gains came from engineering the process. Automation then locked in those gains.
This is the sequence. It is not a criticism of automation. It is a clarification of what automation can and cannot achieve on its own.
The Kuwait result is the only real client case ESSAM publishes. Other scenarios in ESSAM materials are labeled hypothetical or illustrative. The principle it demonstrates—that process engineering precedes automation in an effective improvement program—is consistent with what Lean and Six Sigma practitioners have documented for decades. Over 10,000 Lean Six Sigma professionals currently rely on ESSAM, applying that same principle through a modern, conversational interface.
How to audit your current RPA program
Four diagnostic questions reveal whether the underlying processes in your program were engineered before automation was applied.
What percentage of your RPA budget goes to maintenance versus new development? A well-structured program runs roughly 70 to 80% on new development and 20 to 30% on maintenance. When maintenance consumes more than 40% of the budget, it signals that bots are running on fragile, unstandardized processes.
What is your bot exception rate? If bots are raising exceptions on more than 10% of transactions, the process has more variance than the script can handle. Engineering the exception paths is the correct response—not adding more exception-handling logic to the bot.
How often do bots break when upstream systems change? A bot that breaks when a field is renamed or a portal refreshes is brittle by design. Fragility is a structural property of UI-layer automation operating on unstandardized processes. It cannot be patched away permanently. The only durable fix is engineering the process before the bot is deployed—so that interface stability is a design requirement, not an assumption.
Do your bots have documented SLAs with fallback procedures? If a bot goes down, how long before the backup human process becomes the default? Bots without SLAs and fallback plans are undocumented liabilities in your operational resilience framework—relevant in any MAS or BNM audit.
Use ESSAM's process cost calculator at https://essam.ai/tools/process-cost-calculator to quantify the fully loaded cost of your current bot exception rate. For most programs, the number exceeds what the team expects.
How agentic process engineering differs from RPA
RPA platforms execute fixed scripts at the interface layer. ESSAM operates differently: it baselines a process through conversation, identifies waste against the E-S-S-A-M framework, generates a redesigned standard operating procedure, and deploys that SOP to operators through channels they already use.
WhatsApp penetration in Singapore stands at 88% and in Malaysia at 92%, according to external industry data. ESSAM deploys updated SOPs through those channels—the ones operators already have open. No training program, no IT rollout, no specialist tools required.
ESSAM is a process engineering platform, not a bot. It operates across the full 7-step improvement cycle: Baseline → Analyze → Optimize → Document → Deploy → Feedback → Repeat.
ESSAM also serves the Migrate stage directly. Routine judgment tasks—status checks, escalation routing, exception triage—can be handled by an agentic system that adapts to variance rather than breaking on it. This distinction matters as processes become less stable in response to regulatory change.
A second distinction: ESSAM's improvement cycle is continuous. RPA programs typically run in project waves—deploy a batch of bots, measure results, plan the next wave. Between waves, processes drift. The bots continue executing the old version. ESSAM's Feedback and Repeat stages mean the process model updates as operations change, and the deployed SOP reflects the current standard rather than the one documented 18 months ago. That gap between documentation and operational reality is where most improvement programs lose momentum.
Where this does not apply
RPA remains the right tool for stable, high-volume, interface-layer tasks in environments where API integration is not feasible. Trade-confirmation data entry into legacy systems, month-end reconciliation feeds, and regulatory-report submissions through government portals are common examples where RPA delivers durable value at a reasonable maintenance cost.
The argument in this post is not that RPA should be replaced. It is that RPA should be sequenced correctly—after Eliminate and Simplify & Standardize, not before them.
ESSAM accelerates expert process work. It does not replace compliance judgment, credit-decision authority, or the human review steps that regulators and internal risk frameworks require. That boundary matters in credit underwriting and AML workflows, where MAS and BNM frameworks mandate human accountability for final decisions. No automation platform does. The professionals who use ESSAM outputs remain responsible for what those outputs recommend.
Describe your process; ESSAM returns the baseline
You describe one process in plain language—what it does, who touches it, where it typically slows. ESSAM returns a baseline, a waste map, and a redesigned SOP. That is the input a well-sequenced automation deployment needs.
Share the process at apac.essam.ai/contact. No forms to fill, no specialist to brief—plain language is enough to start.
Frequently asked questions
What does RPA stand for?
RPA stands for robotic process automation. It refers to software that mimics user-interface actions—clicking, copying, pasting, entering data—across applications, without modifying those applications at the code level.
Is RPA the same as artificial intelligence?
Traditional RPA bots execute fixed, rule-based scripts. They do not learn, adapt, or make decisions. Some RPA platforms have added AI components for specific tasks such as document reading or intent classification, but the core execution model is rule-based. RPA and AI are distinct categories that can work together but are not interchangeable.
Why do RPA bots keep breaking?
Bots operate at the user-interface layer. When that interface changes—a renamed field, a new screen layout, an updated portal—the bot script breaks. This fragility is a design property of UI-layer automation, not a maintenance failure. The structural remedy is to standardize the underlying process so that interface changes are minimized, and to engineer exception paths rather than scripting around them.
When should a bank use RPA versus structured process engineering?
Apply process engineering first: eliminate waste, simplify, and standardize. Then apply RPA to the stable, clean result. RPA deployed before engineering locks in whatever inefficiency exists in the current state. The sequencing matters more than the tools selected.
How does ESSAM fit alongside an existing RPA program?
ESSAM handles the improvement stages before and after automation: baselining, waste identification, process redesign, SOP documentation, and continuous process health monitoring. RPA handles execution of stable, defined tasks at the interface layer. They serve different functions in the same improvement cycle. Teams that use ESSAM to engineer processes before deploying bots report lower maintenance costs and fewer bot failures over a 12-month horizon.
Related reading: