Our processes are very flexible….….in doing useless things

These days, many business related stories seem to be about our fast changing world. Although I still have the same haircut as 20 years ago, I assume there must be some truth in that.

Translated to process management you might hear terms like flexible, adaptive or agile.  It all has to do with being able to change what you do. When necessary. 

Probably you might hear or use other terms, but I always use the terms flexible and adaptable, to explain that there are different levels of change when we talk about processes.

 

Flexibility and Adaptability are not the same

BPM is about getting the right level of grip on processes.  Some think that grip means ‘standardization’ or ‘force’ all cases into a predefined path.  

If your processes have to deliver the same result for 20 years with no variations, this might sound ok, but that’s hardly the case in any business these days.

So, ‘right level of grip’ can also mean flexibility and let executors in the process have more control on what should happen instead of predesigning everything.

And that’s what this little story is about, because there are 2 levels of flexibility in processes that get mixed up sometimes,  I think (as said, some might use different terms for it):

Flexibility in executing a process for one case (called a process instance)

The Adaption of a process to a changing environment (changing the process definition)

 

Never forget; Processes are about delivering results (about which you promise something)

As you might know; I often use the metaphor of traveling because a trip has a lot in common with a process. Both have a destination.  In a process that’s called a result (product, service or solved problem).  And that’s the thing to start with I think, because you always have to be aware a process is a means, not a goal.

A process is a means to deliver a result.  The result is what counts; the process is only the thing that brings you there.

Back to travel; assume I am in Berlin and my desired destination is Amsterdam.

So Amsterdam is my result, but to be able to design a good process, I must also define what I promise about that result. That’s what I’d like to call the goal.  That might be getting there fast, cheap, shortest route, least produced CO2,  etc.

Based on this result with goals, I can design the characteristics of my process (plan my travel). 

 

Flexibility; being able to change during the execution of a process

Assume the travel can be made by train or by car. You can imagine both offer different flexibility to the traveler.

If I designed a ‘train process’, the execution will be quite standardized and not really flexible. The train will bring me there fast, but if something happens (tree on the track) I am not able to take an alternative path because I, as executor, am not in charge of the process (the train driver is).  

So when everything is predictable during executing, such a process is OK and reliable.  

In software, (traditional) workflow systems can support these types of processes.

When more flexibility during execution is needed, using a car might be a better idea.  I, as executor, am in the lead.  I can decide to take another road in case of traffic jam. I can speed up if I like (taking the risk of not being compliant with laws anymore).  Of course, in real life there will be boundaries , but it is more flexible to reach my result.

In software, case management systems might be a better support for these kind of processes.

And is software really important in that?  Maybe, but mostly are empowered, result aware, employees supported with useful information to base their actions on.

So flexibility is about the way to take alternative paths in a current process design (getting in Amsterdam fast).  In that case, the result is more important than executing a standardized process.

 

Adaptability; being able to change your process design.

Above is all about flexibility in a current process design.  But assume my processes were always designed to bring me to Amsterdam fast. But nowadays I want to get there cheap (it’s still crisis…) .  So, the environment changed. Can my processes adapt to that?

So adaptability is about being able to create new process designs. It’s not about the non-flexibility in execution a process, but about being able to design new processes.  

If travel must be cheap now, but my processes keep on delivering ‘fast’ they will be running out of sync with my environment.

Back to my travel to Amsterdam. Assume I designed the current process by leasing a very fast (but quite expensive) Bugatti Veyron for 6 years.  I can get there fast in a flexible way.

But now, because of changed circumstances, I want to get there cheap.  Unfortunately, my process is ‘stuck in the lease term’ , which means I cannot adapt easily (for example by buying a fuel economic diesel car).

And that is what adaptability is about; being able to get rid of my old process and develop new process designs.  Talking about software again; you can imagine that if your current process is ‘hidden’ in billions lines of code, how fast can you change your processes? 

 

So standardization and flexibility are just ways to execute and manage a current process.

Adaptability is about being able to change processes so they keep on fitting the wishes of their stakeholders.  

So even very flexible processes might deliver things nobody wants because they are not adapted.

Happy processing!

If you mix up means and goals, you will get fabulous soccer...

...but still might lose every game. 

So, what does process management have to do with soccer?

Besides traveling, sometimes I use the metaphor of playing soccer to explain terms like process, process result,  process manager, process owner, process improvement, etc.

The most obvious is executing of the process: playing a soccer game. But processes shouldn't be executed for fun (at least, in companies), so the result of this process is a ‘played soccer game’.  No doubt this will be fun and healthy, but this doesn't automatically mean you will win.

With this I’d like to explain that there is a difference between the process result (game played) and the goal attached to that (winning, I assume).  In business you might see that many organizations deliver the same result, but what they promise about it, might be very different. That’s depending on your strategy (do I want to be fast, cheap, flexible, the best in quality, etc.) and of course what your customers expect about the process result.

