If you want to become an expert at Business Process Mapping, then you'll LOVE this guide.
I've personally created hundreds of process maps using many different techniques.
Okay a bit of an exaggeration.
But when do I get the MOST substantial successes?
When I take clear action against the mapped business process.
Here's what I think:
Business Analysts could make so much impact if we can PROVE that our process maps will enrich staff morale, surge productivity and even boost the profitability.
But how do we do it? Well that's what this post is all about.
First, I give you a real life example.
Second, I tell you HOW to map your process properly.
Third, I tell you WHAT to do with your process maps for ultimate benefits.
The third is by far the most important part of process mapping so even if you don't read the full post make sure you read this part (go there now).
A real Life Process Mapping Experience
TOP TIP: DON'T tell people you need to map their processes. Why? Because that doesn't tell them about any of the benefits they get from it.
If you're going to get people to accept process mapping. You MUST say this:
You: "Here's what I'm going to do for you"
"I'm going to remove duplicated work, improve staff morale, make your team more efficient, increase productivity and help you manage your cross team communications"
"And here's how I'm going to do it"
"By getting a thorough understanding of your current workload and processes, so I'll need a bit of time from your team"
Manager: "I'm not sure. They're all extremely busy"
You: "It will only be for a few hours each week and I promise, you will realise these benefits if you let me work with you"
Manager: "Okay then"
A couple of years ago, I was writing requirements for a hugely complex process.
It only crossed 3 core teams.
BUT, the process started with paper requests being received from up to 36 different areas of the business at any one time.
ALL these requisitoners had to be kept in the loop until the process finished.
AND paper was being printed left, right and centre.
AND work was being duplicated every day.
AND staff productivity was plummeting week-by-week.
So what did I do?
Well, I knew I could improve the processes, but I needed more information.
I spent 1 week engaging stakeholders and collecting info.
3 weeks mapping the AS-IS processes.
2 weeks analysing the AS-IS processes.
1 week reviewing the timings.
2 weeks mapping and implementing TO-BE processes.
And BOOM ' I had everything I needed to make significant improvements, which I knew would conquer ALL of the above issues.
The result?
With a little help of an automated (Microsoft) Sharepoint system.
Eliminated duplicated work.
Pleased team leaders.
A very impressed Head of Finance (Director).
And some invaluable process mapping experience for me!
Holding a Process Mapping workshop
Knowing and doing this WILL put an end to you asking yourself.
"Okay, where do I start with this bloody process map"
I said that to myself many times when I first started mapping processes.
These are the steps:
1. Preparing for a Workshop
The first rule is this.
Make sure you invite the people that DO the job to your workshop. NOT the people that manage the people that do the job.
So decide WHICH process you want to map
Then organise a meeting with these people.
Be sure you have a WHITEBOARD to draw the process on.
2. Conducting the meeting
First you need to understand where the process starts.
Your first question to ask the team?
"What's the first thing you do when you __[e.g. process an invoice]__"
During the workshop make sure your attendees don't go off track.
A great way to stay on track is by repeating the last process step they gave you.
Then asking what's next.
Like this:
"Okay so first you open the post - Then what do you do"
Simples!
I'm sure you will need to do this multiple times but don't be afraid of showing some authority.
I'll expand on this in Process MApping Golden Rules below.
3. Closing the workshop
Make sure you thank the team and tell them next steps.
You're probably thinking I don't need to tell you that.
But it's sooo easy to forget that I just want to embed it in your minds.
Process Mapping Golden Rules
For me, it's VERY easy to get confused when mapping processes in Microsoft Visio.
Especially as they get bigger and bigger or more and more detailed.
But how do you avoid the confusion?
You follow these simple rules (and questions).
But first you should know this.
3 of my favourite techniques are:
1. Swimlane Diagrams
Why? Because they are great for showing too many handovers between teams.
2. SIPOC Analysis (Supplier, Input, Process, Output, Customer)
Why? Because you can see exactly who receives the output of the process.
3. Standard Process Mapping
Why? Because they are easy to do.
So here goes.
This image shows you the most popular shapes used and what they represent:
1. Always start with a VERB inside a Task box - Simple!
For example: Process, Complete, Print, Send, Create etc.
2. Show a standard process stage with a single line
Like this:
Look out for "as soon as I've done ___(a)_____, I do ____(b)_____. No ifs, no buts"
Ask "do you always do ____(b)______ after doing ____(a)______"
If the answer is 'always' then it's a standard step.
TIP: Always have an arrow at one end of the connecting line as it shows which task comes last
3. Use a diamond shape to signal a decision
Like this:
Look out for someone saying
"It depends, sometimes I do ____(b)____ other times I do _____(c)_______"
That tells you they must check something so you need to ask
"What occasion would you do ______(b)_________ and what occasion would you do ____(c)______"
They might say.
"if it's rejected, I bin it' If it's accepted I enter it into the system"
You could also push them to tell you by asking:
"Would you ever do differently depending on the outcome?"
If the answer is YES
Then you know there's a decision to make. Use the diamond shape
4. Draw AND rules with 2 separate connector lines
Like this:
Look out for someone saying "After I've done ______(a)______, I do ______(b)_____ AND I do _____(c)_____"
You could even ask "is there anything else you do AFTER _____(a)_____"
If the answer is YES, ask them what and add it to the process.
A different AND connector will look like this:
It means "_____(c)_____ can only begin once _____(a)______ AND _____(b)_____ are complete"
5. Show OR rules by joining their connectors
Like this:
Look out for:
"I can only start _____(c)_____ when EITHER _____(a)_____ OR _____(b)_____ are complete, but not both."
More often than not this will occur AFTER a decision node, where the process joins back up again.
6. Show EVENT triggers alongside the process
Like This:
Listen out for "I have to do _____(a)_____ every day at 9am"
So 9am is your trigger.
Triggers can be time based, e.g. 9am, Day 1 of month, Every Tuesday
Or they can be internal within the team, e.g. After a team meeting.
Or they can be external from the team, e.g. Customer rings in.
So keep an eye out for these triggers and whether they might be causing unnecessary bottlenecks.
Analysing your process maps
You WON'T be able to improve a process or automate a process efficiently without taking this next step.
You can be thinking about this during the initial As-Is workshop but DON'T get to hung up on making changes to early.
Why? Because you NEED to get a full understanding of the whole process FIRST.
1. Ask the questions
So once you have a nicely designed Visio diagram, you can start asking yourself this:
Are there any gaps or steps missing?
Is there any duplication of work, either within the team or outside of the team?
Are there overlaps, where different teams perform the same activity?
Are there any activities that add no value?
And how can you remove these activities from the day to day workload?
Are there people waiting for other work to be completed before they can start their task?
Are there invoices sitting in a tray (i.e. excess inventory) waiting to be dealt with? How can this be eliminated?
Are there any task dependencies that don't make sense?
With the answers to these questions, you are well on your way to reengineering the process.
But you need to tell the managers how you plan to improve it.
2. Map the proposed TO-BE Process
If you are using a system to automate the process, remember to think about the capabilities of that system.
And ask yourself if it is the optimum solution to the issues you asked about earlier.
3. Get EVERYONE on board with your proposed changes.
A great way to do this with the team is to make them think it's their idea in the first place.
DON'T let this worry you about not get recognition for your ideas. You WILL get recognition if you continue to work hard and win people round.
4. Implement your changes
This is probably the most difficult part.
But don't try and do it all in one go ' It WILL fail!
Have you heard the saying?
'How do you eat an elephant? One bit at a time'
Well that's exactly the case for implementing business improvements.
Focus on resolving one issue at a time
5. Conduct a Review
This will ensure your changes have had the desired effect.
And there are a number of ways in which to do this.
Such as:
- Shadowing the team
- Conducting another process workshop
- Timing task completion
- Analysing the no. of process completions within a set time frame (e.g. weekly)
So there you have it. A complete guide to mapping business processes.
Do you have anything to add?
Have you had any difficulties with process maps?
Let me know in the comments below.
Matt – it is a great article to get people to understand the value of mapping processes. I think that you can simplify the notation to get even better results.
– use hierarchical mapping to keep the diagrams simple and readable
– only use activity boxes, not differen shapes
– attach “resources” to activity boxes rather than force boxes into swimlanes
– put text on the lines to make handoffs clear
We had HUGE success with 1000’s of clients over the last 20 years. And now we have launched a completely fee cloud hierarchical process mapping app.
Great article Matt… my company is a gold mine of process improvement opportunities and youve inspired me to go prospecting!
Very good tips on the As Is workshop… it’s so important to focus on the current state and not let anyone (including yourself) start brainstorming potential changes at that point. I believe it’s valuable to let people stray off topic to a certain extent, and even gripe a little, especially during the very first meeting; but I love your suggestion about repeating the last step to pull people back out of their rabbit holes when that’s appropriate.
The Visio tips are excellent too. I’ve been writing process flows for decades, but I’m always looking to improve and refresh my skills. Most of what I’ve read on this topic places too much emphasis on details like making all your YES connectors point in the same direction (fine, for a final version) and never duplicating any point (which can make for some crazy connections). Getting hung up on rules like those during the initial mapping process can really bog you down. I like your focus on the basics.
Personally, I’ve never branched an AND nor an OR the way you show in #4 and #5 under the golden rules. I’ve always made another decision point instead… and often struggled with that. I can see how what you recommend might be cleaner. I’m trying to wrap my head around it though and I’m wondering if you would be willing to provide an example of how mapping an “AND” with this method fits into a wider area of the map?
Thanks again for the article!
Matt – Thanks for a great article. Will be recommending its inclusion in additional readings for a BA fundamentals class I teach in a PM graduate program. Great comments too! @Ian Gotts – resource as text element vs swimlane – I like the idea but I don’t like tiny fonts. And there is always someone saying “I just want to see what I do”, so I’ll have to try it before I commit. @Victoria agree whole-heartedly with some slack on wandering in the first workshop and distinct decision points. I’ll echo the request for a follow-up to that point.
Hi Brad,
Thanks for your comments. Really glad you liked the post. And even happier that you want to share it with your classes.