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.
Latest Articles
Comments on all Articles