And then we are at process again, because, in the end, a process is ‘the thing’ that delivers what you promise.

So, to do what you promise, a process has to be executed. And that’s just daily business, because every company has processes. That doesn't mean all companies have a clear process focus or that those processes perform well, but processes? They must be there.

Talking about process performance; to make a process perform, several aspects of a process design should work together.  

The most obvious in soccer are the players on the field. They are the process executors. They might have different roles in the process (forward, defender, free kick taker or goalkeeper). Besides the players a process needs other enablers like a system to play (workflow), equipment, information etc.

The coach of the team can be seen as the role of process manager. He or she is watching the game and has indicators to see the performance. Main indicator will be the score, but in soccer they are collecting many types of information these days. (S)he continuously checks if the game (in process terms I’d like to call this a case) is on track to the desired outcome.

When this doesn't seem the case, the process manager can change things, trying to improve the process during the game. Think about substitute players, moving players, defend more, take a risk by making some fouls, etc.

To me that’s the core of Business Process Management; being aware that processes happen on the play field and not in the locker room (like creating process models or discussing processes ‘in theory’). Being able to act before the case is finished. A game can only be won on the field.

An important role in this must be played by the players on the field (employees). If they know what is expected out of the process and know how they can act to improve process performance, you don’t need endless improvement projects; the process is improved during the game.  I like this kind of empowerment.

Sure Emiel, but one important thing to remember is that not all process executors are the same. Some have a natural sense for improvement, while others don’t care and just do their job. And there are even players who need very strict instructions from their coach.

So being able to adjust things during the game is very dependent on the people in the process. So, maybe they need some coaching in that.  

Also, some processes are so predefined/standardized that adjustments during the game are not possible anymore; once a case is started it will be executed as agreed upon.  In that case you can only tell if the process performed well, after the game is finished.

And when, after playing several games the team is not high on the ranking, the process design itself might not be as good as hoped, and a structural change might be needed. You could say this is the responsibility of the club owner (the process owner). He can decide to buy new players, fire the trainer etc. But these are structural changes and for sure will cost lots of time and money. And aren't they a little too late?

But, despite all the continuous improvement talks, in many companies process improvements are still done this way. Is that bad?  At least it’s bad luck for the customers who were still served by the old process definition. It’s really depending on your industry and your customers how agile your processes should be.

Adjust on the field or complain in the locker room? I’d like the first option, but as said: are employees capable of taking this role? Are they empowered to act? Do they know how to act?

I am a true believer that BPM is daily business and to do this as best as possible you need several roles. To me the most important roles are the executors and the process manager. They make it happen for your customers. By the way, these roles can be played by anyone. A player can be the coach too. Or the process owner can also be a player.

So, on of my first steps for every company thinking of 'doing something with processes' would be educating everyone on the basics of BPM, so they have a clear understanding how they can contribute to make your processes do what they promise.

On the field by preference. 

Happy processing!

I always model my processes in scale 1:25....

...so they fit on one page.

Thousands of articles, white papers and books have been written (but also read?) about process modeling. One extra won’t hurt, will it? And when you’re lucky, you probably will not learn anything new. 

Modeling processes; who doesn’t do it?

Process modelling. It seems the first and most appealing thing companies do when they start doing 'something with processes’. 

And yes, I’ve done it a lot in my, so called, career. But after all the consultancy fees enabled me to buy a second  and third house, a few sports cars and a boat I never use, I thought that time has come to start discussing the value of it. Process modelling is a means, so don’t do it without a goal.

So, very often I run into discussions about pro’s and con’s which I most of the time like to trigger with some quotes I regularly post on my www.procesje.nl blog.

<Advertorial>

For those who can understand Dutch, I even combined them all in a little booklet:http://www.procesje.nl/procesmodelleren.pdf

<End of shameless Advertorial>

And those quotes are not meant to make people angry or to play the funny guy (although…). I use them to make people reconsider their process modelling efforts. 

Because, in general, process modeling will take up a lot of time, effort and money. So, please make it worth it!

Before even touching a mouse, spend money on a BPMN book or grabbing some sticky notes, I would ask myself; why should we model our processes? Why make nice pictures (you know it’s a little more than that) of the work we do in our company each day?

If that question is answered in your company, it means that you are very clear on the reason for modelling your processes.  But for those who aren’t, what could be those reasons?

I’ve seen many reasons why companies modeled their processes. 

Tell me how to do my job

Some model their processes, so they can be used as some kind of working instructions. Finally they will be converted to nice process manuals on the intranet. 

And everyone goes back to work.

