Customers don't care about BPM cycles

As you might have read, this year Gartner discovered that BPM is about the customer*

*Italic text is intended to be a little sarcastic

Customers? Please, come on. What else? Oh yes, a process can have more stakeholders, but in the end they all can go home if your processes don’t serve customers.

A process is a means to deliver a result and if nobody wants that process result, there is no need for that process at all. To me that’s the essence of BPM; executing useful processes.

BPM cycle

But - what’s in a name - BPM is also about managing those processes. And if you read about BPM, you often run into the following picture of a BPM cycle.

For sure it’s depending on how you explain the terms, but to me it is missing the fact that managing processes happens on different levels. I’d like to call it the difference between “On the playfield” and “In the locker room”. I wrote about it in an earlier post.

It’s not one flow

I was triggered to write this post because of the fact that “Design” and “Monitor” are drawn in the cycle as they are part of one flow. In my opinion those are actions that happen on different levels and I think that these different levels of “managing processes” are not acknowledged in this cycle.

To explain this, I’ll take a simple pizza example. Assume that a pizzeria wants to deliver pizzas, so the process ‘Deliver pizza’ needs to be designed. This means thinking about aspects like:

• How do we make a pizza?
• How do we deliver a pizza?
• What tools do we need?
• How many supplies do we need?
• What kind of people do we need?
• What information do we need?
• How can customers contact us?

I think you are very familiar with process design, so you know what I mean.  And for now I assume (like many process improvements books do) implementation happens by miracle and the process can be executed. This leads to the first part of my alternative cycle:

That brings me to the essence of this post.  What you often see is that a process is designed in general for “someone who wants to have a pizza delivered”.  

More cases

But, there are many ‘someones’, so in real life execution, there are many cases for which the “Deliver pizza” process is executed.

At a certain time at night there might several cases in the process. You might know those Pizza companies where you can track pizza orders live on a screen. In a simple picture it could look like this:

The colored balls represent the cases currently in the process. Overviews like these are what I would call, good old, process monitoring.  

So if you want to know the status of all cases at real time, you need to put some monitoring on top of execution.  That’s happening on case level, not on process design level. That leads to the next addition to my cycle:

Process result and goals

Customers don’t care about process design, they care about their individual pizza order and they expect that their order is delivered as promised.

So during process design you have to think about “What do we promise to each individual case?”

Then you have to be aware of the difference between process result and goal.  In this case the result is “Pizza delivered”. That’s what millions of pizza companies do, but the goal is what you promise about that result.  And that could be promises, depending on your strategy, about quality, time or costs.

But, let’s keep the goal simple for now and let’s decide the goal is “within 30 minutes”. 

So the final promise of the process to an individual customer is “Pizza delivered within 30 minutes”

If that is the promise, monitoring should also tell you what the status of that promise is for each case. So, in the pizza example, monitoring should tell you the expected delivery time of cases:

And when processing of cases continues, it is possible that for some cases the promised delivery time cannot be achieved.  The goal of monitoring is to make you aware of that. After a while, the status of cases could look like:

Being able to act

The red case is expected not to be delivered within the promised 30 minutes. That’s nice to know of course, but quite frustrating if you cannot act upon it. One of my sayings is “What’s a speedometer without a throttle or a brake? Useless.”

Being able to act is about flexibility on case level. Does the process design offer flexibility to act during execution?  In the above example that could mean immediately pick up the red case and give it a higher priority, by stop working on cases that are still on time.  

If that flexibility is made possible, monitoring leads to immediate adjustment of execution.

That makes the alternative cycle look like this:

The picture above is what I think process management should be about. But to be honest, it could better be called case management, because you manage the progress of all the cases.

From the field to the locker room

The cycle “Execute- Monitor- Adjust” is what I call “Playing on the field”, because you can only win a game when your are still playing. You can only achieve that 30 minutes delivery time when the pizza is not delivered yet.

But there is also “Locker room talk”.  After you seem not to be able to solve it during the game and lost several games in a row, it might be time to discuss how the playing strategy can be changed. In the locker room.

So when you see that more and more customers start to complain about late delivery and you are not able to solve it during execution, it might be time to take a look at the process design. That’s the traditional process improvement cycle. After you measured that the process is not performing as expected, the process can be analyzed, which can lead to a redesign the way you would like to execute the process. This can mean changes in the workflow, tools, people etc.

That makes the cycle, or actually 2 cycles, complete:

 

The picture itself is not important, but with this picture I’d like to make clear what BPM is about.

On top is execution. That’s the most important to customers. When you have more customers, the cases can be monitored and when the process doesn’t perform you could try to redesign it. 

Who is responsible? 

This also makes it possible to put the roles  "executor",  "manager" and “owner” (that's how I call them) on top of the picture.

These are just roles, but who is playing these roles is depending on the way you would like to manage your process.

For example, for my own process “Deliver training”, I am the process owner, process/case manager and , luckily, the process executor.

To conclude; a comparison

In this post, I went from one picture of a cycle to another picture of a cycle to distinguish management on case level from management on process level.

When you compare my final picture with the original one, you see that ‘Optimize’ and ‘Model’ are gone.

To me, “Model” is not a separate step, but is an activity you could do during Design. It’s a way to execute the design step.  I think it was in the original cycle because it was BPMS oriented.  

I didn’t add “Optimize” as a separate step, because I think it isn't an activity, but the goal of both cycles in my picture.

The monitor cycle is about optimizing the experience of individual cases.  

The design cycle is about optimizing the process when process performance is lacking.

What cycle gets the most attention?

Which of the two Optimize cycles gets the most attention is depending on the level of flexibility you allow, or are able to implement in the operation of your processes.  

If you like strict procedures that cannot be changed for an individual case, you decided to switch off the monitoring cycle.

If you allow (or need) more freedom during execution, you have a more flexible monitoring cycle. 

I also spend some words on that here. 

But the biggest difference between the original picture and my picture is the place of execution. I put it on top, because most companies already have processes and in the end execution is the only way to serve your customers.

And yes, those processes could possibly be improved. And the cool thing?

Now you got 2 cycles for that! ;-)

Happy processing!