As-Is Process Map: Draw the Process You Actually Have, Not the One You Wish You Had

The As-Is Process Map sits in the Measure phase of RDMAICS. By the time you open it, you have recognised a problem and defined a scope. Now you need to see the work as it runs today.

The tool does five things. You draw the process. You classify each step by value. You record process time and wait time. You validate the drawing against BPMN 2.0. Then you export to BPMN, Visio or SVG so the map can travel outside the tool.

Use it when the team disagrees about how work flows. Use it when handovers are suspected but not proven. Use it before you design any future state, because a to-be map built on assumption will fail quietly.

Do not use it to document a process nobody has complained about. Mapping takes effort. Spend that effort where a measured problem already exists.

Everything below is built on the sample data that loads when you open the tool. This case is fictional. It exists to show the mechanics, not to describe any real organisation.

The sample uses one pool, named As-Is Process. Inside that pool sit three swimlanes. The first is Customer. The second is Front Office. The third is Back Office.

That structure is deliberately plain. A customer initiates something. A front office function receives and handles it. A back office function completes the work that the customer never sees. Many service processes reduce to exactly this shape once you strip the detail away.

Keeping the case simple makes the method visible. When you apply the same steps to your own process, the swimlane count will grow and the step count will grow with it. The sequence of work does not change.

Start with the pool. A pool is the boundary of the process you agreed to study in the Define phase. In the sample it is named As-Is Process. Name yours after the process, not after the project.

Then add swimlanes. Each swimlane is an actor. The sample uses Customer, Front Office and Back Office. One lane per actor. Resist the urge to create a lane for every individual role, because lane sprawl makes the map unreadable and hides the handovers you are trying to count.

Order the lanes the way work tends to travel. In the sample, the Customer sits at the top, the Front Office in the middle, and the Back Office at the bottom. When work crosses from one lane to another, the crossing line is visible. Those crossings are your handovers.

Only once the lanes are set should you place activities. Lanes first, steps second. Reversing that order usually means you redraw the map.

Once the steps are on the map, classify each one. Value classification is the part most teams skip, and it is the part that turns a drawing into evidence.

Ask two questions of each step. Does the customer care about this step and would they pay for it. Is the step required to meet a legal or regulatory obligation. A step that passes the first question is value adding. A step that fails the first but passes the second is business value adding. A step that fails both is non value adding.

Be honest in the Back Office lane. Internal checks, rework loops and approvals often fall into the non value adding category even when they feel essential. Essential and valuable are different things. The map is there to make that distinction uncomfortable.

Classify as a group, not alone. Disagreement about a classification is useful information. It usually means the step has an unclear purpose.

Next, record two numbers against each step. Process time is the time the step takes when someone is actively working on it. Wait time is the time the item sits before that step starts.

Keep the two separate. Combining them is the most common data error in process mapping. When they are combined you cannot tell whether the problem is capacity or queueing, and those two problems have completely different fixes.

Wait time is usually larger than process time and it usually lives at the lane boundaries. In the sample structure, that means the point where work moves from Customer to Front Office, and the point where it moves from Front Office to Back Office.

If you do not know a number, write down the estimate and mark it as an estimate. A labelled estimate is useful. An unlabelled guess that later gets quoted as fact is not.

When the map is drawn, run the validation. The tool checks the diagram against BPMN 2.0, which is the open notation standard for business process models. Validation catches structural faults such as steps with no outgoing path or gateways that do not resolve.

A map that passes validation is a map other tools can read. That matters at export time, because the tool exports to BPMN, Visio or SVG. BPMN carries the structure to other process platforms. Visio suits teams who already work that way. SVG is for documents and slides.

The tool also offers an AI review of the map you have built. It produces an AI interpretation of this map, written in plain language, so you can check whether the structure you drew matches the story you believe you are telling. Read it as a second opinion, not as a verdict.

Treat validation and the AI review as two different checks. One tests whether the diagram is well formed. The other tests whether the diagram is sensible.

A validated As-Is map lets you make a small set of decisions with confidence. First, where to focus in the Analyse phase. The steps with the largest wait time and the non value adding classification are the obvious candidates.

Second, whether the problem is a handover problem. Count the lane crossings. In a three lane structure like the sample, every crossing is a point where work changes hands and context can be lost.

Third, what to measure next. The map tells you which steps deserve proper data collection rather than estimates. Fourth, what to share. The export options mean the same map can go to a governance pack, a process repository and a workshop wall without being redrawn.

The map does not make these decisions for you. It narrows the field so that the conversation is about a shortlist rather than the whole process.

The first mistake is mapping the official procedure instead of the real one. The procedure document describes intent. The As-Is map must describe behaviour. If the two differ, the difference is your finding.

The second is too much detail. A map with hundreds of boxes is not more accurate, it is less readable. Stop at the level where a step has a clear owner and a clear output.

The third is skipping value classification because it feels subjective. It is subjective, and that is fine. The purpose is to organise judgement, not to replace it.

The fourth is drawing the map in a meeting room with no one present who does the work. The people in the lanes must be in the room, or the map is fiction of a less useful kind.

The As-Is Process Map will not tell you why the process behaves the way it does. It shows where time accumulates and where value is absent. The cause sits behind that, and finding it is the work of the Analyse phase.

It will not verify your data. If you enter a wait time that is wrong, the map will accept it, the validation will pass, and the export will carry the error outward. Validation checks notation, not truth. Nothing in the tool can tell you that a number came from a guess.

It will not design your future state. There is no automatic removal of non value adding steps and no generated to-be map. Redesign requires judgement about risk, control and capability that no diagram holds.

It will not quantify benefit. The tool records process time and wait time. It does not convert those into cost, savings or a business case. Those calculations depend on assumptions you must state and own.

Finally, it will not create agreement. A map can make disagreement visible and specific, which is valuable. Resolving it still takes a conversation between the people in the lanes. The sample case here, with its Customer, Front Office and Back Office lanes inside a pool named As-Is Process, is a teaching example. Your own map will be messier, and that mess is the point.