Business process

Process documentation has a habit of living in three places: a diagram in someone's slide deck, a policy document, and the actual behaviour. Drawing the process on the Confluence page that describes it removes one of those three.

For most processes a flowchart is enough. Reach for BPMN when the process will be automated or when the notation is part of the requirement.


#When to draw one

  • Documenting how work actually moves through a team.

  • Designing a process before building any of it.

  • Compliance documentation where the process must be evidenced.


#What is on the diagram

Element

Meaning

A flowchart

Most processes, most of the time

A swimlane diagram

When the handoffs between teams are the problem

BPMN

When it will be automated, or the notation is required

A DMN table

When the hard part is a decision with several inputs


#A worked example

A purchase request, with the approval threshold visible:

Business process

The source, which you can paste into a new diagram and edit:

flowchart TD
  A([Request raised]) --> B[Line manager review]
  B --> C{Under 5,000?}
  C -- Yes --> D[Approved]
  C -- No --> E[Finance review]
  E --> F{Budget available?}
  F -- Yes --> D
  F -- No --> G[Deferred to next quarter]
  D --> H([Purchase order raised])

#A few things that catch people out

  • Draw the rejection and timeout paths. They are the parts people ask about.

  • One diagram per process. A diagram covering three processes documents none of them.

  • Approvals can be run for real rather than only documented. See Integrations.



Diagrams next to the words they explain.