Because working; that’s what people do. Organizations have processes, but people have jobs.  And as a real process (I don’t like to use the non-saying term ‘end-to-end’) can cross many people and jobs, a manual of a process is not automatically a manual of someone’s job. It might be a manual of many jobs. Do you think people can easily find the information they need?

So, although intentions (enable your employees to do their job well) might be good, I think there are better ways for working instructions than process maps. And that also has to do with the possibilities of technology, these days.

For example; I like to work on my motorcycle. When I need an instruction on how to change the spark plugs, I don’t take the manual, but I grab my phone and search on YouTube.  

It starts with viewing one movie, but in the comments I usually find better tips and finally I am able to change the spark plugs. Besides that, I also found an online store to get them cheap and have some new friends to go for a ride.

So with all the online sharing these days (even within the boundaries of your company), I think the value of process mapping for working instructions is close to zero.  You could think of using it for some kind of decision diagrams, but that’s not a process.

So, are working instructions still provided in your organization, or are employees responsible for it themselves? And, if they are provided, what’s the format they come in?

This is the way we comply!

Unfortunately we seem to live in the compliancy and  age, so I also see processes are modeled for these compliancy issues.

Companies, so also their processes, have to be compliant with all kinds of regulations, certification, standards etc.

That is why some model their processes to make clear how they think they meet these compliancy requirements.  I would say that is just theory. You are compliant in real life, not in a model.

To check if theory meets practice, all kind of (internal) audits are done. To me, compliancy is a symptom of too much regulation and fear, so wouldn’t it be much cooler that everyone just behaves well (like the guys at fifa), so we don’t need this compliance terror anymore?

I hear you thinking: dream on, Emiel! 

But, if compliance is really needed, why do it plastic style? With models? Wouldn’t it make more sense to implement ways of working that just are compliant? Implement your processes, don’t model them.  

Process Improvement

Talking about changing the way of working; the reason that is most mentioned for process modelling: improving processes. Who doesn’t have a process improvement project these days?

(Did you notice, this article is 800 words on its way and I didn’t use the word Lean yet)

Whether or not modelling processes might be useful for process improvement, the first step I often see missed is a clear understanding of the need for improvement.  

As processes are ‘the things’ to do what you promise, it is never a bad idea to take a look at how they perform. I think it should start with understanding of what promise a process has to fulfill and facts about the performance of a process.

Why would you improve processes that are doing well?  Or even worse; why spend time on improving useless processes?

Should process improvement start with modeling the as-is process? I don’t think so. I would start with understanding the as-is performance of that process. Why start improving a process without knowing if it performs or not?

But, I have to be fair; modelling (as-is) processes is still done a lot. And many times I wonder if that delivers what is expected of it. 

Those workshops (I agree; they are fun to do and when well done, they can be helpful) cost a lot of time, employees seem enthusiastic at first, but when nothing comes out that can disappear very easily.

And yes, I know all the arguments.  Like, you cannot tell what to improve if you don’t know the current situation. And sure, it is good to know what causes bad process performance, but is a process model really a good view of the current situation?  The current situation is what happens now, so in fact, when modelling, you are always talking about the past.  How we DID it. Once upon a time.

But one thing is more important I think; what are you actually modeling when you are making a model of a process?

Let’s take a car design point of view. When you want to design a car, you might start with a sketch. This ‘model’ is a small 2d version of the car. But it shows you what it will look like in real life. Maybe a little later a full scale 3d model will be made. With the help of this model you understand how it looks, can do wind tunnel tests etc. And that might be really useful before start building the real car.

Look in the dictionary for ‘model’. You’ll probably find something like ‘on a small scale’. Like the model of the car.  But is a process model a process on a small scale?  Not really, I think.

Most of the time, it’s just a set of agreements of how to represent the several aspects of a process. Blocks for activities, arrows for the order between them, diamonds or circles for decisions, a ‘curly block’ for documents, a hat for an executor, etc.

And people probably can understand what the model means, but is that the same as understanding the process?  Or understanding what causes bad process performance?

Because that what was what we were talking about; improve a process because it doesn’t deliver what we want. So does a process model tell you what is broken?

Not very often it does. And I think the reason for that is that a process model misses one important thing of a real process; the dynamics of execution.  Processes are most of the time modeled with one case in mind. But in real life many cases might run through the process.

In real life operation, cases will probably also have effect on each other. If an employee is working on one case, the other cases must wait. Or the office is closed on Saturday and Sunday. Or customers keep on sending the wrong information. You don’t see that kind of dynamics of real life in a process model.

A step forward in this could be making use of process mining. In the ‘animations’ of process mining, you see all the flowing cases projected on top of the process model. You see where cases flow smoothly, what routes are taken most often or where cases get (actually it’s ‘got’) stuck.

