The key to project success often lies in the ability to change or improve business processes. No technology in the world will fix a poor process, so it’s important at the outset of any project to have a good handle on: 1. what the processes are that you’re trying to improve and 2. what the implications are of any process changes as a result of the project you’re implementing.

Like anything, people involved in a process will better understand the part they play if the process is clearly documented (and more importantly in a format that is easily understood). We apply a simple process mapping methodology that from experience ensures:

• processes can be captured/mapped quickly
• process understanding can be quickly achieved
• process documentation can be easily maintained moving forward.

You’ve all seen the spaghetti process diagrams that either require a masters degree in analytics to interpret or simply get ignored. It’s time to throw the spaghetti out and follow the five keys that we know work well for mapping business processes…

1. Capture first - refine second

Use a whiteboard, freehand notes, laptop as needed – whatever your personal preference is.

Capture the process information first, refine it second. Ask the following questions:

• What’s the purpose (objective) of this process?
• Who are the players?
• What kicks off (triggers) the process?
• What’s produced at the end (outputs) of the process?
• What do we need to know (inputs) to perform the process?
• What are the major steps in the process?
• What are the known variations in the process?

2. Define the process as it normally happens

Your process diagrams should describe how the process normally happens. It should not describe every variation – this would create an overly complex diagram. A process will often have variations and exceptions but these are better described using annotated notes. This approach will ensure processes are easily and rapidly understood by business users, while at the same time ensuring all process variations and how to deal with them are captured.

3. Distinguish major steps from minor steps

The process diagram should include major activity steps only. Minor steps should be included as tasks at the procedural level. This approach ensures process diagrams are not overly long and can be rapidly understood. Major steps can be likened to ‘what you do’ and minor steps to ‘how you do it‘.

4. Limit the number of boxes in your diagram

As a general rule of thumb, if the number of boxes on the diagram is more than 7 to 10 then you should consider two things:

• Have minor tasks been incorrectly included as major activity steps?
• Is the diagram actually trying to define more than one sub process?
• Would it improve user comprehension if the process was presented as two or more sub processes with links to show connections between them?

5. Use verbs (action words) at the beginning of your sentences

Most people only read the first three to five words of a sentence before moving on to the next. It’s therefore important to capture the action required early in your instruction, e.g. Enter request into the system / Approve request / Update system record etc.

The above should give you a great starting point and remember one thing, don’t get too caught up in the detail.

We challenge you to use our five keys for mapping business processes and see for yourself the results. Let us know how you go!