As-Is and To-Be Process Analysis: Mapping Current and Future State

As-Is and To-Be Process Analysis: Mapping Current and Future State

As-is and to-be analysis compares how a process works today (the as-is state) with how it should work after improvement (the to-be state). The as-is-to-be process method has five steps: map the current process, validate it with the people who run it, design the future process, compare the two to find gaps, and turn each gap into a requirement or action.

Business analysts use it before system changes, automation projects, and process redesigns. It keeps teams from building solutions for a process nobody has actually documented.

Key Highlights: As-Is and To-Be Process Analysis

• Definition: The as-is state describes the process as it really runs today, and the to-be state describes the intended future design.
• Process: as-is and to-be process mapping moves through gather, draw, validate, redesign, compare, and specify.
• Comparison: a good gap table covers steps, handoffs, systems, and cycle time, with a conclusion for each.
• Example: a customer refund walk-through shows the method with illustrative numbers.
• Reusable tools: a two-part template covers the step-level map and the gap register.
• Outcome: every gap should end as a requirement, an action, or a deliberate decision to accept it.

Introduction

Someone proposes a new tool to fix slow approvals. Everyone agrees the approvals are slow. Then a manager asks, "How do approvals work today?" and four people give four different answers.

That moment explains why current-state and future-state work exists. You cannot improve what you have not described, and you cannot design a better process without a clear picture of the one you have.

This guide shows how to run an as-is-to-be process analysis from start to finish. You will see how to map the current process, design the future one, compare them, and convert the gaps into requirements. A worked refund example and a reusable template follow. The method sits at the heart of many  business analysis practices, so it helps anyone who improves processes, from analysts to operations leads.

If you are new to the role, start with  what is a business analyst  for context on who usually runs this work.

What Is As-Is and To-Be Analysis?

As-is and to-be analysis is a technique for understanding a process in two states and finding what must change to move from one to the other. The as-is state is how work is done now, including workarounds. The to-be state is how work should be done after the change. The difference between them is the gap.

The same idea appears in formal business analysis. The BABOK guide from the International Institute of Business Analysis (IIBA) places it in the Strategy Analysis knowledge area. There, "Analyze Current State" and "Define Future State" are two separate tasks. Gap analysis then supports the Define Change Strategy task. Practitioners often call this pairing current-state future-state analysis.

Three terms deserve a plain definition before you start.

Analysis and mapping are not the same thing. Analysis means understanding the process, its problems, and its goals. Mapping is one way to record and share that understanding. A map without analysis is just a drawing.

When Should You Use It?

Use the technique when a change affects how people, systems, or data interact. Common triggers include:

• Replacing or adding software, such as a new CRM, ERP, or workflow tool.
• Automating manual work.
• Merging teams, products, or companies.
• Responding to audit findings or regulatory change.
• Reducing complaints, delays, or cost.

Skip the full method for trivial changes. A one-step fix does not need a swimlane diagram.

Mapping the As-Is Process

As-is and to-be process mapping starts with the current state, because every later decision depends on it. A weak as-is map produces a weak to-be design. This is also where  process mapping  skills pay off: you set boundaries, choose a notation, and keep the detail consistent.

First, define the scope. Name the trigger that starts the process, the outcome that ends it, and the parts you will leave out. A SIPOC summary (suppliers, inputs, process, outputs, and customers) is a quick way to agree on boundaries before you draw anything.

Gather Information

No single source tells the whole story, so combine several:

• Interviews with people who perform each step, not only their managers.
• Observation, where you watch the work happen and note what people actually do.
• Document analysis of procedures, forms, templates, and policies.
• System data, such as ticket timestamps, logs, and status changes.
• Workshops that bring several roles together to walk through the flow.

Capture facts for each step: who does it, which system they use, what goes in and out, how long it takes, and how often it goes wrong. Record the exceptions too. Real processes are full of them.

Measure three kinds of time:

Processing time is the hands-on effort. Wait time is the delay between steps. Cycle time is the elapsed time from start to finish. In many processes, waiting accounts for most of the cycle time, which changes where you look for improvement.Lean teams expose this with value stream mapping, which separates value-adding time from waiting.

Expect a gap between the documented procedure and daily practice. People develop workarounds, such as keeping a private spreadsheet or approving by chat. Those workarounds belong in the as-is map, because they reveal unmet needs.

Draw the Current Flow

Pick a notation your audience can read. A swimlane diagram works well for most business processes because it shows who does what and where work crosses between roles. For more precision, use Business Process Model and Notation (BPMN), the standard maintained by the Object Management Group.

