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.

The Basics

• 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? 

Bad habits

• 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.

Cheers,

TPN

Comments

[Jorge Perez]

Hi Craig;

I couldn't help myself to note the following in the interest of your discussion.

In fact i'd be VERY interested what others say.

RE; Bad Habits

- Using task shapes as start and end points. BPMN actually indicates that if you don't use a start shape you don't need an end shape. You could theoretically have a task shape that says Start and another one that says End - that conforms. On the other hand, if you use a Start shape, you must use a End shape. Pretty important rules

- BPMN also allows a swimlane for systems - Check it. Unfortunately (or fortunately if you are a data nerd) if you are working on a large implementation (which generally includes systems now days), you need to indicate what task may be done manually AND automatically. A swimlane can be anything that indicates a hand-over. Another recent finding on the BPMN rules is that you can have swimlane that indicates an input to a process, i.e. a document, an email and likewise you can have a swimlane to show an output.

- Remember, a role can be anything that passes information (which includes systems) in the sequence of events of a process. Otherwise you haven't captured the right process.

- Fixing Crossing Lines (wow, i remember the days when we worked at CommInsure where crossing lines was a BIG NO NO). Good to see that some things change.

Cheers,
Jorge

[The Process Ninja]

Hi Jorge - all of your comments are totally valid in the context of BPMN. I probably should have been clearer - these are my own personal preferences and are not limited by any notation or methodology.

Personally I like start and end shapes as they simply make it easier to see the start and end points in a sea of tasks. I didn't used to do this but I now like them as long as they have a verb-noun format i.e. not just a green or red dot. System swim lanes I don't like as I still feel that systems are tools of the work people perform (no matter how automated). Roles to me are human beings performing tasks and systems are tools that human beings use to get work done.

Inputs and outputs is an interesting discussion but I see those simply as emanating from another process.

As for the crossing lines, well, I'm man enough to admit that I can change my mind! But I still think it looks ugly...

Cheers,

TPN

[Jonas]

Hi Craig,

Naming is important for readability and use of a process map. I would like to ask you why you suggest using verb-noun for process titles. I know this is common for a large group of modellers, but to me a better abstraction between Tasks and Processes is more logical. That's why I suggest using process titles as nounified verbs:

Task title: Fulfill Order
Sub-process title: Order Fulfillment

[Daniel Lock]

Craig,

Process maps are tools, or inputs to communicate something, solve a problem, or make a decision. They are not ends in themselves. Mistaking this is the worst of all habits.

"Investors, we lost money this year, but we have really improved our process maps..."

Dan

[Emiel kelly]

I think most of your points or valid, if......you really want to map your processes. Sometimes it seems that organizations think that mapping their processes will automatically improve them. As we all know that's not true. 96,54 of the process maps ended up like stones in a pavement; created, been there for years, but no one pays any attention.

In this context, your first point is the best. Making companies aware that processes don't exist for fun. They exist to create results. For example a delivered pizza. Goals must be set for this result for example within 30 minutes. 

I should make Anyone aware of that and create insight in process performance. So insight in a process is not the same as a process map. 

If it seems your process isn't performing well, you might consider mapping them, to find the causes of bad process performance. 

In that context you have to be aware that customers don't pay you to improve your processes, they pay you to execute them. Which one of you never participated in projects that turned 'has been' process maps into 'nice to have' process maps. All theory. Processes don't happen in the locker room, they happen on the playing field. 

So then it comes to execution, having real time information on the cases in your processes and how they are on track. What's the use of a speedometer if you don't have a throtthle or a brake? So the real power lies in adapting the process to deliver the process result with the goals set for that. 

You don't need process maps for that, you need guts and empowered employees.

That's why I am a fan of creating process awareness everywhere in the organisation. Staring with a process landscape with clear process results and clear goals. Teach everyone on what makes a process perform and how they are empowered to adapt those aspects. 

If they need a process map, ok, but never make it a goal or an endless project. As with any tool;use it with common sense.

Why make a building plan if you don't want to build a house? But if you really want to map your processes, your approach looks ok.

Last riddle: why is a process map in bpmn like the mona lisa?

The appreciators think it is art. Most people don't understand it. And in the end it is just a picture on the wall.

Happy processing!

[The process ninja]

@jonas - sorry I don't understand the difference between what you are saying and what I am saying.

To the others - totally agree but this isn't a post about the use of process maps it's about how to do them if you have to do them. Saying that I think this discussion is a good Segway into another post about the value of process mapping and modeling - much of which I believe is a vain exercise in wasting money!