Process Mapping – Introducing Decision Points

In the previous article, I introduced a basic process map consisting of a process start point, a process end point, two process steps and connectors.

It’s rare that a process map is a straight line like that simplified process. There are usually options which can take the process down different paths.

In the case of our book-buying process, we may want to ask the customer if they want the book gift-wrapped as part of free promotion.

Decision Points
The most common symbol for a decision point is a diamond (or a rhombus for the pedants out there). Similar to the process steps, the decision point is linked by a connector into the diamond. The difference is that the decision point should have at least two connectors coming out. It’s generally best to label each connectors with the outcome that it represents, otherwise the reader is guessing which outcome they’re looking at.

So back to the gift-wrap example.

As you can see, I’ve added the following items to the previous diagram:

• Decision point of Gift-wrap
• Outcome of Yes
• Outcome of No
• Gift-wrap Book process step

It could be that there are more outcomes from the decision point. Or that the decision point leads to another decision point, e.g. Red or Blue wrapping paper? More complex would be that some points are only available.

Notation
I’ve already mentioned the common use of a diamond for the decision point and that outcomes should be labelled. In addition, the text inside the Decision Point should be a question. And the outcome labels should be appropriate as answers to that question. Sometimes we have to abbreviate the responses due to space. Bear in mind it’s all about communication, so think whether the readers will understand the abbreviated labels.

Ideally I’d have had a longer label for the decision point in the above example. My excuse is that I’m creating the maps on desktop software, then having to export in a way that works for this website. That’s not the way I’d normally work, since I’d usually use the process modelling software that the client has bought into. I could still get a longer label but the process map suffices to show how decisions are depicted.

You may also see a decision point duplicated at the end of the options. i.e. the process would show a decision point, then the options/outcomes, then bring them all back to a further decision point (often empty). This just shows that the decisions have been resolved and that there’s only the one path forward from that point on. This depends on the modelling standard you subscribe to.

Here’s an example of that. I find that the additional decision point can confuse less-technical, more business-oriented readers. It also takes up more space on the screen or paper. So I tend not to use it that often or until a project is at a more technical stage.

The Most Common Mistake
The most common mistake I see in process mapping is that there aren’t enough outcomes in the process map. The analyst may have assumed that the answer is yes or no. Often there are other outcomes, e.g. don’t know, timed-out, incorrect response, didn’t understand the response. It becomes more of an art than a science as to how many of these outcomes are included. Bear in mind that as more time passes and the project moves forward, then more of those outcomes should be documented.

Note the Ending
In the case of the gift-wrap example, the Process End is the same ‘Book Bought’ whichever outcome is taken from the decision point. That suits us because the Process of Buying a Book is still completed, regardless of whether the customer wants the giftwrap or not. It is possible to have different endings depending on the outcomes inside the process, we’ll get to that later.

Is that sufficient?
In short, no. It’s a start. Some of the first few steps in the process mapping journey. There is more to learn. For instance, we’re not depicting who does what, what else they do, the details of paying for a book, or even what happens if we charge for the gift-wrapping. I stated it was a free promotion earlier since it allows us to focus on the decision point itself. I also want to go into more detail about how process steps relate to processes.

Checklist for decision points

• Is the symbol noticeably different from process steps or other items? (actually not necessary, but very worthwhile if the process modelling tool allows it and most diagramming tools do).
• Do the decision point have enough outcomes?
• Is there a label on each outcome?
• Does every decision point have a question as its label?
• Do the outcome labels relate the decision point question?
• Do all the outcomes connect to other items? (e.g. process step, process end, decision point)

Modelling Standards
I mentioned Modelling Standard above. I refer to standards such as BPMN or UML, specifically UML activity diagrams. In this series, we are starting with basic examples, moving towards depicting models conforming to those standards. The main thrust is to get the basics right and point out some of the common mistakes along the way. Watch out for different terminology, in BPMN the decision points are referred to as Gateways.