Thursday, 25 April 2013

Process mapping for the uninitiated – part 1

Maybe you have seen a process map and wondered how to produce one, or you’ve heard others talking about them and wondered what it’s all about. Hopefully this article will help you to:

  1. Understand what a process map (or model) is;
  2. When and where to use one;
  3. How to go about creating one

This article is part 1 of four.

What is a process map?

A process map, or process model, is a graphical representation of the activities or tasks that make up a process. They show:
  • Who is involved;
  • The tasks or activities;
  • The sequence in which the tasks take place;
  • Any decision points and branches involved [1].
The reason for using maps rather than text is that processes normally have branching points, with two or more things that can happen. Describing this in text is very difficult because text is linear so you have to describe one branch in full and then go back and describe the next branch, and so on. In a graphical model you can see the branches.

Take this very simple diagram as an example: hopefully you can work out what is happening after a few seconds of looking at it. Now read the textual description of the same process below the diagram (click to enlarge). Which works best?
Process map for making tea

To make a cup of tea:

Check the kettle has enough water. If it doesn’t fill the kettle, plug it in and turn it on. Otherwise just turn it on. While the water is boiling get a clean mug and add a tea bag. Then add sugar (if you take sugar) and add milk (if you take milk). Once the water has boiled and the kettle has switched itself off, pour water into the cup and allow to brew. Remove the tea bag and drink your tea.

Of course this could be more elaborate: for example how much sugar? how much milk? how long to brew? etc., but hopefully you get the idea.

Looking at the diagram above, all of the points I noted earlier are present: you can see who (and what) is involved – here it’s you and the kettle. You can see the sequence of tasks running from left to right, and what tasks are involved (in the rectangular boxes). You can also see when branching occurs, designated by the diamond shapes. There are two variations here: an empty diamond with a question represents a decision – often a yes/no type as shown here – but it can be any sort of decision and there can be more than two options. In this case only one of the options can occur, e.g. if the kettle is empty you fill it (you don’t just switch it on), OR if the kettle is full you just switch it on. Then there’s the diamond with a plus sign: this means things happen in parallel: while the kettle is boiling you get the ingredients ready – in this case both branches must happen (and again there can be more than two things that must happen in parallel). The green and red circles simply designate the start and end points.

When and where to use process maps

There are essentially two types of process map: as-is and to-be. As their names suggest, one is to describe what happens currently (as-is), whilst to-be is used to define what you want the process to do in the future.

As-is process mapping is a discovery tool. It’s to show clearly and unambiguously how things are done right now. Managers may think they know what the processes are, but all too often the actual work done on the ground is not what they think it is. So one reason for process mapping is to inform the organisation what actually happens. In fact, you may even find there is no one "as-is" because there are many variations (to take a trivial example from making tea: some people may add milk before pouring water and others afterwards). The point then becomes to do just enough mapping to show the nature of the "mess" and convince the authorities that the "mess" exists [2].

So as-is maps are used when you need to discover what is really going on. And you have to involve the people who do the activities, not just the managers (who will describe what should be done, not necessarily what is done).

To-be process mapping is a consultation and consensus building tool in order to arrive at an agreed future state that you want to achieve (usually some sort of improvement). So here, again you must involve all the people who take part – staff and managers– because one of the hardest things to do is impose a new process on people who have had no say in its design [3].

How to create a process map

There are essentially two stages to creating an as-is process map:
  1. Create an initial map using a workshop with the people who do the activities;
  2. Draw up the result using a graphical tool and a standard process modelling notation.

Preparing the as-is workshop

Here are some essentials to check before you run a process mapping workshop:
  • Identify who is the overall process owner and get their agreement that this is the right thing to do;
  • Identify the services involved with the process and meet with each service manager / supervisor to describe what is going to happen and why. This is critical because, as with any work study approach, they may see any investigation of their area as a challenge, so it’s essential that you get them on your side [4].
  • Equally, you need to identify the operations staff involved both to get a sub-set who will attend the workshop (unless the teams are very small, in which case you might involve everyone), and to explain what’s happening and gain trust. Like the supervisors, they will initially be suspicious that this is about job losses, so again it’s vital that you explain that process improvement is about making their working life more fulfilling and not about redundancies [5]. (Of course, in some cases process improvement is about automation and consequent loss of jobs: if this is going to be the case then it’s best to be honest up front and not try to pretend).
  • Find a suitable space for the workshop: it has to be large enough to accommodate a long roll of paper on which post-it notes will be mounted. A room with a long blank wall is ideal. It should, of course, also be comfortable, etc..
  • You’ll need the following supplies:
    • Roll of brown paper (or lining wall paper)
    • Post-it notes
    • Felt pens with medium (not fat) nibs
    • Blue-tac or other suitable stuff to attach the paper to the wall
    • Soft pencils (e.g. 4B)
  • To prepare the brown paper, cut off a suitable length – I find about 3 metres is good – and fold it lengthwise in half and then in thirds (with firm creases). When unfolded you’ll have six “lanes” running the length of the paper. Prepare at least six of these sheets before the workshop, and paste two up one the wall, one under the other to provide 12 lanes.
  • You’ll also need to do all the usual stuff for a workshop such as refreshments, joining instructions, etc..

