As-Is Process Mapping in Six Steps Before Any Change

Map the Process Before You Change It

Gartner finds a 46% gap between how processes are thought to run and how they really run. As-is process mapping closes it before any change.

Alexander Kiel

Business Analyst · Banking & Wealth Management

15.05.2025 · 6 MIN READ · PROCESS OPTIMISATION

ON THIS PAGE

1. Set the Boundaries

2. Walk the As-Is Process

3. Draw the Handoffs

4. Measure Each Step

5. Find the Root Cause

6. Change One Step at a Time

Sample case: Siemens

In short

FAQ

Most process changes start with a picture of the process that does not match reality. Gartner research director Marc Kerremans puts it in numbers: a 46% gap between how businesses believe processes are carried out and how they are done in practice. As-is process mapping closes that gap before anything is changed.

Visibility is rare. In a Forrester survey of 818 decision-makers commissioned by Celonis, only 16% said they have complete visibility into their processes. The same survey found that 71% use ten or more applications to execute a single process. Change built on that picture often fails. In a McKinsey survey of 1,946 executives, just 26% said their transformations had been very or completely successful.

In banking, the cost of a wrong picture is higher. A client onboarding, a payment run or a migration touches several teams, systems and controls. Do you know how your most important process really runs today?

As-is process mapping compared with the designed process: request, check, approve and execute as designed, against extra steps for missing data, a second check and an email to operations, with a rework loop

STEP 1

Set the Boundaries

A process map needs a clear start and end. Define the trigger, the final output, the customer of the process and the owner who can decide on changes. Without these boundaries, a mapping workshop turns into a discussion about the whole organisation.

Regulation gives banks an extra reason to be precise. Under DORA, financial entities shall identify, classify and adequately document all ICT supported business functions. They must also document the assets and dependencies behind them and review this at least once a year. A well-scoped process map is a direct input for that documentation.

✓

Name the trigger, the output and the customer of the process

✓

Appoint one process owner with authority to change it

✓

Agree what is out of scope before the first workshop

Where exactly does your process start and who decides when it changes?

Keep in mind: A scope that covers everything produces a map nobody can use. Start with one process and one product.

STEP 2

Walk the As-Is Process

Map the process where the work is done, not in a meeting room. Lean practitioners call this going to the gemba. The Lean Enterprise Institute describes the aim of a value stream map as creating a shared understanding of a process, built by observation and by talking to the people who do the work.

Follow one real case from trigger to output: a client file, a payment or a change request. Note every step, every wait and every workaround. The procedure manual shows the process as designed. The people doing the work show the process as it runs. When I walked processes with the people doing them, the real process rarely matched the documented one; the gaps were workarounds built to meet deadlines.

✓

Follow real cases instead of the written procedure

✓

Interview the people who do the work at each step

✓

Record workarounds, spreadsheets and side channels

When did your management team last follow a single case through the whole process?

Keep in mind: People describe the process they think they should follow. Ask them to show you the last case they handled.

STEP 3

Draw the Handoffs

Most delays sit between steps, not inside them. Swimlane maps show who does what and where work moves from one team or system to the next. Each handoff is a point where information is lost, re-entered or left waiting in a queue. A good map uses simple, consistent symbols.

The Forrester survey found that 71% of organisations use ten or more applications to execute a single process. Every switch between applications is a handoff, even when the same person does both steps.

✓

Draw one swimlane per team or role involved

✓

Mark each system used and every manual re-entry of data

✓

Highlight handoffs by email, phone or shared drives

How many times does a single case change hands before it is complete?

Keep in mind: Handoffs to Compliance or Risk are often left off the map. They are frequently where the longest waits are.

STEP 4

Measure Each Step

A map without numbers shows where work goes but not where time is lost. Measure for each step how long the work takes, how long the case waits and how often it comes back. The difference between total lead time and actual working time is usually the largest improvement potential.

Data is often available already. Workflow tools, ticket systems and core banking logs record when each case enters and leaves a step. Process mining tools use this data to rebuild the real process automatically. Forrester found that 53% of organisations use process data that is more than one day old, so check how current your figures are.

