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 !