Deja Vu

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.

deja-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!“.

dogs dinnerThe 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?

What you see depends upon your perspective.

uh___perspective__by_paper_flowersIf you go on a site visit to see another organisation, let’s say because you want to see if you can ‘borrow’ someone else’s brilliant ideas, be very mindful of the effect of your own constrained thinking on what you will see!

“…Everything we see is a perspective, not the truth.” (Marcus Aurelius)


Examples:

The Operations Manager: If you go to see a manufacturing plant, see that it is really clean and tidy, notice that they use a technique (and related tools) called ‘5S’…you could come back to your own plant and tell everyone to ‘do 5S’.

…but you would have missed the point as to how that manufacturing plant arrived at their current reality. They will likely have engaged everybody in the factory as part of a deeper ‘Lean/ Systems Thinking’ management system. They will have an environment in which ‘5S’ is relevant to them and can thrive.

It is likely that your top-down mandate to ‘do 5S’ won’t be embraced and you, the ‘command-and-controller’ will say “it didn’t work here”…and will go looking somewhere else for another ‘brilliant idea’ to impose.

The Healthcare Executive: If you go to see a hospital looking for ‘best practise’, see that some of the best surgeons use ‘checklists’…you could purchase a pack of ‘expert designed’ checklists from a consultant and mandate their use by all your surgeons.

….but you would have missed the point that the checklists (or any other effective yet dynamic ‘standardised work’) were designed and owned by the people who were using them because they believed that they were a meaningful counter-measure to meaningful problems.

It is likely that your surgeons won’t accept your imposed checklists…and you will attempt to implement controls to enforce their use, leading to extra costs and much worker- management resentment.


Note that the American car manufacturers AND Toyoda (now Toyota) went to see Henry Ford’s revolutionary ‘River Rouge’ production plant at about the same time as each other (the 1920s)…but they were looking at the same thing through very different eyes and came out with very different observations (e.g. economies of scale vs. flow)…and the rest is history!

The best way to make meaningful and sustainable improvements is to always start from the perspective of the customer, see the customer’s value stream as a system, understand its purpose and provide an environment in which all the process performers and managers are intrinsically motivated to continually improve this system towards its purpose. And, to be clear, this (in part) requires the removal of any and all management instruments that do the opposite.

Whilst it might be useful to see what others are doing, perhaps to spark ideas, this shouldn’t be your starting point and neither should it be the end point. You should know what you are trying to achieve before you look, and you should (meaningfully) experiment before you implement.

Two quotes that apply here:

On tools: “A fool with a tool is still a fool” (Grady Booch); and

On environment: “People’s behaviour is a product of their system. It is only by changing [the system] that we can expect a change in behaviour.” (John Seddon)