As a Process Engineer, I spend a lot of time in Visio, and even though I have been formally trained in Business Process Modeling Notation (BPMN), I usually rely on just 5 symbols when creating my process flow diagrams. These can all be found in Visio’s Flowchart – Basic Flowchart Shapes palette:

Although I have re-purposed the Sub-Process symbol for my own purposes (I use the double lined rectangle to indicated an automated step rather than a sub-process), I like to think that keeping a small list of visual elements allows for better comprehension by those reading the diagrams.

With this small palette of shapes, I can flow out most processes with a high level of precision. It doesn’t allow for looping events or message flow elements, but then again, anyone who looks at my process diagrams can follow them without needing a reference card to figure them out.

In every one of my Process Step blocks, I always enter text in the box indicating who is responsible for performing this step. In the following diagram, you can see that there are two teams are involved. The Incident Response Team (IRT) and the Watcher team:

You will also see that I color code my lines for the Happy Path (green) and Unhappy Path (red). The more red lines there are on the diagram, the more prone the process is to producing bad outcomes.

A few rules I follow:

• All process start/end points (ovals) have either one exit or one entrance point respectively
• All Process Steps (rectangles) have exactly one entry point and one exit
  • Process Steps explicitly say who (or what in the case of automated process steps) is to perform this step
• All Decision Points (diamonds) have exactly one entry point and two exits (one exit for yes, and one exit for no)
  • Decisions implied in the Decision Points are to be made by the group responsible for the Decision Point’s upstream Process Step
• If a process gets too large to fit on a single page, extract a cohesive unit of work and put it on its own page utilizing the baseball “home plate” shape

What you will never see in my process flows are swim lanes. Swim lanes (IMHO) are the bane of simple process flow diagrams.

Swim lanes represent the “Who is responsible for performing a step” in a process flow. Gee, I convey that in the box itself. This truthfully only works if a single team is “Responsible” for the activity. What if two teams are responsible for the activity? Many people who use swim lanes have a step that bridges the line between two swim lanes. Well that makes for a very visually confusing picture. Let me ask you, does this make sense?

In this example you can see that the last beige box on the left is shared between Non SA User and the SA Business Team. What if it the step were shared between the Non SA User and ERMI Ops? Sure, you could re-arrange your swim lanes, but if you had other process steps shared between the Non SA User and SA Business Team, you would be totally screwed.

What’s more, swim lanes only represent a fraction of information needed to define the roles and responsibilities associated with complex processes. For a true representation of the roles and responsibilities of a process, you need a RACI table.

A RACI table allows you to define single or multiple Responsible parties to each process step, and in addition define:

• Who is Accountable for the activity (there can only be one Accountable entity)
• Who is Consulted for the activity (Consultation is a two-way communication and the step can’t be completed until feedback is given from the consulted party)
• Who is Informed when the activity is performed (a one-way communication that doesn’t impede the progress of the activity)

My advice to you is that if you need to convey responsibility, be explicit in the process step box. If you have complex diagrams with shared responsibility, step up to a true RACI authority matrix in support of your process diagram.