Without putting much thought into the details of how to use pools and lanes, BPMN practitioners commonly employ these elements based on the following definition:
- BPMN Pools describe whole organizations and contain lanes.
- BPMN Lanes describe who is executing a specific set of tasks.
While these statements are valid, a deeper understanding is required to produce high-quality process models that can serve as a proper foundation of your BPM initiative.
Let’s have a look at a bank credit quote creation process.
According to our basic understanding of BPMN pools and lanes, we might model the process as follows:
However, when paying attention to detail, we see that the diagram doesn’t comply with more detailed good practices for using BPMN pools and lanes:
- Only things that matter to us should be modeled within an expanded pool. In our example, ‘Customer’ should be a collapsed pool: we don’t control what the customers are doing, we just know we receive credit requests from them. They might send the quote to their financial advisor asking them for feedback for example. Modeling the customer part of the process dilutes our modeling scope. As a rule of thumb, we can say that a process diagram should contain exactly one expanded pool, which contains the process in scope - and if necessary one or multiple collapsed ones.
- BPMN Lanes should represent specific roles. The lane ‘Sales Department’ is not sufficiently specific. We need to define what roles are exactly in charge of the different tasks. For example, the task ‘Prepare special terms’ might need to be executed by a senior or specialist role.
- BPMN Lanes should not represent individuals. The Lane ‘Joan Doe’ is too specific. If in your real-world process, the task is always executed by one specific person, you most likely have a problem. The process can’t be properly executed when this person is on sick leave or vacation. Moreover, when the person leaves the company, she might take a lot of implicit knowledge with her. In our example, you probably want to introduce a ‘Risk Analyst’ role (and possibly a ‘Risk Analysis’ department).
Good Practice for BPMN pools and lanes
Let’s now adjust our process diagram to improve the weaknesses we just identified:
As you can see, the scope of the diagram is now clearer. The events and tasks in the ‘Customer’ pool didn’t provide any additional meaning. In the Sales Department, we identified roles that are in charge of executing different sets of tasks and the ‘Risk assessment’ task is now no longer mapped to an individual.
Depending on the actual scenario, you might furthermore consider the following adjustments:
- To help readers understand where the diagram is located within your process landscape, you can replace the pool name ‘Bank’ with the name of the end-to-end process, for example ‘Credit: request-to-grant’.
- The task ‘Calculate terms’ might be actually executed by a computer system. In such a case, you should represent the system as another lane, so readers understand that this task has been automated. As an alternative, you can use a service task.
- You might not be in control of the Risk Analysis Department, so you can model this department as a collapsed pool. By definition, communication between pools requires the use of message flows. This facilitates the creation of well-defined interfaces for inter-pool communication.
Conclusion
Rethinking the way you use BPMN pools and lanes in your BPMN diagrams helps you to create concise and understandable diagrams as it prevents unnecessary overhead when documenting your process landscape in the SAP Signavio Process Manager. Properly employed pools and lanes provide not only a clear and transparent overview over responsibilities, but also well-defined restrictions of the diagram’s scope. For further reading, we recommend Bruce Silver’s BPMN Method & Style.
Pro Tip - What does the spec say?
The BPMN 2.0 specification states that “a pool is the graphical representation of a participant in a collaboration”. Consequently, using pools primarily for whole organizations, - for example 'Bank' or ‘Customer’ - as well as using pools to set organizational boundaries - for example ‘Sales Department - is consistent with the spec.
However, BPM experts recommend to name pools after the corresponding end-to-end process (see for example in BPMN Method & Style). This facilitates process awareness. And in many cases, the organization name is obvious, anyway.