S02E05: Process Modeling Notations

As promised in the previous article, I will be discussing various different modeling notations and to get things going I am going the answer the fundamental question "what is the best modeling notation?" right away: it depends. Of course you all expected that answer, however, it is true. Depending on your intention to model, certain modeling notations will be more effective and suitable than others, but one thing is always good to remember: modeled processes (or documented processes as I like to call them) typically serve two purposes:

(1) to consume the information for various different purposes (think about training a new employee or defining a baseline for process improvement) and

(2) for creation/maintenance purposes, typically used by process analysts or subject matter experts.

As a result, there is a delicate balance between the information that you want to expose to the end users (the consumption perspective) and the information you need for proper process management and improvement (the creation perspective) and conserving this balance is like walking the tight rope, one misstep and you're going to disappoint a lot of people.?

Traditionally, the act of modeling or documenting processes was applied most frequently for large process-related projects, like ERP implementations (or nowadays for ERP to the cloud migrations) and for a long time this activity has resided under the umbrella of the IT organization. Throughout the years however, BPM has made its way into the "business" side of organizations and as a result, processes are being documented with a different perspective, imposing different and new requirements on the way processes are modeled. One of these requirements is that there are new and different pieces of information (I call them enterprise artefacts) that need to be captured in relation to the process and its activities, for example: you might want to identify that there is a risk related to a certain activity in the process and it would be good to capture that.?

At the moment that you want to start modeling processes a couple of things are important (at least in my opinion):

• The process logic needs to be recorded
• The process activities need to be recorded
• The interfaces to preceding and succeeding processes need to be recorded

Other than that, a number of other pieces of information are very valuable to capture, such as;

• The roles that are responsible for the execution of the activities in a process
• The applications that are used for the execution of the activities in a process
• Policies, risks or controls that have a relation to the process, or steps in the process

Too make a long introduction short, there are different reason to model a process, different use cases and different target groups and all of these considerations have an impact on the question: what modeling notation to use? So, what I will not do (and not even able to do) is to tell you what the best modeling notation is. What I can and will do is review the most used modeling notations and give you some guidance on the pros and cons of them. The shortlist of notations that I will discuss is (in random order):

• EPC (or Event-driven Process Chain)
• BPMN (or Business Process Modeling Notation)
• VACD (or Value-Add Chain Diagram)
• UPN (or Universal Process Notation)
• eBPMN (or... enterprise BPMN)

Now, there are many more modeling notations, but most of these are tailored for a specific use case. Examples are strategy models, business canvas models, value stream model (in the lean six sigma sense), business control diagrams, customer journey model and this list goes on and on and on.?

Let's get cracking with the most high level modeling notation type:

VACD (or Value Added Chain Diagram)

The concept behind a value chain was already described by Michael Porter back in 1985 in his best seller Competitive Advantage: Creating and Sustaining Superior Performance. This modeling notation is quite often used for the top levels of the process hierarchy (L0-L2 or L1-L3 depending on where you start counting). It is very usable for stringing together high level end to end processes and functional decompositions. It is characterized by the classic chevron icons that are used and typically do not use process logic (in the sense of gateways).?

EPC (Event Driven Chain diagram)

This modeling notation has been developed by IDS Scheer (later: Software AG) for use in the ARIS BPM platform. It has been used as the defacto default modeling notation for a long period of time, just think about the fact that SAP modeled all of its business processes that it covers with its ERP platform in the EPC notation. The core essence of the EPC notation is the combination of events and activities, stringed together using gateways (if necessary). This modeling notation can be used in a rich or clean setting, meaning that you can choose to include related enterprise artefacts like roles, risks, applications in the actual model (rich option) or that you "hide" this information in so-called functional allocation diagrams (clean option). The choice between the two is quite arbitrary and depending on the preference of the organization. Another very frequently used functionality of the EPC notation is the process interface, where you can make a link to other existing processes and since interaction between process happens all day, everyday it is important to be able to capture this information.?Below are some examples of EPC processes.

BPMN (Business Process Model Notation)

The BPMN notation has been developed by the Object Management Group (OMG) and has found its way into every self-respecting BPM platform. The primary use case for the BPMN notation can be found in the process automation areas of organizations. The notation is semantically strict, but therefore quite consistent (if you can read one BPMN model, you can read them all (almost)). The look and feel across BPMN models is also consistent because most if not all of the used symbols and icons are prescribed. This systematic approach to process modeling works really well if you want a system to consume the information rather than a human being, in other words, in comes the term: model to execute. The idea behind this concept is that you model a (part of a) process in such a detail that it can be understood and executed via an application without human intervention. I remember that we played around with this in my previous company about 6 years ago, and it did work, albeit not intuitively easy. Of course, this has been improved over the years.??

BPMN is still the notation of choice when it comes to the more technical user groups in application development or process automation.?

UPN (Universal Process Notation)

This is the notation that is the most unfamiliar for me personally, but let's give it a shot. The idea behind UPN originates from 2004 and was released in 2008 as an open standard by Nimbus (later: TIBCO, after acquiring Nimbus). It was developed to make process maps more readable and user-friendly, basically by leaving out as much technical noise as possible and focus on the information that users need to understand a process (think about the why, what, who, when and why, especially this last one is not often encountered in process models). The notation itself is tool-independent and quite information-dense (relatively high amount of information per cm2), enabling it to pack more information on a single page, but in my view also running the risk to overexpose readers to too much information at once. Nevertheless, the main difference between UPN and the other notations is that UPN is a true mapping notation and not a modeling notation. It can handle multiple layers of process maps (i.e. a hierarchy) but in principle it is not object-oriented and thus it will be more difficult (if not impossible) to maintain large repositories without a massive amount of additional work. I will add immediately that this will not always be a downside and personally I do see a use case for UPN when it comes to the consumption side of process maps, provided it can be integrated in a true process repository that is using object libraries and proper governance.?

eBPMN (Enterprise BPMN)

This modeling notation is a variant of the BPMN notation (you did not see that one coming, right?) and has been developed by Software AG and can only be found in their BPM platform (ARIS). Based on the experience and feedback of it customers, Software AG combined the pros from EPC and BPMN to allow its customers to model process with the semantic strictness and robustness of BPMN while at the same time allow for the enrichment of the models by adding enterprise artefacts that normally are non-existent in formal BPMN. The eBPMN notation is fully compliant with BPMN 2.0 so the interaction with other applications (like described in the BPMN section) is safeguarded.?

Summarizing all of this

It truly depends on what it is you are trying to convey to the reader when you need to make a choice on how to model your business processes. There is no magic spell that you can use to always end up with the perfect choice of notation, you have to try and sometimes fail. For some time I am trying to set up a decision tree for choosing the right modeling notation, but in all honesty there are too many variables to keep this decision tree simple.

We all have preferences, but if I have to share my experiences over the last 10 years of being really active in this field, I would say that BPMN (and eBPMN) is gaining ground fast for detailed process models (at the expense of EPC), VACD is still the undisputed king of the high level process domains and end to ends and UPN might make its way into the consumption realm of process modeling in then near future. Again, my personal view, nothing more, nothing less.

What say you?