Why Current-State and Future-State Mapping Matters
Every process improvement begins with the same question: where are we now, and where do we want to be? In banking operations, the gap between those two states is where inefficiency, risk, and wasted effort live. Current-state mapping (also called as-is mapping) documents how a process actually operates today. Future-state mapping (also called to-be mapping) designs how the process should operate after improvements are made. Together, they form the analytical backbone of any transformation initiative.
The temptation in many banking projects is to skip the current-state analysis and jump straight to designing the future. This is a mistake. Without a disciplined understanding of how the process really works — including the workarounds, manual interventions, and undocumented steps that staff perform every day — the future-state design will be built on assumptions rather than evidence. The result is solutions that look elegant on paper but fail in practice because they did not account for the complexity that frontline teams deal with daily.
As-Is Process Mapping Methodology
Capturing the current state requires more than drawing boxes and arrows from memory. A rigorous as-is mapping exercise uses three complementary techniques to build an accurate picture.
Observation is the most powerful and most underused technique. Sit with the people who perform the process and watch what actually happens. In banking, this means observing a trade settlement analyst as they process a transaction from confirmation through to settlement, or watching a KYC analyst work through an onboarding case. Observation reveals steps that no one thinks to mention in interviews — the copy-paste from one system to another, the manual check of an email inbox, the phone call to a counterparty to confirm details that should be in the system. These hidden steps are often where the most significant waste lives.
Interviews with process participants, managers, and downstream consumers of the process output provide context that observation alone cannot capture. Ask open-ended questions: "What happens when this goes wrong?", "What do you do differently on month-end?", "Where do you spend most of your time waiting?" Interviews reveal exception paths, seasonal variations, and pain points that may not surface during a single observation session. Interview multiple people who perform the same role — you will often find that each has developed their own approach, highlighting a lack of standardisation.
Document review examines existing SOPs, desktop procedures, system documentation, and regulatory requirements. Compare what the documentation says should happen with what you observed and what interviewees described. The gaps between documented procedure and actual practice are among the most important findings in current-state analysis. In banking, these gaps frequently exist because processes evolved incrementally — a system change here, a regulatory update there — while the documentation lagged behind.
When constructing the as-is BPMN map, include every step you discover, even if it seems trivial or embarrassing. Mark manual interventions, handoffs between teams or systems, decision points, and especially wait times. Use BPMN timer events to indicate where work sits idle, and message events to show handoffs that depend on external parties. The goal is an honest, complete picture — not a sanitised version of reality.
Identifying Waste Using Lean Categories
Once you have a complete current-state map, the next step is to analyse it systematically for waste. Lean methodology identifies categories of waste that are directly applicable to banking operations.
Waiting is the most pervasive waste in financial services. Work queues for batch processing, transactions sit pending approval, reconciliation breaks wait for investigation. Every timer event on your BPMN map is a potential waiting waste. Ask: does this wait exist because of a genuine business requirement, or because of a process or system constraint that could be eliminated?
Rework occurs when defects in upstream steps force downstream teams to correct, re-process, or re-submit. In banking, rework is endemic — misbooked trades that need amendment, regulatory returns that fail validation and require correction, payment instructions that are rejected by the beneficiary bank and need re-instruction. On your BPMN map, look for loops that return to earlier steps, and error boundary events that trigger correction paths.
Over-processing means performing work beyond what is necessary. Dual data entry into multiple systems because they are not integrated. Manually formatting reports that could be generated automatically. Applying four levels of approval to a low-value, low-risk transaction. If a step exists only because "we have always done it that way," it is a candidate for elimination.
Handoffs between teams, systems, or departments are a major source of delay and error. Each handoff introduces the risk of miscommunication, data loss, and queue time. On a BPMN map, handoffs appear as message flows between pools or as task transitions between lanes. Minimising handoffs is one of the most reliable ways to reduce cycle time and error rates.
Value-Added vs Non-Value-Added Analysis
A structured way to evaluate every step on your current-state map is to classify it as value-added (VA), non-value-added (NVA), or necessary non-value-added (NNVA).
A step is value-added if it transforms the product or service in a way the customer would pay for, it is done right the first time, and the customer cares about it. In trade settlement, calculating the net settlement amount is value-added. The customer needs this to happen correctly.
A step is non-value-added if it exists only because of process inefficiency. Re-keying data, chasing missing information, correcting errors from upstream steps — none of these create value. They are candidates for elimination.
A step is necessary non-value-added if it adds no direct value to the customer but is required by regulation, risk management, or current technology constraints. Sanctions screening on a payment is required by law, even though the customer does not perceive it as adding value. These steps cannot be eliminated, but they can often be streamlined or automated.
Walk through every task on your as-is map and label it VA, NVA, or NNVA. In most banking processes, teams are surprised to find that only 20-30% of steps are truly value-added. The rest is waste and regulatory overhead.
Designing the To-Be Future State
With the current state documented and waste identified, you are ready to design the future-state process. The to-be map should directly address every source of waste and inefficiency identified in the as-is analysis. This is not a wish list — it is a disciplined redesign grounded in evidence.
Start by eliminating NVA steps entirely. Can the rework loops be prevented by fixing upstream quality? Can the manual data entry be replaced by system integration? Can the waiting time be removed by switching from batch to real-time processing?
Next, streamline NNVA steps. If sanctions screening is required, can it run in parallel with other checks rather than sequentially? Can compliance approvals be automated with rule-based logic for standard cases, reserving manual review for exceptions only?
Then optimise the remaining VA steps. Can handoffs be reduced by restructuring team responsibilities? Can decision gateways be simplified with clearer business rules? Can subprocesses be reused across similar products?
The future-state BPMN map should be complete and executable — not a vague sketch. Define the events, tasks, gateways, data flows, and exception paths with the same rigour you applied to the current state. This map becomes the specification for implementation.
Gap Analysis Between Current and Future State
The gap analysis formally documents the differences between as-is and to-be. For each gap, identify what changes are required — process changes, system changes, organisational changes, policy changes — and the dependencies between them. This analysis feeds directly into the implementation roadmap and helps stakeholders understand the scope and sequence of the transformation.
Banking Example: Trade Settlement Before and After T+1
Consider a bank preparing for the move from T+2 to T+1 settlement. The current-state map of the trade settlement process reveals the following: after trade execution, an operations analyst manually confirms trade details with the counterparty via email, typically taking 2-4 hours. Matched trades are then queued for a batch allocation run at 16:00. Settlement instructions are generated overnight and sent to the CSD the following morning. Exception trades — mismatches, missing SSIs — are investigated manually, often taking an additional day. Under T+2, there was enough buffer time to absorb these delays. Under T+1, there is not.
The as-is analysis identifies critical waste: the manual confirmation step (waiting and over-processing), the batch allocation (waiting), the overnight instruction generation (waiting), and the manual exception handling (rework). Value-added analysis reveals that only 25% of the cycle time is spent on steps that actually progress the trade toward settlement.
The future-state map redesigns the process for straight-through processing (STP). Trade confirmation is automated through an electronic matching platform, eliminating the email-based confirmation entirely. Allocation runs continuously in real time rather than in a single daily batch. Settlement instructions are generated and sent to the CSD within minutes of matching, not overnight. Exception handling is supported by an automated enrichment engine that resolves missing SSIs from a golden source database, with only genuine mismatches routed to human investigation.
The gap analysis identifies four required changes: implementation of an electronic matching platform, migration from batch to real-time allocation, automated instruction generation, and an SSI enrichment engine. Each change has dependencies and a sequenced implementation plan. The future-state map serves as the target architecture that guides every workstream.
In the next module, you will learn how to build a process repository, establish governance standards, and create documentation that meets the expectations of regulators and internal audit.