grzegorz.gruchman's picture

Prologue

If there were several dozens of activities within an enterprise, life would be simple, albeit not necessarily profitable for process professionals. However, since there are thousands of them, hierarchies of activities and/or processes should be used to comprehend such a crowd.

ARIS Process Hierarchies

ARIS has a very flexible facility to build hierarchies of processes. Models are assigned to diagram objects and this allows to link models on the same level of detail as well, using the so-called process interface symbol. 

Functional process classification hierarchy

The advanced approach to ARIS process architectures is based on the principles outlined in the previous Fire and Ice installment. To reach detailed process models in a top-down fashion, one of the two process hierarchies can be used. The first one is based on the classical functional decomposition method. Figure 1 illustrates such a hierarchy for a generic retail company, using a functional decomposition diagram. All activities within an enterprise are divided into Management, Core and Support Processes. Core Processes include Sales, with Channel Sales as one of components.

As seen on the fourth decomposition level,  Channel Sales activity includes Create Sales Order via Internet process. Once it is reached, one can navigate to the assigned detailed process map, Event-driven Process Chain (EPC). As there are no models below this one, one can call this process elementary. Using process interfaces, one can also explore the labyrinth of interlinked EPCs on this level.

End-to-End process classification hierarchy

The second hierarchy is more shallow. It has only two levels and is devoted to cross-functional End-to-End (E2E) scenario processes (see Figure 2). E2E Sales is one of the scenario process groups and it includes E2E Internet Sales process as one of components. It is portrayed on a Value Added Chain Diagram (VACD) and assembled from the elementary processes, identified within the functional decomposition hierarchy. One of its building blocks is Create Sales Order via Internet, with a link to the corresponding EPC model. Each EPC can be reached from the higher level model, but horizontal navigation between EPCs is also possible.

VACD defines lower-level process components and outlines their general arrangement. However, this works only if all lower-level processes are always executed and in a sequential manner. Otherwise, one has to explore the whole network of detailed, hard-wired EPCs. One should be careful however, as some of the links between them may lead to processes outside a given E2E scenario scope.

Sub-Processes and Call Activities

How does the hierarchy topic look like in BPMN? The specification deliberately does not define means for modeling of functional decomposition. Nevertheless, it talks about activity hierarchies and the notation is well equipped to handle hierarchical process models. The first mechanism is a Sub-Process, sort of a micro process model. A Sub-Process is embedded within a higher level process and it has a small ‘+’ marker at its bottom. It can be collapsed to hide internal details, it can be also dynamically expanded. Figure 3 illustrates this facility.

BPMN Sub-Process and its expansion facility

A Sub-Process exists only within the context of a single process model, i.e. it cannot be executed independently. This implies important modeling restrictions. Only a single start event should be used and it cannot have a defined trigger. In addition, pools are not allowed as well.

Such restrictions do not exist for a Global Process invoked using the Call Activityi. In contrast to a Sub-Process, such a process can be reused. It can be also executed independently, i.e. on its own. As opposed to a Sub-Process therefore, a global Process may have start events with defined triggers. A Call Activity has the same symbol as a Sub-Process, with a thick line around.

Sub-Processes in action

The Sub-Process facility exists mostly to make BPMN process models more concise and readable. As for the Call Activity, its mission is to reduce the number of process models and to enable their shared use. Unfortunately, BPMN provides no direct means to identify such situations, i.e. to identify the same processes used in different contexts.  

Please have a look at Figure 4. It presents the same E2E process hierarchy as before, using BPMN notation and hierarchical modeling style.ii Process classification is portrayed using a special type of model available in ARIS, namely a swimlane tree. Such a model is not defined in the BPMN specifications, but it fills nicely the obvious gap in this respect.

BPMN and E2E process classification hierarchy

The cooperation model defines elements of the E2E Internet Sales on the third decomposition level. For simplicity, all of the activities are sub-processes, modeled on separate diagrams. Please note the parent model shows how the process actually works, as it includes high-level business logic. As for the lower-level components, they are not directly linked and one cannot track the whole process flow without the parent model. Please note also the Internet Customer exists as a lane, not as a separate pool. This is justified by her or his lack of sovereignty over data entry activities, as they have to follow the logic embedded within the corresponding front-end application.iii

Instance Alignment

If you compare the BPMN cooperation model with the Value-Added Chain Diagram on Figure 2, you will notice it lacks the Bank Settlement sub-process. No mistake here, it was removed because BPMN pays particular attention to process instances. A start event creates always a new process instance and all activities executed till its completion have to be related to its initial trigger. In other words, there has to be a one-to-one correspondence between the instances of each activity within the executed process.  

This rule is called instance alignment.iv The process model portrayed using VACD fails the instance alignment test. While the activities Create Sales Order via Internet, Bill Internet Customer, Issue Goods and Ship Goods handle one order instance, the activity Bank Settlement is performed for a batch of orders. Hence, for simplicity, it was removed from the BPMN model.v Lessons learned from M2E projects performed so far clearly indicate a mismatch between classic process modeling and best BPMN modeling practices. This results in a lot of rework on the BPMN side after transformation of EPC models.

M2E ready hierarchical EPC process model

What can be done to make ARIS process models ‘M2E-ready’, as I call it? The last figure portrays how such a truly End-to-End hierarchical model may look like. VACD on the third decomposition level should be replaced by EPC model. This allows to include logic in such a parent process model, which is otherwise not possible. In addition, process interfaces should be discarded from the elementary EPC models. Process interfaces are convenient for detailed analysis, but they also frequently make the elementary process models not truly reusable.vi

Epilogue

The long-term benefits of hierarchical process modeling are independent of notation. Truly modular, context-free elementary process models can be used and reused as building blocks for various End-to-End scenario processes. Such approach makes also the whole process hierarchy more flexible and immune to ripple effects of change on lower levels. The parent process model in turn makes it also possible to comprehend and analyze the logic of End-to-End processes, even in case of complex ones.

The ideas on parent-child EPC modeling have been around for quite some time. However, they were rarely used in practice. With the advent of BPMN and Model-to-Execute they deserve a fresh look and serious consideration, particularly in new projects.

See also my previous posts on BPMN topic:

References

  • i - For the record, the Call Activity can be also used to invoke the Global Task, a reusable, elementary task definition, that can be called for execution from within any process.
  • ii - For details on hierarchical modeling style, see Bruce Silver, BPMN Method and Style, 2nd  Edition, Cody-Cassidy Press, 2011, pp. 54-55. 
  • iii - For detailed justification, see Thomas Allweyer, BPMN 2.0: Introduction to the Standard for Business Process Modeling, Herstellung und Verlag: Books on Demad GmbH, 2010, pp. 55-56.
  • iv - For detailed explanations of instance alignment, see Bruce  Silver, ibid., pp. 119-121.
  • v - For details on M2E see Model 2 Execute – from idea to reality for example.
  • vi - In real life modeling, there would be more differences between the classic VACD/EPC process models and the recommended two-level EPC structure. The parent process model would probably include more logic from the level below, whereas child process models would be simpler. 
Tags: BPMN