Follow these steps:

1. List the activities in order, using verb-and-noun labels such as "Check order status."
2. Place each activity in the lane of the role or system that performs it.
3. Add decisions as branches with clear conditions.
4. Show loops where work returns for rework or correction.
5. Annotate each step with its system, time, and known problems.
6. Mark pain points visually, for example, delays, manual re-keying, duplicate checks, and unclear ownership.

Map what happens, not what should happen. If the policy says one approval and practice involves three, draw three.

Keep the level of detail consistent. A map that shows one step as "Process request" and another as "ten micro-actions" confuses readers. Start at a high level, then expand only the areas where the pain concentrates.

Validate With Process Owners

A map is only a hypothesis until the people who do the work confirm it. Walk through the diagram step by step with process owners and frontline staff. Ask three questions: Is this what happens? What is missing? What happens when something goes wrong?

Compare their answers against data. If staff say a step takes ten minutes and the timestamps show two days, find out why. Often the difference is waiting time that nobody notices.

Record corrections, update the map, and obtain agreement from the process owner. Version the document and note the date, because processes change. This signed-off baseline protects you later when someone says the current state was "different."

Designing the To-Be Process

The to-be process is the intended future workflow, designed to meet defined business goals under real constraints. It is not a wish list. It answers the question: given what we learned, how should this process work?

Design in this order:

1. Confirm the goals: State what the change must achieve in measurable terms, such as faster resolution, fewer errors, or stronger controls.
2. Find root causes: Use root cause analysis techniques such as the five whys or a cause-and-effect diagram. If you redesign symptoms, the problems return.
3. Challenge every step: Ask whether each step can be eliminated, simplified, combined, or automated, the core question in any process improvement effort. Do not automate a step that should not exist.
4. Reduce handoffs: Each handoff adds waiting time and a chance for information loss.
5. Define roles and rules: Specify who owns each step, what decisions they make, and which business rules apply.
6. Respect constraints: Account for regulation, policy, budget, technology, and team capacity.
7. Set targets: Attach measures, such as cycle time, error rate, and cost per case, to the new design.
8. Test the design: Walk stakeholders through it, run a pilot where possible, and refine it.

Involve the people who will run the new process. A to-be design created in isolation often fails in adoption, even when it looks elegant on paper.

The future-state process should build directly on the as-is findings. Each major pain point in the current map should have an answer in the new design: removed, reduced, or consciously accepted. If a pain point disappears without explanation, the design is incomplete.

Also consider more than one option. A lightweight redesign may meet the goal at a fraction of the cost of a full system replacement. Compare options on benefit, cost, risk, and effort before you choose.

As-Is vs To-Be Comparison

The comparison is where as-is and to-be process mapping turn into decisions. Place the two states side by side and measure the difference on the same aspects. This current state/future state analysis shows what to fix first.

The table below explains what to record for each aspect and how to read the gap.

A gap is useful only when you can name its type. Classify each one so the right person can act on it:

• Process gaps: missing, redundant, or badly ordered steps.
• Technology gaps: missing features, manual re-keying, or absent integrations.
• People gaps: unclear roles, skills, or capacity shortfalls.
• Data gaps: missing fields, poor quality, or no single source of truth.
• Policy gaps: rules that conflict with the new design or are not enforceable.

Not every gap needs closing. Rank them by business impact and effort. A high-impact, low-effort gap becomes a quick win. A low-impact, high-effort gap may stay open by decision, and that decision should be documented.

As-Is and To-Be Example: Customer Refund Process

A refund process shows the method well because it crosses several teams and systems. The example below is hypothetical. It describes a mid-sized online retailer, and every figure is illustrative, not real-world data. Replace the numbers with your own measurements.

The As-Is Process

The retailer's current refund flow runs like this:

1. The customer emails customer support to request a refund.
2. A support agent creates a ticket manually in the helpdesk tool.
3. The agent looks up the order in the order management system.
4. The agent emails the warehouse to confirm the returned item arrived.
5. The agent emails finance to request approval.
6. A finance approver reviews the request and replies by email. Every refund needs approval, whatever the amount.
7. A finance analyst issues the refund by hand in the payment gateway portal.
8. The analyst emails the agent to confirm completion.
9. The agent emails the customer.

Validation with the team reveals the pain points. Agents retype order details into three systems. Warehouse confirmations get buried in shared inboxes. Small refunds wait in the same approval queue as large ones. Customers receive no updates between the request and the final email, so they write again, which creates more tickets.

The To-Be Process

Using the root causes, the team designs a future-state process:

