AddThis Social Bookmark Button

Reinventing the Swim Lane Diagram. Part 1

We've all used the swim lane diagram. It's simple and easily demonstrates a process, but I've often thought it could do more. When I document a business process, I want to show more than just who is doing what; for example, indicating which systems they are using, what kind of data they are updating, and illustrating a wider picture of the process. These are all factors that render significantly improved results and refined clarity. In this article we'll look at some ways we can take the basics of the swim lane diagram and add some heightened functionality.

In this first part, we'll cover a method of demonstrating process and systems interaction within the style and template of a traditional swim lane.

Let's pause first to set the scene with a typical process swim lane for a sales quoting approval process. In this process, let's imagine that there are four different systems: the Sales Person working in their CRM system, quoting tool and email client, Sales Management in an approval tool.

Does the swim lane below really demonstrate this clearly?

In this diagram, it's difficult to realize at a glance, that the Sales Person has three separate systems (in many organizations this can also mean three separate logins). As a result, it doesn't accurately demonstrate the amount of work the Sales Person might need to do to produce a quote. In fact, on the face of it, the quote approval process looks simple!

So what can we do to make it more readable? One option would be to color code the boxes to show the different systems, as follows:

 

Again, this diagram seems to work by color coding the different systems, but what really ends up happening? One might think, "Wow, nice colors, what do they mean?" So, similar to the first diagram, we are left with unanswered questions and an ambiguous picture of the process. Legends, too, seem to just add to the confusion.

Let's look a little deeper. Colors, although effective in distinguishing difference, in the above example require a legend. If we could make more economical use of color and eliminate the need for the legend, things would be better. The diagram below does just that. By using color in the border and including a colored label, you can simply differentiate the systems (i.e., adding the system name to the label eliminates the need for the legend).

Now you can clearly and quickly see that when the Sales Person creates a quote, they have to actually use three different systems, with a fourth system used by the Sales Manager for approvals. All this is achieved without the need for a legend and I haven't confused the reader with lots of overwhelming colors.

 

Finally, I can also annotate to add some further details. In this example, I am sacrificing some readability for a deeper understanding; however, in this case, I think it works. Using an email icon, I annotated both the Quote Approval and Email Client. The approval discount condition is also annotated.

Every diagram should have a version number, ideally a date and an author. This will ensure that when you use the diagram, in a presentation or a meeting, you can guarantee everyone is referencing the same information. A date allows you to see when the diagram was last updated, and the author serves as a reference if the diagram is used elsewhere in the organization.

 

In our company, we have set up our process diagrams using a Visio stencil, creating a template for repeated use. The parameters of the template include clearly defined color coding schemes for all major systems (green means finance, blue means sales, etc) with regular color mapping to other types of diagrams (i.e. system diagrams, data flow diagrams, etc.) Over time, business users recognize these colors, and find this an effective way to illustrate when a business process requires the use of multiple systems (as shown in the example). It also indicates where there is systems overlap between departments (e.g. when a Sales Person interacts with a Finance-based system).

To summarize, we've concentrated on ways to increase the effectiveness of the swim lane diagram. The sparse and efficient use of color, defining each color's meaning, and the introduction of labels and annotation allow for a more profound exchange of information. In Part 2 we'll start to explore further additions to the swim lane diagram for tracking the underlying data usage, and investigate methods to clarify swim lane diagrams when put into a context of the wider picture. We'll also talk about having now set up a basic swim lane template, how we can then increase adoption and maximize the use of it.

Don't forget to post your comments below!

Mark Jenkins is Manager Business Analysis Group at Websense. Mark has spent the last year establishing a formal Business Analysis Group at Websense that now plays an active role in all major business projects. As part of the development, he created new process and documentation standards, which assisted in the overhaul of IT Project processes, placing the BA Group at the forefront of the IT to business interactions. He can be reached at mjenkins@websense.com

