The process model in BPMN: reducing its complexity.
Blog: Flokzu
Building a process model is the most relevant step to manage a business process under the BPM paradigm. Process modeling with the BPMN standard could seem difficult and scaring, but… does they really bite?
The BPMN bite
Business Process Model and Notation (BPMN) has become the worldwide standard for business processes diagrams. In fact, it is an OMG Standard. It is intended to be used directly by non-technical users (i.e stakeholders). But also by IT-staff (programmers, designers), to automate business processes using a BPMN compliant engine.
Ok, the standard is flexible enough to cover both, business users’ needs and technical staff’s needs for automation. This means the BPMN standard will need to support a wide range of elements and artifacts. Certainly, this leads to complexity.
As a way of example, the following image summarizes the type of events that you can use in a process model (source: BPMN 2.0 specification):
In other words, the standard is necessarily complex, to cover all and every single business process’s need. Said that, in the next sections we will see if this complexity is always necessary.
One process model for each audience
When we build a process model, we build it for an audience. If we are trying to describe the process for the CEO and Board of Directors, the most important thing is that the model is easy to understand. It should include only relevant steps and information. Technical details will make them lost their focus.
In contrast, when you model a process to be automated in a BPM Suite, you need the greatest level of detail. IT staff need to know every possible case, relevant data, and metadata to be stored, formal conditions for the gateways, etc.
A Process Model is firstly a communication tool. It must fullfill its audience needs. In other words, it needs to have the right complexity and detail level for this audience.
BPMN supports using different levels for different audiences. For example, you can define a process with a few “bubbles” that are subprocesses. You will show the top-level process to the board of directors, hiding the details of each “bubble”. But, when you pass the same BPMN model to the IT staff, they will explode those “bubbles”. Inside each “bubble” they will find the level of detail they need.
Process modeling toolset.
You may be thinking that you don’t need the full BPMN artifact set. Your particular business process is not so complex. And you may be right.
In fact, there are a few artifacts that are really necessary for any process model. Certainly, user tasks, gateways, and sending mails seem to be needed in most of your administrative processes.
In Flokzu, we carefully selected the most useful artifacts and put them in the toolset. In the image below, you see just a reduced set of BPMN artifacts. Some of them support configuration (for example, you can setup the Gateway as Exclusive or Inclusive).
This reduced toolset dramatically reduces complexity. You only need to learn how to use a few very intuitive artifacts. A business user will see the model, and just understand it.
Of course, when you try to model a complex business process, you will need more and more artifacts. The idea here is “hiding” them in the configuration of simpler artifacts. This way, you keep the first level of the model understandable for everyone. And those who need more detail can dig into the model to get the information they need.
No-code / low-code compromised?
When modeling a process to be automated, you need an automatic transformation from the “drawn” model to the “executable” model. This is what the no-code / low-code BPM paradigm promise. Moreover, this a very relevant instrument to increase the understandability of the model.
If you model a process and just pressing a button you have it running, you can show your user how it works. They can try the automated process, and get back to the model to adjust it. This improvement cycle notably accelerates the comprehension of the model and the business. People will get involved in discussions about the process, how to improve it, how to measure it, etc.
On the other hand, if you model the process, and you have to wait one day (or week) to have it deployed and available to be used, the involvement of the team will be much lower. This is why no-code / low-code capabilities are so relevant for a successful process modeling team.
In conclusion…
The BPM Notation is the worldwide standard for process modeling. Given it is very wide, it is also complex to understand all its artifacts. You can reduce this complexity identifying the audience of the process model and adjusting it for them in particular. Using a reduced toolset dramatically improves the understandability of the model. A low-code / no-code BPM Suite will enable trying the process and improve iteratively. This leads to a strong involvement and commitment of the process modeling team.
If you have doubts about what it would be like to use Flokzu in your company for process modeling and automation, we offer you a free trial of our Premium service. We will help you model your first processes (in minutes, and without complex configurations) and then automate them without coding.
Click here to schedule a 30 minutes working session to model one of your real business processes.
The post The process model in BPMN: reducing its complexity. appeared first on Flokzu | Cloud BPM & Cloud Workflow.
Comments (1)
Leave a Comment
You must be logged in to post a comment.
The original intent of BPMN version 1.0, which standard I commented on many years ago, was to analyse and document business process models. It was a wonderful thing for a business process analyst to create a model that reflected multiple business dimensions (organisation, process, information, events and locations). It was and is powerful as an analysis and documentation standard. Whilst it included a lot, it didn’t include much of the finger detail needed for runtime process design, including many of the event types.
BPMN version 2.0 is intended as a rigorous language that can be used to design processes, and does include a lot of detail, which I have used in a number of business process design and automation tools over the past fifteen years or so. However, the challenge in putting a detailed model together is socialising and verifying it. People can become lost with pools, rules for boundary events etc, and require more explanation and reinforcement than you might expect. It’s not supporting then that some vendors are not implementing the full standard in order to reduce visual modelling complexity.
Having used Flokzu a bit now, I think it has struck a good balance between the necessary detail and keeping unneeded complexity out of the visual modelling area; putting it instead in dialogue boxes. Flokzu’s models are readily understood by the business audience, and the process designer can then socialise the end product quickly thanks to the productivity of the Flokzu platform. I’m looking forward to using Flokzu in my consulting work as The Process Expert, and seeing Flokzu mature further given its amazing start.
Steve Barnes
The Process Expert