Intro to Business Process Modelling (BPM)
BPM is so important that it easily tops my list of essential BA skills. It’s one of my favourite things to do (in a work context), is easy to learn and is highly effective. To really understand and appreciate the value of BPM, let’s look at what is, how it’s used and why it’s important.
A business process is a sequence of activities or tasks that takes an input and produces an output. In fact, there is an easy (and quite ugly) acronym to remember the key aspects of a business process: SIPOC – Supplier (the person who supplies an input to the process), Input (the thing that gets transformed via the process), Process (the set of activities that transforms the input), Output (the thing that gets produced), Customer (the recipient of the output). However, I’m not really a fan of the SIPOC term, since it doesn’t account for other important elements of BPM, namely, actors, events and outcomes. Business processes are the means by which an organisation delivers its products and services to its customers. Without them, literally nothing gets done.
A model is an artificial representation of a real world thing. The representation is usually simplified compared to its real counterpart, in order to make analysis easier, by dispensing with minute details that don’t really impact the function of the thing.
So, a business process model is a simplified representation of an actual business process, and is generally presented as a diagram.
Why do we need them? There are several (very good) reasons, given here in no particular order:
· To enable analysis of the process (to identify inefficiencies)
· To enable automation (finding where tasks could be done by a machine, for example)
· To identify weaknesses in the process
· To communicate how something is done (e.g. for training purposes)
· To ensure consistency of process execution
· To satisfy a regulatory requirement
· To enable process improvements
· To support digital transformation or business change programmes
Clearly, many (maybe all) of these things can contribute to improved operational performance and perhaps more importantly customer service. So, it makes sense, then, that having clearly defined processes is a helpful position to be in.
Process models are generally drawn at 4 different levels of abstraction, defined below:
Level 0: the highest level, generally just the main function of an organisation, e.g. construction
Level 1: a map of all the processes that an organisation does, linked together by dependency
Level 2: the level we usually mean when we say process, the sequence of tasks that deliver an output
Level 3: a detailed, step-wise description for each of the tasks, like a procedural instruction manual
By the way, it’s timely for me to say that the terms ‘process model’ and ‘process map’ are frequently used interchangeably. This is not accurate, from a purist’s perspective (which happens to be my perspective!), so if a colleague of yours uses the term ‘process map’ when they really mean level 2 process model, do the right thing and politely correct them… then correct them again the next 17 or so times they repeat the same error, or until one of you concedes and agrees to let the other ‘have it their way’. Just to clarify, a process map is a specific type of process model – a level 1 process model (see above).
Anyway, it’s important to understand that process models exist in this hierarchy of levels. To help visualise it, here’s a diagram I once produced for training material:
My final point on BPM is that it’s very useful to use a consistent, well-defined format or notation across an organisation. This is for 2 main reasons:
1) it’s easy to have a common language to communicate in, where everybody can learn the meaning of the symbols and use them in a consistent way, and
2) common notations (for instance, BPMN and UML) have been developed over literally millions of hours of thought, trial-and-error and use, ensuring they are comprehensive enough to cover all the reasonable scenarios that a business process might incorporate.
This second point is especially important, since trying to represent a process for the purposes of designing software requires absolute precision and accuracy. I often think back to learning how to draw circuit diagrams in school, and knowing that if the diagram isn’t logically correct, then the circuit will not work as expected. Remember, those funny looking symbols exist for a reason.
Furthermore, learning to use the correct notation is easy. Really easy. And, once you know it, that’s another technical skill you can add to your repertoire.
So, by some way of conclusion, BPM tops my list of BA techniques because it is powerful, useful (nay, essential), and quick and easy to learn. What do you think? Do you agree or disagree? Was this blog post useful? If so, hit the like button and feel free to leave a comment.