Comments (17)Add Comment
...
written by Paul Mulvey, July 28, 2009
A good way to partition out the AS-IS physical incarnation of the system. As you move towards an essential, you'll probably drop the systems, but this is a good way to show the systems involved in the original process.
...
written by Jay MacArthur, July 28, 2009
Good ideas.
Do you have any documentation on process levels?
...
written by Brian, July 28, 2009
Are the bordered/labeled boxes stencils you created in Visio?
...
written by Martin Schedlbauer, July 28, 2009
Why not simply use UML (or BPMN) which has notation-level support for what you want to do?
...
written by Margaret Wolfe, July 28, 2009
We are currently using very similar notation on an ERP implementation for supply chain management. One small difference is that we put the name of the functional area within the application in the top line of the box. We also number each box which demonstrates the level of decomposition and allows us to 'blow up' particulary complex processes on additional flows.

We have not used the additional icon notation however we will consider adding to our flows as it really does give additional insight at a glance.

As far as not using UML, this particular approach provides more information than standard UML activity diagram, and BPMN seems less intuitive than this approach. One thing I really appreciate is that whatever is used must be able to communicate simply and intuitively within the current environment.

Thanks, Mark!

...
written by Scott Jerome, July 28, 2009
Firstly, the initial two process maps do not have yes/no's on the decision points and there is no connecting arrow to the customer part of the process.
What is the trigger for the commencement of this process? What is the end point of this process?
Numbering of the process steps could also help with referencing particular process steps when creating a procedures document etc.

I feel that business process diagrams should represent just that - Business processes, not the systems behind them.

What is the scope of the diagram? Is it for use in training end users after the design of the solution or is it to help with a design?
The system may not have yet been designed and the first thing people should do is to define the Business process to design the system around. Business processes should define what systems/solutions may be required to automate part or all of a process, not the other way around.
If it is for training post-design, why not use a work instructions document that references the systems, together with a diagram showing the business process behind it? Getting someone to understand what the Business is trying to achieve through a process should be the priority and then the systems can be learnt afterwards.
This is trying to convey too much information and could be confusing.
...
written by Chris Caputo, July 28, 2009
Mark - I like the idea, however there are many companies that have banned the use of color printing to save dollars. I've been using various shading patterns to get around it.
...
written by Rizwan Khurshid, July 29, 2009
Mark, I really like the idea you have floated here and I am doing the same scheme but not really using the predefined colour schemes however idea is same to increase the readability of the user.

Further, I do agree with you for not using the BPMN due to the limited modelling notions it provides.

Cheers,

Riz
...
written by msthorley, July 29, 2009
I don't get not using BPMN. Its a growing standard that increasingly will offer options for diagram portability and for generating the system that other approaches will not and it will EASILY achieve all that is described here and more.
...
written by Donna, July 31, 2009
I have used color coding of boxes for awhile now and it has really inspired our VPs to understand and refer to processes which is a huge switch. I never thought about outlining them in color though and will give it a try!
...
written by Alan Maxwell, August 02, 2009
For systems that have a significant part to play in the current process, I often include a swimlane for each such system to document the high level business activities the system does. For example who/what current system applies the business rules to involve the sales manager. Is that a decision made by the Sales person, or is it an automated task carried out by the Quote system, and when does that occur in the process.

For the Sales Quote example given, there would be five swimlanes: 1. Customer (always at the top), 2. Sales Person, 3. Sales Manager, 4. CRM system, 5. Quote System. Not Email system.
With its own swimlane, the scope and impact of the major systems is very clear.

Note: I also had a few questions about the starting point, end point and a few other things, but expect some of these to be addressed in later steps.
For example, is the starting point the customer requesting a quote.
...
written by Willem Van Galen, August 04, 2009
I echo A.A. Maxwell's comments:
-- Use one or more swim lanes for systems, separate from the non-automated roles/participants in a process. Systems represent the automated portions of a process. To facilitate understanding it’s important to keep these separate from the non-automated portions, that is, the manual roles and activities.
-- The triggering role/participant swim lane always on top (Customer, in the case of the example). Swim lane diagrams are also called Line of Visibility diagrams, which refers to the line that separates the triggering role/participant’s swim lane from all the underlying ones (this can be drawn as a single fat line). The idea of this term is that the only roles and activities that are ‘visible’ to the triggering role/participant are the ones that interact directly with the triggering role/participant’s swim lane. You could call these the process's public elements. All other roles and activities are encapsulated within the process. These could be called the process's private elements.

Regards,

Willem

Willem Van Galen | Senior Systems Analyst |
Information Services | London Life Insurance Co. | London, ON | 519-435-4087 |
...
written by Alan Maxwell, August 05, 2009
I am looking forward to further posts in this series to see how things progress.

I started to reformat the 'Sales Quote Process' swimlane diagram and apply the conventions I normally use and just going through the modelling process raised a few questions.

A. The Sales Quote Process
1. I would probably have the customer trigger the process by requesting a Quote. I use a particular Visio symbol to highlight trigger points (that includes brief text describing trigger), and it will be useful to see what other approaches are used.
2. There are normally rules when setting up someone new in a CRM system that are not obvious in current 'step 1' diagram. Eg credit check etc so that is often documented in another 'Create Customer' process. Does that apply here?
3. Who or what system decides to involve the sales manager?
4. Impact of the Sales Manager not clear. No exit from Sales Manager activity. Can Sales Manager change quote (eg by reducing the discount) - Is customer contacted etc?
5. What is the closing activity and is there a link to another process diagram where customer accepts quote?

B. I have also occasionally added data access information to 'Process' diagrams. In the right circumstances it provides a one stop location for all important information on a process. It will be good to see what other approaches are used for this.
...
written by Alan Maxwell, August 05, 2009
Does anybody else try and avoid use of explicit decision shapes in process diagrams?

Instead I normally have named lines coming from the process that makes the decision with brief text describing the condition that is met for that path. For example rather than Yes and No labels from the 'Discount Approval Needed' decision, I would have two lines with text like 'Manager Approval Required' and 'Manager Approval Not Required' coming from the 'Produce Quote' shape.

My reasoning is that:
1. The decisions are often made within the process that precedes the decision shape and showing them separately from the process can cause confusion by having two (or more) shapes on the diagram rather than one.
2. The decision is often worded to have just a Yes or a No response, and the Yes/No responses must be read in conjuntion with the text in the decision shape anyway.
3. Some diagrams have included several decisions in a row including one with 5 decision diamonds in a row. Instead of 6 important exits from the process being documented each of the 10 (Yes + No) exits were documented including those potentially internal/hidden ones that just went to the next decision diamond or returned to the main process. With the extra symbols and lines, that diagram looked complicated. It also made un-necessary assumptions about the sequence of the decisions (that in the end were wrong and involved re-work of the diagram).
4. Separating out those decisions into separate shapes on the diagram is sometimes an example of drilling down to a level of detail of how within the process too soon.

For me, not using specific decision symbols means process shapes with more than one exit path must have ALL exit paths labelled with the condition that must be met.
But the benefit is fewer shapes on the diagram and fewer lines, with just as much clarity.
...
written by Alex Larson, August 18, 2009
I too have used system lanes to indicate the impact of systems on a process. I try to avoid the use of color as a signifier, because it relies on everyone having color copies or viewing online and I also have a couple colorblind customers.
...
written by tala, October 04, 2011
i have one question , what i should do if two or three swim lane have the same process , like in my assignment i have 3 actors which all of them can view the information , if i want to draw the activity diagram , where i should put the process of "view the information " . in which one of the swim lanes ?
...
written by Chris, January 19, 2012
@Tala, probably too late with this answer, but there are two solutions depending on your circumstances.

First is to note that Swimlanes can represent ROLES as much as ACTORS. So you have three actors that share a specific role (e.g. three processing clerks that perform a receipt in the same way) put one "purchasing" role that goes on the left-hand side.

Second is to have three swimlanes, one per actor, and clone the process three times. This is preferable if the three actors have different roles, but they share this one common process. Further, this allows you to document where the results of the process go if the successor process differs for those Actors with different jobs.

Write comment
We love to see comments! However, please do not market or sell any products. Your comment will be removed immediately!
smaller | bigger

busy