Subprocesses In BPMN
As a de facto standard in process modeling, BPMN offers the possibility of reducing the complexity of a model by using subprocesses and thus creating a suitable degree of abstraction. Since an appropriate degree of abstraction is purpose-bound, it cannot be considered uncoupled from the objective of the model. While models, that serve as a base for process automation, must have a high degree of complexity, these details are not important for users from business areas in most cases. By using sub-processes, the practicality of a diagram can be maintained for both groups and complexity can be reduced as required without relying on different process models. Therefore, subprocesses do not only maintain the relevance of a model and thus the quality of it, but also have a positive effect on the reusability and cost of changing process models.
With the new release 3.26.0 of the BPMN Modeler Enterprise collapsed subprocesses can be expanded and edited within the parent process. To do so, an activity is declared as a collapsed subprocess and then expanded via the blue arrow, allowing it to be modeled.
Subprocesses can be nested as desired, so that several levels are created within one process. An integrated navigation bar provides an overview of the process depth and a possibility for navigation during modeling.
In the example of the insurance claim, the activity carry out payment is modeled as a collapsed subprocess. By clicking on the arrow, the displayed subprocess opens up and can be edited. The navigation bar shows the name of the collapsed subprocess and the name of the participant (Insurance Company) from which the process originates.
The hierarchy within the process encapsulates complexity and reduces it at the top level. If necessary, activities can be specified comfortably with the new feature instead of jumping between processes or creating new ones. In addition to an enhanced usability, this also increases the readability of the processes.
Diagram Links vs. Subprocesses
Although at first it may seem that subprocesses and diagram links serve the same purpose and are therefore easily interchangeable, a closer look reveals that the use cases of the two features are different. In the following, we will clarify when links should be used and when you should fall back on subprocesses.
Basically, subprocesses are suitable to abstract process models, whose size and complexity lead to confusion and consequently reduce the understanding of the process. In this case, it can make sense to make use of subprocesses and consequently increase the readability and clarity of the process. The evaluation of an appropriate degree of abstraction must always be related to the intention of the model. Certain processes have a high level of detail and therefore can not be considered helpful for the understanding of certain users. In this case, sub-processes help to simplify the process model and encourage consensus within different stakeholder groups.
During modeling, subprocesses should always be checked for reusability within other processes. If there are multiple uses for a subprocess, it should be modeled separately from the parent process so that it can be integrated by multiple processes. This can be done easily by creating a link within the parent process that points to the isolated sub-process. This way, complex processes can be created from existing sub-processes, resulting in service-oriented process modeling, which increases the reusability of the processes and reduces the maintenance cost.
It can be seen that subprocesses and diagram links are not mutually exclusive, but are complementing each other in various situations. As always, it all comes down to context.
It's Your Turn!
Try out the new release 3.26.0 and start modeling subprocesses within the parent process. Keep in mind the different use cases for subprocesses and when to rely on other functionality. Have any more questions? Feel free to ask!
Back to blog overview