BPMN Diagrams – Never Too Late For An Intermediate Timer Event

Business process modeling in the real world requires us to represent how processes deal with exceptions, delays and deadlines. Intermediate timer events can be used to model deadlines and the business processes for handling them.
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. In this article, we will look at an example of a business process that branches off in a different direction when a deadline has passed.

In this business process modeling example, a contractor performs work for a client, submits an invoice, and then receives payment for the work. If the invoice is not received within 30 days of the invoice due date, the contractor contacts the client with a follow-up call, and then receives the payment. If the payment is still not received within 90 days of the due-date, the contractor writes off the bill as a bad debt.

The default behavior, as represented by the sequence flow, is that the contractor receives payment after submitting an invoice. If 30 days pass after the due date of the invoice, it represents an exception to the desired business process. The exception handling routine is easy to differentiate from the normal flow of the business process.

Here’s what the equivalent process would look like in a classical flow chart. The classic flow chart represents the exception handling of a delayed payment with a decision box that loops back to the original “receive payment” step in the process. The same “loop back” technique could have been used in the BPMN diagram, but the format chosen above is easier to read and more explicit in indicating the normal process from the exception process.

Summary

We can model exception processes with intermediate boundary events. An intermediate timer event, when placed on the boundary of an event, represents what happens after a specific delay, or at a specific time (if the process is still within the annotated activity when the timer is triggered. This can be modeled with classical flowcharting techniques, but they are more cumbersome, and also are less effective at presenting the difference between the intended process and the built-in exception handling.