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!

I think I'm missing a part

Readers who know me, might remember that I spent quite some years working for a vendor of BPM software. 

The first years we offered all kind of separate products that supported doing "something with processes".  Think about stuff like:

• Modelling tools to model processes (not only the workflow so also data, people, applications, etc)
• Workflow management tools to support the execution of well definable processes
• Case management tools to support the execution of more dynamic processes
• Process mining tools to discover "processes" out of log files of the systems you use to execute 

So, specific tools that were, at that time, quite good in what they were designed for. 

But, then came the time where "Holistic BPM" was on the rise; taking all aspects, that are needed to manage and (continuously) improve an organization by process, into consideration 

Technology wise it led to the era of the BPM suites. Since that time, the names might have changed into things like "Smart Process Platform" or "Digital Business Platform", but the main idea stayed the same: combining the functionality of the separate products and more important; make them work together. In a suite.

As a process nerd I thought this was amazing. Complete overview and control on all your processes from one overall platform. 

Starting with a process model, that, if you liked, could be exported to a nice process manual, but also the possibility to develop the model into a system where you can support the execution of a process. With work lists, e-forms, data-integration, monitoring; just everything that could be labeled "case management by process".

Wow, BPM suites; they sound like every process oriented companies' dream. Especially when you want to start form scratch and want to support the execution of your processes with BPM technology. 

But, the truth seemed that "starting from scratch" was an illusion in many cases. And that's not so weird, because organizations just have processes. Maybe they could be improved, but they are already executed. Every day. 

Besides that, there are many processes in organizations of which you could ask yourself if it's worth the effort to design them, including the supporting software, by yourself. 

Think about back office processes like "pay invoice". Many organizations just want "a tool"  they can use to do the job. Just buy some best practices (maybe with a little configuration) and get to work. 

And that's not so weird at all. I don't know many organizations (or actually some decision taking person)  that says "We want BPM".

But, I know many organizations that issue permits, repair bikes, treat patients or develop software. In short, the specific reasons why those organizations exist and customers like to spend their money there. 

And that brings me to the traditional BPM approach "a good process starts at the end" 

So, I would always start with a clear view of your desired process results. The extra post-it note about "wanting to sleep" is to stress that you always have to be sure that your process results still are the best way to help your customers. 

If yes, then ask yourself if that process result is delivered as promised. If not; that could be a reason to take a look at your process(es).

And you know that a process is set of collaborating aspects, of which supporting software is just one. 

Maybe you will discover that starting from scratch in a BPM suite is not necessary, but more and more you see that vendors offer "turn key solutions" build on top of their platform.

You'll find them in the warehouse in the "Smart process apps" storage shelf. 

But always keep wondering if your process would benefit from a  do it yourself kit or that a second hand bed from the jumble sale is more than enough.

God Natt and sweet processes!

On nice castles and managing processes

When you walk through Process Country, you might hear stories about BPM, workflow, Adaptive Case Management and Process Mining. I can imagine you might think; what do they all have to do with my day to day processes? 

I think they all have to do with managing your organization in a process oriented way. Be aware that "by process" is just one way to manage your organization, but as processes are ‘the things’ to solve problems (by their results), having more grip (or better; the right level of grip) on them might be a good idea. 

In my opinion a process oriented way of working, should start with thinking about what results (products/services) solve the problems of (future) customers. And yes, to deliver those results, processes are executed. 

You can see it as making a trip. Before starting a trip you (at least business wise, probably not private ;-) should know where you want to go to, or better; what problem you'd like to solve. In case of traveling that could be something like "I'd like to be at another place and the problem is that I'm not there". 

Then you have to decide a lot of things. The route, the best way of transport, best time to travel etc. Translated to a business process, this means that processes need many aspects (often called ‘enablers’) to perform. You need good people, right information, supporting tools and a smart route to follow.

Focusing only on the route (in process terms, called the workflow) is too minimal to understand what is needed to make a process perform. But this workflow is most of the time the skeleton of the process to talk about. So a process; at least you will follow a route to that destination. But, this route might not always be known upfront and there might be smarter routes, so pack your backs and ….

 …imagine you ended on the top of a hill somewhere in Europe. You realize that you are some kind of lost. But then, when the fog disappears, you see a beautiful castle on another hill, a few miles away. You decide that your desired result is 'being at the castle on the other hill' and you need a walk (a workflow) to get there.

But, between you and the castle there is a very large and dark (some would call it scary) forest. But, as always, you are lucky. Just before you want to start walking, a man comes out of the woods. He says he came from the castle and says he is called ‘mister structured’. That is why he has written down all the steps he took to reach the hill you are on. Although the man looks strange with his long jacket and pointy teeth, you trust him and follow his notes in reverse order.

Turn left at the big stone, follow the little path between the oak trees for 1 mile, cross the river at the wooden bridge and finally you reach the castle.

