If you haven’t seen a flow chart before, you probably started work 30 seconds ago. But often they’re a rather colourful diagram printed on an obscenely large piece of paper with a quagmire of boxes, diamonds and parallelograms which exist to ease your understanding about how a part of the business functions. Don’t get me wrong, I’m not going to diss flow charts too strongly, there are advantages to the humble flow chart.
Most people are visual learners and as such a diagram can go a long way to assisting the understanding of a function of business. Furthermore the symbols used in Flowcharts are fairly well known (a box represents work, a diamond represents a decision etc.) And of course if someone has taken the time to draw a process they are trying to help, and so presumably care about making things easily understood.
However, there are some things which aren’t particularly well expressed using a flow chart, for example, participants are often not well defined in a flowchart, often the author will use colour codes to represent participants in a process, which is great until the flowchart is accidentally sent to the black and white printer 2 minutes before the meeting, or some of the author’s audience is colour blind, saying “sorry Larry - stay back after class and we’ll annotate yours, try to keep up with the discussion” is a great way to be taken off the Christmas card list! Another way of highlighting participants is to repeat their name in each box - again not ideal as often Real Estate is limited with these diagrams.
Another thing that’s often not well expressed in a flow chart is the exceptional flow. Sure we’ve got ourselves a very pretty looking normal case, however life is seldom stock standard normal case and so modelling exceptional cases either calls for a separate diagram or perhaps a tollerance of clutter, and the eye of a Where’s Wally champion.
It is for the above reasons and my background as a developer that I am drawn to Business Process Modelling Notation (or BPMN for short) as a way of overcoming the above shortcomings and communicating business process.
I’ll point out some of the rules in a sec, but first a word of warning: BPMN is very precise, it’s almost like programming given the rules, standards and conventions it employs. As a developer I like (or at least have a grudging respect for) rules, standards and conventions. But my view is that you only need to abide by ALL of the rules if you want a computer to process the diagrams (which is possible), and there is benefit to a low level implementation.
So… the back story. I was first introduced to BPMN at what is possibly the worst possible time - a summer semester at uni. The weather was nice outside and there I was in a lecture theatre listening to our professor ramble on about the subtle difference between an inclusive and exclusive gateway, but although it was really, really dry and I’d have to jack myself up on a ridiculously large cup of coffee and a red bull before each lecture, even at the time I appreciated the elegance of a standardized way, and I filed it away as potentially useful and carried on studying.
Years later, I found myself trying to explain an end to end process which had multiple exceptions in it to people at work, and remembered that dry summer at uni and set about drawing the process. What’s motivated me to post this evening is the lack of questions about process following the release of the document (as well as the kudos received).
BPMN diagrams represent processes in a pool with lanes. Each lane in the pool represents a participant in the process. As an example, I’ve drawn a model of the steps involved in moving an application to a new server.
The process pool is where the action is happening, and the participants are very clearly defined. Usually this represents a collection of teams where the detail is important. Other pools may exist outside of the main process pool, and these usually are black box processes where the detail of what happens is not especially important - all we need to know is the input/output of that entity (usually a third party).
PROTIP: Participants should be generic in nature - i.e. even though John Smith may be the dude when it comes to a certain task, it’s probably best to specify his role in case he changes roles or leaves the company.
Tasks are represented in a box and represent a piece of work which needs to be done. Work is very loosely defined as something which takes time, which adds value to a process. By extension tasks may be performed by humans or by machines.
Events are represented as circles and usually correspond to a milestone or something happening below is a list of a mixed bag of events:
There’s a bunch of others - which you should explore and get to know in your modelling tool (i.e. Visio or Lucidchart).
Events may happen in the main process flow:
OR, they may be used on top of tasks when you’d like to ‘catch’ an event triggered by the task itself (for example something went wrong within the task which is caught with an error):
Gateways are analogous to decisions in flow charts, again there is a dense array of rules which govern the use of gateways, but the most useful are the:
Before I explain the difference between those two gateways there’s one nugget of information about flow you should know:
The best way to visualise process flow is to think of a token running along the arrows inside of the diagram, which tracks progress of an instance of the process. As a general rule, one instance of a process will at any one time have a single token located somewhere inside it. That is until it hits a gateway…
So back to gateways, remember the inclusive and exclusive gateway? Well this is where the token behaviour becomes interesting.
The exclusive gateway by its very nature is much like a decision, depending on the condition expressed on the gateway, the gateway will choose a path for the token to proceed along.
However this behaviour is a little different when it comes to a parallel gateway. Instead of choosing a path, the token is split along multiple paths - which is how you represent parallel workflows.
You don’t need to model every single notification between participants inside the same pool - it’s unecessary - assume that they’re in contact, and in the event that communication needs to be standardised consider other ways in which you could document it.
Lines should always flow left to right, and the diagram should maintain a horizontal timeline. If you run out of space, it’s time for page 2.
Try not to cross the lines. This will ensure your diagram is easily read without having to trace the flow with deep concentration or a pen/finger.
Pretty neat huh? However, as I’ve eluded to, process modelling with BPMN can get very very dense. It’s designed to be as precise as a programming language, although I’d say it doesn’t really need to be to introduce an improvement to documentation.
If you’d like to go down the rabbit hole - there be plenty of material to get down with the BPMN: