Process Mapping and Improvement: A Practical Guide for Business Analysts

Written by Jude Mahoney

Agile Delivery Lead | Business Analyst Mentor | 20 Years Experience

LinkedIn: Jude Mahoney

Process mapping is one of the most recognisable Business Analysis techniques. Put a few boxes on a page, connect them with arrows, add a decision diamond or two and you have something that looks convincingly like analysis, (to be fair, drawing boxes with lines attaching them together could also apply to solution architects, or if the lines are inside the boxes, UX experts). 

Unfortunately, producing a process map and analysing a process are not the same thing.

A beautifully drawn diagram can document an inefficient process perfectly without doing anything to improve it. Equally, a relatively simple process map sketched during a workshop can expose duplicated work, unnecessary approvals, poor hand-offs and system problems that have cost an organisation thousands of hours.

The value is not in the diagram itself. It is in what the diagram allows you and your stakeholders to see, question and change.

For a Business Analyst, a useful approach is:

1. Define the purpose → 2. Set the boundaries → 3. Identify the people involved → 4. Discover the real current process → 5. Map the AS-IS → 6. Analyse the process → 7. Find the root causes → 8. Design the TO-BE → 9. Validate the improvement → 10. Turn it into change

That final part is important. Process mapping should rarely end with an AS-IS diagram sitting in Confluence. The point is to understand how work happens today well enough to decide whether and how it should happen differently tomorrow.

1. Define why you are mapping the process

Before opening Visio, Miro, Lucidchart or whichever tool you use, establish why you are doing this.

“We need a process map” is not a particularly useful objective.

Why?

Perhaps customers are waiting too long. Perhaps costs are increasing. A team is making too many errors. A new system is being introduced. Nobody understands who owns part of a process. Different departments are performing the same task differently. A regulatory requirement has changed. An organisation wants to automate manual work.

The purpose affects the analysis.

Imagine an organisation tells you:

“We need to map our customer refund process.”

Start asking questions.

Why now? What appears to be wrong with it? Who is affected? Is there evidence of a problem? What outcome is the organisation trying to achieve?

You may discover that the actual concern is:

Customer refunds currently take an average of nine working days, generating complaints and avoidable contacts with Customer Service. The organisation wants to understand the causes of delay and determine whether the process can be reduced to three working days.

Now you have an analytical objective.

Output from this stage

You should be able to describe:

Problem → Reason for analysis → Desired outcome → Success measure

That gives your process map a purpose beyond documentation.

---

2. Define the boundaries before the map becomes enormous

Processes have an irritating habit of connecting to other processes.

Suppose you are mapping customer refunds. Where does the process begin?

When the customer decides they want a refund? When they contact the company? When the request is logged? When the returned item reaches the warehouse?

And where does it end?

When Finance approves the refund? When the payment provider processes it? When the money reaches the customer's account? When the customer receives confirmation?

There may not be one universally correct answer.

What matters is defining the boundary appropriate to the problem you are investigating.

A useful structure is:

Trigger → Process → Outcome

For example:

Trigger: Customer submits a valid refund request.
Process: Request is assessed, approved and processed.
Outcome: Refund is issued and customer is notified.

You may also want to identify what is explicitly out of scope (otherwise you can end up mapping the entire company!).

This prevents a two-hour workshop about refunds gradually turning into an analysis of the organisation's entire order-management platform.

3. Identify who actually performs the process

The person who owns a process is not necessarily the person who understands how it works.

This distinction matters enormously.

A senior manager might tell you:

“Customer Service verifies the request and sends it to Finance for approval.”

Someone doing the job every day may say:

“Yes, except we have to check the order system first, then copy the details into a spreadsheet, email the warehouse if the value is above £100 and wait for Finance to update another system before we can continue.”

Both people may be describing the same process from different perspectives.

Identify the people who:

• perform the work;

• make decisions;

• provide information;

• receive outputs;

• own systems involved;

• handle exceptions;

• manage or own the process;

• experience the process as customers or users.

For larger processes, stakeholder analysis or a simple RACI may help. For smaller pieces of work, a straightforward list may be enough.

The important thing is to involve the people who know what actually happens, not merely the people who know what is supposed to happen.

