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…
Анатолий, я бы явным образом выделил две ситуации:
1) Когда кроме передачи самой “эстафетной палочки”, больше ничего делать не надо - вся необходимая информация для выполнения второй задачи уже сохранена где-то по итогам первой, откуда второй исполнитель сможет ее достать. Эта информация может храниться в контексте этого процесса в BPM-движке, на файл-сервере, в ECM- или ERP-системе. Но, главное, она уже там, откуда исполнитель второй задачи сможет ее непринужденно извлечь, как только это понадобится.
2) Когда помимо передачи активности следующему исполнителю требуется передать еще и какие-то физические артефакты, которые не достаточно просто сохранить в информационной системе. И тут вот есть две подситуации:
а) Первая задача заканчивается тем, что ее исполнитель сам обеспечивает попадание физического артефакта в некоторое условленное место, откуда исполнитель второй задачи может его взять, когда будет необходимо. При этом первая задача не завершается, пока артефакт не окажется в точке передачи (в том же лотке “входящие”, либо не улетит по пневмопочте получателю - если, конечно, пневмопочта считается средством гарантированной доставки). Тогда это мало чем отличается от ситуации номер 1.
б) Первая задача заканчивается тем, что ее исполнитель выдает физический артефакт некоторому промежуточному агенту, который должен его доставить в то место, где его сможет получить и начать использовать исполнитель второй задачи. Например, пакет документов передается курьерской службе для доставки в удаленное подразделение, как вы это описали. Вот тогда не обойтись без этой промежуточной задачи (которая, по факту, может оказаться целым подпроцессом, включающим межпроцессное взаимодействие).
Дмитрий
Спасибо за полезное уточнение.
Кстати, мне приходилось несколько раз наблюдать следующую детскую ошибку в отношении физических артефактов, совершаемую достаточно опытными аналитиками. Эпизод процесса типа такого: получают оригинал документа на бумаге, сканируют его, затем с отсканированным документом что-то там делают (не важно, что). И вот тут-то происходит самое интересное: про бумажный оригинал все забывают, и не понятно - то ли он должен оставаться в сканере до конца своих дней, то ли его можно отправить в мусорное ведро или шредер.
Естественно, потом-то оказывалось, что этот оригинал кому-то очень даже нужен, и тогда в процессе появляется развилка, про которую ранее забыли: оригинал на бумаге начинает жить своей жизнью, а его электронный образ - своей. Своих аналитиков я стараюсь приучить к этому паттерну: если с физического артефакта был снят электронный образ, то нужно подумать, что затем происходит с каждым из этих объектов в отдельности.
Справедливо. Чаще наверное в архив, а не в шредер. Причем желательно с пометкой “хранить до …”, чтоб он не остался до конца дней теперь уже в архиве.
Да, как правило, это выход в какой-то подпроцесс архивирования, потому что если бы оригинал куда-то надо было отправить (например, передать бумажную накладную перевозчику), то про него бы, как правило, при построении процесса вспомнили. А когда документ надо отправить архив, то это воспринимается как “с глаз долой - из сердца вон”, и про него забывают чуть раньше, чем следует.
In fact, if they’re using a BPMS, task assignation and transfer is built into the software- so quite literally you won’t have to write code for assignment in most cases.
Scott, the point is that they don’t need to model it even if there is no BPMS on the horizon.