Running the as-is workshop

To create the process map you need people to write on the post-it notes the actual activities that take place. There is no one way of doing this, and your approach will vary according to the size of the group, your familiarity with them and them with each other, etc., but here’s a reasonably tried and tested approach:
  • Ask people to write down what they do on post-it notes. They shouldn’t worry about what others do for any hand-offs – just concentrate on what they themselves do, and if there is a hand off, just state where it goes (e.g. send form to HR recruitment team).
  • Once they have written everything down, they should arrange their own set of post-its in sequence. This usually results in realising some steps have been missed: fill the gaps.
  • Now comes the fun part: start to assemble the post-its on the long roll of paper that has been stuck to the wall. 
  • Working with the group, identify where the process starts and label the top lane with the name of the role that undertakes the first activity. Use pencil for this - or make sure the marker pen doesn't go through to the wall.
  • Then get the relevant person to stick their post-its on in the right sequence. As soon as they get to a hand off point where they have to wait, stop them there. However if they have a parallel split (i.e. they hand off to one person and in the meantime carry on doing more of their bit, let them continue, but mark where the branch occurs so that you can pick it up with the relevant role).
  • Get the role who they hand off to, to carry on, having labelled the next lane with the new role’s name. 
  • If they hand back to the first person, then the first person can continue from where they left off, otherwise carry on identifying new hand offs and labelling lanes as appropriate.
  • Continue in this fashion until all the post-its have been applied. Inevitably you’ll find as you do this that people identify missing tasks – add them in as appropriate.  
  • The next stage is to “walk through” the process so far, and the trick of the facilitation is to identify missing branches. This happens when the person has described the default pathway but not the exceptions. For example they may have a sequence like: fill out requisition – get sign off – place order on system. The question to ask is: when you get sign off, is it always agreed? They may say, “No; sometimes it’s denied or sometimes the manager asks for a modification such as smaller quantity or cheaper alternative”. So you have a new branching point that needs to be described. (As you get more experienced, you can do this as you go along, because you’ll start to get an eye for when branches are likely to occur.)
  • As the map builds up and branches are identified, draw connecting arrows using pencil. Inevitably, you’ll find you have to change these as the process gets filled out for the reasons described above (e.g. filling gaps). Cross trough unwanted lines.
  • Once the process is complete, draw in all the final connection lines in felt pen (make sure it doesn’t go through onto the wall behind!). An example map is shown below  (click to enlarge).

Things to note:

  • You’ll often find there is more than one way that things get done. Don’t get bogged down in identifying them all. Get the participants to agree which is the most common or which one they’ll use as most representative, and then make notes about the variations as and when they occur (if possible it’s helpful to have assistant to act as scribe for this).
  • People will start to identify improvements as they go. Note these down, but resist getting into detailed discussions on improvements. Remind people they’re here for the as-is at this stage. But at the same time thank and encourage them, because this is what we want: people to identify their own improvements, and note that there will be a follow up to concentrate on that aspect.
  • Avoid any accusations between teams/roles: if there are delays in the process due to hand-off queues note them down but avoid confrontations over them. Actually what you will often find is the reverse: because people often will be seeing for the first time how they fit into the bigger picture you’ll find them saying things like: “I didn’t realise this affected you in that way” and being very open to change.
At the end of the workshop, remember to thank everyone and explain what’s going to happen next and approximately when.

In part 2 we’ll look at creating a graphical drawing of the as-is map, part 3 will look at using BPMN the and part 4 will consider the to-be process.

[1] Paul, D., Yeates, D., and Cadle J. (eds) (2010) Business Analysis (2nd Ed) p. 136
[2] ibid, p. 139
[3] ibid, pp. 142-143
[4] Kanawaty, G. (ed) (1992)  Introduction to Work Study (4th Ed) pp. 27-29
[5] ibid, pp. 29-32

No comments:

Post a Comment