4. Discover the real AS-IS process

Now investigate the current state.

Do not begin by asking somebody to email you the existing process document and then redraw it.

Existing documentation can be useful, but it is evidence rather than truth.

Use interviews, workshops, observation, system walkthroughs, documentation, data and real examples to reconstruct what happens.

Start with the trigger and walk through the process in sequence.

At each stage ask questions such as: What happens next? Who does it? What information do they need? Which system do they use? How long does it take? What decision is being made? What happens if the answer is no? What happens when information is missing? Where does the work go next? What happens in unusual cases?

One particularly useful question is:

“Can you show me what you actually do?”

People naturally simplify processes when describing them from memory. Watching someone perform the task can reveal workarounds and additional steps they have stopped consciously noticing.

A stakeholder might say:

“Then I check the customer's details.”

Watching them do it reveals that they log into one system, copy an ID into another, download a document, compare two addresses manually and record the result in Excel.

That is considerably more useful information.

5. Map the AS-IS clearly

Once you understand the current process, represent it at a level appropriate to the analysis.

A basic process map might use:

• oval — start/end;

• rectangle — activity;

• diamond — decision;

• arrow — direction/flow.

A swimlane diagram can be particularly useful where a process crosses teams or roles because it makes hand-offs visible.

For example:

Customer Service	Operations	Finance
Receive request
Check customer details
Send request →	Review eligibility
	Send for approval →	Approve refund
	← Receive approval
Notify customer		Process payment

Even this simplified view raises questions.

Why does Finance need to approve every refund? Why does the request move backwards after approval? Who owns the process overall? What information is transferred at each hand-off? Where does the nine-day delay occur?

That is what a good map should do.

It should provoke questions.

How much detail should you include?

Enough to answer the problem you are investigating.

A map containing six boxes may be too high-level to expose anything useful. A map containing 400 boxes may be technically accurate but impossible for stakeholders to understand.

Start at a sensible level and drill down where the analysis requires it.

You can always create sub-processes for areas requiring more detail.

6. Analyse the process, not just the picture

This is where process mapping becomes process analysis.

Take each part of the AS-IS and challenge it.

A useful way to do this is to examine seven areas:

VALUE

Does this step actually contribute to the desired outcome?

Would the customer or organisation notice if it disappeared?

TIME

How long does the work take?

More importantly, how long does it wait before somebody does the work?

A five-minute activity sitting in a queue for three days is not really a five-minute part of the process.

HAND-OFFS

How many times does responsibility move between people, teams or systems?

Every hand-off creates an opportunity for delay, misunderstanding or lost information.

DUPLICATION

Is information entered, checked, approved or processed more than once?

Why?

DECISIONS AND APPROVALS

Who makes each decision?

What information do they use?

Does every case genuinely require approval?

SYSTEMS AND DATA

Which systems support the process?

Is information copied manually between them?

Are teams working from different versions of the same information?

EXCEPTIONS

What happens when the normal process doesn't work?

Sometimes the happy path is perfectly efficient while 30 per cent of cases fall into an exception route that takes five times longer.

That exception route may be the real process-improvement opportunity.

7. Look for the classic signs of process waste

You do not need to become a Lean Six Sigma specialist to recognise common process problems.

Look for things such as:

Waiting — work sitting untouched between activities.

Duplication — the same information being entered or checked multiple times.

Unnecessary hand-offs — work bouncing between teams.

Rework — correcting errors that could have been prevented earlier.

Over-processing — additional checks, documentation or approvals that add little value.

Manual work — repetitive activity that may be suitable for automation.

Bottlenecks — one activity or team restricting the whole process.

Workarounds — spreadsheets, emails or unofficial processes created because the formal system doesn't work properly.

Unclear ownership — nobody responsible for the process from beginning to end.

Inconsistent rules — different teams handling the same situation differently.

Poor information — missing or inaccurate data causing downstream problems.

One of the most revealing questions you can ask somebody performing a process is:

“Which part of this drives you mad?”

The answer is not automatically your solution, but it is often worth investigating.

8. Measure where you can

Process improvement becomes much stronger when you can support observations with evidence.

Suppose stakeholders tell you:

“Finance approval is the bottleneck.”

