Process Mapping

Why we need a robust process mapping system


Process mapping should be considered much more than a simple visual representation, such as it become a critical activity when we have to analyse a process in order to gain a better process understanding

Paolo Mazzoni, PTM Consulting

We usually do not need the process map per se, but mainly as a starting point for further analysis. Any mistake or weakness in the process representation may jeopardize the entire effort of achieving comprehensive process knowledge. It is important to appreciate that process mapping is the basis for process modelling or simulation, including risk analysis or statistical simulation.A process mapping activity should be robust, efficient and maintainable. In this way the process map will help to understand the system and provide explanations by representing all the process functions and connections. Moreover, it facilitates a systematic approach to complex systems through a structured and objective way of representation. In addition, it allows information sharing. Finally, it allows identification of critical aspects connected to the process, giving a shared representation of all the elements involved at each development stage.


An ideal process mapping activity will have the following attributes:

• Robustness: The process can be replicated by different people, with different backgrounds, under different conditions, to yield the same results. This is important to preserve the process knowledge and ensure it is not affected by personal bias or from any other particular condition.

• Efficiency: This can be described in terms of how good the communication is between stakeholders despite different backgrounds, and the ability to coordinate efforts according to the complexity of the system and the pre-defined level of information required.

• Maintainability: This is the property that a process map must possess, as the process may change. This easily happens when we start to map a process during the development phase. Accommodating change without losing information, redoing work or being forced to perform further analysis are all important when completing the process map.

Process mapping tools

Various tools can support process mapping activities in different ways, with differing levels of detail and complexity. Each one is suitable or has been developed for a specific purpose; none is perfect, but there might be some aspects that should be evaluated more carefully with respect to what we consider an “ideal” tool. One of the more common process mapping tools is the Block diagram. This is a diagram of a system, in which the principal parts or functions are represented by blocks connected with lines that show the relationships among the blocks. The block diagram is typically used for high-level, less detailed description aimed more at understanding the overall concepts and less at the details of implementation. This level of information usually is not enough to start with further analysis

Ishikawa diagram

The Ishikawa diagram (also called a fishbone diagram or cause-and-effect diagram), used in conjunction with the block diagram represents the most common approach for process mapping. Ishikawa, in its interpretation as a “cause-effect” diagram, represents the link between function and output, with a causalities-based logic, superseding the logic sequence that has been depicted in the block diagram. This approach is probably the most used in preparation of any risk management process, and has the greatest advantage of being very easy and not time consuming. Conversely, difficult maintainability and subjectivity can limit this approach to a one-off implementation. Risk management, however, is never a one-off implementation, but rather a process and a continuum for

Flowchart diagram

the entire life of the product. There are other easier and more intuitive mapping tools, such as the flowchart diagram.


The flowchart diagram provides a clear schematic representation of a process. Besides the simple data and flow representation, the flowchart diagram can support decision-making activities during the process in a basic yes/no decision. This kind of method is simple and user friendly, but this representation is static, and the output is a photograph of the process in a well-defined time. Each change in the process will determine the update of the whole diagram.

There are other families of tools, such as the SIPOC diagram (Supplier, Input, Process, Output, Customer), generally known as “value mapping tools,” that may be used in some context due to their scope of identification of the value chain inside the process. These tools are very flexible and allow easy and quick use, but conversely, in respect to the risk management and full process understanding, the potential to focus on a specific value force to use a cut-off for the information that seems not be related to the “value” object of the analysis; this pre-selection necessarily leaves a lot of potential area unexplored for a complete understanding. Thus, different teams can generate different diagrams from the same general value, but not exactly the same use of basic information.



Please enter your comment!
Please enter your name here