✓

Measure working time, waiting time and rework per step

✓

Use system logs to check the times people estimate

✓

Count how many cases go through without any rework

What share of your cases runs from start to end without a single correction?

Keep in mind: Averages hide problems. Look at the slowest 10% of cases, as they often show the real causes.

STEP 5

Find the Root Cause

A map shows symptoms: a queue, a loop, a repeated check. The cause often lies elsewhere, such as missing data at the start of the process or an unclear rule. The Institute for Healthcare Improvement describes the 5 Whys as a method to ask "Why?" five times until you reach the root cause.

Apply it to the steps with the most rework or waiting time. A rework loop in a credit check may come from an incomplete client form, which in turn comes from a sales process with no mandatory fields. My article on finding the bottleneck in bank operations shows how to find the step that limits the whole process.

✓

Pick the three steps with the most rework or waiting time

✓

Ask why until the answer points to a cause you can change

✓

Test each cause against data from the map

Are you fixing the step that fails or the step that causes the failure?

Keep in mind: A problem can have more than one root cause. Stop asking why when the answer leads to an action, not after exactly five questions.

STEP 6

Change One Step at a Time

With the current state mapped and measured, design the target process. Remove steps that add no value, reduce handoffs and fix the root causes first. Then change one part of the process, measure the result against the baseline and continue with the next. My article on simplifying the process before you automate shows which steps to remove first.

In the McKinsey survey, respondents whose organisations held daily discussions of results were twice as likely to report success. The as-is map provides the baseline those results are measured against.

✓

Fix root causes before automating any step

✓

Pilot each change on a small number of cases

✓

Compare lead time and rework with the baseline from the map

Could you prove with numbers that your last process change worked?

Keep in mind: Automating a broken process makes the errors faster. Simplify first, then automate.

Got a Wicked Problem? First, Tell Me How You Make Toast | Tom Wujec (Fellow @ Autodesk)

SAMPLE CASE

Siemens

Siemens has around 385,000 employees and customers who order about 30 million items a year. Between order entry and cash collection there can be up to 60 process steps, about 300 million activities and 923,000 process variants. Former CEO Joe Kaeser said that hardly any other topic frustrated him as much as this complexity.

Siemens first used process mining in its audit department in 2011. It later applied the method to order-to-cash, rebuilding the real process from system data. The team tracked three measures: automation rate, rework rate and a custom "Digital Fit Rate", which divides manual activities by sales order items.

The results were measurable. Siemens increased its automation rate by 24% and reduced rework by 11% globally, which removed about 10 million manual touches per year. Around 6,000 people now use the tool across logistics, finance, procurement and sales.

Key takeaway: Siemens did not start by redesigning order-to-cash. It first made the real process visible, agreed a small set of measures and then improved the steps that caused rework.

"If you can't describe what you are doing as a process, you don't know what you're doing."

W. Edwards Deming (Statistician and Management Consultant)

In Short

Every process change rests on an assumption about how the work is done today. As-is process mapping tests that assumption before money and time are spent on the wrong problem.

Organisations that set clear boundaries, walk the real process, measure each step and fix root causes first can change processes with far less risk. The map is not the goal, but it is the baseline for every result that follows.

Frequently Asked Questions

What is the difference between as-is process mapping and process mining?

Process mapping documents a process through observation, interviews and workshops. Process mining rebuilds the process automatically from system logs, showing every variant and its timing. Both methods work best together. A map captures steps outside the systems, such as emails and phone calls, while process mining at Siemens showed hundreds of thousands of process variants that no workshop could reveal.

How detailed should a process map be?

Detailed enough to show every handoff, wait and decision, but not every keystroke. A good test is whether someone outside the team can follow a real case using the map. Start at a high level for the whole process, then add detail only where measurements show long waits or rework. Too much detail slows the work and hides the main problems.

How long does it take to map a process?

There is no fixed duration, as it depends on scope, the number of teams involved and the data available. A single, well-bounded process can often be mapped in a few workshops and case walks. Larger processes across several teams and systems take longer. Using system logs where available reduces the effort and gives a more reliable baseline than estimates made in workshops.