Basic BPMN Assumptions:
- All information is stored
- Organization has a mechanism of tasks assignation and transfer
- Every task is accompanied by appropriate instruction
- Every task has standard duration and there is a way to control it
2. Organization Has a Mechanism of Tasks Assignation And Transfer
Time after time students bring diagrams like this to my BPMN training:
Well - formally speaking, it’s pretty correct. Besides, BPMN doesn’t imply a particular methodology so you are on your own right to adopt any style of modeling.
But I have a suggestion: let’s concentrate on actual job, not on parasite «transfer-accept» kind of tasks. Look where we’d come otherwise: every «real» work would be accompanied by two parasite tasks and the number of rectangles at the diagram will triple.
Hence I propose the following basic assumption: when we depict a straightforward sequence flow between tasks -
it implies that:
- The company has some regular mechanism that transfers tasks between performers. No matter what it is - BPMS, email, phone, couriers and incoming/outgoing trays… as soon as the calculation was prepared, the process would move to the accounting department for sure.
- The basic discipline is in place granting that if e.g. the task «Prepare calculation» was assigned to Sales department, it will be executed. No one has neither the right nor the ability to pretend he/she did not notice the task or did not realize it was assigned to him/her or to decide not to accept the task. If this assumption isn’t met then it’s a failed organization overall and there is no use to talk about process management.
Some clarification is needed here: of course, when it comes to process implementation with or without BPMS, the assignation and transfer issues will arise: performers for every task should be assigned, organizational structure and the user directories (LDAP, AD) should be properly set up, reassigning a performer during an execution should be possible to handle e.g. employee leave or sickness.
So I’m not trying to downplay these issues, let alone ignoring them. Just like in case of process data, I suggest splitting the complex task into independent ones which means forgetting about tasks assignation and transfer while developing a process diagram.
As a final remark, here is a counter-example of a meaningful «transfer-accept» kind of tasks: a leasing company sends vehicle registration papers to a remote branch eight time zones away. In this case it’d make sense to depict the «Send papers with courier» task and probably record the package id, date and time to control the delivery.
But normally a sequence flow connecting tasks like on the diagram above is enough.
To be continued…