BPMN is a complex notation. Let's for example consider the 48 different events and their properties (type, throwing vs. non-interrupting vs. catching).
How, you might think, am I going to engage business users, using a notation even seasoned experts cannot understand in full detail?
The answer is simple: not every BPMN user needs to understand the minute details of BPMN – it's sufficient when everybody knows enough about BPMN to be able to communicate on the level of abstraction that suits them best. In this way, BPMN is comparable to English, which has established itself as the current lingua franca and is often spoken by non-native speakers who need to agree on a common language not every participant knows well, but all can communicate in.
When finding such a common denominator in BPMN, the challenge lies in employing the right level of abstraction on the different levels of your business process landscape. Employing dedicated BPMN subsets for each level of abstraction helps you to prevent unnecessary complexity and to embrace different modeling styles that support the corresponding business scenarios best.
The four key abstraction layers of a BPM-centered process landscape
For the sake of simplicity, let's subdivide the process landscape into four levels that represent the most important abstraction layers and have a brief look at the modeling elements that fit well to each level.
- The overview level On the overview level, you shouldn't use BPMN at all. Instead create value chain diagrams without any formal semantics. The diagrams should be so simple that any person in your company can understand them at a glance.
- The end-to-end process level End-to-end process diagrams provide a high-level perspective on your operations. Accordingly, they shouldn't contain any bells and whistles that distract from their main purpose of documenting business goal-oriented process flow. We recommend using only start and end events, tasks/collapsed sub processes, pools/lanes and connectors for modeling end-to-end processes.
- The business process step level
Business process steps are diagrams that document the organizational details of an end-to-end process activity. Consequently, you need a more expressive element set, that may include intermediate events, for example. For modeling end-to-end processes, you can start with the BPMN Core Elements subset and extend it, if necessary.
- The technical process step level
The technical level specifies the exact role IT systems play in your process. To specify technical details like exception handling and data storage, you need to make use of a large set of BPMN elements. Even on the technical level, however, you shouldn't introduce unnecessary complexity by using the all syntactical sugar the BPMN specification offers. As a practical example, if you want to deploy the diagrams to a process execution engine, you want to stick to the BPMN subset the engine supports
The levels we introduced don't need to exactly match the levels in your process hierarchy – they are simply suggestions. You can, for example, spread business details over multiple levels.
Getting started with using BPMN subsets
BPMN subsets are groups of BPMN element you can assemble for a specific purpose. For example, you can create a subset for all elements your modelers should use when creating end-to-end processes.
In the Signavio Process Editor, you can configure your own BPMN subsets with a couple of mouse clicks.
Create a subset for each abstraction layer you have in your business process landscape. You can deactivate (default) sets that your modelers should not use.
When modeling diagrams, you can select the subset that fits your modeling purpose best.
Adapting your modeling style to the perspective of your stakeholders
With element subsets and abstraction layers in mind, you can start to optimize your process landscape to communicate clearly and effectively with different stakeholder groups.
Using BPMN subsets is just one step on the road to better communication. BPMN is in this respect just like a natural language, with style and tone. You can manage your modeling style and the way you use the notation in the same way you do when writing emails and communicating with different stakeholders. People tend to do this naturally by changing vocabulary depending on whether the recipient is a casual friend, or a senior executive requiring a more formal approach. When embracing this approach you will intuitively adjust your modeling approach according to the stakeholder groups you want to engage with a diagram.
Further reading
In his book BPMN Method & Style, the renowned BPMN expert Bruce Silver introduces three levels of BPMN modeling:
- descriptive modeling,
- analytical modeling and
- executable modeling.
Whereas Bruce doesn’t mention an overview/process landscape level – which you shouldn’t model in BPMN – the other three levels mostly match up with the levels we introduced above. Microsoft’s Nick Malik employs an abstraction approach that’s inspired by Martin Fowler’s abstraction levels for software development. Have a look at their writings and decide which approach suits you best – and don’t hesitate to adjust any of the concepts to your organization’s individual needs.
For more information about BPMN modeling style, take a look at our modeling guidelines overview.
Get started with collaborative process design now and sign up for a free 30-day trial account.