Pools
A pool is a basic BPMN element that sets the boundaries of a business process. A pool will contain at most one business process. This means that two processes have to be modeled in two different pools. A pool may have visible internal details in the form of a process that will be executed (called a “White-box Pool”), or a pool may have no visible internal details (called a “Black-box Pool”). The type of pool that should be used will depend on the level of detail needed and the specific context. “White-box” pools are most commonly named after the corresponding business process (e.g. “requirement management process”, “help-desk process” or “service delivery process”), whereas “Black-box” pools are commonly named after the corresponding organization, person or system (e.g. “supplier”, “customer” or “content management system”).
Lanes
A Lane is a sub-partition within a pool and is used to organize and categorize activities of a process. Most commonly, a lane represents an organizational role (e.g. developer, analyst and manager). However, lanes may also be used for other purposes (e.g. first phase, second phase and third phase)
Common misunderstandings
The meaning and semantics of Pools and Lanes are commonly misunderstood. For example, a set of pools can be incorrectly treated as a set of lanes within a single pool or vice versa. This leads to syntactically and semantically wrong process models.Because of the semantic differences between pools and lanes, the BPMN flow elements (activities, gateways and events) are connected differently depending on whether they are used within a pool or between pools. Within a pool, BPMN flow elements are connected with sequence flows in the following ways, presented in Figure 2.
Only message flows can be used when communicating “between-pools”. Message flows indicate the exchange of messages between two pools or processes, including their synchronization. Message flows can be used as defined in figure 3:
Note that in both cases the connections are allowed only between elements, as represented in the previous two figures. Based on these misconceptions, the following three mistakes are common when modeling BPMN:
Mistake 1: Missing Sequence flows
Problem. When modeling multiple pools (e.g. in business-to-business situations, where two or more processes interact), a common mistake is when activities in a Pool are not connected to sequence flows. The most frequent reason for this mistake is that a modeler may treat multiple pools as a single process and incorrectly interpret messages flows as way of indicating a sequence of activities. This kind of process model is not valid because the sequence of activities has not been clearly defined.
Solution. The modeler should always model and validate individual pools, and bear in mind that a pool cannot contain more than one process. This means that all flow elements in a pool should be connected using sequence flows as defined in figure 2 and figure 3.
Mistake 2: Incorrect Usage of Sequence Flows
Problem. Another common problem when modeling multiple pools is that a modeler may treat a set of pools as a single pool with multiple lanes. In this case, a modeler uses sequence flows between pools. The end result will be an incorrect model (see figure 2) of a single process that spreads over the boundaries of the pool.
Solution. The most common solution to this problem is to exchange pools with Lanes within a single model, as presented below. If several pools need to be used (perhaps when several independent processes exist), the solution to Mistake 1 should be used.
Mistake 3: Improper use of Lanes
Problem. Sometimes a modeler may incorrectly treat a lane as a pool, thereby representing individual processes within separated lanes. This is wrong, because a lane is just a “activity-classifying mechanism”. The figure below shows this mistake.
Solution. The most common solution to this problem is similar to the previous one; define a single process out of two (shown in Figure 9). This means that the redundant start and end events are removed from the model. In the case that several pools are actually required (several independent processes exist), the solution to Mistake 1 should be used.
Nevertheless it is important to mention that it is not syntactically wrong if a single process has two start or two end events! For example, several different events could start a process in different places, for instance; an asynchronous start of a process through a message trigger, or the periodical start of a process every morning. On the other hand, it is common that a process ends at different end states (e.g. “successful treatment” or “unsuccessful treatment”).
Conclusions
This article introduced the concept of BPMN “swimlanes”, which can be modeled with “pools” and “lanes”. At a glance, both elements look very similar, however, they have completely different meanings!A pool is a container for a single process, whereas a lane acts as an “activity-classifying mechanism”. Based on these differences, the way in which BPMN Flow elements are interrelated differs completely. In the case of between-pools interactions, only message flows can be used. On the other hand, only sequence flows can be used within a pool and between lanes.
0 comments:
Post a Comment