Fire and Ice. Part 4. BPMN Process Models

Prologue. It took a while, but we finally reached a detailed level, where most of the BPMN treatments begin. In the previous installments, modeling of interactions between participants (Conversation) and pools (Collaboration) was taken care of. Now, modeling of the process itself is the subject of a quick overview. Its elements will be discussed using a part of a full process model, to be revealed later. The basic process elements are presented on the picture below.  

Process. BPMN defines a Process as “… a sequence or flow of Activities in an organization,  with the objective of carrying out work. In BPMN a Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows.”i A process can be depicted either on a Collaboration Diagram, generally if there are several pools, or on a  Business Process Diagram, if there is only one pool. In any case, a process must be fully embedded within one pool and it can communicate with other pools only via message exchanges.  



Activities. In general, “… an Activity is a generic term for work that company performs in a Process.” Activities are thus the executable elements of a Process. The basic activity categories are Tasks and Sub-processes. A Task is an elementary Activity, “… used when the work in the Process is not broken down to a finer level of Process Model detail”. The most common Task types are:

• A Manual Task, performed by a human without any interaction with software
• A User Task, performed by a human with software support
• A Service Task, fully automated and performed by software without any human participation

On the picture above, activity Check PO is a manual task, whereas Enter Sales Order is an example of a User Task, as indicated by icons in the upper left corner. As for a Sub-process, it is subdivided into activities on a lower level of detail. The Check Stock Levels activity is a Sub-process and there is no icon on its symbol this time, as activities of different types can be hidden inside. Instead, a small ‘+’ sign indicates this Activity can be expanded. In fact, its contents can be embedded within the parent diagram, as the BPMN specifications require such a facility.    

Events. The concept of an Activity and its classification are kids stuff when compared to BPMN events, as there are literally tens of event types and various ways to classify them.



The Event concept is fundamental to BPMN, as it allows to describe processes in an event-driven manner. In general, “… an Event is something that happens during the course of a Process.  Events affect the flow of the model and usually have a cause (trigger) or an impact (result).” There are three major categories of events, depending on how they affect the process flow:  

1. A Start Event begins the Process flow and to avoid confusion, only one Start Event for a Process is preferred. PO Received is a Start Event, triggered by arrival of a Retailer PO message.   
2. An Intermediate Event indicates something that happens between the start and end of a Process. Such events are usually related to intermediate messages sent or received. Production Order Transferred is an Intermediate Event.   
3. An End Event indicates where a path in the Process will end. As many End Events as needed are allowed, as the Process may end in many ways. Within our sample, Correction(s) Request Sent is an End Event.   

Although there are few generic event types without explicit triggers and results, these concepts   are precisely the reasons why events multiply so happily. The kinds of event triggers and results are indicated by small icons inside their symbols. In order to see the wood from the trees however, we will use only one kind of a trigger and result, namely a message.



Two of the presented event examples have a small message icon inside. In BPMN-speak and in line with its conventions, PO Received Start Event catches the incoming Retailer PO message and the icon is transparent. Production Order Transferred Intermediate Event throws the Production Order message and this in turn is indicated by a black icon.     



Gateways. “Gateways are used to control how [Process paths] converge and diverge within a Process.” In other words, they are decision points concerning further Process flow. “The term ‘Gateway’ implies that there is a mechanism that either allows or disallows passage through the Gateway”. Again, there are plenty of Gateway types, but only two of them will be utilized in the ACME case.



An Exclusive Gateway is used to create alternative paths within a Process flow. This is basically the “OR” logical operator, as for a given Process instance only one of the paths can be selected.  A PO OK ? is an example. A Parallel Gateway is used to create or to combine parallel flows and acts as an “AND” . logical operator. Obviously, a Parallel Gateway initiates parallel paths without checking any conditions, therefore it is not labeled. Such a Gateway follows Check Stock Levels Sub-process.  



Sequence Flow.  Activities, Events and Gateways are the basic, elementary building blocks of a Process. Now for their connections. In general, a Flow is a directional connector between elements of a BPMN diagram. We already encountered a  Message Flow, used to depict message transmission between pools. A Sequence Flow in turn is used to connect Process elements. Both types of Flows are not equal and there are two complementary iron rules to be observed, under a severe penalty:

1. A Sequence Flow can travel freely within a pool, but cannot cross its boundaries.
2. A Message Flow can be used to connect Process elements residing within different pools, as well as to connect pools as such. However, it cannot be used to connect elements of the same Process, i.e. contained within one pool.

Lane. A Lane is the final part of the BPMN diagram puzzle. It is a partition “… used to organize and categorize activities within a Pool” and can be either horizontal or vertical.ii Lanes can be used for departments, jobs or applications. Within the OTC - Retailer Order – Fulfill Retailer Order pool, lanes represent departments, such as Sales Department, Warehouse and Finance Department.

The Process Model. We are armed now with all the necessary basic concepts, the time has come to present the complete Fulfill Retailer Order process, pictured above.

1. The process instance is initiated when the Retailer Purchase Order (PO)  is received in the ACME Sales Department. It is verified and if something is missing for example, the request to make the required changes is sent to the Retailer. The process reaches a premature end in such a case.
2. If the PO is correct, it is entered into the database and the process flows into the Finance Department. The Retailer balance is checked if the PO can be credited. If not, the Sales Department prepares the polite Retailer PO Rejection letter. Once it is sent, the process ends.
3. If the credit can be granted, the Finance Department books the PO. The Check Stock Levels activity is performed next, under responsibility of the Sales Department. If one or more of the required products are not in stock, the Production Order is generated. We will see how it works on a more detailed diagram for this sub-process.
4. Regardless of the stock level check results, the Retailer PO Confirmation letter is prepared, with estimated delivery date. If there is no Production Order, i.e. all PO items were in stock, the process can enter delivery arrangements at once. If however the Production Order was generated, it is transferred to the Produce Goods process. Subsequently, the fulfillment process pauses and waits until the Production Order is realized. Its completion means also the missing products are ready for delivery at the Warehouse.
5. The Prepare Delivery sub-process takes care of the shipment preparation. Once the shipment is ready, the Despatch Shipments via Courier process is advised. The Courier Services Company arrives every day to pick up all the daily shipments and the confirmation message is sent back.  
6. After shipment confirmation, the  ACME Invoice  is prepared by the Finance Department and sent to the Retailer. Afterwards, the pr ocess pauses temporarily again and waits patiently for payment.
7. Process flow is resumed when the payment confirmation is received, courtesy of Register Payments process. All that is left is to close the PO and the process ends successfully for good.

Lowest Level. All that remains is to present the lowest level models for the two sub-processes, Check Stock Levels and Prepare Delivery. The corresponding diagrams are pictured below and are largely self-explanatory. Please note the diagrams contain several Service Tasks, absent from the higher level picture. They have a small cogwheel icon in the upper left corner. Next installment soon.

Past installments of Fire and Ice Blog:

• Fire and Ice. Part 1. BPMN 2.0 Today - Overture
• Fire and Ice. Part 2. BPMN Conversations - The Big Picture
• Fire and Ice. Part 3. BPMN Collaboration - Collaboration
• Fire and Ice. Part 5. BPMN and the Forgotten Art

References

• i - Other elements are also Data Objects and Associations, but these are not part of Analytic Class.
• ii - The term Swimlane seems to be more suitable instead of Lane. For the record however, please note BPMN specifications define a Swimlane as a more general concept, namely as a “a graphical container for partitioning a set of activities from other activities”. Therefore, a Pool and a Lane are both classified as a Swimlane.