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
- 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. .
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.