An Introductory Guide to Process Mapping & Modelling
Process mapping or modelling is an oft misunderstood and under-utilised skill. Unfortunately most learn their skills over time, on the job and pick up bad habits along the way.
In my experience process mapping can be simple and effective if a few simple guidelines are followed - whether you are using swim lane diagrams, EPC’s or simple flowcharts. Here are what I consider to be the key basics as well as some bad habits to be avoided.
- Title. Always have a title to explain what your process is about.
- Title format. Title format should be in a verb-noun format i.e. what is it that is being done? For example: Create Purchase Order, Document business process! As a simple test of a good title, if you reverse the title it should give you the output of the process: e.g. Purchase order is created, Business Process is documented.
- Successful customer Outcome. Every process should specify a successful customer outcome i.e. what is it that the process contributes for the customer?
- Process Owner. Who is ultimately responsible for the process and it’s outcomes?
- Levels. Whilst you may start looking at the process from a high level (e.g. value chain), unless you get down to the task (or activity level) you are wasting your time. Get into the detail of specific tasks that are performed. Typically the task level is referred to as “level 3” but ultimately what people call levels varies and is a discussion best reserved for process academics.
- Tasks. Tasks should be named in a verb-noun format e.g. Input purchase order data, Read Visio Guidelines.
- Roles. You always should be specifying who is doing what at a role level. If you start talking about divisions or branches you’ve gone too high level and need to discover who is doing what.
- Start (or trigger) – every process needs a start point. There may be multiple start points. A process will typically start (and end) with the customer.
- Tools. Identify anything that is used to complete the task such as systems, forms, etc. Link these to the task. Think of these as tools required to complete the task.
- Systems. Identify systems used and whether they are automatic or require manual input.
- Shapes. You don’t need much more than start, end, task and decision shapes to draw a good process map. Studies have shown that 90% of BPMN shapes are never used. Don’t get hung up on choosing obscure shapes that no-one will recognise.
- Audience. Think about who is going to be shown the map. A good test is that you should be able to show a process map to anyone and they should be able to understand it.
- Flow. You should be able to follow the process through in a logical manner. Conduct peer reviews and if you find your colleagues getting stuck you know that others will too.
- Loops. For each task, ask yourself “what if this went wrong?” If it can go wrong, what are the implications and where does the process loop back to?
- Forgetting to include a swim lane for the customer
- Using abbreviations or jargon
- Using task shapes as start and end points
- Getting too obsessive about notation. Focus on comprehension, not on observing the notation rules
- Creating swim-lanes for systems or other non-role based items
- Documenting only the “happy path” where everything goes right – document all possibilities or you will miss key information
- Being obsessed with fixing crossing lines. Studies have shown that the key element in comprehension of diagrams is the length of the line rather than if it crosses another line (Source: Dr Daniel Moody)
- Not using colour – colour is a great means of quickly creating easy to understand categories
Please share with me your tips or pet peeves when it comes to process mapping or modelling.