How to select activities for your process model – Some BPMN guidelines


Should everything that happens within your company be represented as an activity?

The picture above shows a list of possible actions that might be going on in an organization. As a process modeler, would you include all of them as activities in your diagram? Or do you think some are too detailed or rather not detailed enough to be considered an activity? Maybe you even argue that some of them are not relevant enough to figure in a process at all…

The decision on what to include as an activity and what not is not an exact science. Having worked for 5 years as a consultant in BPM for AGServ and its spinoff Agilians in Geel, Belgium, I have seen a multitude of different process models claiming to describe the same process. More often than not, different analysts make different selections of activities.

However, if you want to design a process model with the purpose of implementation, it is of vital importance that you select your activities at a suitable level of detail. This is especially so in case your organization is planning to use a Business Process Management Suite.

Currently, the ability to select a correct level of detail for your activities, is called expertise.

Based on experience, a seasoned process modeler will be able to understand what activities should be merged, split, omitted and included to end up with a process diagram that can be used for implementation. In this post, I will try to uncover the tacit knowledge of those experts and turn it into practical guidelines for junior practitioners. I propose guidelines for process modeling that – I think – will lead to higher quality process models. These guidelines are based on my personal experience. They are derived by looking at what works and what doesn’t work and by comparing models that can be implemented with those that either should not or could not.

I cannot and do not claim ownership of the truth. Neither do I claim all guidelines can be applied in all situations. Much like a compass, these guidelines provide direction without revealing the actual route.

As a subprocess, a compound activity, consists of many other activities, I will focus on identifying an atomic activity.

The guidelines are designed to apply for process models that are intended for implementation. But even then, diversions are always possible. Some notable exceptions are listed underneath.

  • The goal of your process model might not be implementation. Modeling to expose wasteful steps in a process, takes an approach that is different from modeling for automation.
  • Reporting requirements may force you to include some activities. This might happen if it is considered important to monitor the state of a process instance at a certain step. Monitoring on activity-level is simple and in most BPMS out-of-the-box. Activities that are important to monitor, might be of special concern to your stakeholders. They are unlikely to trust a process in which their valued step is merged into another.
  • The end user does not consider the breakdown of tasks natural. The end user will have to work with the automated process. If they feel the process is a burden rather than a simplification of their job, your BPM project will not be a success

  1. An activity is atomic, but only in the sense that an atom is atomic as well. It does consist of smaller actions, but not all actions must be activities themselves.  So how to interpret atomic then? An activity represents a coherent package of work that is completed as a unit. If necessary, merge and split your activities until each represents a unit of work. .
    1. An activity is typically not interrupted before completion. Once you start it, you finish it. These are the actions of which is typically said: “I will leave in 5 minutes, I will not start with this [activity] anymore.” It is perceived as unproductive or not workable to postpone completion of the task.
    2. An activity can be reasonably followed by as well as preceded by a break. Every activity can be preceded by a lunch/coffee/day break just as well as it can be followed by one. On top of not being interrupted, an activity is a small milestone on itself.
  2. An activity adds information to your case. Each time a process is started, you can imagine an empty file being attached to it. The process will be “building” the file to include everything that is needed to fulfill the process goals. You want every single step in your process to contribute new information to the file. This information might be needed to proceed with a following step in the process. Examples are production orders, sales offers, insurance claims, a credit history… But it may also be some form of proof or checkpoint that you need for audit reasons. I refer to delivery notes, letters of rejection, confirmations of payment… For every single activity, you should be able to state what new information is added to the file. If you cannot define this, kindly remove the activity from your diagram.
  3. An activity is completed by a single person There is exactly one person that will complete a task. Whenever multiple people are supposed to perform an activity, focus on the outcome of the task rather than the action. (See Guideline 2). A meeting as part of your process? Focus on the goal or meeting minutes and make one person responsible. Several stakeholders discussing a decision? Focus on documenting the decision and make one person responsible. A negotiation step? Focus on the outcome of the negotiation and make one person responsible. Damage checks, inspections, repairs … Focus on the damage/repair report… etc.
    1. An activity can be reasonably assigned to a person that did not complete the previous activity. This is true regardless of the swimlanes of both activities. An activity is a unit of work. Completion is meaningful and a milestone on itself. The new activity can be seen as a “fresh start”. Even though you could question the efficiency of actually assigning the next activity to another person, you could make an assessment of a form that is submitted by someone else.
  4. Activities do not depict transfer of work. This is well-known, but bears repeating. Transfer of work does not generate new information (see Guideline 1). Swimlanes and sequence flows express transfer of work. You are not supposed to model explicit tasks for this purpose.

As this is a preliminary attempt, all of you are kindly invited to provide feedback.  It would be a shame not to use the invaluable asset that is your experience. Together, we can create a practical list of guidelines and help junior practioiners to become experts more easily..

Looking forward to hearing from you.

This entry was posted in Business and tagged , , , , by Frank Vanhoenshoven. Bookmark the permalink.

About Frank Vanhoenshoven

Frank Vanhoenshoven obtained a Master in Business Informatics at Hasselt University in 2009. He joined AGServ and its spinoff Agilians, delivering consultancy as a Technical Consultant and Process Architect in various projects. Since mid 2015, he is part of the research group Quantitative Methods - Business Informatics at Hasselt University. Apart from his research activities, he is a member of the teaching team for the courses Business Process Management, Information System Analysis and Data Analytics.

4 thoughts on “How to select activities for your process model – Some BPMN guidelines

  1. Hi, the subject is interesting to me. I recently obtained a Master in Computer Sciences at Central University of Las Villas (UCLV) related to this topic. Mainly the objective of the work was to propose quality measures for the visual representation of business process models in BPMN. In this way the definition of a set of quality measures for the evaluation of the visual representation of the business process models was achieved, as well as a theoretical validation of the same. I am currently focused on making an empirical validation of the proposed measures and proposing thresholds for them.

    • Thanks for reading the post.
      Would you think the findings from your work are in line with the ideas presented in the blog? It would be nice to hear if there is anything you disagree with or anything you would like to add.
      (Maybe you have a link to an english version of your work regarding the quality measures? )

  2. Greate post!
    Uncovering the tacit knowledge seems to be an excellent practice. Nothing better than gaining specialist or group knowledge to abstract the best of the scenario.
    Do you think monitoring the the process and make improvements it’s a good practice or the most important is to hit the first time?

    • There are some potential language pitfalls here, but I assume you ask about the situation where you implement a process, then monitor to see if there can be a better scoping of tasks in your model.

      Few people would argue against monitoring and process improvement as key activities in a BPM-oriented organization. However, I think the focus of process improvement is mainly on improving your process rather than improving the representation of your process.
      In that regard, I would not consider it a good practice to make a random decision on your model and see which choices work and which do not.
      The aim should be to implement a process that is both realistic and workable from the beginning. Needless to say, this does not prevent you from detecting improvements anyway.

      I would also like to point out that a suboptimal decision on how to scope the tasks in your model may lead to frustration in the workforce. If the users have to return to their task list and claim the next task in the process at inconvenient moments, they may consider the process application a burden rather than a blessing. This can cause friction which can harm your BPM project.

      Having all of this said, it is equally important not to forget that a bad decision now is better than a good decision never. So, try to get it right from the start, but don’t stall implementation because you’re searching for early perfection.

Leave a Reply