1. The customer submits a refund request through a self-service form that asks for the order number and reason.
2. The system validates the order and checks eligibility against the refund policy, then creates the ticket automatically.
3. A warehouse return scan updates the order status without any email.
4. A business rule approves refunds under an agreed value threshold once the return is received. Higher-value refunds and fraud-flagged cases route to a finance approver.
5. The helpdesk calls the payment gateway's API to issue the refund and records the reference on the ticket.
6. The system notifies the customer at each status change. Agents handle exceptions only.

This is the to-be process: fewer steps, fewer handoffs, and controls built into the flow. Finance still reviews risky cases, so control improves instead of weakening.

The Comparison

Notice what the comparison reveals. The refund itself needs very little effort. Almost all the elapsed time is waiting, and the improvement comes from removing the waits, not from making people work faster.

The team should also protect controls. The new design needs an audit trail for each automated approval, a fraud check before any automatic refund, and a reconciliation between the payment gateway and the ledger. Each of these becomes a requirement in the next stage.

Turning Gaps Into Requirements

A gap register shows what is missing. Requirements describe what the solution must do or provide to close each gap. As-is to-be analysis creates real value only when it reaches this step, because projects deliver requirements, not diagrams.

Follow this sequence for each gap:

1. Give it an ID and a root cause. If you cannot explain why the gap exists, you may fix the wrong thing.
2. Choose the requirement type. The BABOK guide separates business, stakeholder, solution, and transition requirements. A gap about approval rules is usually a business rule. A gap about integration is a solution requirement. A gap about retraining staff is a transition requirement.
3. Write a testable statement. Describe the capability in clear, specific words.
4. Add acceptance criteria. Say how you will know the requirement is met.
5. Trace it. Link each requirement to its gap and to the business objective it supports.
6. Prioritise and assign an owner. A gap without an owner rarely closes.

Use the refund example to see the result.

Many requirements come out of conversations, so validate them with the people affected. Workshops, interviews, and prototypes, the core requirement elicitation techniques, help confirm that a requirement reflects real need and is not an assumption.

Prioritise with a simple method such as MoSCoW (must, should, could, won't), and base the ranking on business impact and risk Our guide to prioritization techniques compares it with other options. A requirement that protects financial control, such as the audit log, is a "must" even if customers never see it.

Finally, keep the link between the current state, future state analysis, and delivery alive. When scope changes, return to the gap register and ask which gaps remain open and which the team has accepted.

As-Is and To-Be Template

A reusable template saves time and keeps every analysis consistent. This one has three parts: a process header, a step-level map, and a gap register. Copy the tables into a document or spreadsheet and adapt them.

Start with the process header, which anchors the as-is and to-be process mapping to a clear scope.

Next, complete the step-level map twice: once for the current state and once for the future state.

For the to-be version, replace the last column with the proposed change and add the business rules that apply. Then compare the two maps in a gap register.

A few tips make the template work better:

• Measure real times before you fill in the as-is columns. Estimates tend to understate waiting.
• Keep one row per activity. Combining several actions hides problems.
• Give every success measure a baseline and a target, such as "cycle time from 8 days to 2 days."
• Review the gap register with stakeholders before anyone starts building.

Common Mistakes

• Documenting the ideal process. Mapping the policy instead of the practice hides the workarounds that matter most.
• Setting an unclear scope. A process with no clear start and end grows until the analysis never finishes.
• Skipping validation. An unvalidated as-is map loses credibility the first time someone disagrees with it.
• Designing the to-be in isolation. Solutions that ignore frontline experience meet resistance.
• Jumping to tools. Choosing software before understanding the gaps often automates a flawed process.
• Ignoring exceptions. Happy-path maps look tidy but miss where real effort and risk sit.
• Having no baseline metrics. Without a measured starting point, you cannot prove improvement. The DMAIC Measure phase shows how to set one
• Leaving gaps without owners. Unowned gaps stay open, and the analysis turns into shelfware.
• Mapping in too much detail. Excess detail makes maps unreadable and slows decisions.

Conclusion

The as-is-to-be process method works because it forces a sequence many projects skip: understand the real process, define the better one, measure the difference, and convert it into requirements. Each stage protects the next. Validation protects the baseline, the baseline protects the design, and the gap register protects the project scope.

Start small. Choose one process with a clear pain point, map it with the people who run it, and measure its wait times. Then use the refund example and the template to build your own comparison. If you want to formalize these skills, ECBA certification training introduces the business analysis fundamentals behind current-state analysis, requirements, and stakeholder work.