How to Produce Usable Business Process Maps

MML's approach to process mapping is set out diagrammatically below.

This approach has been carefully designed to:

• give clients the capability to map processes in a way that enables them to:
  • describe “as is” processes accurately, in a way that informs and explains;
  • design “to be” processes that will work, are efficient and robust.
• provide them with a simple and effective mapping tool and teach them how to use it.

Although business process mapping techniques have been available for several years, many companies use inappropriate tools. Certainly, flow charts, data flow diagrams or IDEF0 will deliver something. But these tools were designed for a different purpose and it's hardly surprising that they do not describe business processes very well. To draw a parallel, it would be like trying to drill a hole with a router!

MML's approach is different. It uses a purpose-designed tool, one that has been used in a wide variety of different situations, from small stand-alone sub-processes to full-scale major BPR projects. It has demonstrated its ability to deliver manageable and useful process maps. It has two particular advantages:

• an ability to communicate the process flow easily to all levels in the company, from board to shop floor and through that to build understanding and buy-in.
• the production of a set of re-producible, legible and fully integrated maps that can very easily be subject to the sort of rigorous change control process used for physical drawings.

The following sections briefly describe the key elements.

An initial essential first step is to define the process that is to be mapped. It is critical here to take a process and not a functional view. It is also necessary to define the scope of the process to be mapped, its start and end points as well as any key areas that are out-of-scope.

This definition takes the form of a formal scoping document. How this is put together will determine what the process map will reveal and for new processes, what it will deliver. There is a separate methodology for developing the design specification for new processes.

Because the process must by definition be cross functional, then the team(s) set the task of producing the detailed maps need to be cross functional. Experience suggests that the ideal team size is around five or six, plus a facilitator (and scribe). Larger teams can be used but tend to slow the mapping process down.

Where large and complex business processes are being mapped it is helpful to sub divide the overall process into smaller sections and assign each sub-process to a separate team. Where this is done it is essential to maintain adequate communication between the teams. Assigning members to ensure that:

• sub-processes combine to produce a complete whole, without gaps;
• a consistent level of detail is maintained in the definition of activities.

The RAD notation was specifically developed to map processes. It differs from the more commonly used flow diagrams in a number of particulars:

• it focuses on what people do, i.e. activities;
• it assigns activities to roles, enabling it to describe the interactions between roles. This is often the most vulnerable part of any process;
• it handles the convoluted nature of processes with specific symbols for alternate and parallel routes. This enables it to deal elegantly with exception conditions;
• it makes clear the route by which decisions are made, including the escalation process;
• it provides a simple method of identifying gaps and inconsistencies.

The mechanism of producing maps is iterative. Most frequently it is done over a matter of weeks with each mapping team meeting once or twice a week for a “RAD session”. Each session typically lasts half a day, during which time the team works at completing the map. Between sessions they have time to address any issues or questions that arose from the previous session. Between four and eight sessions are usually sufficient to complete the map.

A more detailed description of this notation is available on request.

Maps produced in “RAD sessions” are usually hand drawn. For publication and change control purposes (see below) they are redrawn in Visio. Standard templates exist for this.

We normally expect a single sub process to cover somewhere between five and seven “roles”, often but not always defined as departmental responsibilities, and to cover between two and six pages. If they fall outside of these broad limits they are either:

• too small and are probably maps of functional activities rather than processes;
• too large, meaning the sub-process has been defined too widely.

Converting the maps into Visio format allows them to be widely circulated for review and comment. Because Visio supports dynamic links to Excel it is possible to assign metrics to individual activities, such as frequency, cost, resource, duration, data requirements etc. These are held in a spreadsheet behind the diagram but also appear against the specific activity on the map.

In producing the maps it is necessary to facilitate the mapping teams. This needs to be done by someone with experience of process mapping techniques and the type of process being mapped so that they can:

• arrive at the “right” level of detail;
• retain focus on the scope;
• challenge pre- and misconceptions about how the process actually works;
• for “to be” processes, introduce knowledge from other companies and sectors;
• play the role of coach, advisor and devils advocate to test the robustness of the map;
• can assist in maintaining the integration between sub-process maps.

The RAD notation supports inter- and intra-map links. However, there is a critically important step that must be carried out before the maps are finally signed off — that of checking that there are two ends to each link and that they properly represent the correct flow of activity.

Consolidation defines the task of reducing the maps to more manageable proportions. It is limited to the activities that take place between interactions. However, it does provide a shorter and simpler presentation of the process and is commonly used for presentation and approval purposes.

Interactions play an important role in describing processes in realistic and easily understood terms. They describe the relationship between roles (often departments). In reality, interactions tend to be the weakest areas of many processes — the places where they most frequently break down. In the real world, hand overs often become hand offs. Because of this it is important the map is drawn, from the start, at the right level of detail. This is also particularly important as interactions cannot be broken down or decomposed to lower level of detail. Similarly, they cannot be summarised or amalgamated during consolidation. Quite sensibly, it is not good practice to define an activity in one role that implies an interaction with another — simply because the interaction is not shown explicitly on the map. If it cannot be seen it probably will not be understood.

Once the maps are formatted in Visio it is possible to apply a formal change control mechanism. This is used for a number of purposes:

• tracking the development of the initial approved map through the various iterations;
• ensuring that any subsequent changes to one map take account of the impact the change will have on other parts of the process;
• ensuring changes are approved before being implemented.

Where clients have implemented ISO9001/2000, some have used their process maps, under change control, as a major element of their submission and award status.