Process mapping and design

Why process mapping? Process mapping is a technique that allows us to visually understand the process, who is involved, and how the inputs into the process are translated into outcomes or deliverables. Processes are mapped at what level, not the how level, what is to be achieved and not how it is actually done. This is important because all too often, business processes are mapped with too much detail with the result that they lose clarity, and with it, understanding. It is this understanding that is important at this stage. The details can follow. Processes can be mapped for many reasons. Training and development, simply to understand what the process involves. To aid communication and awareness of position in the process.

To identify gaps and non-value adding steps or activities. To show who is involved, what they do, and when. To demonstrate to all managers and staff that processes deliver results, not departments’ sections promoting cross-functional teamwork and understanding. To create the important link between the process itself and its critical performance measurements. To measure the effect of resources and people on performance. And to identify business improvements. Having created the system and identified the processes that make up the system, the next stage is to understand them in more detail, and particularly, their cross-functional nature. In designing and effectively implementing a management system, we need to understand the processes, measure them, and finally, improve them based on the performance determined.

This comes from the knowledge that nothing can be improved if it is not measured, and nothing can be effectively measured unless it is firstly understood. In mapping an individual process, we need to begin by understanding where the process fits into the system and what the inputs and outputs/outcomes are. Understanding its position in the system allows us to more accurately define the inputs and outputs and identify what the purpose of the process is. Understanding the purpose is important as this will help shape and define the measures you will use to control and manage the processes at a later date. If we take a working example of a management system, we can explore how an individual process could be mapped.

The management system shown in this diagram is made up of core and support processes, defining its plan, do, check, act nature. If we then take the winning business process, we could define the purpose of the process, its inputs and outputs as shown in this diagram. Having defined the inputs and outputs and the purpose of the process, the next stage is to determine what method to use to map the process. Strictly speaking, you could write a process in any form, be that text-based, video, et cetera,

and ISO 9001:2000, International Organisation for Standardisation, a quality management tool, does not determine what method you should use. Convention, however, dictates that processes are mapped. There are two types of process map, one with swim lanes and one without swim lanes. Here’s a simple manufacturing example. XYZ Corp makes grommels. Grommels are made of three pieces of metal, two of which are welded together and then joined with a third. The current swim lane diagram for XYZ Corp showing what the swim lane diagram for the manufacturing process currently looks like. Define critical activities and cross-functional interfaces. A part of any process map or definition is to define the cross-functional interfaces that occur quite naturally within the process.

If you are using swim lanes, this is, of course, easy to demonstrate. Each lane defines the function carrying out the task. Whether or not this is a person depicted by a job title or a department, each lane defines who is responsible for carrying out the task. Sometimes, when mapping a process, you may find that the activities tend to fall into one department or section or are the responsibility of one person. If this occurs, then you are probably writing a procedure or a functional departmental activity.

This is a sign that the correct processes have not been identified when the system was designed and there is a real danger that you are mapping departments or functions rather than processes, which by their nature are cross-functional.