Staring at a process nobody has ever written down? Business process mapping means drawing each step, owner and decision as a diagram. Start by choosing one process, talk to the people who do the work, then draw it.
This guide sits under our wider coverage of business process management.
| Item | Value |
|---|---|
| Steps in one common mapping method | 7 steps |
| First step of that method | Identify objectives, scope, players and work areas |
| BPMN 2.0.1 publication date (OMG) | September 2013 |
| Status of BPMN 2.0.1 on the OMG page | Formal |
| Year the OMG was founded | 1989 |
Figures come from ProjectManager’s mapping guide and the OMG’s BPMN 2.0.1 page. They can change, so check the sources before you rely on them.
What business process mapping actually is
A business process is, in ProjectManager’s words, “a series of tasks or steps that need to be taken by an organization to accomplish a concrete goal.” A map is the picture of that series.
The same guide says a good map shows what the steps are, who is responsible for each, which tools are used, what the standard for completing the work is and how success is judged. That is more than a flowchart of boxes: it records ownership and quality as well as order.
Maps are useful well beyond efficiency work. Typical uses include training, regulatory compliance, internal auditing and clarifying roles.
Before you draw: pick the process and the people
Most mapping efforts go wrong at the start, not at the drawing board. A vague scope such as “sales” produces a sprawling diagram nobody finishes.
Narrow it down with a short checklist:
- One process, such as “approve a supplier invoice” or “onboard a new customer”.
- A clear trigger, meaning the event that starts it.
- A clear end point, meaning the outcome that tells you it is done.
- A named owner who can settle disagreements about how it really works.
ProjectManager’s first step is the same idea: identify the objectives, scope, players and work areas you want to focus on.
How do you map a process step by step?
The method below is a plain sequence you can follow with a whiteboard or sticky notes. It follows the same logic as published seven-step methods, which run from identifying the process through analysis to installing new methods.
- Define the boundaries. Write the trigger, the end point and the goal on one line.
- Gather information. ProjectManager’s guide says this is done by “gathering information and conducting interviews with the people who do the work you’re mapping.”
- List the activities in the order people actually perform them, not the order the manual says.
- Add the decisions. Every “if” becomes a branch, such as approved or rejected.
- Assign owners to each step, by role rather than by name.
- Draw the diagram and walk it back to the people who do the work.
- Correct it until the people involved say “yes, that is what happens”.
Do not try to improve anything while you draw. Map what happens today, including the workarounds, because you cannot fix a process you have described wrongly.
A worked example: approving a supplier invoice
Imagine the process is “approve a supplier invoice”. The trigger is an invoice arriving by email, and the end point is payment being scheduled.
After talking to the people involved, the activity list might look like this:
- Accounts payable logs the invoice and checks it against the purchase order.
- If the amounts match, the invoice goes to the budget holder for approval.
- If they do not match, it goes back to the supplier or the buyer for correction.
- Once approved, finance schedules the payment.
Notice what the interviews add. The manual may say invoices are approved the same day, while the people doing the work tell you they wait for a manager who travels often. That gap between policy and practice is exactly what a map is meant to expose.
On a swimlane version, accounts payable, the budget holder and finance each get a lane. Every handoff between lanes becomes a visible arrow, and handoffs are where waiting time usually builds up.
Choosing a diagram style
You do not need a heavyweight notation for a first map. A simple flowchart uses rectangles for activities, diamonds for decisions and arrows for the flow between them.
A swimlane diagram adds ownership. As ProjectManager puts it, “each step is divided between different teams or individuals who are responsible for them”, so the diagram looks like lanes in a swimming pool.
Use this rough guide:
- Plain flowchart: one team, one short sequence.
- Swimlane: work that passes between roles or departments.
- BPMN: processes that must be precise, shared across teams, or later automated.
Hand-drawn maps are fine. ProjectManager notes maps can be hand-drawn or created in software, and says you do not need to be a BPMN expert to create one.
Where BPMN fits
BPMN stands for Business Process Model and Notation. It is maintained by the Object Management Group (OMG), a standards body that says it was founded in 1989 and that its standards are driven by vendors, end-users, academic institutions and government agencies.
The OMG’s page for version 2.0.1 lists a publication date of September 2013 and a document status of “formal”. That status applies to that dated page; a later version may exist, so check the OMG’s specification list if you need the newest release.
BPMN’s value is a shared vocabulary. Events, activities, gateways and lanes mean the same thing to every reader, which matters when a map is handed to developers or a workflow tool.
Common mistakes and what to do after the map
The most common failure is drawing the process from the policy document instead of from practice. The fix is simple: interview the people who do the work, as the method above says.
Other mistakes to avoid:
- Mapping too much detail. If a step needs a second page, give it its own map.
- Skipping exceptions. Rejections, rework and missing information are where delays hide.
- Treating the map as finished. Processes drift, so date the map and review it.
Once the current state is agreed, you can analyse it. ProjectManager’s guide suggests studying the map and challenging each step by questioning the why of it. That is the point where business process improvement begins, and mapping is one stage of the wider bpm lifecycle.
Keeping the map useful over time
A map that sits in a folder soon stops matching reality. Give it a version date, a named owner and a review habit, such as checking it whenever a tool, team or rule changes.
Store the map where the people who run the process can find it. If only the person who drew it can read it, it will not survive a change of role.
A few habits make maps easier to trust:
- Use the same shapes and naming style across every map, so readers do not relearn the conventions each time.
- Name activities with a verb and an object, such as “check invoice” rather than “invoice”.
- Note the tools and documents used at each step, since the same guide says a map should capture what tools will be used.
- Record who agreed the map and when, so later changes are traceable.
If the process will later be automated, the map becomes the starting brief. A clear, agreed map of the current state is far easier to turn into a workflow than a description given from memory.
Frequently asked questions
Is process mapping the same as flowcharting?
They overlap. A flowchart shows sequence, while a process map also records owners, tools and standards for completing the work.
Do I need special software?
No. ProjectManager’s guide says maps can be hand-drawn or created in software. Start on paper or a whiteboard and move to a tool when the map needs sharing.
Who should be in the room?
The people who do the work, plus the process owner. Interviewing the people doing the work is a core step in the method above.
Do I have to use BPMN?
No. BPMN is a formal notation from the OMG, useful when precision or later automation matters. Many first maps use plain flowcharts or swimlanes.
What do I do with the finished map?
Check it with the people involved, then look for unnecessary or repeated steps. Combine, rearrange or remove them one at a time.
