BPMN bites: Define the magic!

“BPMN bites” is a series of tips and tricks on getting started quickly with basic fundamentals of Business Process Model and Notation (BPMN) as defined by the BPMN 2.0 standard developed by the Object Management Group.

When defining a business process utilizing the BPMN standard, it is sometimes difficult to know exactly where to start.

• You are a subject matter expert in the process, or you are a technologist that has interviewed the SME about the process. So you are confident in the flow, how it works, alternate cases, etc………check.
• You have some kind of proper BPMN modeling tool….check.
• You are familiar with the BPMN standard. Perhaps you have been using it a long time, or perhaps you took a tutorial or read a book……check.

But in BPMN you have so many options for symbols to represent different things. Where do I begin? How do I know when I am ready to start modeling?

As someone who has trained people in BPMN 2.0 at Camunda, I have received this exact question before. The answer is actually quite simple. You need to know the criteria that need to exist in order to start your process, and you need to know the criteria necessary in order to declare that your process is now complete.

In other words, you need a well defined start event, and a well defined end event.

Believe it or not, that is it. This information is enough to say that you have a process in BPMN.

Let’s take an example of a business process where an invoice is received, and the company needs to pay the invoice. In terms of the happy path, you should safely be able to declare the following:

• The process starts when an invoice is received.
• The process ends when the invoice is paid.

Think of an event in BPMN (represented as a circle) as a marker that represents that a status or milestone has been reached. Therefore, it is labeled in the past tense. So “Invoice received” instead of “Receive Invoice”.

While this simple model is a valid business process in BPMN, it feels like something is missing. Namely, there should be some details describing how the process goes from one milestone to another. How does the invoice go from “received” to “paid”? If you know this process, then you might be tempted to just start modeling like crazy at this point. Instead, I suggest that you keep things simple. Let’s assume that something happens to magically move our invoice status from “received” to “paid”. We can capture this work as an activity in BPMN.

Now it is good to verbally translate your process, so that you can confirm that you are on the right track.

1. The process starts when an invoice is received
2. Then, some kind of magic happens
3. Then, the invoice is paid.

Again, we still have a valid process. Now I think it is time to “define the magic”. If we had to describe the handling of our invoice in one single unit of work, what would we call it?

Starting every BPMN process this way has great benefits.

• It forces you to define entry/exit criteria for your happy path first. This is often missing in so many business processes that I have reviewed. Even worse, I sometimes see events labeled “Start”/”Stop”. Please, no!
• By creating a process with one and only one activity, it forces you to properly name your process! That’s right, the name of the activity that does everything is actually the perfect name for your process. So in this example, we will name our process “Handle invoice”. Why? Because that is what the process is doing. It is handling invoices.

Obviously, this is an exercise, and not a design pattern. You would not just dump a bunch of code into a single activity to do everything. If you did then you would not have much need for business process automation in the first place. Instead you have created a building block that helps to guarantee clarity and structure as your process definition grows.

For instance, very quickly you know that we should separate the reviewing of the invoice from the actual paying of the invoice. And what happens if we review the invoice and it is rejected? Now we have an alternate case; a way of ending the process without paying the invoice.

A good modeling thought here is to try to define your start and end criteria first, then model how you get there after that is defined. It will feel like you are modeling from the inside out. The mistake I often see is watching people think that they have to model from left to right, defining each and every alternate case before even bothering to define how the process ends. Instead, I suggest that you define your criteria, then you declare that magic is happening, then finally you can define the magic.

I hope that helps you in your business process automation journey! Considering following me for more BPMN bites in the future.