Time flies by so quickly, and it’s been too long before I could get back behind the writing board (also known as a keyboard) to share some of my thoughts with you all. This time I was triggered by a podcast episode (actually two episodes, and they are called 99 and 99.5) of the
What’s Your Baseline?
crew,
Roland Woldt
and
J-M Erlendson
in which they intensively debated the usefulness or lack thereof of the BPMN standard. Here’s a link to their episodes.
Part 1: https://www.whatsyourbaseline.com/blog/2025/10/06/episode-99-bpmn-3-pt-1-definition-history-and-complaints/
Part 2: https://www.whatsyourbaseline.com/blog/2025/10/13/episode-99-5-bpmn-3-pt-2-ideas-for-improvements/
What I will not do is to repeat all the points they were discussing (for that you can listen to their excellent podcast), but I would like to take a step back and actually investigate a little bit into how we look to the modeling of processes in the first place.
So, let’s get into it.
If we look back into the history of process modeling, we’ll find that the origins go back to the late ’80’s, early 90’s of the previous century. Topics like quality management, ISO certifications put a stamp on why companies would engage in the documentation of their business processes. Later on followed by the first massive ERP implementations (applications like SAP and Oracle are all build around a set of predefined business processes after all).
Slowly but surely, an additional use case for the documentation of process arose and that was the ability to use this information to communicate it to a much wider group of people, the end-users. As you can imagine, large organizations employ thousands of people (or more) and they all need to execute small portions of business processes. In the end, as an organization, you would like to make sure that everything they do is neatly aligned and that all activities serve the highest cause of the organization, being the strategic targets & vision. Little side-step here, the lack of this alignment from the strategy, via the operating model and processes to the shopfloor is the number one reason for strategy implementation or transformation failure.
So, where does this leave us with regard to the core essence of modeling? I really enjoyed the playful banter between Roland and J-M, but their message was absolutely serious: do we need a revision (updated version) of the BPMN 2.0 standard?
Bluntly put: we do…. but….
I get the feeling that we’re trying to manufacture a standard for process modeling that needs to be able to cover every possible situation and I believe that this line of thinking is what made ARIS very comprehensive, but at the same time incredibly difficult to implement enterprise wide (from an end user perspective).
Instead, I would argue that with current day technology we don’t necessarily need to keep the data and form in which it is presented in one single place. After all, different audiences have different requirements and desires for how to consume the information that has been documented.
What do I mean by that?
In the screenshot below, you’ll find the standard process model as a horizontal swimlane diagram, based on BPMN 2.0 standards.
Great for modelers and process experts, not so ideal for your average end-users. The information that is presented through the means of a flowchart is actually nothing more than entries in a database (at least, that is how it should be and how the most professional tools approach it and this is also exactly the reason why other tools look nice, but really can’t support an enterprise BPM implementation) and this means that we can also come up with alternative ways of presenting this information so that it makes more sense to clueless end-users (or is more easily consumable).
In the screenshot below is an example of an alternative way of presenting process information that is less centered around the structure of the process, but more around the information that has been captured about the process. End-users tend to find this an easier way to consume the information they are looking for. In the end, this is the exact same information, coming from the exact same place in the database, but represented visually different, easier to consume.
Because of the current capabilities, I would say that we are now able to disconnect the data of a documented process from the visual representation of this data and this means that we don’t need to have a single modeling notation to cover all possible use cases.
Just imagine the situation where you model a process (probably using BPMN 2.0 guidelines (or 3.0 in the future, who knows)), but you are free to chose how the various user groups can consume this information.
Modeling in BPMN is still obviously very important and relevant, certainly in more technical use cases where you want to orchestrate processes based on a process model. Automation works best when modeled in a standardized way, of course. I just believe that any standardized format for process modeling is not ideal for the vast majority of end-users and they simply represent a very significant factor for the adoption of the BPM implementation.
There, I said it… process modeling is important, but it’s not the only way to bring process related information to the people in your organization.
Now, let the commenting begin….
