What do i mean with that? A basic way of designing a process could be to develop a ASIS process design that clearly shows how the process is implemented. A TOBE process design to identify the gap that has to be covered. A implementation plan that removes the gap and takes us from ASIS to TOBE in an effective manner. Sounds easy don't it? Usually there is no trouble in developing the ASIS or the TOBE process. The implementation plan should be no big deal either. So why is there a general understanding in the business that implementing process is hard? I frequently hear and read that communicating during implementation of the process is what is the hardest thing with processes implementations. As soon as you show a process to a stakeholder or an process operator for verification during design you either get rolling eyes and a general lack of interest or the opposite, an theoretical acceptance but not the corresponding action in reality when implementing. How come we during the process design so often get acceptance from both performers and stakeholders but in reality we struggle so hard with the implementation and realization of it?
Many years ago when i was a process youngster i had such firm belief that i could, and would, change the word by designing better processes. That was it. It was a revelation for me and i could see the "code" in front of me, just like in the movie The Matrix when you see the rain of letters and numbers falling down on their computer screens, i could read it. I did a lot of good during those years but boy what a fight it was. The effort of establishing a TOBE and get it reviewed, accepted and even communicated was a walk in the park compared with actually establish the changes and implementing the new way of working. The constant discussion of metrics, tools, activities, input, output, people depend on you, this is required not optional etc. Anybody could have been discouraged by this but i had seen the light so I just kept trying even harder. The more i talked about the process the more alienated i got. I was a process fool with a tool! That was a long time ago and a lot of water has passed under the bridge since then and my conclusion are that the more we talk and communicate about the processes itself, the further from reality we are perceived.
What we need to come to terms with is that the process is just a visual representation of a series of activities that can be sequential, parallel, conditional, mandatory etc. and is usually a combination of them all. The way we design and visualize a process has absolutely nothing to do with a operator actually performing a part of the process. It has nothing to do with why something has to be performed in a certain order or not. What we, as process designers, are experts in is to see and understand the purpose of a process and how to, by a series of activities and flows, achieve that purpose. We use our technique to represent the information required in the process and all conditions that needs to be fulfilled. We can even measure the process to see progress and outcome and propose adjustments based on that. But as i said earlier it is not a question of designing the TOBE or ASIS or even the implementation plan that is the challenge. It is in communicating and establishing the process to achieve the purpose and value designated with it.
So the dilemma here seems to be, how do we design and implement a process without talking, showing or ever mentioning the process itself to the outside world? We need to communicate based on outcome and use a language that establish trust and ambition. The process itself absolutely needs to be designed and constructed but we maybe need to look at it as if it was confidential. Yes, it is a big secret of the trade and is never to be communicated or shown outside the design room. The only thing that is to be revealed is the purpose of the process and the value that it will bring. This would mean that we will have to change the way we speak and communicate when it comes to processes. There are some ground rules for process design so lets take a look at what should be present in a process and see where we end up.
- A process have a defined trigger.
- A process have a defined end result.
- A process have a purpose.
- A process brings value.
- Each activity have an initial condition that needs to be met before it should be performed.
- Each activity has an end result condition that needs to be met before considered finished.
- Each activity have a responsible performer (even if automated).
- Each activity is supported by a tool (even if performed with pen and paper).
- Each activity is dependent on information that is required to be performed.
- Each activity generates information before considered finished.
If we could se the above in a process design we could consider it to accomplish the basics in process design. But if we apply the dilemma on this situation and agree on that never mention or to show the process itself, how do we communicate about it? Well the first question is who are we communicating with? If we are communicating with a stakeholder we certainly should talk about the purpose and value the process brings. Even every activity can be described in value. So what of the ground rule list should be considered when talking to a stakeholder?
Interests of a stakeholder:
- A process have a defined end result.
- A process have a purpose.
- A process brings value.
- Each activity has an end result condition that needs to be met before considered finished.
- Each activity generates information before considered finished.
Every point in the list above can be described as purpose and value. As you can see everything is result based. It is what we get from the activities and process itself. Each process activity can even be described in value and purpose if needed to go to that level of detail. Still, never to have mentioned or shown the activities or the process design itself.
How would the list look if we would talk to an operator (performer). This time i divide it in two parts. The first part is what i consider operator requirements. Basically what the design suggest should be achieved and available for the operator before performing her work (process activity). The second part is what is expected of the operator and must be achieved by her to consider the activity as performed.
Requirements by the operator:
- Each activity have an initial condition that needs to be met before it should be performed.
- Each activity is supported by a tool (even if performed with pen and paper).
- Each activity is dependent on information that is required to be performed.
Required of the operator:
As you can see it is much easier to isolate the purpose and value in each process activity if we break it down to this level and simply answer the question WHY for each process step and each statement for process design. This way we can communicate with any person about the process or even a small part of the process but disguise it in terms of purpose and value FOR her, or the purpose and value contributed BY her to achieve the overall purpose and goal with the process.
It is more about the words we use than in the format we do it in. If you are used to present and communicating using slides continue with that. Just make sure you never reveal the process design in the material. Always express yourself in beneficiary terms FOR the attendee or requirements OF the attendee. This is applicable for stakeholders, operators, managers, end users etc. The process is just a tool of the trade and a way to describe the information flow, the activities where it is used and modified/created for a specific situation. It can be used for many things and should mainly be used where both the author and receiver base their assumptions/analysis/design on processes.
In other circumstances you are better of hiding it!
- Each activity has an end result condition that needs to be met before considered finished.
- Each activity generates information before considered finished.
It is more about the words we use than in the format we do it in. If you are used to present and communicating using slides continue with that. Just make sure you never reveal the process design in the material. Always express yourself in beneficiary terms FOR the attendee or requirements OF the attendee. This is applicable for stakeholders, operators, managers, end users etc. The process is just a tool of the trade and a way to describe the information flow, the activities where it is used and modified/created for a specific situation. It can be used for many things and should mainly be used where both the author and receiver base their assumptions/analysis/design on processes.
In other circumstances you are better of hiding it!
Inga kommentarer:
Skicka en kommentar