Why You Should Use the Swimlane Format to Flowchart Your Procurement Process

Process mapping is a tried and true way to visually see how your procurement processes from end to end. The Swimlane technique is in a sample flowchart format used by many procurement engineers to help clients define their current processes. In addition it is a very good technique to help develop a more efficient procure to pay approval process by helping to remove gaps and redundancies within the approval chain.

A flowchart is a sequence of graphical symbols and shapes that create a visual diagram that can be used to document a procedure. Procurement engineers utilize these flowcharts as part of their change management toolbox when assisting their clients in re-engineering their business procedures.

A flowchart can help a team collectively map out their inter-departmental processes and procedures into diagrams that create a clear and concise road map that can be traced by anyone. Using the Swimlane format helps breakdown the various parts of a complex process into organized “lanes” that can be re-ordered and connected and easily validated for accuracy.

Analyzing a flowchart using the Swimlane configuration enables the reader to logically follow the sequence of steps, specific rules and paths they should take when certain situations are encountered, even if they are not intimate with the procure to pay process. E-procurement type project engineers incorporate these methods and tools to ensure the new designs mimic the current approval process or make them more efficient, if possible.

There are many tools that can be used to develop Swimlane flowchart diagrams. You can use basic presentation, spreadsheet or word processing software to create basic flowcharts. For more complex diagrams and process maps, many procurement contractors will use specialized software tools that have more bells and whistles.

In summary, when learning how to draw flowcharts, it is imperative to develop a standard methodology that helps organize information in a concise manner. Mastering the Swimlane format as part of your sample flowchart toolbox will enable you to produce flowcharts that are effective in taking high level information and breaking it down into the basic parts and pieces that can be read by anyone.

Cross Functional Flowcharts in Visio

A Cross functional flowchart is the same thing as a swim lane flowchart – it is used for showing departmental or individual responsibilities in a process flow. A cross-functional flowchart can be used to illustrate the relationship between a business process (task or procedure) and the functional units (such as departments or individuals) responsible for completing it. In other words, it can show who does what in a process and can graphically highlight areas when one process overlaps with another one or situations when a bottleneck might occur.

What is a Deployment Chart?

There is no significant difference between a deployment flowchart and a cross-functional flowchart; they are two synonyms for the same concept, and are sometimes also referred to as “Process Maps”. However you describe it, a cross-functional flowchart is an excellent tool for clearly displaying process flows across organizational boundaries and identifying delays, repetitive steps, excessive control points, specialized tasks, and potential points of process failure.

Shapes and Process flow

The shapes used in a swim lane flowchart are the same as the standard flowchart shapes; rectangles, lozenges and diamonds are conventionally used to represent the steps and decisions that make up the process. Cross-functional flowcharts can display the process either vertically or horizontally. Generally speaking, a vertical layout gives a little more emphasis to the functional units while a horizontal layout emphasizes the process. It is important to spend a little time planning this, because by the time you get to the other end of your swim lane flowchart, you may forget who’s responsible for what, and why a shape is in a particular band.

Cross-functional flowcharts use the same routing style and direction as simple flowcharts, but the additional presence of swim lanes and phases can lead to routes that get hidden because they overlap with swim lane and phase boundaries.

Tools to create a Cross Functional Flowchart

No special equipment is required to construct a swim lane flowchart – a simple sheet of paper will suffice. The best way to begin is to create enough bands to hold each step of the process you want to document. Start by listing all the people or departments that will complete a task down the left side of a sheet of paper. Write the first process step next to the name of the player who performs that task. Write and draw a box around the second process step on the appropriate row. When you are done, the “as is” process will be clearly documented.


Of course, this can be a time-consuming process in itself, and specialized software exists to make the job quicker and easier. One of the best all-round diagramming tools on the market is Microsoft Visio. Visio allows a swim lane flowchart to be produced very quickly, and furthermore, allows for easy editing when changes are required – a potential nightmare with a paper-based flowchart.

Making a flowchart with Visio helps you identify waste and capture processing time and clearly displays cross-functional activity, so in Visio 2010 the swim lanes are containers. The routing engine looks for these overlaps and adjusts routes to avoid them, so if you use Visio to make very long and wide swim lane diagrams, you may be glad of this new feature.

