As-Is vs To-Be Process Mapping — Step by Step

Why process mapping matters

You cannot improve a process you do not understand. As-Is process mapping makes the current state visible — not as management believes it to be, but as it actually operates. To-Be process mapping designs the improved version. The gap between them is the transformation the project must deliver.

How to map the As-Is process

Talk to the people who do the work, not their managers

Managers describe the process as it is designed. Frontline staff describe the process as it is lived — including the workarounds, the informal steps, the exceptions that happen "all the time", and the things they do to compensate for system limitations. Both perspectives are valuable. The frontline perspective is more accurate.

Walk the process, do not just interview about it

Ask to observe the process being performed if possible. Watch, ask questions, note what the official process says versus what you observe. Ask: "How often does that happen?" "What do you do when X occurs?" "Is there a simpler way to do this that you would prefer?"

Measure what you can

Volume: how many times per day, week, or month does this process run? Duration: how long does each step take? Error rate: what percentage of instances include a rework step? These numbers make the case for improvement and set the baseline against which the To-Be process will be judged.

Document what you find, not what you expect

If a step has three different ways it can be performed depending on who is working that day, document all three. Informal variation is not an exception to be dismissed — it is often the evidence that the official process does not work as designed.

How to design the To-Be process

Start with the outcome, not the steps

Define what a successful process completion looks like from the customer's perspective. Then ask: what is the minimum number of steps required to achieve that outcome? Every step that does not directly contribute to the outcome is a candidate for elimination.

Apply the ESAD test to each step

For each step in the As-Is process, ask: can it be Eliminated? Simplified? Automated? Delegated to a less costly resource? Most processes contain steps that survive not because they add value, but because they have always been there.

Design for exception, not just the happy path

The To-Be process should handle the most common exceptions explicitly. What happens when a document is missing? When a system is unavailable? When a decision requires escalation? Exception handling is where most process designs fail in practice.

Measuring the improvement

Compare the As-Is metrics against the projected To-Be metrics: cycle time, error rate, cost per transaction, customer satisfaction. These become the business case for the transformation and the acceptance criteria for the project.