And when you are lucky and the log files, where process mining is based on,  contain more data, also information about processing time, waiting time, throughput time etc. can be seen.

And that might give you a better idea about process performance, but be aware those are still symptoms of bad process performance. It’s like playing back your gps/satnav, not a tool that tells you how to make your car faster. You know something went wrong, but what is the cause? And, more important; how to fix it?

And besides that, it’s the past. It shows how fast you have driven. It’s too late to brake now. But of course it can be very useful for improving the process in the future. To prevent you from making the same mistakes.

And this ‘past thing’ brings me to what I wrote in earlier posts; customers only care about the process you execute for them, not what you will do better in the future for other customers. They want to be served; on the play field. Not afterwards in the locker room.

So how can process models be brought closer to real life?  I’ve been thinking about this and found it hard to find an answer.  I think the first thing to be aware of is that most processes are (maybe not as well as needed) already executed at this moment.

So, modelling those processes would not be my start. The first thing I would try to achieve is to set up some kind of monitoring of cases.  Making everyone aware what’s going on in the process.

To bring this into practice, I once printed a picture with the milestones in a process, put it on the wall and used sticky notes for each case to make clear what the status of each case was.

Of course this needed some discipline and was not very ‘digital’, but employees had a good overview and got more and more engaged to improve when they saw visualized what type of cases caused troubles.

You could call it manual monitoring. Might sound stupid and inefficient, but it met it goals. 

But you are right;  these days there are many tools that can connect to the systems that are used for execution and show the status of cases in monitoring style. Some are even capable, with the right data of course, to do some predictions about the progress of a case. It’s based on fact of the past, but ok; it’s all in scale 1:1!

So my first start would be to make clear for process players what cases are in the process at this moment, what’s their status and whether or not they are on track. In that case they know what is going on in the process. Process manager is a role, not a position.

And as I truly believe that executors are the ultimate source for continuous process improvement, they should be coached on what aspects make a performing process, so they can initiate change when needed.

And is I said at the beginning of this story;  that’s no rocket science. To me bringing process monitoring and after that, analysis and improvement to the work floor is the most logical thing to do. Because it’s all about serving customers. And customers are not served by mapping processes. They are served by executing them (the processes, I mean).  

In the end process management is about bringing those processes to a good end. And executing those processes is the least you can do for that, I think.  

Oh yes, I was discussing the value of process models and most of the times models are far from execution.

But as you probably know, technology has improved last years, so in many BPM suites modelling can become execution. So what you model becomes some kind of workflow system real time. It’s cool technology, but, as you can imagine,  not suitable for all types of processes. Not all processes can be managed workflow style. But again; it’s on the play field, so might be a good start.

Besides that; a process is so much more than an automated workflow (actually it’s caseflow, because work doesn’t flow, cases do). Do you have capable  people?  Where does the information come from?  How is the process managed? etc.

Tools definitely can help to improve how you execute and manage your processes, but always be sure it suites the way you would like to execute the processes.

To summarize; Process modeling definitely has its value, but also be aware of its drawbacks.

There are many reasons to take a look at your processes. But, a process is not a process model, so always ask yourself if it can help you to achieve what you would like. Never forget; in the end your customers are only served by executing processes, not by modeling them. 

So, If you still think you need to model your processes (as working instructions), please call me.  I’ve seen a cool motorcycle that I want to buy.

Happy processing !

I am going to Portugal and to be honest; I'm nervous about that

I like to work with organizations on their processes

I love it to learn new things and pass them on 

I love it to be surprised every day about what's going on in organizations

I love it to not take myself too serious

and I'm passionate about translating all the above into blogs with a ;-)

And that's why I, at several digital places, like to contribute to process related discussions. Also at BPM.com where I regularly end up in fights with people who think that BPM is technology or BPM is a project ;-)

And it seems that some think that my vision (which I just see as common sense) is quite unorthodox. And to my surprise I received a request to become a speaker at a BPM conference in Portugal. 

In a skype conversation with the organizer, he told me that my vision is appreciated and would fit well in this year's conference. 

What? Me at a BPM conference?  I'll just do helping organizations with process related issues and I write about that. Who would be interested in that? 

And besides that, this year's theme is Digitization. That has nothing to do with BPM, does it?  ;-) 

Especially these kind of "heuh? statements" is what they appreciate. After some more chatting we concluded that a better role for me would be to lead a panel discussion. 

Several people who know very much about Digitization and me being the voice of the audience, trying to understand all the mumbo jumbo. 

I spent a night thinking about it after concluding "Who cares? The worst thing that could happen is that my career will be over for ever"

A little cynical of course, but me, as a shy boy from the North East of the Netherlands, leading a panel with all those gurus? It makes me a little nervous, to be honest. 

I hope the weather in Lisbon will be nice.