Representing Choice in a Process Diagram

A business process is compsed of activities.  Are those activities of a computer (an automating diagram) or are those activities of people (a facilitating diagram)?  There are places for both kinds of diagrams in making organizations run better, and BPMN is a notation designed to support both as well.  To support facilitation diagrams well, there is one key thing that is missing: a way to denote a “choice“.

A “choice” is a decision that human actor makes.  This is quite different from a decision which is just a “branch condition”.  A business process is for knowledge workers leverages people more for their evaluative decision making, than simply as a unit of execution.  While an organization can be automated to eliminate tedious and mechanical tasks from the business process, one will never be able to automate the strategic decisions.  For example:

• Deciding who to hire into a team.  An elaborate set of rules and conditions might weed out the candidates, but the final decision depends upon so many factors that simply can not be represented in data about the person.
• Deciding which photo to use for an advertisement campaign.  This choice depends upon many subtle aspects of the photo, and may depend also on current events or zeitgeist.

These sort of things will never be automated, but instead business processes will facilitate human decision making.  As process diagrams rise to higher level workers, the process itself is more about helping people to communicate.  Each person serves as an expert in some aspect of the business, and the process is moving information around to allow these people to coordinate their work together.

Such a process is like language.  It is more like a conversation than it is like a dance.  I was involved in an early project in this area (Fujitsu’s Regatta Techonology from the early 1990’s) where we called these conversations “colloquies“. We modeled the pattern of exchange upon a field of study called “speech acts“.  The people participating in the process are communicating things to each other.  John Searle classified all speech acts into five main categories, and of those, the category of  “declaration” is the most important.

A declaration is a speech act that by its very utterance changes the behaviors of the people involved.  I always give the example of a traditional western marriage ceremony where the preacher “pronounces them man and wife”.  That utterance changes the behaviors of almost all the people in the room (well, some only change a little :-).   When writing a report, the declaration of being finished is most important.  Whether or not they stop writing at that moment is immaterial.  By making this declaration, the reviewers to start reviewing, and the writer commits to not making substantial changes.

The most important speech acts to model in order to track the state of an organization is the “declaration”.  Approving or denying a purchase request is a declaration.  Rejecting a loan request is a declaration.  Even saying that you are “done” with a task is a declaration.  Note that in every case, a declaration involves a choice.  Even in cases where there is only one path forward, the human actor must choose the time of that declaration.  A choice is two things: a “selection” of a path forward, and an “event” denoting the specific occurrence of that selection.

BPMN does not have a way to represent choices (declarations).  How can that be?  Surely it has branch conditions — isn’t that good enough?  Certainly branch conditions can be pressed into service for this, but a choice is different.  Here is a good example of a use for a branch condition:

Figure 1

Figure 1 shows a typical purchase request where it goes through some steps and then find that there is a branch, where purchases involving IT equipment get some special handling (usually requiring additional approvals).   This is not really a “choice” in the way I mean it.  Either the purchase request includes IT equipment or it does not — there is no need for an expert to make a judgment call on this.  It is not the managers job to make this decision. The branch depends on the facts of the case.  It does not matter who designates that the items are IT equipment.

A “choice” is something that a person must make, and it matters who makes the decision.  Consider the following process:

Figure 2

Figure 3

Look at Figure 2 and 3: which one makes it clearer who it is that decides to hire or not?  There are several reasons why Figure 3 is better.  Figure 3 makes it very clear who is responsible for making the decision.  The “Final Review” step will be assigned to a person (or role) and it is very clear that part of that job is to make the decision.  In Figure 2, there is no real way to know which step was involved in making settings that effected the branch condition.  The “causality” behind the branch is not clear from the diagram.  Figure 2 is good when the branch depends more or less purely upon the facts of the case, and the branch does not represent a judgement.

The event circles imply timeliness.  Figure 3 is a better representation of the asynchronous aspect of this choice: the activity itself is not going to move forward until the user communicates the decision, at the time that the decision is complete — that makes it very much like an event.  The event symbols make it clear that only one choice will be triggered, which naturally makes this have an XOR behavior.  Finally, Figure 3 is more compact, which is an important consideration when drawing real-world processes.

Remember, in that process, “Hire” and “Pass” are declarations that are made by the person performing the Final Review. And in making that declaration, the state of the process is changed accordingly.  Go back and look at the Trouble Ticket Scenario, and notice that almost every node consists of a choice that the actor must make in how to move forward in the process.

Figure 3 does not represent standard BPMN but it should.  The ability to represent a choice may not be important in a diagram representing calls to web services.  But a business process for facilitating the work of knowledge workers is greatly enhanced by a direct way of representing choice, because the declarations that a person in those processes would be making is clearly represented.