How to create a process map: current and future state

A process map is a picture of how a piece of work actually gets done: the trigger that starts it, the steps in between, who performs each one and what comes out at the end. Where a flowchart concentrates on sequence and decisions, a process map adds responsibility and handoffs, and it is usually drawn at a slightly higher level.

Process maps are usually made to understand a process or to change it, and the second depends on the first. So the usual approach is to draw two maps: the current state and the future state.

Process map, flowchart or swimlane?

The terms overlap, and teams use them loosely. A working distinction:

Diagram	Main question it answers	Typical level of detail
Flowchart	What happens next, and where does the path split?	Individual steps and decisions
Process map	How does this piece of work move from trigger to outcome, and who is involved?	Major steps and handoffs
Swimlane diagram	Who does each step?	Steps placed in one lane per role

If the work repeats in a loop or is really about layers or overlaps, a cycle, pyramid or Venn may say it better; see choosing a process diagram. In practice, many process maps are drawn as swimlanes, because the lanes make responsibility visible. If you want the drawing technique in detail, swimlane diagrams explained walks through it. This article focuses on the mapping work around the drawing: gathering the facts, reading the map and designing the change.

Before you draw: set the frame

Agree three things with whoever asked for the map.

1. The trigger. The event that starts the process. “A new supplier invoice arrives” is a trigger; “accounts payable” is not.
2. The outcome. What finished looks like. “Supplier paid and invoice filed.”
3. The purpose. What the map is for. Training new staff, reducing delays and preparing for an audit each call for a different level of detail.

Write these at the top of the page. They stop the map from drifting into neighbouring processes, which is the most common reason process maps grow until nobody can read them.

Mapping the current state

The current-state map records what really happens, not what the policy says should happen. The gap between the two is often the most useful thing the map reveals.

Talk to the people who do the work

Sit with one person from each role involved and ask them to walk through a recent, real example. Ask what they receive, what they do with it, where it goes next and what they do when something is missing. Written procedures are a useful starting point, but they rarely mention the workarounds.

Record steps at one level

Each box should represent a meaningful unit of work, such as “Match invoice to purchase order”, not “Open email” or “Manage finances”. If one role describes ten small actions and another describes one large one, regroup them so every box sits at roughly the same level.

Mark the waits and the loops

Two things matter more than the steps themselves.

• Waits. Places where work sits in a queue: awaiting approval, awaiting a missing document, awaiting the next batch run. Mark each one, even if nobody can say exactly how long it lasts.
• Loops. Places where work goes back to an earlier step, such as an invoice returned to the supplier for correction. Note what causes each loop.

For example, in an invoice process at a distribution company in Chennai, the current-state map might show invoices arriving by email and by post, a manual match against purchase orders, a wait for the budget holder’s approval, and a loop whenever the purchase order number is missing.

Reading the current-state map

With the map drawn, review it with the people who contributed. Ask them to correct it before you analyse it. Then look for:

• Handoffs that add nothing. Work that passes to someone only to be passed back.
• Repeated checks. The same information verified by two different roles.
• Missing information at the start. Loops often exist because the first step doesn’t collect what later steps need.
• Single points of dependency. One person whose absence stops the process.

Write each finding as a short note beside the relevant part of the map, so the map carries its own diagnosis.

Designing the future state

The future-state map shows how the process should work once the changes are made. Draw it with the same trigger, outcome and level of detail, so the two maps can be compared side by side.

Work through your findings one at a time:

1. Remove steps and handoffs that add nothing.
2. Combine repeated checks into one, owned by one role.
3. Move information-gathering to the start, so loops become rare.
4. Clarify ownership wherever a step had none.

Keep the future state realistic. A map that depends on a system nobody has budgeted for, or on a team that doesn’t exist, will be admired and then ignored. If some changes need investment, draw an interim state first.

Presenting the two maps

When you share the maps with a steering group or client, place them side by side or on consecutive pages with identical layouts. Highlight the steps that change, using one accent colour, and leave everything else neutral. A short list beneath, one line per change with an owner, turns the comparison into a plan. If the steering group expects a full presentation, the two maps can sit inside a deck made with the Presentations.AI presentation maker.

Keep both maps after the change goes live. The future state becomes the new current state, ready for the next review.

If you can describe the process in words, from trigger to outcome with each role’s part, DiagramsPro can lay out the map for you to check and refine.