Start here · 01 · 5 min

Why BPMN instead of boxes and arrows?

Anyone can draw a flowchart. The problem is that two people reading the same flowchart disagree about what it means.

Here is a perfectly normal process diagram. Read it, then answer the four questions below.

A vague process diagram

Start, four tasks in a row, end. It shows the order of work, but not who does it, what runs in parallel or what happens when things go wrong.

Receive orderCheck orderNotify customerShip goods
  1. Who checks the order, sales, or the warehouse?
  2. Do the checks happen at the same time, or one after the other?
  3. What happens if the customer never replies?
  4. Is “notify customer” a phone call a clerk makes, or an automated email?

The diagram answers none of them. Every reader fills the gaps differently, and they only discover they disagreed after the software was built.

The same process, stated precisely

BPMN answers those questions in the notation itself. The circle with an envelope says a message starts this. The diamond with a plus says the two checks genuinely run concurrently. The envelope on the task says a system sends the notification, not a person.

The same process in BPMN

An order message starts the process. A parallel gateway runs Check stock and Check credit at the same time, then a send task notifies the customer.

Order receivedCheck stockCheck creditNotify customerOrder confirmed

What BPMN actually gives you

PropertyWhy it matters
Execution semanticsEvery symbol has a defined runtime meaning: the token rules in a later module. A model is not a picture; it can be simulated, and at the executable level, run.
A standardBPMN 2.0 is an OMG specification, also published as ISO/IEC 19510. Your model opens in someone else’s tool.
One diagram, two audiencesThe business reads the shapes; engineering reads the same file as an execution definition. No translation step to fall out of date.

The third row is the one that changes how teams work. Everywhere else, the business draws a picture and engineering rewrites it as something executable, and from that moment the two drift apart. Here there is one file, read two ways.

That subset is small enough to learn in an afternoon. What takes longer is the part nobody warns you about.

"The hard part is never the notation. It is getting a room of people who all believe they already agree to look at one diagram and discover that they do not. That argument is the deliverable: the model is just what makes it possible to have."

After this module you can

  • Explain why flowcharts leave critical questions unanswered
  • Name what BPMN adds: execution semantics, a standard, and one diagram for two audiences
Skip without completing