9 Simple Rules of Business Process Mapping
How to Develop Business Process Map
This article was created to simplify the process of creating a Business Process Map for your organization(s). In my experience, people try to codify the business process map where they follow strict guidelines as well as complicated notations to map out business processes. Consequently, they lose sight of what is the most important part of a business process map — a simple and powerful communication tool to document the business activities from start to finish. I hope this “9 Simple Rules of Business Process Mapping” will help you in developing a business process map in near future.
1. Description
9 Simple Rules of Business Process Mapping consists of:
- Use Simple Notations
- Use Concise Task Name
- Use Swim Lanes
- Use Levels
- Use Numbers to Denote both Task Orders and Task Levels
- Use Left to Right Order
- Do Not Crowd Process Diagrams with Tasks
- Important! Do not Develop Business Process Map in a Group Setting
- Important! Ensure you capture manual corrective step(s)
2. Prerequisites
Following are prerequisites for this tutorial:
- Basic knowledge of Microsoft Visio. There are multiple tutorials available online on using Microsoft Visio.
- Basic knowledge of Microsoft Visio’s BPMN Basic Shapes stencil. This stencil is used since it produces a professional-looking process map. Please note that we do not use most of the functionality of this stencil since it goes against our keep it simple philosophy. There are multiple tutorials available online on using Microsoft Visio’s BPMN Basic Shapes stencil.
- Basic knowledge of Microsoft Visio’s Cross-Functional Flowchart Shapes stencil. This stencil is used to create horizontal swim lanes.
3. Nine Simple Rules of Business Process Mapping
3.1. Use Simple Notations
Use simple notations when developing your Business Process Map. All you need is the following four notations.
People usually ask — isn’t using notations like flowcharts as shown below will be more informative. You will have the flexibility to precisely document the business activities.
Business Process Map is a communication tool between you and your stakeholders. To develop a business process map, you will need to conduct a series of meetings with multiple stakeholders at the same time. Describing what each notation means to the same stakeholders multiple times gets old extremely fast and most importantly, it deviates the focus away from the process of mapping business activities to logistics of business process mapping. Please keep it simple.
3.2. Use Concise Task Name
When describing a task, use a concise task name. It should follow the structure of Verb followed by Noun. An example of task names in “IT Help Desk Workflow” process diagram would be:
1. Submits LogIn Issue Request
2. Creates Ticket
3. Assigns Ticket
4. Resolves User LogIn Issue
5. Closes Ticket
If a business process map requires more descriptive information, then use decomposition to provide more detailed information at a lower level(s).
Following are issues with not using concise task names:
1. If you use a more descriptive task name for one task and a more concise task name for another task, then the varying level of details may be captured at the same level, resulting in too much information captured in one place. The concept of levels will be described in more detail in “Use Levels” section.
2. If you use a more descriptive task name, then the task notation size will increase to accommodate more descriptive task names where there will be varying sizes of task notations, losing the professional look and feel of the process map as shown below. The business process map is often gets shared with the highest level of executives. A more polished and professional-looking business process map will bring more weight to the table when communicating with the executives.
3.3. Use Swim Lanes
Use swim lanes, divided by roles, to denote which role is responsible for a task. Expanding upon “IT Help Desk Workflow” process map described earlier, we are able to convey which role is responsible for a task as shown below, adding clarity to the business process map.
Swim lanes should always be horizontal where roles are placed on the left-hand side.
3.4. Use Levels
Use levels to document more detailed business activities. Tari Kaupapa from the project office of Massey University outlined a Four Level Process in his paper on “Process Mapping; Process & Guide.” He used the following guidelines to understand and identify the different processes in the business organization:
- Level One: is the standard high level and lists the operational levels of an organization.
- Level Two: depicts the end-to-end processes across the operational areas.
- Level Three: shows the roles and associated steps required to complete a specific process within an operational area.
- Level Four: is the documentation of instructions and procedures required to complete steps in the level three processes.
Please be careful when you are decomposing tasks to either level 3 details or even level 4 details. Here are some numbers that illustrate the logistics of decomposing all tasks to level 4 details:
- Level One: 1 Business Process Map with 8 tasks
- Level Two: 1 Level One Business Process Map with 8 tasks decomposed to additional 8 Business Process Maps with 8 tasks each or 8 Process Diagrams and a total of 9 Process Maps
- Level Three: 8 Level Two Business Process Maps with 8 tasks decomposed to additional 8 Business Process Maps with 8 tasks each or 64 Business Process Diagrams and a total of 73 Business Process Maps
- Level Four: 64 Level Three Business Process Maps with 8 tasks decomposed to additional 8 Business Process Maps with 8 tasks for each or 512 Business Process Maps and a total of 585 Business Process Maps
Notes: Not all tasks will be decomposed to level four details, but the above number illustrates monumental efforts required to decompose all tasks to level four details. It also explains why there are only four levels.
A good rule of thumb is to capture business activities to Level Two details for “AS-IS” business processes and Level Three details for “TO-BE” business processes.
Expanding upon “IT Help Desk Workflow” process map as described earlier, we are able to convey detailed steps required to “Resolve User LogIn Issues”, adding clarity to the process map.
Changes are made to “User Login Help Desk Process” process map where there is a plus sign for “Resolve User LogIn Issues” task to denote that there are additional details and links to “Resolve User LogIn Issue” process map as shown below.
“Resolve User LogIn Issue” process map expands on “User Login Help Desk Process” process map with the following as shown below:
- Entry Task, which is preceding task in prior level process map as represented by “Assigns Ticket” and links to prior level process map
- Exit Task, which is succeeding task in prior level process map as represented by “Closes Ticket” and links to prior level process map
- Three new tasks, which provides detailed steps required to “Resolve User LogIn Issue”
3.5. Use Numbers to Denote both Task Orders and Task Levels
Use numbers to both denote task order as well as task levels to improve clarity. When using numbers to denote task levels, use the following simple rules:
- Level One: Use the whole number from 1 to 10 (e.g., 1)
- Level Two: Use previous level number + “.” + task order number (e.g., 1.2, if the previous level number was 1 and task order, is 2)
- Level Three: Use previous level number + “.” + task order number (e.g., 1.2.2, if the previous level number was 1.2 and task order, is 2)
- Level Four: Use previous level number + “.” + task order number (e.g., 1.2.2.4, if the previous level number was 1.2.2 and task order, is 4)
Expanding upon “IT Help Desk Workflow” process map described earlier, we are able to convey step order, adding clarity to the process map.
Expanding upon “Resolve User LogIn Issue” process map described earlier, we are able to:
- Clarify that Entry Task (e.g., 3. Assigns Ticket) is carried over from the previous level process map
- Clarify that Exit Task (e.g., 5. Closes Ticket) is carried over from the previous level process map
- Clarify that tasks 4.1, 4.2 and 4.3 are decomposition of “Resolve User LogIn Issue” as documented in the previous level process map
3.6. Use Left to Right Order
We process all information from left to right order when we are reading a book, reading a document as well as a timeline (e.g., months, quarters, or year) when reading numbers.
Utilize left-to-right order to develop a process map, which improves both readability and convey time order.
Here is an example of what not to do:
- Snake Process Map
Snake Process Map is the result of trying to fit too many tasks in a process map as shown below.
The following process map re-orders tasks in left-to-right order, which improves both clarity and timing order of tasks as shown below.
3.7. Do Not Crowd Process Diagram with Tasks
Lastly, always remember a simple rule — there should not be more than 10 tasks in a process map. Otherwise, you will end up with a series of snake process maps.
3.8. Important! Do not Develop “AS-IS” Business Process Map in a Group Setting
There is an assumption in an organization, to develop a good business process map, you will need to invite all stakeholders to a meeting then develop a consensus-driven business process map in a group setting. This is a wrong assumption and this may lead you to a rabbit hole of meeting after meeting without producing anything of value.
When developing an “AS-IS” Business Process Map, it is best to develop a simple and complete business process map using your knowledge of business processes or if available, working with a single Subject Matter Expert (SME). After this is completed, go to another SME to hopefully enhance Business Process Map and continue the process until you achieve sufficient consensus from all SMEs. After this is completed then invite all stakeholders to a meeting then review the completed Business Process Map. It is expected that there will be some modifications as the outcome of the meeting, but this will be manageable. This can be resolved by making needed modifications then sending out a revised Business Process Map for their review and approval.
3.9. Important! Ensure you capture manual corrective step(s)
In every organization I have worked for, people perform tasks on a daily basis to correct supposed automated tasks and expedite tasks to move supposed friction-free tasks.
Interesting thing is that these tasks are rarely captured when developing “AS-IS” Business Process Map, resulting in delays in projects as well as cost over-run or worse — manual workaround to fix supposed new and better “TO-BE” business processes.
Assume these tasks exist in your organization. The faster you unearth these tasks and document them as part of the “AS-IS” Business Process Map, the more successful your business transformation project will be.
4. How to Develop Business Process Map
This is multi-part series on How to Develop Business Process Map. Business Process Map Series consists of:
- Part 1–9 Simple Rules of Business Process Mapping
- Part 2 — How to Develop “AS-IS” Business Process Map
- Part 3 — Elaborate on “AS-IS” Business Process Map
- Part 4 — How to Develop “TO-BE” Business Process Map
