I’ve come across the concerns of Keith Swenson and Anatoly Belychook on the missing expressive power of BPMN with respect to the description of human decisions in business processes. Bruce Silver has tackled the problem too.
I (together with my research group and the WebRatio team) definitely share their concern. After some discussions, experiments, and on-the-field experiences, we decided to go the pragmatic way: we explicitly modeled the human decision (thus challenging the BPMN orthodoxy, I hope we won’t be killed for this:) according to a “proprietary” notation which is however in line with the BPMN 2.0 notation for tasks.
Concretely, we defined:
- user gateways for describing user decisions
- automatic/service gateways for describing decisions taken according to a rule (this is the standard semantics for BPMN gateways) or performed by a service
To give a flavor of the idea, here are two samples from our “BPMN+” diagrams drawn in WebRatio:
- User gateway (notice the small human icon)
 |
| User Gateway in WebRatio |
- Service gateway (notice the small gear icon)
 |
| Service Gateway in WebRatio |
We are successfully using this notation in several projects, but we would also be glad to receive some feedback from the community. Does it solve the issue discussed by the experts above? Is it so irrespective to standards?
Let us know!
Really good proposition. Well, but I continuo worry about the execution of BPMN Processes by a machine. What do you think about it?
Marco, I think that the new notation would work w/o problems, but so would have the old one too 🙂
AFAIK, Keith Swenson gives 4 issues that call for explicit support of human choice:
1 better causality
2 conciseness
3 timeliness
4 enables BPM tools to render UI that maps directly into a speech act
Looking at this list, item 4 can be addressed by the proposed notation, not sure about 3 (I am not that familiar with semantics of gateways in BPMN), issues 1 and 2 are not addressed. Though I can't comment on how important those issues are..
OK, this may work as well as my suggestion I gave here: http://www.saperionblog.com/lang/de/our-second-wish-to-bpmn-2-1-in-respect-to-process-execution-human-decision/3021
The trick must be that the workflow system has to handle an human task followed by a human gateway with the same user involved in a handysome manner as I explained in my request. The user should not ge a new task in his workflist after finishing the first one. With finishing the first he should be asked how to decide as well.
Best Regards, Martin
Dear Keith,
thanks for your authoritative and precise opinion.
I partially share your concerns on the proposed notation, as I reported also in the response to Scott Francis before.
I think the advantage of our notation is mainly conciseness and intuitiveness: one simple block represents both the decision point and the routing options in a very compact way. You proposal did that too, but with a slightly more complex notation. On the opposite, I agree that your solution can be applied to a wider range of situations and can comprise complexities that cannot be applied to ours.
From our experience, our notation is still very useful in a lot of simple real-life scenarios. For the others, we already basically apply a variant of yours.I don't see the two as competing, but more as different syntactic sugars to be used based on convenience.
Andriy,
your analytical evaluation of Keith requirements is useful indeed.
Conciseness should also be covered (and it's actually a strength point), if I'm interpreting it correctly. Not sure about timeliness. Can you possibly cite (or I should ask Keith himself) a direct online reference to the definition of the requirements you mention?
Martin, this is exacly the semantics we give and it' very close to your proposal indeed. It's just a different graphical notation. As I was commenting with Keith, this works for simple cases which quite frequent though.
Marco, items 1-3 are described here: http://tinyurl.com/66huwy4 after Figure 3.
BTW, I think that user choice is an activity (with a duration, a start and an end event, of which the latter is the declaration Keith mentions). In contrast, gateways are events. So user choice and gateway are quite different.
Thanks for the reference.
I agree that gateways are events. Our main motivation in setting them as user driven was that in some very simple cases the user can be simply considered the agent executing the event.
Keith, “combined manual/automated actions” is definitely sensible and I can see a lot of situations where it is useful. I like your interpretation and would not worry about overloading of the symbols.. Also the use of the circular events is nice in this setting.
Another way to distinguish between decisions under the control of a user and system-driven decisions is to model a separate pool called “Workflow Engine”.
This pool would contain every activity that happens in in the workflow engine. If a task is done with a person using the workflow engine, then it is a human task. Otherwise the tasks like “message, send, receive” and so on should be used to separate the different kind of system actions.
The manual tasks (activities that have no existance in the workflow engine) are modeled in the pool of the user. Therefore it is easy to see if a gateway models a decision of a human or a system. No extension of the BPMN is required. In addition, this form of modelling is a good preparation for an executeable diagram…