How often does your function experience people coming in to ‘map processes’? And when this happens, how often are they referred to a similar exercise, usually performed for a specific project, carried out a year or so ago?

When your function digs out (what they can find of) these earlier process mapping ‘artefacts’ (as they are, in my view, unhelpfully labelled) for the new mappers to look at, how often do they say “excellent, we’ll use these as a starting point” and then adopt a slightly different mapping approach/ method/ tool and do it all over again.

….and the people ‘mapping’ and those ‘being mapped’ experience a certain déjà vu.

Even worse, do the ‘mappers’ take process performers away from the process to do the mapping in workshops?! Do you think this enables them to map reality or a set of opinions? Do you think they end up with a highly crafted and nice looking ‘logical diagram’ or the complex and messy truth?

If processes have been mapped before and this is being done (yet) again, then some hard questions need to be asked.

• why did they get mapped last time?
• who (if anyone) agreed/ agrees with what they produced?
• who used/ uses them to perform the work?
• what happened to them? (are they likely to be complete, current and meaningful?)
• …and therefore, why does it need doing all over again?

Projects vs. Processes:

If the purpose of mapping is ‘for a project’ then there is already a problem.

A process exists all the time, no matter what projects are being done on (or, more likely, to) it.

A process should have a purpose and a clear customer. It will have demands that are placed upon it (both value and failure) and a capability for handling that demand (which includes variation). It will have a desired flow (how it should be performed), a current flow (how it is performed) and a set of system conditions (constraints) that make this so.

Whilst a project might affect a process, you shouldn’t need a project to understand a process and you don’t always need a project to improve a process. If you do, then you aren’t properly managing your processes!

Conversely, if you’ve got a project that is going to have a major impact on your processes….you had better be managing your processes well for this project impact to go smoothly. Otherwise you can expect the proverbial car crash.

Purpose

Let’s get to the real point: Every process performer wants to do a good job and, to do this they desperately* want:

• really good process knowledge that they can easily use to do their job to the current standard;

• this process knowledge to be able to cope with (absorb) the variety that they experience in customer demands, not force them into an unhelpful straight jacket;

• to be able to use their actual experiences (as opposed to what is supposed to happen) and make sure that these learnings are captured, understood and properly used so that the process knowledge is continuously improved for them and for the benefit of their colleagues;

• to know when the standard has changed, why and to what such that they can easily and consistently adopt it…and this means there is NO confusion as to what the new standard is and from when it is to be adopted.

What you will notice from the above is that it is the process performers who most want and need excellent and current process knowledge and, standing back, this is actually rather obvious!

* I use the word ‘desperately’ because this is what I always hear when I talk to the process performers at the Gemba (the place where the work is done). They cry out for the above!

But is this what our usual process ‘mapping’ focus is? I would say not.

Reality:

So what actually happens?

Projects come along, pull process performers into workshops, ask them what they do, document what they say, (sometimes) ask the process performers to ‘sign off’ on these ‘artefacts’ (grrr) who, in turn, typically think “it doesn’t tell the whole picture but, yeah, that’s about right” or “it’s not how I would have explained it, but I can see what you’ve done there”…and then the project goes away allowing the process performers to get back to their reality….until, wham, the project change is sprung on them.

In parallel to this, process performers are getting on with their day jobs and, desperate to make it easy for themselves to know what to do, they create (or augment) the necessary process knowledge to perform the work. They do this in whatever medium they have available to them, in what little spare time they have and then store it wherever is convenient for them. All of which is totally understandable.

Over the top of all this, those who determine the policies to be adhered to when carrying out a process (let’s call them the process owners) issue ‘memos’ (in increasingly modern formats) informing all of what is changing and how it should be done from now on. Similarly, these process owners also issue ‘rebukes’ as to what people are doing wrong (along the lines of “didn’t you read my memo dated xyz!”) and warning them to “do it right from now on!“.

The above usually creates what I would refer to as a ‘dog’s dinner’

Here are some thoughts on what’s needed for our processes to continually deliver customer value:

• Clarity as to what the organisation’s set of value streams (and processes within) are and who is responsible for what;
• A horizontal focus on these value streams, rather than a vertical silo focus…so that:
  • a process is seen from the customer’s point of view
  • there is meaningful collaboration by process performers across the flow
• The process performers and process owners jointly owning their own process knowledge….they need to:
  • determine what they need to know and how it is best provided/ presented for their ongoing consumption;
  • like using this process knowledge; and, even better
  • like improving it (meaning this has got to be easy and obvious to do)
• A focus on the wider subject of process knowledge, not (just) process maps:
  • i.e. any/ all knowledge necessary to perform the work
  • this includes the business rules (policies) to be applied when performing a process, and any necessary supporting materials
• A true understanding of Service organisations such that the process knowledge helps the performers to absorb the variety within customer demand, not frustrate it
  • we shouldn’t attempt to create a ‘process encyclopaedia’ that clinically answers everything since no such thing can truly be created. Instead, it needs to allow the absorption of variety
• An experimentation mentality (trial and error) from which to continually improve how process knowledge is created, provided and improved
• Expert help on what tools are available to enable the above BUT this help is not to ‘do it’ to them or for them….but to advise and support them

Some good tests for process knowledge are:

1. how comfortable (or conversely, anxious) a new starter is when beginning their work; and
2. if/ how well a seasoned operator picks up a change in process without reverting to the old way.

And finally….it’s not about tools!

It doesn’t matter how good the ‘process management’ tool is that you have found if you don’t understand and properly live the above. Your investment in such a tool (and the resources to populate it) is likely to become one huge costly, dare I say ‘dog turd’ of a, mistake. You can create amazing (looking) process knowledge in an awesome tool but if no one uses it to perform (and continually improve) their processes then, wow, what a waste!

“A fool with a tool is still a fool” (Grady Booch).

Conversely, we seem to have the idea that there is only one tool ‘out there’ that will work for us. Rubbish. Many tools will help you, though no doubt some will help more than others. The process performers can successfully start with using, say, MS Word if they want…and then continuously improve through their experimentation and learning…where this may take them in many directions as opposed to finding ‘the one tool to rule them all’.

There is no ‘right answer’ when it comes to tools, only a never ending journey to continually improve the efficiency and effectiveness of how process performers know how to carry out their work in the best way currently known for the good of the customer.

Are you currently involved in ‘process mapping’? Is this Déjà vu for you?