139 days. That is how long a Kuwait-based bank's procurement cycle ran before it mapped the actual work — not the ideal workflow on a slide deck, but the real sequence of handoffs, approvals, and waiting time that consumed staff-hours every week. After Abdulla Al-Awadi, the bank's then-Chief Strategy Officer, applied a structured improvement discipline to that single process, the cycle fell to 57 days: a 59% reduction, 82 days retired. No new enterprise software platform was procured. The discipline came first.
That gap — between buying BPM software and actually doing business process management — is the source of most wasted IT budget in banking operations today. The two things share a name, but they are not the same thing. Conflating them is how ops leaders end up with a platform license, a consulting invoice, and the same cycle times they started with.
The discipline that software cannot replace
Business process management, as a discipline, is the structured, repeating practice of identifying how work actually flows, measuring where it loses value, redesigning it, deploying the new design to the people who run it, and repeating the cycle. It is not a one-time modeling exercise. It is not a diagramming deliverable. It is continuous.
The discipline has five practical stages, regardless of which methodology label you apply:
- Baseline — Capture how the process actually runs today, with real timing data.
- Analyze — Identify where value is added versus where time is consumed without output.
- Optimize — Redesign to eliminate waste, simplify handoffs, and standardize the improved path.
- Deploy — Get the new design into the hands of the people running the process.
- Repeat — Measure again, because processes drift.
These five stages are iterative and sequential. Skipping step 1 (baseline) is the single most common reason process improvement projects underdeliver. You cannot measure a 59% improvement without knowing what 100% looked like.
BPM software — enterprise workflow platforms, modeling tools, low-code orchestration suites — is designed to support steps 3 and 4. It assumes the analysis is done and the process design is approved. It is a deployment and enforcement layer, not a discovery layer. When ops teams use it as a discovery layer, they are building infrastructure on an unexamined foundation.
Why banks buy the software before doing the discipline
The sales motion for enterprise workflow platforms is well-funded and persuasive. A platform demo shows a clean, draggable flowchart, role-based task routing, audit trails, and SLA dashboards. It looks like process improvement. The trouble is that those features only add value once the process has been improved. Before that point, they automate the waste.
Abdulla Al-Awadi observed this pattern repeatedly during his time as a bank executive. Teams would invest in a BPM platform, spend months mapping the as-is process into the tool, and emerge with a digitized version of the same slow process they started with — now embedded in expensive software. The root issue was never the tool. It was the absence of the disciplined waste-finding step that should have preceded the tool decision.
This is not a criticism of any specific platform category. Well-implemented workflow orchestration delivers genuine value. The sequencing is the problem: buying the software before running the discipline is the banking equivalent of buying a warehouse management system before auditing your inventory.
What the discipline looks like in practice: the E-S-S-A-M framework
ESSAM operationalizes BPM as a discipline through the E-S-S-A-M methodology: Eliminate waste, Simplify & Standardize, Automate, Migrate low-value work. The sequence matters. Elimination comes before automation because automating a wasteful step makes it faster and more reliable — and more wasteful.
The Kuwait bank procurement case illustrates the sequence directly. The initial instinct was to document the existing 139-day process and then select a platform to manage it. Conversational process capture — the baseline step — surfaced staff-to-staff variance that no existing system had recorded. Analysts in the same team were completing the same tasks through different paths, with different document requirements, at different speeds. That variance was the waste. Eliminating it, simplifying the remaining steps, and standardizing the approved path shrank the cycle by 82 days before any orchestration decision was finalized.
The E-S-S-A-M sequence provides a decision gate at each step:
- Eliminate: Does this step need to exist at all? If not, remove it.
- Simplify & Standardize: Can this step run consistently with fewer inputs, fewer decisions, fewer handoffs? Document that version.
- Automate: Now that the step is clean, can a rule execute it without human judgment? If yes, automate.
- Migrate: Can this step be absorbed by a different team, an external service, or a self-service layer?
A step that fails the Eliminate test should not reach Automate. This gate structure is what prevents digitizing waste.
The 7-step improvement cycle that makes discipline repeatable
Discipline without structure drifts. ESSAM's 7-step improvement cycle provides the repeating frame that prevents process improvement from being a one-time project:
- Baseline
- Analyze (calculate cycle time: value vs non-value)
- Optimize (apply E-S-S-A-M to the analyzed waste)
- Document (generate the approved SOP)
- Deploy (get the SOP to the staff who run the process)
- Feedback (capture variance and drift)
- Repeat
Step 2 — calculating cycle time as value versus non-value time — is the measurement most teams skip under time pressure. It is also the step that makes the improvement provable. The 139-day baseline made the 57-day result auditable to a board. A team that skips the baseline has an improvement story; a team that records it has evidence.
Step 5 is where the discipline-vs-software gap shows up most clearly in banking ops. Traditional BPM platform deployments require staff to log into a new system, learn a new interface, and change their workflow tools. ESSAM deploys approved SOPs via WhatsApp — a channel with approximately 88% penetration in Singapore and 92% in Malaysia (external industry data). Staff receive the improved process through a tool they already use every day, with no installation, no training session, and no change-management program. The improved design reaches the people running the process on the day it is approved.
How to diagnose whether you have a discipline gap or a software gap
Banking ops teams are rarely starting from zero. Most have some combination of existing workflow tools, documented processes (even if outdated), and a BPM or low-code platform that was purchased for a specific use case. The question is not usually "should we buy BPM software?" It is "why isn't our existing setup producing the outcomes we expected?"
There are 4 diagnostic signals that indicate a discipline gap rather than a software gap:
Signal 1: Your cycle times are unmeasured or inconsistent. If you cannot state the average cycle time for a core process — and the range of variation around that average — you have not run the baseline step. The software cannot supply this. It records activity in the system; it does not capture the time spent in handoffs, email queues, or informal decision loops outside the system. A discipline gap is almost always a baseline gap first.
Signal 2: The same process runs differently across your team. If 3 analysts handle the same process type in 3 different ways, your documentation is decorative. Standard operating procedures that exist but are not followed indicate a deployment failure, not a documentation failure. The discipline requires capturing the variance, understanding why it exists, and designing it out — before standardizing the approved path and deploying it in a way staff will actually use.
Signal 3: Your process improvement projects produce reports, not results. A workshop that produces a map, a consultant engagement that produces a recommendations deck, and a BPM modeling project that produces a set of diagrams — all of these are symptoms of discipline without deployment. The improvement cycle is incomplete if it stops at "documented." Step 5 of the 7-step cycle — deploy — is where the result lives.
Signal 4: The same problems recur after improvement projects. Process debt accumulates when improvements are not maintained. If your team fixes a process in a workshop and the same issues reappear 6 months later, the feedback and repeat steps (steps 6 and 7 of the 7-step cycle) were skipped. Software can automate a process, but it cannot enforce the discipline of reviewing drift and updating the standard.
If 2 or more of these signals are present, a software investment will not close the gap. The discipline runs first.
When BPM software becomes the right decision
BPM software is the right decision after the discipline has been run, not before. A process that has been Eliminated, Simplified, Standardized, and optimized for Automation is a strong candidate for a workflow orchestration platform. At that point:
- The process design is clean and stable.
- The handoffs are defined and bounded.
- The automation rules are unambiguous.
- The before/after comparison provides a baseline for measuring platform ROI.
Buying the platform at this stage makes economic sense. The platform is enforcing a proven design, not encoding an unexamined one.
The corollary is that the discipline itself can be run without any BPM platform. The Kuwait bank's 59% result was achieved through conversational process capture, waste analysis, E-S-S-A-M redesign, and WhatsApp SOP deployment. The workflow platform conversation happened after the outcome was visible, not before it.
Where this frame does not apply
For processes that are already optimized and simply need to scale — high-volume, rules-based transaction processing, for example — an orchestration platform is often the right first move. The discipline-first principle applies most forcefully to processes with high variance, ambiguous ownership, and unexamined handoffs: exactly the profile of most banking back-office work.
If your process is running consistently, hitting its targets, and the only constraint is throughput, scaling the platform is reasonable. If your process has unmeasured cycle time, staff-to-staff variance, or recurring rework loops, the discipline should precede any technology investment.
It is also worth noting that ESSAM accelerates expert work; it does not replace human judgment or mandatory controls. In regulated banking environments in Singapore and Malaysia, compliance controls and governance sign-offs remain human decisions. The discipline identifies and removes the non-value time around those controls — the waiting, re-routing, and rework that sits between mandatory checkpoints, not the checkpoints themselves.
Start with one process, not a platform decision
If you are weighing a BPM platform investment, describe one process that is currently costing you cycle time or staff-hours. Share the steps, the handoffs, and the pain points with the ESSAM team. You will receive a baseline analysis, a waste map identifying Eliminate and Simplify opportunities, and a redesigned SOP — before any platform discussion begins.
That is the discipline sequence applied to a single process. The baseline and waste map will tell you whether a platform investment makes sense for that process and, if so, exactly what it should enforce. The platform decision becomes a consequence of the discipline, not a substitute for it.
ESSAM is ISO 27001:2022 certified, GDPR-compliant, and SOC 2 Type II certified — built for the data-handling requirements of regulated banking environments in Singapore and Malaysia. The entry point is $40 per month.
That is the discipline sequence in a single engagement. Start there.
Send your process to the ESSAM team
Frequently asked questions
What is the difference between BPM as a discipline and BPM software?
BPM as a discipline is the structured practice of identifying, measuring, improving, and repeating process change across an organization. BPM software is a category of tools — workflow orchestration platforms, modeling environments, low-code task routers — designed to deploy and enforce an already-improved process design. The discipline precedes the software decision; the software amplifies a design that the discipline has validated.
Why do BPM software implementations often fail to improve cycle times?
Most implementations begin with modeling the existing ("as-is") process rather than analyzing its waste. The software then digitizes and enforces the current state — including its handoffs, rework loops, and variance. The result is a faster, more visible version of an unimproved process. Improvement requires the waste-finding discipline first.
What is the E-S-S-A-M framework and how does it relate to BPM?
E-S-S-A-M — Eliminate, Simplify & Standardize, Automate, Migrate — is a structured improvement methodology that operationalizes BPM as a discipline. It provides a decision gate at each step: waste is eliminated before steps are automated, and the approved design is standardized before deployment. This sequence prevents teams from automating non-value steps.
How long does it take to run the BPM discipline on a single process?
A single process baseline and waste analysis can be completed in one session using conversational process capture — no flowchart software, no IT team involvement, no specialist required. The Kuwait bank procurement baseline that preceded a 59% cycle-time reduction was captured conversationally. Documentation and SOP generation follow the analysis step.
How does ESSAM deploy an improved process to banking operations staff?
ESSAM deploys approved SOPs via WhatsApp, which carries approximately 88% penetration in Singapore and 92% in Malaysia (external industry data). Staff receive the improved process through a channel they already use, requiring no new software installation, no training session, and no change-management program. Deployment happens on the day the design is approved.
Related reading: