Business process modeling requires us to model behaviors of people and organizations. Those behaviors often involve waiting. Prescribed delays, or waiting for a specific time or date is what we can represent with an intermediate timer event in the sequence flow of a BPMN diagram. This article shows an example of how to model this delay in a business process.
Background
We presented an introduction to BPMN diagrams over a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.
The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).
Intermediate events are one of the more unfamiliar items in the BPMN language. They also allow for some of the cleanest, unambiguous expressions of steps in business processes.
Intermediate Timer Events
The BPMN intermediate timer event allows us to either have a process wait explicitly, or have a process react to the passing of time (for example, if someone does not pay a traffic ticket within 30 days, a citation will be issued). In this article, we will look at an example of a business process that waits until a predetermined time before continuing.
When we use an intermediate timer event within the sequence flow (aka normal flow) of a process, it indicates that the process will wait. An intermediate timer can be defined to wait for a fixed amount of time – 30 days, 20 seconds, etc. An intermediate timer event can also represent a delay until a fixed time or date. For example, a continuous integration process might wait until 3 a.m. before initiating network-intensive automated tests.
In this example, a process waits until either the first or the fifteenth of the month before continuing.
This is a business process modeling example of the compensation relationship between a contractor and an employer. The contractor does work, submits an invoice, and receives payment. The employer receives an invoice, and then waits until either the first day or the fifteenth day of the month before paying the contractor.
The BPMN representation of this delay is very easy to model and to read with an intermediate timer event. We can imagine the business queueing up all contractor payments until the 15th of the month. We can imagine a desperate business waiting even longer when trying to manage cash flow problems, or earn extra interest at the expense of their suppliers.
If we were to use a classical flowchart to depict this delay, the employer’s process might look like the following
While this can also be easily understood, it requires an extra step of processing to evaluate the common decision-point symbol with its flows to determine that it is acting as a delay. With larger diagrams, this can become somewhat tedious. The BPMN intermediate timer event, is starkly contrasted by the intuitive interpretation (clock equals delay) and distinctive appearance without additional flow elements (connectors).
Summary
The intermediate timer event, can be used to represent delays in a process by including it in the sequence flow of the process. It is distinctive in appearance and easy to read. The proper interpretation of an intermediate timer event is straightforward, unlike a decision element in a classical flow-chart, which is overloaded to achieve the same functionality.
A question from a reader: “I don’t understand the solid line in the contractor pool between Submit Inv and Rec’v Pmt.. Seems there should be no line because the contractor has nothing to do with that process. Am I close?”
Good question about the connector. One thing about BPMN is that within each pool, the process is as it appears to the owner of the pool. From the contractor’s perspective, he submits an invoice and gets paid. The same way that he would throw a ball up and catch it. The fact that there is something else affecting the sequence of events is irrelevant to the contractor. His process (as far as he knows) is to get paid, if he submits the invoice, without having to do anything else. The messages (dashed lines) between the swim lanes indicate that the process involves communication, and lets anyone reviewing the diagram appreciate exactly what it is that “someone else” has to do.
BPMN is good that way, in that you can view the process from either participant’s perspective, and overall.