Process models are a core skill of business analyst, but sometimes it feels like this:

BPMN is an amazingly useful and detailed method for documenting processes in a clear way. The symbols are pretty familiar if you’ve ever seen a flow chart, where you start with a circle, have several boxes to denote actions, a diamond to highlight any decisions/branching paths, and a circle at the end to say it’s done. Add some black arrows to denote responsibility moving across and “swim lanes” surrounding parts to call out who the actor is doing the work. Congratulations, you’ve got a generic UML style flow chart! But the value in BPMN is elegance in displaying the depth. Below is the high level items/objects you need to assemble a process model in UML & BPMN:

First difference you might notice with BPMN is there are a few more “core” objects, such as pause events, the ability to associate 2 things, and the ability to denote when a message but not responsibility is passed.

The next great part, is that for each one of these objects, there is generally a sub-variant. Want to say “this starts every 15 minutes?” Change your Start Event to a “Timer” Start Event. Want to say it starts when an email arrives? Change your Start Event to a “Message” Start Event. Task done by a system? Change your Task/Action to a “Service” or “Script” Task/Action. Want to highlight a path for escalation or errors? Intermediate/Pause Events have those options!

Okay, there are a lot of options, we get it. Where do I start to actually model a process?

Levels of detail:

Firstly, you need to decide what level of detail you’re modelling. There is a mixed view of the levels, and some document them in BPMN or via other tools (like Porter’s Value Chain or enterprise modelling). We’ve tried to include a size reference, and an audience you may use it to address.

• Level 0 aka Context Level or Enterprise Level:
  • This is the highest level of process modelling that provides an overview of the entire process at an organisational level, including its objectives, inputs, outputs, and stakeholders. It is a high-level representation of the major groups/divisions/areas involved, used to communicate the overall process structure to stakeholders.
• Level 1 aka Value Mapping model
  • This level provides a more simplistic “rolled-up” representation of the process flow, including the major steps and top level activities involved. It is used to understand the current process and highlight areas of change. This is likely the most detailed process flow you’d use in a wide audience presentation, or print on a single A4 sheet of paper.
• Level 2 aka Logical model
  • This level represents the improved process flow after making changes based on the analysis of the As-Is process. It provides a more detailed representation of the process, including sub-processes and activities (which are not broken down into tasks or their smallest steps), and is used to communicate the changes to stakeholders. This is likely the most detailed process flow you’d give to an executive, or print on a single A3 sheet of paper.
• Level 3 aka Operational Level (where most BPMN documents take place):
  • This is the most detailed process flow you’d give to a human. It includes the activities broken down into specific tasks, inputs, outputs, and decision points taken by people, and how they might interact with systems. It is used to guide the execution of the process, for training and is usually the level of depth used to support continuous improvement/optimisation. This is likely the most detailed process flow you’d give to a human, and may take up several A3 sheets of paper.
• Level 4 aka Implementable Level:
  • This is the lowest level and most detailed process flow, used for system automation. It includes the specific tasks, inputs, outputs, and decision points taken at a code level by systems and manual actors like people. It is used to automate processes as it can be converted to code,and is usually the level of depth used to support systems improvement/optimisation.

Process of process modelling:

1. Who is involved? For each person, provide them a “Swimlane” to have their respective tasks in
2. Mark the Start Event – Is it caused by something arriving, does it happen on a schedule, or is there something else that kicks off your process? You might find you have multiple triggers along the process that start things at different points.
3. Walk through the process, adding tasks and the obvious decisions that take place. Remember, every arrow is marking responsibilities as things normally happen.
   1. Where decisions take place, make sure to name the line so we can tell what decision leads to what action next!
4. Include an End Event to highlight when things most likely stop.
5. Go back to the start, and walk through the diagram to make sure it’s logical at this point
   1. If you’re using Visio, use the Check Diagram feature to validate it and call out any errors!
6. Go action by action and ask the following prompts;
   1. What happens if an error occurs? Does it stop, take a different path, or continue?
   2. What happens if an escalation occurs? Does it stop, take a different path, or continue?
7. Note any messages coming from the system and who they go to with the dash-line.
8. Check if any actions should be
   1. Loops; some actions can be done one at a time, others in parallel, others only need to be actioned once.
   2. Collapsed Sub-Tasks; Denoted by the plus at the bottom, these highlight there is A LOT happening under this particular task. You might not need to detail that “make coffee” actually means “go to the fridge, get out the milk, go to the cupboard, get out the beans, etc”.
   3. Unique task types; it’s good to flag tasks that are manual, done by scripts, done by services/systems, etc.
9. Give it to someone else to read. They should be able to trace their finger along and make sense of tasks!

But what about UML?

UML is fine, but it lacks a lot of depth. You can mark decisions and tasks, but marking that there is a specific error path from a task gets bloated very quickly with superfluous decision points needing to be added asking “Has an error occurred” repeatedly. BPMN is just that little bit more clear, neat, and detailed, with a range of iconography to help explain situations and events. Additionally, tools like Visio allow you to “check” your diagram against the rules, ensuring consistency against standards, which is fantastic for double checking your work. Below is a little example, including Visio saying it’s following the standards:

As you can see in this very simple basic example, UML requires an additional decision point to call out the “Divide by 0” error, and without the iconography it can get a little more confusing, even if the wording makes up for it.

References and resources:

Need a free modeller? Bizagi Modeller is pretty solid. Visio is more of an industry standard. Bpmn.io also has favourable mentions.

BPMN quick guide: https://www.bpmnquickguide.com/view-bpmn-quick-guide/

Some useful examples: https://camunda.com/bpmn/reference

Stefan Carton

Updated: 13/02/2023