What is as-is / to-be modeling?
As-is modeling documents the current state of a process — how work actually gets done today, including workarounds, bottlenecks, and unofficial steps.
To-be modeling designs the future state — the improved process after removing waste, automating steps, or reorganizing responsibilities.
The gap between the two is your improvement plan. Without an as-is model, you are guessing. Without a to-be model, you have no target.
| As-Is | To-Be | |
|---|---|---|
| Purpose | Understand reality | Design the improvement |
| Source | Interviews with people who do the work | Analysis, workshops, benchmarking |
| Includes workarounds? | Yes — that is the point | No — workarounds should be eliminated |
| Level of detail | High — capture everything | Focused — only what changes and why |
| Audience | Everyone involved in the process | Decision-makers + implementation team |
Step 1: Map the as-is process
This is the hardest part — not because BPMN is difficult, but because getting the truth out of an organization is difficult. Follow the approach from our how to map a process guide:
- 1.Define the scope — one process, clear start and end
- 2.Interview the people who do the work (not their managers)
- 3.Draw the happy path, then add decisions and exceptions
- 4.Validate with everyone involved
Critical: Map what actually happens, not what should happen. Include the manual workaround, the Excel spreadsheet that should not exist, the approval that everyone skips. This is where the improvement opportunities live.
Step 2: Analyze the gaps
With the as-is model in front of you, look for these patterns:
Bottlenecks
Steps where everything queues up waiting for one person or one system. Often visible as a single task with many incoming flows.
Redundant steps
The same data entered in two systems. The same check done by two different roles. Information sent, then re-sent in a different format.
Unnecessary handoffs
Work bouncing between roles when one person could handle it end-to-end. Every handoff is a delay and a potential communication gap.
Manual steps ripe for automation
Sending reminder emails, copying data between systems, generating standard documents. If a task follows predictable rules, a system can do it.
Missing error handling
What happens when a step fails? If nobody knows, that is a gap. The to-be model should define explicit error paths.
Step 3: Design the to-be process
Start from the as-is model and apply changes. Do not start from scratch — you want to see exactly what changed and why. For each change, document the rationale.
Common improvements:
- -Eliminate — remove steps that add no value (unnecessary approvals, redundant checks)
- -Automate — replace manual tasks with system tasks (BPMN service tasks)
- -Parallelize — run independent steps concurrently instead of sequentially
- -Simplify — merge handoffs, reduce approvals, flatten the flow
- -Add controls — error handling, timeouts, escalation paths that the as-is lacked
Step 4: Compare and present
Put the as-is and to-be diagrams side by side. Highlight what changed:
- -Red — steps removed
- -Green — steps added (automation, error handling)
- -Yellow — steps modified (moved to a different role, changed conditions)
This visual diff is what decision-makers need. It shows exactly what changes, why, and what the expected impact is. Much more convincing than a text document.
Common pitfalls
- -Skipping the as-is — jumping straight to the to-be means you are designing without understanding. You will miss root causes and solve the wrong problems.
- -Making the as-is too pretty — the as-is should be honest, not polished. If the real process is messy, the diagram should reflect that.
- -Changing everything at once — a to-be model that changes 30 things simultaneously is an implementation nightmare. Prioritize changes by impact and feasibility.
- -No metrics — without measuring the as-is (cycle time, error rate, cost per instance), you cannot prove the to-be is better. Attach KPIs to both models.
Keep learning
Frequently asked questions
Do I always need both an as-is and a to-be model?▼
For process improvement projects, yes. For documentation-only purposes, an as-is model may be sufficient. For greenfield processes (brand new, no current state), you only need the to-be.
How detailed should the as-is model be?▼
Detailed enough to identify improvement opportunities. Capture every step, decision, and handoff — including unofficial workarounds. You can simplify the to-be model, but the as-is needs to be honest.
Should I use BPMN for both as-is and to-be?▼
Ideally, yes. Using the same notation makes comparison straightforward. The as-is might be less formal (fewer event types, simpler notation), but both should be in BPMN for consistency.
How do I measure improvement between as-is and to-be?▼
Define KPIs before you start: cycle time, error rate, cost per instance, number of handoffs, manual steps count. Measure these on the as-is, then estimate (or measure) them on the to-be.