Business process modelling: key elements
Building blocks to model any process
Modelling a business process often becomes one of the key steps of a business analyst’s job. A process model helps with visualising the problem area or defining the future state. It eases understanding of the subject matter, supports with scoping of solutions, quality assurance, and training. Overall, a good process model makes life easier.
However, with the number of modelling notations and tools on the market, it is sometimes hard to figure out what you need from a process model; especially when every vendor has an opinion.
So it’s important to remember that regardless of the modelling technique that you chose, at their core all process models are concerned with similar key elements. We’ll cover what they are in this article.
Structural elements of a business process
These are the building blocks; the foundational components of a process which need to be understood in order to be modelled.
Outcomes
Also called results or work products.
By definition every process exists to deliver a specific repeatable outcome. You need to be able to identify the outcomes of the process, and then make sure your model shows how those outcomes are produced.
Actions
The steps of the process.
Each action is an activity carried out by an agent — be it a person, an organization, or an automated solution. An action is an activity: an application of effort to produce a final or intermediate result that will be passed on to the next step of the process, or to the customer of the process as a final outcome.
Generally speaking actions can be manual or automated; performed by a human, or by a machine.
Process hierarchy
Sometimes when you model a complex process, some actions can be too sophisticated and will require further detailing. In this case we are talking about introducing sub-actions, or sub-processes. What appears to be just a single step in you current level of detail, can be modelled as a separate full-blown process if you dive deeper into it, e.g. you have a very simple three-step process: 1) accept the request, 2) review the request, 3) approve the request.
However, the step to review the request may prove to consist of multiple checks and elements, e.g. compare the request data with the reference database, check the legality of the request, assess the feasibility, compare it against company’s policies, etc. It may be a multi-step process on its own, but, for the purpose of the analysis, those smaller steps are rolled into one bigger activity. This is something you want to understand and potentially capture in your modelling.
Generally speaking, processes are often organized into hierarchies. On the top level, you may have some process groups as big collections of processes, e.g. Marketing, Communication, Production, etc. Each one can be broken down into a value stream adding steps that convert resources into valuable outcomes. Each value stream can contain one or multiple high-level processes. Those can be broken down into detailed business processes. Those can in turn be broken down into individual step definitions and workflows — essentially working instructions on how to execute individual steps of a bigger process.
This model is not ideal, and different companies and different process areas will require different depths of hierarchy. It is important to understand which higher level activity your process belongs to when modelling activities.
Participants
When there is an activity, there is someone performing this activity. That is what process participants capture.
You need to understand who is involved in doing the work, and how the work item travels from one participant to another.
Triggers and other events
Sometimes things happening outside of the process affect your process. These are called events.
A great example of an event is your starting trigger — an event that initiates a process. A trigger event happens in the world, and it has meaning to the process.
Other examples of events can be time events (e.g. time lapsed since an activity started or finished, or a certain date or milestone achieved, etc.), conditional events, results of other processes, errors, etc. An event is something that matters for the process but is not produced by the process activity per se, or is not a part of the process activities.
Process logic and control flows
The majority of process notations will have some rules for how to put the structural elements together. They may define a further breakdown of these elements into sub categories, etc. Or they may have certain rules for certain types of elements. In a nutshell, any process model will show you: the steps, who performs them, which events matter for those steps, and which outcomes are achieved.
However, when you have a process consisting of many steps, very rarely those steps are performed in no particular order. Usually, steps must run in a specific sequence. So, after you’ve identified the steps and events of the process, you need to make sure your sequencing is correct.
Sequencing the steps
In a simple scenario when steps are linear, you just work with your stakeholders, or observe the process, or study the documentation and eventually place your process activities in a line, connecting them with an arrow that will show the order of execution. This means the previous step has to finish for the next step to start.
Alternative paths
Sometimes, you may encounter variations in the process flow. Some steps are mutually exclusive, which means only one of another step can be performed, and there is some decision logic that tells you which one to choose.
This will be shown as a decision node in the process flow. It is customary to use a diamond shape to indicate a decision, but different notations may have different visuals for it. Conceptually it is the same — a decision helps you figure out which flow to follow after the decision point.
Often you will have some annotations to help decide which arm of the flow to choose.
Parallel activities
Some decisions are not mutually exclusive, meaning the process may follow multiple or even all possible paths.
These are sometimes called forks — they split the process into multiple streams that run in parallel and then converge at some point later on.
Termination events
Some process steps may result in the termination of the process.
In our example process, it occurs when we disqualify a prospective client. We can make it explicit by using a special symbol.
When to terminate a process is an important part of process logic, and it is not any less important than any other element. Sometimes a process just gets into a state when there is no need to continue with it, e.g. a quality check is failed or legal eligibility of the particular request is failed, etc. Each termination will potentially map to one of the process outcomes as defined above. Indicating it visually makes it explicit and removes the confusion as to whether it is meant to be the end of a process or the modeler just forgot to draw a line.
It is also a good practice to clearly indicate the starting event of a process. Not everyone from your audience may have a habit to read from left to right for example, so a clear indication of a start may make your diagram better — it may also explain which event(s) trigger a process.
Participants
When you have multiple participants in a process, it is also important to understand how the work is handed over from one participant to another.
In addition to assigning responsibilities, this may also uncover hidden steps. For instance, imagine that one department finishes working on a contract and hands it over to another department. Seems simple. Until you ask a question about how the work gets there? It may turn out the documents need to be sent via courier services which are provided by a third party business altogether — this is a massive part of the process which could have been missed.
Information objects
Finally, some steps of the process may not only generate control flows — which tell what is the next step of the process — but also signals or messages. These are events and activities that do not directly contribute to the progression of the process, but rather serve as information exchange elements. A message can be sent to another party to get informed about the status of the process, or to trigger another process on their side. This way a message will serve as an event in another process and can be used as one of the ways to orchestrate multiple processes — to get them aligned via messages.
That’s it
And that’s it in terms of the key elements of any process and the key components of process logic. If you:
1) Capture the following elements:
- Outcomes
- Actions
- Participants
- Triggers
2) Sequence them using control logic elements:
- Alternative paths
- Parallel activities
- Terminations
3) Add participants and information objects
4) And find a place for it in the process hierarchy, then
it means that you’ve done all the heavy lifting in preparing your process for modelling. Now, you just need to pick a modelling notation and plot your elements following its rules, being confident you’ve got all you need to capture the process.
Business process modelling is covered in more detail in my Coursera course. Check it out!
Want to learn more about business analysis directly from me or read my book? Explore the options ;)
If you enjoy reading stories like this and want to support me as a writer, consider signing up to become a Medium member. It’s $5 a month, giving you unlimited access to stories of Medium. If you sign up using my link, I’ll earn a small commission.
