Unfortunately, the question “how to model human decisions in BPMN” isn’t frequently asked.
“Unfortunately” because the intuitive answer is wrong. This is not a fork but a parallel execution:
After exiting the “Approve Claim” task the process will continue in parallel on the outgoing flows whatever is written on them.
Valid BPMN diagram looks like this:
It’s implied that the process has a boolean attribute “Approved”. User sets this attribute at the “Approve Claim” task, the gateway checks its value and the process continues in one of the flows.
As you can see, BPMN authors didn’t provide a special construct for human decisions but implemented them rather artificially: a special attribute that must be set by a human and checked in the gateway immediately after.
The user interface for the task where the decision is made may look like this:
When “Done” button form is pressed the task is completed.
I agree with Keith Swenson that BPMN misses explicit support of human routings.
Firstly, human-based and automatic routings look alike at a diagram. Yet this is an important aspect of the process.
If it was my decision I’d introduce explicit support of human routing into BPMN. Since first diagram above is actually more intuitive than valid BPMN, I’d leverage on it:
The existing flow types - Control Flow, Conditional Flow and Uncontrolled Flow - are extended by Human Controlled Flow here, marked with a double dash.
Another issue are screen forms like the one above which provoke user mistakes: it’s tempting to press “Done” and get rid of the task without paying attention to the attributes.
If a decision is requested from a human then the form should look like this:
The buttons could be generated automatically from the process diagram above.
Yet it’s possible to utilize this technique for standard BPMN, too:
“Done” button is replaced by “Approve” and “Deny” here, each of them being bound to two actions: set the attribute value and complete the task.
Now I’m going to use this occasion to appeal to BPMS vendors: please give the opportunity to create more than one button completing the task and bind them to attributes. If you didn’t do it yet, of course.
Hi Anatoly,
I discussed this missing BPMN pattern as well, see http://www.saperionblog.com/lang/en/our-second-wish-to-bpmn-2-1-in-respect-to-process-execution-human-decision/3021
Martin
Martin
Thank you for the input and for the link to google group I found in Keith’s comment to your post.
Of course the pattern itself isn’t new - the first part of the post is mostly for those who are new to BPMN. How do you feel about “Human Controlled Flow”? Unfortunately the existing Controlled Flow misses XOR logic.
Anyway, I wrote it mostly to talk about UI part of the problem: I realized recently that human routing must be rendered differently than normal user task and that we can do it even within today’s BPMN.
Keith Swenson has been urging something like this for a long time. For me, it is not significantly different from conditional sequence flow, and I would have the same objection to your diagram whether it had diamonds or double slashes on the tails: It is not clear that the two output paths are exclusive alternatives or inclusive. You depend on human understanding of the label instead of the explicit behavior of XOR gateway. Whether two paths in a process level are alternatives or parallel flows is crucial to the downstream process. If you were to say that the double slash always means exclusive human choice, I think it would be a harmless addition to the palette, and apparently a welcome one to some people.
Bruce
Thank you for sharing your thoughts. Of course the human controlled flows are supposed to be exclusive.
К слову, а как правильнее обозначить задачу “Рассмотреть заявку” - как “пользовательскую” (с человечком) или как “неавтоматизированную” (с “ладошкой”)?
Конечно как User. Manual task вообще проходит мимо системы; workflow-движок проскакивает ее не задерживаясь. Фактически это комментарий аналитика: “а в это время…”.
interestingly, Lombardi (now Websphere Lombardi Edition) implements something very much like this for user interfaces, and it is quite intuitive and efficient. the UI drives the possible endpoints, rather than the other way around (which makes sense actually).
I fully agree this is a weakness of BPMN.
We propose an approach based on “user gateways”, you may want to read about it here:
http://marcobrambi.blogspot.com/2011/01/user-gateways-in-bpmn.html
Do you think this could be helpful?
Marco
I considered the option you proposed, too. But for me human decision is a task rather than BPMN-style pure (task-less) gateway.
E.g. when a person in charge decides to reject an application, he must specify the reason; when approving, he must specify some other data like budgetig item. We may set up Approve and Reject buttons so that thet will be unavailable until the requested data are entered. Can it be done within your approach?
Kind regards
Anatoly
Thanks for continuing the discussion on this. Your example of adding the response buttons the UI is exactly what we do in Interstage BPM. What is particularly dramatic is that we can edit a process even while it is running, so to simply add a new line from one activity to another instantly adds the new “completion choice” to the UI. It really reduces the complexity.
More posts on BPMN at: http://social-biz.org/tag/bpmn/ and http://social-biz.org/tag/bpm/
One more thing: we used the circular “event” symbol because it is natural to represent this choice as an event. Events are exclusive, just like choices. Events happen at a point in time, just like choices. The activity is started and remains in active mode, until completion, either by event or choice. While the activity is active, the worklist item appears on the users worklist, and is removed from the worklist when either an event comes, or a choice is made. To me, the user choice is really just another kind of event.
Что значит автоматическая развилка, а что решение человека? Я так понимаю вы имеете в виду решение человека как нажатие кнопки явное или явное ДА в электронной почте или устно. А автоматическая, это решение после обработки на основании данных? А зачем их разделить? Решение человека это часть задачи, часть его работы и было бы некорректно это микро действие выносить за пределы задачи в какие то там ромбики или отдельные обозначения стрелок. Ибо решение человека, являясь частью задачи может Сопровождаться входящими данными. Во общем считаю удачным ходом отсутствие разделения - решение человека это часть задачи, а не часть чего то за ее пределами, не часть передачи управления след задаче