It is generally much easier to separate the business process into elements, and then to create a map for each element. Each element map is composed of tasks that represent the steps needed to properly support the element, and arrows to demonstrate their relationships. This is where we need to use judgment. How detailed we define the process will determine the usefulness of the map. A rule of thumb I like to use is that we want enough details so that the map becomes a good visual aid to do the work, but not so much detail as to render the map complex and difficult to use.

Some people use swim lanes as a way to depict who is responsible for each task. Swim lanes are typically horizontal zones where each zone represents a specific role within the organization. By looking at your lane you can easily see all tasks that are assigned to you. I like swim lanes if the maps are kept relatively simple, but on more complex maps the connecting lines are confusing. For more complex maps such as the ones discussed here, I prefer adding a header on each task to identify who is responsible for that task. The map then follows the process logically from start to finish and has sufficient details to be a useful visual aid.

When defining an element’s process map, start by identifying the inputs and outputs of the element. Then, walk through the process step by step identifying the desired state – that is, how the element should be managed. To do this we need to involve the people who are currently part of the process. We also need a facilitator who understands best practices to guide the group.

In terms of process maps, many people start by mapping an element’s current state and then move on to mapping its desired state. Unfortunately, most of the effort is spent on the current state maps, which will ultimately be thrown away. While we can use these to develop a migration path to desired state, there are much easier ways to do this, which we will discuss later. Incidentally, whenever I have mapped current state, I find that everyone is doing things his/her own way and there can be as many potential current state maps as there are individuals. I always go directly to desired state and have as yet not missed a beat.

The following are examples of process maps. As you will notice roles are added as headers and the maps follow the logical process steps. An important aspect of the maps is their visual value. We should always strive to document our processes and procedures and encourage/mandate our personnel to read and apply these. However, procedures tend to be wordy and cumbersome to refer to regularly. A graphical representation of the process, though not as thorough, is an excellent reinforcement tool and can easily be posted in strategic areas as a visual reminder.

Map example

Map example

Tip from Effective Organizational Engineering for Reliable Operations by Paul Lanthier