How do you find the balance between creating documentation that is specific enough for people to use without writing too much text? A good answer is to replace your written process description with a swimlane diagram. This post is about how you succeed with this.
Be aware that there are many BPM and Visio experts that can complicate this area. If your process involves people then all you need is a simple swimlane diagram. New to process mapping? Check out our simple process mapping guide.
How does a swimlane diagram help work?
A swimlane diagram clarifies “who does what”. This is what people care about. Everything else risks adding clutter and get in the way of people understanding your process documentation. If you don’t focus on this then you end up documentation for the sake of documentation.
Focusing on “who does what” makes sense when research shows that processes rarely fail because of individuals not doing their job (Deming). Processes fail because handoffs and knowledge transfers between people go wrong. One person thinks his job is done and the next one doesn’t know that the gauntlet has been passed to him. This uncertainty stops the process. Like a black hole in your company. This is where a swimlane diagram is useful. It shows exactly which role that is responsible for which activity. When you connect people with roles then it starts to make sense for everybody.
Now you have basics in place and are ready to start with creating your swimlane diagram.
Step 1: Name and scope your swimlane diagram
First, you need to select a process to start with. You can start with your company’s business model, value chain or current process hierarchy. This first step is a natural top management activity – later steps should involve the people that will do the work.
Alternatively, you can start the process that has the most impact on your customer experience – or where you have the biggest opportunity to improve.
Complaint handling is important to do well, so I’ll use that as an example. To name it, it is best to write it as an imperative – “Handle customer complaint”. This makes it personal and actionable. “Complaint management” sounds more like a department name. Avoid any lingo.
When you have selected and named your process then you need to set the boundaries for it. What is its outcome? what starts it? and what ends it?
Start with the outcome of the process. Complaint handling is essentially about turning angry customers into happy ones – while not spending too much money doing this. So the main output is a “satisfied customer.”
Step 2: Select a Process Owner
Now that your process is named and defined it is time to identify the natural process owner. For the process “Handle customer complaint” the answer the person you choose depends on your business. If you have a few large customers then the natural process owner may be your CEO. He or she should get personally involved in a substantial part of the business is at risk. On the other hand, if you have lots of customers then the process owner may be your Customer Service Director. Decide on the process owner based on…
- Who has the most at stake?
- Who has the authority to really change the process? and
- Who has the best understanding of the end to end flow?
In this case, let’s say the Customer Service Director is the owner. It’s an important decision since we’re giving the person with this role the authority to improve the process going forward.
Step 3: Start your swimlane flow mapping – the “who does what”
Now that the scope is clear you have a basis to start adding activities.
Start by defining the organizational roles that are involved. In the “Handle customer complaint” process we have a Customer, a Customer Service Representative and a Technician. Each role has a swimlane that shows which activities he or she will be responsible for.
The customer submits a complaint. This is the event that starts the process. An event is an occurrence that starts (or happens during) a process flow.
Once the event “complaint submitted” happens, then work starts. Work is defined as “Activities”. An activity outlines which outcome that a person with the relevant role is responsible for producing to provide the necessary input for the next role’s activity. Think of it as a chain of work that can be repeated.
In the case of the process “Handle customer complaint”, the first activity is the customer service rep that receives the complaint. She needs to complete the tasks of interviewing the customer, filling in a complaint form and submitting it into a system. So, in this case, the output is that the case is logged in the system.
How much work is an activity? My advice is to keep it simple at first. An activity can include many tasks and take minutes or even days to complete.
The next activity is to resolve the customer’s issue. We’ll keep this with the rep, since she may be able to resolve it at the first contact. This is the best customer experience.
This is a decision point. So we can add a decision if we want to show this clearly. In this case, the service rep makes the decision. She either handles it immediately or escalates it to a technician.
I’ll keep this process simple for now and just add a final activity where the service rep gets confirmation that the complaint is handled to the customer’s satisfaction. We can then add an event to close this – or indicate which process that naturally follows this. (Then you’re starting to show the relationships between your process – a future topic).
This is a swimlane and how you create it. We now have the documentation. That is the easy part. The hard part is to turn it into action. This means that it inevitably will have to change and develop.
Step 4: Change it!
Where do you draw your process? Some use Post-it notes. They even put it on brown paper so they can bring it along.
So what do I do when I want to share it and change it perhaps weekly over the next month?
Some go back and redraw the whole thing in Visio. This takes a lot of time and it makes it “your process” which is good if you will be executing it but less good if others should do this. If you subconsciously see it as your creation then you may (if you’re like most people – and the writer of this article) defend it passionately. You may have good arguments. If nothing else then you risk defending it because you’ll be the one who will have to go back into Visio every time someone spots a necessary change. And believe me, they will love spotting those. So you will try to avoid giving concessions to your colleagues. This is when you lose them and when they stop wanting to turn the new process into account.