What is BPMN?

BPMN solves a fundamental problem: everyone describes processes differently. What's "obvious" to one person is confusing to another. BPMN creates a shared vocabulary that works across roles.

The benefits:

• Shared language for analysts, operations, and IT
• Clarity on roles, handoffs, and decisions
• Standardization so SOPs don't drift from reality
• Automation readiness when stable steps can be executed reliably

Without BPMN, process documentation tends to be inconsistent, outdated, and disconnected from how work actually happens.

BPMN has four main categories of elements:

Events

Something happens: a process starts, receives a message, or ends. Events are circles.

• Start events (thin border): How the process begins
• Intermediate events (double border): Things that happen during the process
• End events (thick border): How the process concludes

Activities

Work that gets done. Activities are rounded rectangles.

• Tasks: Atomic units of work (e.g., "Review application")
• Subprocesses: Groups of tasks that can be collapsed

Gateways

Decision points where the path branches. Gateways are diamonds.

• Exclusive (XOR): One path is chosen (e.g., "Approved or rejected?")
• Parallel (AND): All paths execute simultaneously
• Inclusive (OR): One or more paths may execute

Flows

Arrows connecting elements, showing the sequence of work.

Pro tip: Don't over-model. If a gateway doesn't affect execution, you probably don't need it.

Flowcharts are great for quick communication. BPMN is designed for process clarity at scale—especially when multiple roles, systems, and exceptions are involved.

Aspect	Flowchart	BPMN
Purpose	Quick visualization	Formal process documentation
Standardization	Informal	ISO standard (BPMN 2.0)
Roles/lanes	Optional	Built-in swimlanes
Automation	Not designed for	Execution-ready
Best for	Brainstorming	Operational processes

When to use flowcharts: Brainstorming, explaining simple ideas, non-critical documentation.

When to use BPMN: Processes with multiple roles, compliance requirements, or automation potential.

These practices help you create BPMN diagrams that people actually use:

1. Model the happy path first

Start with what happens when everything goes right. Add exceptions and error handling later—and only if they affect how work gets executed.

2. Use verb-object naming

Name activities with action verbs: "Approve invoice", "Send notification", "Validate data". Not "Invoice approval" or "Notification".

3. One start, one end (usually)

Most processes should have one clear start and one clear end. Multiple end events are okay for different outcomes (approved/rejected), but avoid spaghetti.

4. Make approvals explicit

Don't hide approvals inside tasks. Model them as explicit activities with clear owners. This matters for governance and automation.

5. Assign ownership

Every process needs an owner responsible for keeping it up-to-date. Unowned processes drift from reality.

6. Keep it readable

If you can't explain the diagram in 2 minutes, it's probably too complex. Split it into subprocesses or simplify.

These mistakes undermine the value of BPMN modeling:

Mistake 1: Over-modeling exceptions Trying to capture every edge case makes diagrams unreadable and unmaintainable. Model the exceptions that actually affect execution.

Mistake 2: Unclear gateway conditions "Maybe" is not a valid gateway condition. Label each branch with explicit conditions (e.g., "Amount > $10,000").

Mistake 3: Forgetting about swimlanes Processes involve multiple roles. Use pools and lanes to show who's responsible for each step.

Mistake 4: No ownership defined A beautiful BPMN diagram that nobody maintains is worthless. Assign an owner and review schedule.

Mistake 5: Disconnected from reality The map is not the territory. BPMN diagrams should reflect how work actually happens, not how you wish it happened.

Ready to create your first BPMN diagram? Here's a practical approach:

Step 1: Choose a real process

Pick something you actually want to improve—not a hypothetical example. Approvals, onboarding, and request handling work well.

Step 2: Interview the people who do the work

Ask: "Walk me through what happens when..." Don't assume you know. The people doing the work know the real process.

Step 3: Draw the happy path

Start event → Main activities → End event. Just the normal flow, no exceptions yet.

Step 4: Add gateways for key decisions

Where does the path branch? What conditions determine the path? Add exclusive gateways.

Step 5: Assign roles with swimlanes

Who does each activity? Add pools and lanes to make responsibility clear.

Step 6: Review with stakeholders

Walk through the diagram with the people who do the work. Fix what doesn't match reality.

Step 7: Consider the next step

Is this just documentation? Or will you standardize as an SOP? Or automate?

Start creating your first BPMN diagram →