Вы сильно упростите себе работу над BPMN диаграммами и одновременно сделаете их более простыми и понятными, если примете следующие допущения:
- Вся информация сохраняется
- У организации есть механизм назначения и передачи поручений
- К каждой задаче прилагается инструкция
- У задач есть нормативные сроки, а у организации - механизм их контроля
1. Вся информация сохраняется
Не спрашивайте, где и как сохраняются данные (атрибуты) процесса. Просто примите как данность, что данные процесса есть где хранить и что вы умеете это делать.
Например, в вашем распоряжении есть реляционная СУБД и вы умеете проектировать структуры данных – ваши специалисты знают, что такое третья нормальная форма, ER-диаграмма (диаграмма «сущность-связь»), SQL и т.п.
Конечно, полностью абстрагироваться от данных не получится – рано или поздно вам придется определиться и с этим. Но лучше поздно, чем рано: если стоящую перед вами сложную задачу можно разделить на две относительно независимые – в данном случае на задачу проектирования процесса и задачу проектирования данных – то это непременно надо делать, потому что так ее решать намного проще.
Пример: процесс «Тендер на закупку» –
Вопрос: на основании каких данных осуществляется выбор победителя?
Ответ: на основании предложений от поставщиков (и, вероятно, результатов их оценки), которые появляются как результат выполнения подпроцесса «Получить предложения от поставщиков».
Все, этого достаточно, работаем со схемой бизнес-процесса в предположении, что предложения, полученные от потенциальных поставщиков, где-то хранятся и доступны последующим задачам процесса. Как именно хранятся – в виде тендерных заявок, полученных в бумажном виде, в виде прайс-листа в формате Excel, полученного по электронной почте, в виде XML-документа, полученного через систему электронных торгов, или в виде таблиц реляционной БД – для работы над схемой процесса в общем-то не важно.
Если перед нами стоит задача не только описания, но и автоматизации этого процесса, то после того, как схема процесса готова, надо будет заняться схемой данных. Например, ER-диаграмма тендерного процесса в первом приближении может выглядеть так:
И в дальнейшем, когда процесс будет дорабатываться, параллельно будут вноситься изменения в схему данных. Но не надо объединять эти два аспекта в одной диаграмме – для проектирования данных есть хорошо зарекомендовавшие себя инструменты, а основное предназначение BPMN –проектирование процессной составляющей.
Хотя в BPMN есть объекты данных и хранилища данных, они выступают в роли «граждан второго сорта». Потоки управления в BPMN обязательны – без них диаграмма не будет корректной, а потоки данных опциональны.
Для некоторых аналитиков такой подход непривычен и даже может вызывать отторжение. Опыт работы в других нотациях подталкивает их к тому, чтобы обильно уснащать диаграммы объектами и потоками данных примерно в таком стиле:
Способствует ли объект данных «Заявка» лучшему пониманию схемы? На мой взгляд, нет: раз одна задача называется «Заполнить заявку», а другая – «Рассмотреть заявку», то и так понятно, что у процесса есть атрибут «Заявка».
Поэтому я пользуюсь объектами данных редко – только там, где они важны для понимания логики и в то же время не очевидны. Например, на BPMN-диаграмме можно показать, что в рамках задачи «Выполнить рейс» создается авансовый отчет по предоставленным водителем затратам:
Особый случай – межпроцессное взаимодействие. Здесь, в отличие от оркестровки, потоки данных существенно важны для понимания логики процесса:
Еще по теме:
Продолжение следует…
In regards to your comment “All information is stored” - I have a small disagreement with it.
True, until not long ago that was the case, but then social happened. and with it, the deluge of data and noise that brought with it, and the impossibility to both store it all (it would never get used and is a total waste) and process it in real-time (thus the birth of “Big Data” or i should say rediscovery).
The reason i am bringing this is because we are starting the path where no data will be stored (or very little actually) as the internet of things, big data, and real-time processing become more and more utilized.
everything is stored today, probably - but a large amount of it is useless, and most of what we will use in the (very) near future won’t be stored.
sorry, time to change your assumptions…
Esteban
Esteban, there is a lot of unstructured or poorly structured data around us. But to bring an appropriate result of a business process, the data within it must become structured to the needed degree at some point. This may happen right along with the data input at the entry of the process, or within this very process. But if you do not manage to conquer the chaos of data within the process, you can not guarantee the quality of the process itself and of the result the process is intended for. Thus, as I get it, Anatoly said, that once you have obtained some structured data either from outside or by working over some unstructured data gained from the outside, it is implied that you alway have room where to store the result in the context of the process’s instance, so that it could be used later by the process. Also, you might say that sometimes one has to make decisions based on fussy logic, that is, on come uncertain data. I say: yes, but this case relates more to expert systems natively based on fussy logic. Deem them as “business rules management” layer for you BPM system, and the latter then obtains some structured decision for forking the workflow.