Check.

Perhaps Finance approval takes an average of four hours but requests wait for two days before reaching Finance because Operations only sends them in a daily batch.

Without data, the organisation might optimise the wrong part of the process.

Useful measures can include:

• total process time;

• actual processing time;

• waiting time;

• number of hand-offs;

• error rate;

• rework rate;

• volume;

• abandonment rate;

• cost per transaction;

• customer complaints;

• percentage following exception routes;

• number of manual interventions.

You don't need metrics for the sake of metrics.

Use data to test what people believe is happening.

9. Find the root cause before redesigning the process

Imagine you discover that 35 per cent of refund requests require rework.

You could add more people to handle the rework.

Or you could ask why it happens.

Perhaps customer information is incomplete.

Why?

Because the online form allows submission without a required reference number.

Why?

Because the validation rule was never implemented.

Now you have something very different from a staffing problem.

Techniques such as the Five Whys can help, but the principle is more important than the technique:

Do not confuse the visible symptom with the underlying cause.

This is closely related to gap analysis. Your process map may show you where the current state differs from what is needed; further analysis helps establish why that difference exists.

10. Design the TO-BE process

Once you understand the current process and the reasons behind its problems, you can begin designing the future state.

Do not simply redraw the AS-IS more neatly.

Challenge it.

Ask:

• Can this step be removed?

• Can two steps be combined?

• Can information be captured earlier?

• Can the process be simplified?

• Can a decision be automated?

• Does this approval still serve a useful purpose?

• Can a hand-off be eliminated?

• Can the same information be reused rather than re-entered?

• Can errors be prevented rather than corrected later?

• Can the user complete part of the process themselves?

• Can work happen in parallel rather than sequentially?

A useful improvement mindset is:

ELIMINATE → SIMPLIFY → STANDARDISE → AUTOMATE

The order matters.

Organisations sometimes automate inefficient processes when they should first ask whether parts of the process need to exist at all.

If somebody manually copies unnecessary information between two spreadsheets, automating the copying is an improvement.

Removing the unnecessary information may be better.

11. Don't assume automation equals improvement

Automation can be enormously valuable.

It can also allow an organisation to perform a bad process very efficiently.

Suppose every refund currently requires approval from a manager.

The obvious technology requirement might be:

“Automate the manager approval workflow.”

But further analysis reveals that the approval was introduced eight years ago after a fraud incident and that 99.7 per cent of refunds under £50 are approved without intervention.

A better future state might involve automatic approval below an agreed risk threshold, with only higher-risk cases requiring manual review.

The improvement comes from challenging the business rule.

Technology then enables it.

That distinction is important for Business Analysts because you should not merely translate existing processes into software requirements.

Sometimes your greatest contribution is asking whether the process should exist in its current form at all.

12. Compare the AS-IS and TO-BE

Once you have a proposed future process, compare it directly with the current one.

For example:

Area	AS-IS	TO-BE	Improvement
Data entry	Entered twice	Captured once	Remove duplication
Approval	Every refund manually approved	Risk-based approval	Reduce waiting
Customer updates	Manual email	Automatic status notification	Reduce service contacts
Ownership	Split across teams	Named process owner	Improve accountability
Exceptions	Handled through email	Defined exception workflow	Standardise handling
Processing	Sequential	Some activities parallel	Reduce elapsed time

This helps stakeholders understand that the TO-BE isn't simply a different-looking diagram.

It represents specific changes.

13. Test the TO-BE against real scenarios

A future-state process can look excellent when everybody discusses the ideal customer.

So test the awkward customers too.

What happens if information is missing? What happens if a system is unavailable? What happens if an approval fails? What happens if the customer changes their mind? What happens if two departments disagree? What happens with a high-risk transaction? What happens when the normal rule doesn't apply?

Walk real or realistic scenarios through the TO-BE.

This is particularly useful with the people who perform the current process because they often know the strange cases nobody else remembers.

If the future process only works when everything goes perfectly, it isn't finished.

14. Validate the improvement with stakeholders

The people who helped you understand the AS-IS should have the opportunity to challenge the TO-BE.

But validation needs to go wider than:

“Does everybody like the new diagram?”

Ask whether it addresses the original problem.

If the objective was reducing refunds from nine days to three, can the proposed process realistically achieve that?

Have important controls been preserved? Are new risks introduced? Is the process technically feasible? Are roles and responsibilities clear? Does Compliance agree? Can Operations actually work this way? Does the customer experience improve?

You are looking for a process that is better and workable, not merely theoretically elegant.

15. Turn process improvements into deliverable change

A TO-BE process map is not the end product.

The differences between AS-IS and TO-BE should feed into change.

Some changes may become software requirements or user stories. Others may involve new business rules, training, operating procedures, data improvements, role changes or removal of obsolete activities.

For example:

Process problem: Customers repeatedly telephone for refund updates.

TO-BE: Customers can see refund status without contacting Customer Service.

Requirement: Customers must be able to view the current status of an active refund request through their online account.

Or:

Process problem: Every refund requires manual approval.

TO-BE: Low-risk refunds are processed automatically.

Business rule: Refunds below the agreed value and risk threshold may proceed without manual approval.

Now the process analysis is influencing delivery.

That is where it starts creating value.

---

A Structured Process Mapping and Improvement Method

If you want a repeatable approach, use this:

Stage	Key question	Typical activity	Output
1. Purpose	Why are we analysing this?	Define problem/outcome	Objective
2. Boundaries	Where does the process start and finish?	Define trigger/scope/outcome	Process scope
3. People	Who performs or affects it?	Stakeholder analysis	Participants/owners
4. Discover	What actually happens?	Interviews, observation, data	Current-state evidence
5. Map AS-IS	How does work flow today?	Process/swimlane mapping	AS-IS map
6. Analyse	Where are the problems?	Waste, delay, hand-off analysis	Pain points
7. Root Cause	Why do those problems exist?	Five Whys/data/investigation	Root causes
8. Design TO-BE	How should it work?	Eliminate, simplify, standardise, automate	TO-BE map
9. Validate	Will it actually work?	Scenarios/stakeholder review	Validated future state
10. Deliver	What needs to change?	Requirements/change planning	Requirements/actions

In shorthand:

WHY? → SCOPE → DISCOVER → MAP → ANALYSE → CHALLENGE → IMPROVE → VALIDATE → DELIVER

That is considerably more useful than remembering which symbol means what.

---

A Worked Process Improvement Example

Imagine an insurance company is receiving complaints about the time taken to process straightforward claims.

The stated problem is:

“Claims take too long.”

Step 1: Understand the current process

The BA maps the AS-IS and discovers:

Claim submitted → Customer Service checks details → Claims team reviews → Missing information requested → Customer responds → Claims team rechecks → Manager approves → Finance processes payment → Customer notified

Average elapsed time: 12 working days.

Actual time spent actively working on a typical claim: approximately 90 minutes.

That immediately tells us something.

The process does not contain 12 days of work.

It contains 90 minutes of work spread across 12 days.

Step 2: Analyse where the time goes

Further investigation shows:

• 40% of claims arrive with missing information;

• requests wait an average of two days before initial review;

• every claim requires manager approval;

• information is manually copied between two systems;

• Finance processes payments in batches;

• customers frequently call for status updates.

The problem is not simply that employees work slowly.

The process itself creates delay.

Step 3: Investigate causes

Why is information frequently missing?

Because the online form does not require several pieces of information needed by Claims.

Why does every claim need manager approval?

Because the rule was introduced for all claims following an old fraud-control review.

Why are customers calling?

Because they cannot see what stage their claim has reached.

Now the opportunities are becoming clearer.

Step 4: Design the TO-BE

The future process might include:

• validating required information during submission;

• automatically routing complete claims;

• risk-based approval rather than universal manager approval;

• integration to reduce duplicate data entry;

• more frequent payment processing;

• automated status updates.

The TO-BE might become:

Claim submitted and validated → Risk assessed → Standard claim automatically routed → Claims review → Eligible claim approved → Payment processed → Customer automatically notified

Higher-risk cases follow a separate review path.

Step 5: Turn improvement into change

The analysis now produces tangible requirements, business-rule changes and technical investigations.

The organisation can also measure whether the new process achieves the original objective.

That is process improvement.

Not:

“We drew a swimlane diagram.”

---

Process Maps Business Analysts Should Understand

You do not need to use every modelling notation available. Different maps answer different questions.

Simple flowchart

Useful for straightforward processes and explaining sequence.

Swimlane diagram

Useful where activities move between different teams, roles or systems. Particularly good for exposing hand-offs and unclear ownership.

SIPOC

Supplier → Input → Process → Output → Customer

Useful for understanding a process at a high level before drilling into detail.

Value stream map

Useful when examining flow, waiting time and value across a broader process.

BPMN

Business Process Model and Notation provides a more formal standard for modelling complex business processes. It can be valuable where greater precision is needed, but don't use complexity merely to demonstrate that you know BPMN.

The best notation is the one that allows the people involved to understand and improve the process at the level required. There is no "best tool" only the right one for the job/time. 

A technically perfect diagram that your stakeholders cannot understand is of limited value.

---

Common Process Mapping Mistakes

Mapping the documented process instead of the real one. Existing procedures are useful, but they may describe what should happen rather than what does happen.

Going into too much detail too early. Start at a sensible level and drill down where necessary.

Mapping without a purpose. If nobody knows what decision the map is meant to support, you may simply be creating documentation.

Ignoring waiting time. The largest delays often occur between activities rather than during them.

Only mapping the happy path. Exceptions can account for a substantial proportion of cost and delay.

Assuming every problem needs technology. Process, policy, ownership and business rules may be the real issue.

Automating before simplifying. Remove unnecessary work before paying to automate it.

Designing the TO-BE without the people doing the work. The future state may look elegant while being impossible operationally.

Finishing with the diagram. If the analysis doesn't result in decisions, requirements or improvement activity, ask what value the map actually created.

---

A Practical Process Analysis Checklist

Before you finish, ask:

• Is the purpose of the analysis clear?

• Have I defined the process boundaries?

• Have I involved the people who actually perform the work?

• Does the AS-IS reflect reality rather than documentation alone?

• Have I identified the systems and data involved?

• Have I looked at hand-offs?

• Have I looked at waiting as well as processing time?

• Have I identified duplication and rework?

• Have I challenged approvals and business rules?

• Have I considered exceptions?

• Have I used evidence where it is available?

• Have I investigated root causes rather than symptoms?

• Have I eliminated unnecessary activity before considering automation?

• Does the TO-BE address the original problem?

• Have the right stakeholders validated it?

• Can the differences between AS-IS and TO-BE be converted into actual change?

If the final answer is no, you may have produced a process map.

You probably haven't completed the process analysis.

The Map Is Not the Analysis

Process mapping is powerful because it makes invisible work visible.

A conversation about a process can remain vague for hours. Put that process on a page and suddenly people can point to the same thing.

“Why does it go back to Finance there?”

“Why are we entering that twice?”

“Why does a manager need to approve this?”

“Why does this sit in a queue for two days?”

“Why do we still do that?”

Those questions are where the value begins.

A Business Analyst should therefore resist becoming the person who simply turns stakeholder conversations into attractive diagrams. Your job is to use those diagrams to create understanding, expose problems, challenge assumptions and help the organisation design something better.

Sometimes the improvement will be a new system.

Sometimes it will be automation.

Sometimes it will be removing three unnecessary steps, changing a business rule or giving one person clear ownership.

And occasionally the most valuable discovery is that the organisation should stop doing something altogether.

The map helps you see the process.

The analysis helps you improve it.

Developing Your Process Mapping and Improvement Skills

You can learn the symbols used in a process map in an afternoon. That does not make somebody good at process analysis.

The harder skill is sitting with people who each describe the same process differently, discovering what really happens, separating symptoms from root causes and deciding which parts of the process genuinely need to change.

That requires practice.

Elisto's Business Analyst training focuses on applying techniques such as process mapping to realistic Business Analysis problems rather than simply memorising terminology. The objective is not merely to know what an AS-IS and TO-BE process are, but to understand how you move intelligently from one to the other.

The Knowledge Hub can give you a structured approach.

The real capability comes from learning how to apply it when the process is messy, the stakeholders disagree and the obvious solution turns out not to be the right one.