This was a trip that could, in process terms, be called ‘workflowmanagement-style'. All the steps are done, the result has been reached, but as individual executor you might have no clue why you are doing things.  It’s good old ‘Taylorism’ and is still suitable for some types of processes. And in our current world of ‘social’, ‘transparency’ and ‘co-creation’ there are still a lot of people that ‘just want to do their job’ and don’t care about process at all.

Back to the hill. What if you didn’t meet the man with the written instruction and had to start walking without his route map as a guide?

You just start walking and during the trip you will run into several things you have to cope with as they happen to you. So, you walk miles along the river to find a bridge, hide 45 minutes for an angry bear.  But your walk still has a desired result, so now and then you climb in trees to see where the castle is. After conquering several hurdles, you finally reach the castle.

In process terms, this trip could be called a process of the type ‘Adaptive Case Management’ (ACM).

There is a desired result (in ACM it’s often called a goal), but there is no predefined route. So, during the trip you continually decide what is the best next step. This is seen in processes where knowledge workers (actually I don’t like that word) have to solve problems for several cases, but where every case has its own unique problems and characteristics.

Talking about more cases; assume that there are also other people that want to reach the same castle but base their decisions on their individual experience and apply their individual knowledge.  Some are good swimmers and don't search for a bridge. Others carry an axe and cut some trees to create a path, etc. Depending on their situation they make different decisions and all create their own route.

This ACM style of process management might scare you, because it seems uncontrolled. But that is just how some processes work. It needs trust in your knowledgeable employees instead of micromanagement.  And yes, more control might be possible and needed for some processes, so back to our trip.

What if all these ‘knowledge travelers’ had GPS trackers hidden in their pocket? When you collect all that data, you finally end up with a lot of data about all the followed routes. You can use this data to find out what routes and what decisions had the best results. In this way the data becomes information. 

This way of ‘discovering the followed routes’ is what could be seen as what is called Process Mining. Process mining is a technique to discover ‘hidden processes’ out of big pile of data in the systems you use to execute your processes.

This information can be used to formalize some routes and then we come to what I would call ‘normal process management’.  Most processes are executed several times a week/day/month and might perform better if they are managed as a process.

If 20 people have to reach the castle each day, it might be useful to hand them over the best route known at this moment. In that case even the execution of a process can be supported with a so called ‘Business Process Management System’. Trip wise this can be seen as satellite navigation.

You use the satnav to set your result (the castle). Then you have to be aware that (in my opinion) there is a difference between process result and goals set for that. Because you decide if you want to reach the castle fast, the shortest or the most touristic. That’s depending on your organization strategy.

The satnav (BPMS) will then act as a guide during the execution of a process. It shows you if you still meet your goals (you will arrive at 10:25) and can even warn if you are not compliant (flashing sign that you are speeding).

The more flexible satnavs can even help you to find alternative routes when unexpected things happen (tree on the road).

Conclusion: As you can make trips in different ways, also processes can be managed in different ways depending on their desired result.

So I think the BPM community has to stop with all those workflow vs ‘normal bpm’ vs ACM fights and help organizations to decide what ways of steering will support their processes best.

So thank you for joining me on my trip, but don’t forget the real message of this story.

Although it has some natural gravitation, don't start discussing a process with its route. In my opinion it is better to start with the discussion if the result you are talking about is worth a process at all.

You remember that nice castle? That castle was situated in the city of Bran, Romania. And then you probably know that being at that castle is not such a desirable result at all. All the people that made the trip wish they never did it as they all ended with two little holes in their neck.......

 Happy processing!

Blocks and Arrows, isn't it?

After all these years of "processes are the next thing to focus on", I still experience a limited view in organizations of what makes a process perform. 

To address some of these aspects, I'll take the example of self scanning and paying your groceries (with suchs a scanning "gun") in the supermarket. 

The process is still "getting your groceries home", but the supermarket decided to change (or maybe better, add another version of) the design of the process. 

First of all, the workflow has changed. A few steps have been delete and all steps are executed by the customer, now. 

So, also the people aspect of the process has changed (do customers understand how it works?). 

Information supply also needs to correct (every product needs a correct bar code, otherwise the customer still needs to ask an employee) 

And of course, also the supporting software (to scan and pay) should work and physical stuff like the scanning guns, but also a place to store them, should be taken care of. 

All together, these aspects will result in how well a process performs.

Actually, what does a supermarket expect from these kind of process changes? For who should it be an improvement?  

All the mentioned aspects are things you can "adjust".  But also culture is important. It needs trust in the customer. And not to forget; did customers really request these process changes? 

Above example was just to make clear that a process is not some "blocks and arrows", but a complex collaboration between all kind of aspects. 

But don't forget that the best processes start at the end, so what are actually the goals set for the process result "Groceries paid and in bag of customer"? 

Happy Processing!