Are your processes alive or dead?

Do you have live or dead processes? Unfortunately, many times you work on “mapping” your processes and when the job is done, well, then you feel satisfied. You might go through it with the staff and then put it aside. Many leave the processes to die the binder’s death or the G’s death.

You need to ask yourself what the purpose of developing your processes is? Is it just because someone has decided that the processes need to be described in order to be approved in some way? It may be that they are needed to obtain a certificate or to satisfy someone else’s needs. Said and done; map them and show them off, but then they are forgotten.

Well, maybe it’s not that bad, you think. “We have actually developed the processes and they show our way of working that we follow. So they’re not dead, are they?”

No, I agree. They’re not dead, but they’re not alive either. Zombie appears to my mind. If I came and asked you if you have processes and you say “yes”. Then I ask to see them, at which point you start looking for them in said binder or on G:. When you show the processes, we see that they say version 1 and 2012-04-15. Well, that speaks for itself.

First of all, the fact that you had to look for the processes told me that they are not alive.

Secondly, the date they were last updated also indicates that the processes are not live.

They may show the way you work, and you follow that way of working, but you have not actively worked to keep either your way of working or the description of it alive.

To keep a process alive, you need to actively monitor it, detail it and improve it.

When I say actively follow, I mean that you have them with you, like a map, when you carry out whatever it is that you do in your business. The process in its visual form is close at hand and is present in the discussions that arise about the business. You constantly relate to the processes so that you know where you are, where there is extra work to be done, where there are problems that need to be addressed, and so on.

For this to be a reality, you need to have detailed processes.

If the process is described at too coarse a level, it will not be possible to talk about the details that need to be improved. A too rough process description helps only for a general understanding of what is happening in the business. In addition, these rough descriptions of the processes do not need to be updated. This is because the overall relationship rarely changes.

However, the details of its processes need constant improvement. But in order to improve the details, you need to see the details.

You can only do this if you also describe your processes in detail. Importantly, you need to see that a process is so much more than a flow on a piece of paper. A process is the totality of creating value. A process includes the graphical description of the flow, its constituent governing and supporting documents, the IT support needed to support and execute the work, and the roles that act in the process. So a process is a whole and you have to work on it constantly to improve.

With that in mind, we see that it cannot say 2012-04-15 on the latest version of a process if we look at it today and at the same time claim that our processes are alive. If you are actively working on your processes, there should be a date that is a couple of weeks in the past.

Also, if we are looking at a process that you have been working on for a long time, the version number should be 18, 27 or something like that. This shows that the process is constantly evolving and improving.