Phases in Process Diagrams

Most processes of any length or complexity will have distinct phases similar to those found in Project management. In Visio 2010 there are several new features that help control these phases and clarify the process in so doing. First, a swim lane is highlighted when a shape is added, and second, swim lanes can easily be re-ordered by dragging. When they are re-ordered, the shapes they contain are moved with them.

If necessary, Visio also moves the glue points of dynamic connectors to different sides of shapes to avoid the boundary – a real time saver. However, when a band is deleted all the shapes the band contains are deleted as well – something to be aware of. Another new feature in Visio 2010 is that the title bar of the Cross-Functional Flowchart Shapes stencil will display its shapes when clicked.

Use Flowcharts to Design Your Code

The use of flowcharts has fallen out of vogue with each passing year. There are many programmers who no longer know what the symbols mean and how flowcharts are used. However, flowcharts should not be discredited as legacy just yet!

I have often heard programmers comment that they plan their code within their head as they type code, and sometimes with an air of superiority like they are the only people who can perform such a fete. Concepts suspended within one’s mind though are fluid and constantly within a state of flux. Being able to concentrate upon a particular part of the code whilst maintaining it’s interdependence within the gestalt reality of the rest of the application’s code is akin to trying to see the forest through the trees.

Usually when programming directly from our minds we only focus upon resolving the current problem and then move on to the next algorithm without considering other factors that may make our programming difficult much further into our development. Once code has been written, laying the foundation and future direction of our algorithms, it becomes difficult to see any other alternatives to a particular algorithm or options to replace an algorithm; we end up forcing relationships between algorithms and objects under the illusion of saving time. Often code written directly into an IDE without a prior design means wasted time and effort when you have to re-architect it to fit a subsequent algorithm’s needs or when we have epiphanies of missing contingency planning within algorithms.

The only time I would recommend writing code directly from the top of one’s head into an application is if what we are doing is experimenting in uncharted waters as an exercise of investigation into object usage or problem solving. For the latter, a trial and error approach with slapdash error handling is quite acceptable, as the resulting application will be either refactored into a more elegant solution or discarded altogether.

Flowcharts help make substantial entities of the liquescent concepts in our minds’ eyes. We can focus much more intently upon any particular area of our application’s design without having to sustain the rest of the design within the back of our minds, and we can step back to see the integrated picture clearly at any one time. You will see any missing error handling or kinks in logic whilst mulling over an algorithm’s process flow. As a personal example, I use a small flowcharting application called WizFlow to design my applications. On one particular application I had designed all of the class objects, the sub-systems with their interdependent contracts with a fully normalised database design. During the process of flowcharting my functions I changed the database schema three times, discarding some tables and reducing others to fields within another table. My database design was streamlined to cooperate with my application from my better understanding of the system which flowcharting had given me. My conclusion was:

A flowchart approach results in a fully integrated system where all components are consonant with each other and designed to work seemlessly together.

Most coding difficulty is removed before coding has even begun. It is also much more expedient to change the design of an algorithm or application when represented within a flowchart, by moving a few symbols and adding or removing others, than continuously refactoring code.

Flowcharts also provide documentation of our design decisions before building our application. It is easier to write documentation when you have an overview of an application’s purpose and how it performs it’s functions. This same documentation will help us with troubleshooting and making future decisions upon upgrades. Because we have graphically documented the application already we can use our flowcharts to mark off the various stages of our application’s development as we build. I often mark off the various parts of a flowchart with a highlighter as I build each algorithm. This is a thrifty process as all the guesswork over how an algorithm will operate has been removed by the flowcharting process. Using a flowchart to mark our current position in code is also useful when we have to drop our development work on one application and start work on another as flowcharts makes it is easier to work out where you left off and easier to conclude our coding at an appropriate juncture before moving our development focus to another project.

So in conclusion we should use flowcharts to design our application and it’s code because:

  • Flowcharts show the logic of our design decisions and allow us to plan the most elegant way to build an application by giving us a tangible gestalt view of how our application will fit together, from algorithm to database to network.
  • Flowcharts document our design decisions which will be useful during maintenance and future upgrades of our applications.
  • Flowcharts provide a means to mark milestones of application development as we build upon our application algorithm by algorithm. We will not overlook a crucial piece of code so easily.