To-Be Process Map (BPMN): Design the Future State Before You Build It

The To-Be Process Map is a drawing surface with rules attached. You draw the process, classify each step by value, record process time and wait time against each step, validate the diagram against BPMN 2.0, then export to BPMN, Visio or SVG.

It belongs in the Improve phase of RDMAICS. By that point you have already measured the current state and analysed where the waste sits. The To-Be map is where you commit to a design. It is the artefact your team will argue over, sign off and then build to.

Reach for it when you have a concrete change in mind and need to show how work will flow after the change. Do not reach for it when you are still exploring the problem. A future state map drawn too early tends to lock in assumptions you have not tested. The Analyse phase tools exist for that work.

The tool is also useful as a communication device. A map with lanes makes ownership visible. When three groups each believe someone else handles a step, the lanes settle it quickly.

Everything that follows is built on the sample data that ships with the tool. The case is fictional. It exists so you can see the mechanics without needing your own data first.

The pool is named To-Be Process. Inside the pool sit three swimlanes. The first lane is Customer. The second lane is Front Office. The third lane is Back Office. That is the whole structure, and it is deliberately plain.

Three lanes is a sensible starting point for most service processes. One lane for the party who initiates and receives. One lane for the people who face that party directly. One lane for the people who do the work out of sight. If your real process needs more lanes, add them, but be aware that every extra lane adds a handover to manage.

Treat this sample as scaffolding. Rename the pool to match your own process. Rename the lanes to match the actual teams. Then start placing activities.

Start with the pool. The pool name describes the process as a whole. In the sample it is To-Be Process. Give yours a name a person outside the project would recognise.

Next, name the lanes. The sample uses Customer, Front Office and Back Office. Name lanes after roles or teams, not after individuals. Individuals change roles. The design should outlive them.

Order matters. Put the lane that starts the process at the top, then work downward in the direction the work travels. In the sample, Customer sits first because the customer initiates. Front Office sits second. Back Office sits third. Reading top to bottom then gives you a rough sense of the flow without tracing every connector.

Once the frame is set, resist the urge to detail everything. Place the main activities first and connect them end to end. Confirm the happy path works. Only then add gateways, exceptions and the steps that handle the awkward cases.

Each activity you place can carry two kinds of information. The first is a value classification. The second is a time record, split into process time and wait time.

Value classification forces a judgement. Does this step change the thing the customer is paying for, in a way they would notice and accept paying for. If it does, it is value add. If it exists only because of internal policy, systems or control needs, it is not. Some steps are necessary but still not value add. That is a legitimate answer and often the most useful one, because it marks work you should simplify rather than delete.

Process time is the time the step actually takes when someone is doing it. Wait time is the time the item sits before the step begins. Keep the two separate. Teams routinely find that wait time dwarfs process time, and that insight is lost the moment you merge the two into a single duration.

Record time against the future state you intend, not the current state you measured. This is a design document. If the design removes a handover, the wait time attached to that handover should disappear from the map. If you are unsure, record a range in your notes and flag the step for testing.

Once the map is drawn, run the validation. The tool checks the diagram against BPMN 2.0. This matters more than it sounds. BPMN is a standard, which means a compliant map can be read by other people and other systems without translation.

Validation catches the structural mistakes that are easy to miss by eye. Flows that lead nowhere. Gateways that open but never close. Activities with no inbound connector. These errors rarely cause trouble on a whiteboard, but they cause real trouble when someone tries to build from the map.

Export comes last. The tool exports to BPMN, to Visio and to SVG. Pick the format by audience. BPMN when the map will feed a workflow or automation effort. Visio when the receiving team works in that format. SVG when the map is going into a slide deck, a report or a wall poster and needs to stay sharp at any size.

Export early and often during review cycles. A map that only exists inside one tool tends to be ignored by people who do not open that tool.

When the map is complete, the tool produces a result. For the sample data, that result is an AI interpretation of this map, presented as an AI review.

The AI review explains what the map shows in plain language. It is a reading aid, not a verdict. Use it the way you would use a colleague's second opinion on a draft. If the review describes the process differently from how you understand it, that gap is worth investigating. Either the map is unclear or your understanding is.

The most common use is validation before a sign off meeting. Run the review, read it, and ask yourself whether a stakeholder who has never seen the process would come away with the right picture. If not, the map needs work before the meeting, not after it.

Do not treat the review as approval. It has no knowledge of your constraints, your systems or your people. It reads what you drew.

A good To-Be map supports a short list of decisions. Where to automate. Which handovers to remove. Which approvals to push down to the person doing the work. Where to place a measurement point so the Control phase has something to watch. Who owns each part of the process once it goes live.

The mistakes are predictable. The first is drawing the current state and calling it the future state. If your To-Be map looks the same as your As-Is map with better formatting, you have not designed anything.

The second is over detailing. A map with eighty activities is a procedure manual, not a design. Nobody reads it and nobody signs it off. Split it into a high level map and separate detail maps for the complex parts.

The third is skipping the value classification because it feels subjective. It is subjective. Do it anyway, with the team in the room, and record the disagreements. The argument is where the learning happens.

The fourth is assigning lanes to people rather than roles. The fifth is recording time as a single figure instead of splitting process time from wait time.

The tool draws, classifies, records, validates and exports. That is the full scope. Everything outside that scope is still your job.

It will not tell you whether your future state design is a good one. A map that validates cleanly against BPMN 2.0 is structurally correct. Structural correctness says nothing about whether the design will work in your organisation, with your systems, under your workload.

It will not verify your time figures. Whatever process time and wait time you type in is what the tool uses. If the figures are optimistic, the map will be optimistic and will look entirely credible while being wrong. The tool has no way to check your numbers against reality.

It will not settle value classification disputes. It records the classification you choose. If your team cannot agree on whether a review step adds value, the tool will accept either answer without comment.

It will not manage the change. Drawing the future state is a small part of reaching it. Training, system configuration, role changes, policy updates and the ordinary resistance of busy people all sit outside this screen.

It will not keep itself current. A To-Be map is accurate on the day you draw it. Processes drift. Unless someone owns the map and updates it, it becomes a historical record of an intention rather than a description of how work is done.

Finally, the AI review explains the map. It does not approve the design, carry accountability, or know anything you did not draw. Read it, weigh it, then make the call yourself.