Published on 02/02/2024
By Peter Holroyde
I’m a visual person, and when it comes to designing software, conducting threat assessments, or modelling business processes, I believe that picture is worth a thousand words. When it comes to business processes, having the right type of visual can help anybody understand the process very quickly, without the need for extensive documentation to gain an understanding.
So what do I mean by the “right type of visual”? It’s a combination of two things. Firstly a notation that’s suitable for modelling business processes, and secondly that the notation is used correctly and not abused. The second point is perhaps a bit unfair when discussing notations. What I mean is that the notation must provide the right tools to make providing a good model of the process possible.
It’s completely possible to make a bad representation of a process in any notation, overly complicated and hard to read, a tangle that will be hard to follow in practice. Now, I’m sure you’re thinking that some processes are just that complicated! Yes, it’s true that sometimes things are complicated, but the best notations provide the right tools to help abstract the complications into a model that’s easy to understand.
In this blog post, I’m going to introduce a few different notations which people use to model processes, and then discuss what a good and bad model of a process looks like and some of the tricks you can use to help make a simple model from a complicated situation.
There are plenty of notations to choose from, however there are a few which appear more often than not for modelling business processes. Before we get into the notations, it’s helpful to have in mind the types of things we need to model to describe a business process. The fundamentals are:
With these fundamentals in mind let’s have a look at some notations…
Flowcharts have been around for a hundred years and most people end up with basic familiarity with them. Simple to get started with and easy to follow. It’s not a coincidence that the later notations lean heavily on flowcharts for their influences and approach. Here’s an example in the simplest form:
The lines denote the flow through the process, with activities and decisions easily recognisable even if you don’t know the notation based on the wording.
There are a few other types of symbols and a few rules for how to use them. There are drawbacks, though. In this form, it’s really easy to create a complicated mess of a flowchart, and the same lack of symbols and rules can make it hard to model common concepts without lots of lines and symbols.
Not all is lost, though; a variation of flowcharts known as cross-function flowcharts exists to address a couple of the specific weaknesses of flowcharts for modelling business processes. Cross-function flowcharts add the ability to track the “who” to our model:
That’s suddenly much easier to follow, and it’s clear who is responsible for doing what in the process. If it’s in your lane, it’s your responsibility!
UML, or Unified Modelling Language, is a visual modelling language for designing systems. It dates back to the 1990s and has gone through several versions. It includes many different types of diagrams, with strict rules for their creation. One of these diagram types is the Activity diagram.
So we can represent our four fundamentals, and as a bonus, we can use the split and join bars to show that things will be done in parallel. It’s surprising how much cleaner a diagram you can produce with these bars.
UML activity diagrams are often used to explain the process followed by a UML use case. They’re simple enough to follow without any additional learning, and the purpose of the bars is pretty obvious from the diagram.
Another notation dating from the 90s follows the same basic approach but differs in a few key ways. Firstly it gives us more options for what we can represent. We’ve got things like events and systems, inputs and outputs. This is great but it comes at the cost of the reader requiring more knowledge about the notation to correctly interpret what’s going on. Then we’ve got the way that organisational units, the “who”, is represented. Instead of the lane based approach we’ve seen previously, this notation represents the “who” with nodes attached to the activities (called functions in EPC) they are responsible for. Let’s have a look at an example…
I personally prefer the swimlane approach over this one for describing the “who,” but it’s nice to be able to include extra events partway through a process to show how these can be handled.
Created in the early 2000s and now in version 2.0, BPMN was purpose-built to provide a way to model business processes of all shapes and sizes. While starting simple (and staying simple) is an option, the number of different elements and rules for using this notation can make it seem daunting.
BPMN ticks lots of boxes, though. It covers the fundamentals using swimlanes, flows, and activities and provides different types of gateways for handling different types of conditional and parallel situations. You also have the ability to introduce events, inputs and outputs, and time-based conditions, just for starters.
No I’m serious, people do this! Ok, it’s more often systems and software that do it, but regardless, I’d argue that it’s a bad idea. It leads to problems like incompatibility between systems, institutional approaches that require somebody to train and translate for new members of the organisation, and all sorts of weird and wonderful (if creative) approaches.
I can understand why software developers end up with their own notation, it can be difficult to comply with a formal notation (hey, I’ve been there), and it’s usually a good thing come up with fancy user interface things that make it easy for people to create diagrams. Customers often want to make crazy diagrams, so you don’t want to be too restrictive, and the logic required to process more complicated scenarios possible in BPMN, for example, can be difficult to test and slow to process.
If possible, stay with a known standard. It will allow you to take your diagrams between different systems, and lots more people will be able to understand them if it’s a known notation, you can even advertise for people with experience with them.
There are lots of things to choose from, and this list doesn’t include everything. I hope it’s helped give you a sense of what’s out there and that not all notations are created equally. Some things are more intuitive than others, and there can be such a thing as “too simple,” which will make it harder to represent processes accurately without making nightmarish diagrams.
Equally, it’s possible to use complex notation to make a pretty diagram that’s simple to look at but hard to interpret without a working knowledge of that notation. Like in so many things, balance is the key.
Ok, the fun part. “if it takes somebody more than 5 minutes to explain a process to you, it’s too complicated”. That may be contentious, but I’m serious. I’ve been sat in a room where a business analyst has unrolled a scroll of A3 paper down a table to show a business process, it wasn’t pretty let me tell you. In fairness it is difficult to get complicated processes onto actual paper, and often madness to try. Here are some tips and tricks to try to help, starting with the most important.
This is the crux of things. Hide complexity one level below the surface. If you have a fulfilment process during which the finance department performs some very strange and convoluted process for onboarding a new supplier, you don’t have to make the other parts of the organisation involved in the process suffer by having that on the process diagram. A number of notations provide tools for this kind of abstraction, but let’s stick with BPMN (it’s my favourite in case you’ve not guessed yet).
BPMN offers a couple of ways to indicate an abstraction. Firstly, it includes the concept of sub-processes, which can be visualised open or closed. Let’s look at a quick example.
Carrying on my example of a finance department with some strange ideas about onboarding suppliers, let’s look at Kittens Inc. Their finance team insists that they will negotiate based on the supply of kittens if the supplier likes cats:
There’s some extra detail in there that nobody outside the finance team needs to worry about to understand the process. If we use a subprocess…
That looks much more sane. The use of a subprocess indicates to the reader that there’s some complexity present, but it’s being hidden.
Good BPMN-based systems that execute processes allow users to drill down to see the complexity when they want to, and they allow the process to be executed, keeping it hidden the rest of the time.
The supplier onboarding work could be pulled out into a separate process. This would be sensible as perhaps the finance team want to own their own process for onboarding new suppliers, and when they need to do this for other types of events, perhaps when the organisation wants to procure software rather than equipment in this example.
BPMN allows us to show this:
We don’t care what happens in the onboarding process, but we know when we’ll need to trigger it and what we’ll do after its completion.
Abstracting and structuring your processes in a way which fits the situation is crucial to making processes that are workable for an organisation, as well as being easy to understand and visualise. So what’s the catch? If your tooling doesn’t allow it, or there are demands for paper hard copies of things or flat images to share, this can get tricky. You end up with multiple bits of paper/images, or you lose detailed flat copies. Don’t give into this kind of pressure, this is a trade-off worth making.
Use the simplest notation possible to represent your processes, the parts that are most intuitive. In the example above I felt able to use the BPMN elements for timed events, message start and message end, and data objects without fear of having to really explain anything to someone who has some previous experience with flow charts at least. Even the collapsed sub process isn’t too hard to understand, the “+” symbol implies that there’s more to the story hiding behind that symbol.
That’s not to say that you shouldn’t leverage the more advanced features, but in general only use the less initiative parts of the notation when you have to. There’s usually a balance to be had where the high-level processes are simple, and some of the sub-processes or processes aimed at certain parts of the organisation leverage notation, which requires more training.
Sometimes, there will be multiple ways to model things. Try to be consistent in your approach to these situations, and it’ll help everyone with their understanding. This includes being consistent with how you arrange your process diagrams and how you word activity descriptions.
There are situations where processes are rigid and must be followed. For good reason too, think of healthcare and financial sector settings where negative outcomes of not following safe processes are severe, and organisations have regulatory restrictions that require them to be able to show what they did.
That being said, there will always be edge cases and unfortunate circumstances which don’t fit your process. Have a process for handling these if your environment requires it, and only try to alter your process if these edge cases are frequent enough that they should be modelled.
Some notations allow for some known uncertainty. For example, what if our kitten-crazy finance team needs more flexibility during their negotiations with suppliers? BPMN provides the ad-hoc notation, which allows us to model a situation where we need to say, “At this point some, all, or none of these will need to happen, maybe more than once too.”
This allows individual activities to be tracked and documented rather than just having a black box, but without controlling the flow of the activities during this part of the process.
Don’t be afraid to change things, either. Iterate, validate and discover. A process that doesn’t work for all the people involved will not survive.
Hopefully, this has given you a sense of how important it will be to ensure that your processes strike the correct balance between being very verbose and capturing processes in very fine detail and being practical and useful in practice.
It’s a fine art, and there’s no clear-cut right and wrong. Generally, if it feels right and you can talk it through to a layperson in a few minutes, you’re on the right track!
Pete brings robust security expertise backed by his credentials as an Offensive Security Certified Professional (OSCP). With his strategic vision, Pete ensures our software architectures are secure and scalable, underpinning our clients' trust in our solutions.
