BPMN on one page: a process drawing both directors and developers can read

Ask your sales director, warehouse manager and accountant each to describe how a larger purchase gets approved. You will get three descriptions that disagree on half the steps, each written so that only its author fully understands it. When that description later reaches whoever has to build the system, a fourth interpretation appears.

BPMN exists to prevent exactly that. It is a standard way of drawing processes, with a limited set of symbols that everyone reads the same way.

What BPMN is

The acronym stands for Business Process Model and Notation. The standard is published and maintained by the international consortium OMG, and the version in use is 2.0, whose latest revision is 2.0.2.

For a business owner, the history of the standard doesn’t matter. One practical thing does: a drawing made to BPMN rules can be read by someone who wasn’t in the meeting where it was made. A director sees who does what and where work waits. A developer sees the exact conditions and sequence.

The symbols that cover most processes

The standard has many symbols. For the great majority of business processes, these six are enough:

• Event (circle). Something that happens. A thin-lined circle is the start of the process; a thick-lined circle is the end.
• Task (rounded rectangle). A piece of work someone does. Name it with a verb and an object: “Check amount”, not “Amount”.
• Gateway (diamond). A point where the route splits or joins. A diamond with an X means only one route is taken, depending on the answer.
• Sequence flow (solid line with an arrow). The order — what comes after what.
• Message flow (dashed line). Something exchanged with an outside participant, such as a supplier or a customer.
• Lane (horizontal band). Who does the work. Each role or department gets its own lane, so you can see at a glance where work changes hands.

An example: approving a purchase

Here is what the drawing of a simple process would show, described in words:

1. In the Requester lane, the process starts with the event “Need for a purchase arises”, followed by the task “Fill in request”.
2. A gateway asks: “Amount above limit?”
3. If not, the flow goes straight to the Purchasing lane, to the task “Place order”.
4. If so, the flow goes to the Department head lane, to the task “Approve request”, then to a second gateway: “Approved?”
5. If not approved, the task “Notify requester” follows, then an end event.
6. If approved, the flow goes to the Purchasing lane, to “Place order”, then to the end event “Purchase ordered”.

All of that fits on half a page. And questions that usually surface only once the system is finished appear immediately: what the limit is, who stands in for the department head when they are away, and how long a request may wait for approval.

When BPMN pays off

• When a process runs across several departments and each describes it differently. The drawing becomes the agreement.
• When a process is handed to the people building the system. Client and supplier read the same drawing, leaving less room for “we assumed that”.
• When you are looking for where work waits. On a drawing with lanes, every crossing between lanes is a place where waiting can happen.
• When a process has many exceptions. Gateways force them into the open, because every question needs an answer on every arrow.

When BPMN is too much

• A small firm and a simple sequence. If three people do the work and it has five steps without branches, a numbered list is perfectly sufficient.
• A drawing only its author can read. Use every symbol in the standard and the drawing becomes precise and unreadable. Stick to a small set of symbols.
• A drawing of the ideal process. First draw how the work really flows, then how it ought to flow. The reverse order produces a handsome drawing nobody follows.

A few rules that keep a drawing readable

• one process, one page — if it doesn’t fit, split it into sub-processes
• one start, and clearly marked ends
• every gateway asks a question, and the answers sit on the arrows
• tasks are named with a verb and an object
• draw with the people who do the work, not on their behalf

There are also platforms that can execute a BPMN drawing directly as a program. For some businesses that is a good route. For us, the drawing is first and foremost a tool for agreement and the starting point for designing and building the system — however handsome it is, it is only worth as much as it is accurate.

Drawing processes together with the people who run them, in a form that whoever builds the system can read later, is part of the assessment within our IT consulting and digitalisation plan service. If you would like your most tangled process to fit on one page, get in touch.