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 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:
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.
I really like the use of the term “declaration” and the examples you give to go with it.
This is something I feel people can relate to and use in their processes.
Also, to your point about how to model this more explicitly – I agree this is a shortcoming of the BPMN notation in some respects – it doesn’t clarify when the choice was directly based on human intervention and when it is derivative of human-entered information. There is a difference!
the post really set me thinking on the objective of BPMN and the direction forward in the spec. In the post you refer to decision/judgement by a human participant, but the question that was running in my head was that the model is restricting the choices of judgement, placing a specific location for judgement. Say, for example, how can we model, after interview itself the applicant can be hired. Do you see this as a need?
If the goal is for the person doing interview task to also make this decision, then it should be a single activity: interview and make a choice.
This raises the question of granularity of task, but every task involves a myriad of possible subtasks. But all of the tasks done by one person are put together into a single activity, as long as it is not important to represent those as multiple separate activity. As soon as the baton is passed to another person, you need a separate activity. Thus if one person does the interview and makes the decision on whether to hire, then it is represented as a single activity. If two different people are required: one for interviewing, and one for deciding, then you need two activities — even if sometimes both activities are done by one person.
Generally modeling the decision directly works very well: I have done hundreds of processes.
There is one case where it is not optimal, and that is where a decision is made, but that is followed by a series of steps which are the same regardless of the decision. In this case, both arrows point to the same following node, and, naturally, later you need to have a branch condition that distinguishes which choice was made earlier. The alternative to this is to duplicate that chain of nodes. It is not perfect, but this case is relatively rare.
Excellent post. I always felt that BPMN misess the semantics of “arbitrary choice” and now I know that, thanks to you.
In order to keep with current BPMN, can’t we mark such decisions on a diagram by a different color or use a special icon for them? Let it be a part of custom guidelnes that any BPMN practitioner needs anyway.
My suggestion is that the choice is signified simply by the empty event circle on the edge of the activity. Because a choice happens at a particular time, the choice is kind of like other events, such as timer and exception events. If you had an activity with two choices, a timer, and a exception on the edge, you would know that the activity can be completed four ways: either the user makes one of the two choices, or an exception occurs, or the timer times out. It seems like a natural mapping to me.
Still, there could be other ways to represent it, and my main concern is that there is an agreed upon way to represent this, so that users can draw and read diagrams without confusion.
Just to make myself clear: introducing circle event into future BPMN would be perfect, I just tried to find a workaround for current BPMN.
Your proposal comes with a bonus: if the arrows were labelled this way a tool vendor could automatically generate a UI form containing “Hire” and “Pass” buttons which is very reasonable.
Exactly! The user effectively makes the declaration by pressing the button. The mouse click is mapped directly into a speech act.
Keith – I was meaning to reply much earlier, but along with all the other crap one has on one’s plate these days …
I just posted a note back to Bruce’s exploration of your idea.
The heart of it was that what you are asking for is already in the spec … but it is not widely used. Go look at the Conditional Sequence Flow. pp98
Thanks for clarifying.
My query was more pointing at the need for extensible set of events that you are refering to. My point was that the new model that is being proposed does not allow for such extensions.
Do you see such a requirement into BPMN or dynamic process that you had discussed earlier?
Pingback: links for 2009-04-14 « steinarcarlsen
Derek, your comment about conditional flow is incorrect. Conditional flow does not meet the need in a number of ways.
First of all, if you have three arrows, each of the three arrows might or might not be followed. As a result, 0, 1, 2, or 3 of the arrows might be activated. This is “Inclusive OR” semantics. A choice implies “Exclusive OR” — exactly one will be chosen. I am sure you are familiar with the difference between an Inclusive OR gateway and an Exclusive OR gateway. There is no way in BPMN to indicate XOR behavior on arrows coming out of an activity.
Second, the conditions can depend upon any combination variables. A “choice” is a much more specific concept that represents a decision that that user must make. It might be implemented with variables, but how it is implemented is not important.
Third, the condition is hidden. A “choice” is a visible indicator that corresponds directly to the speech act which is being performed — nothing to do with programming. Simply by adding a “choice” arrow to the activity, and giving it a label, the process designer causes the user at that point in the process to be given that choice.
We at Fujitsu learned this the hard way. Three years ago we changed the notation to put the diamonds on the arrows to indicate conditional flow. This was criticized because it did not represent exclusive flow. Events, however, are exclusive. Events also indicate that an action has occurred at a point in time concluding the activity. So far the updated notation has be accepted by users as a CLEARER indication of the essential communications that people need to make in the enactment of a process.
Bruce Silver’s discussions of this is found at:
(for some reason his blog does not create the automatic link-backs that others do. Should get to the bottom of why they don’t.)
As for Dynamic BPM: It seems that dynamic BPM is more about run time manipulation, and less about rich notation. Because you are creating “throw away” process definitions, you do not need elaborate precise semantic meanings because those take time and effort.
Instead dynamic BPM favors rather simplistic basic interaction patterns. Sometimes using graphical notation will be a barrier, and an “email message” type interface is preferred.
So far as far as I can tell, BPMN already includes everything essential for Dynamic BPM.
http://www.demoprocessmaster.com/HTML/Output/Parallel%20Process/Parallel%20Process.html This shows soem decisions being made – I believe this is the limit of BPMN so far as it currently sits.
This is fine for 99.9% of situations – if not even five 9’s – but even though this is very specific – the vast number of people just do the diamond and leave it at that
Alan, Please, can you check the link, seems to not function. Martin
Anatoly Belychook has documented an anti-pattern where choices are left out of a diagram which should be in there. People document only the sunny day path, but forget the rainy day path.
I believe this is partially the fault of not having a representation for “choice” built into BPMN
Pingback: BPMN 2.0: no longer for Business Professionals | On Collaborative Planning
thank you for your prosposal which I like much. This is what I quite miss in the BPMN. In the most cases where decisions has to be made by users we are modeling this in a simple graphical way.
Until know be modeled not in BPMN, this will come woth our new Version 7 next month. In the old modeler we differentiated to sequence flows. One named “context menue” and the other one “forward”. If the user should decide during forwarding the business case he gets the modeled lables in the context menu. Otherwise only a “forward” is offered in the context menue and the decision is made by the workflow engine depending on the modeled conditions on the sequence flows.
When I read your proposal I directly thought that your empty attached events is the solution. The event is the click by user on what ever present button or context menue. The text presented on the button or context menue is the lable on the sequence flow going out of the empty event.
What can we do to get your proposal into the spec of BPMN 2.0? OK, this seems to be finished. But 2.1 ?
I have just posted about our proprietary solution wishing that we will get what Bruce has proposed with the new “manual” sequential flow:
Our second wish to BPMN 2.1 in respect to process execution – human decision.
Pingback: Modeling Human Routing in BPMN - Process Is The Main Thing
I just found this interesting post. I fully share your concern.
You may be interested to the pragmatic solution based on “user gateways”we are adopting now, I recently posted a summary here:
I would be glad to get your feedback. Do you think this could solve the issue?
I am always interested in creative approaches to thing, and there are some situations where this approach will surely fit, but for the situation I described I don’t think it really works.
Conceptually, I like having the description of the work to be done, as well as the choices to be made, all located in one physical place on the chart. If I give to you a task: evaluate a stock and decide whether to buy, sell, or hold, it is really nice if there is one box which describes the task, and has three lines coming out of it.
Representing that as gateway that blocks waiting for a user to interaction causes two problems in my mind. First is that most assume that gateways are routing logic only, and not actually “doing work”. Gateways are syntactic sugar, while the real work is done in the boxes. Making a decision is usually a really important task. Along with the task of making the decision, we include all the other things, like a user interface and timers to escalate if the decision is delayed too long. It is hard to put all that on a gateway. Second is simply that gateways lack a place to describe the decision being made, and boxes are more comfortable for that.
This notation is particularly useful when you have people that are passing items of work between them. You can draw lines directly between the activity, and each activity is a real task. You may want to take a look at the Trouble Ticket scenario and see how well this work in that case, as well as compare how it would look with your proposed notation: