BPMN 2.0 Из чего состоит модель бизнес процесса
Не стоит сразу охватывать все варианты моделирования тех или иных ситуаций. Не стремитесь постичь многообразие тонкостей за час. Изучайте элементы нотации. Добавляйте новые элементы в модели постепенно. Начните с того, что понятно сразу, затем переходите к сложным вещам.
Это описание элементов BPMN 2.0 поможет вам.
Не пугайтесь разнообразия значков. Для начала можно обойтись базовыми элементами. Со временем, когда появится необходимость в повышении качества моделей, переходите к использованию полного набора элементов.
Нотация BPMN 2.0 - самая гибкая и простая. Гибкость достигается благодаря набору элементов и правилам нотации. Простота - за счет наглядности. Процессы и ситуации могут быть по разному изображены в модели. Например, циклы или ссылки на части процесса могут быть смоделированы как минимум тремя способами. Все зависит от вашего выбора, целей моделирования и того, на кого модель ориентирована.
Самостоятельно ограничивайте набор элементов и правила, которые будете использовать в работе. Не старайтесь использовать все возможности нотации. Берите только то, что вам подходит и необходимо.
BPMN 2.0 - почти полное описание элементов нотации
Операции
Как и другие элементы нотации, операции бывают нескольких типов. Каждый тип конкретизирует действие, с которым связана операция. Типы операций определяются условным обозначением внутри прямоугольника «операция».
Сервисная операция
Операция, которая выполняется сервисом или механизмом. Иными словами, это операции, выполняемые автоматически. Пример - рассчитать цену с учетом скидки. Операция выполняется программой автоматически. Этот тип операций удобно использовать, когда вы отображаете работу программы или инструмента. Или показываете взаимодействие человека и программы. Кстати, пул, который означает сотрудника в модели, также может обозначать программу. Если задать один пул как программу, а другой как пользователя, то можно раскрыть процесс взаимодействия. Такое возможно только в нотации BPMN 2.0.
Пользовательская операция
Операция, которая выполняется сотрудником с помощью сервиса, инструмента или других сотрудников. Это может быть программа, веб-приложение, оборудование и так далее. Если вы обозначили операцию как пользовательская, свяжите ее с сервисом или инструментом, который в ней используется. Пример пользовательской операции - отправить электронное письмо. Сервисом будет выступать почтовое приложение. Еще пример - просверлить отверстие в стене. Инструмент - перфоратор.
Ручная операция
Операция, которая выполняется сотрудником самостоятельно, без применения каких-то сервисов или инструментов. Пример - почистить апельсин.
Отправка сообщения
Операция, результатом которой является отправленное сообщение. И вот первый пример гибкости нотации - операция «отправить электронное письмо» может быть как типом «пользовательская операция», так и «отправка сообщения». Какой тип использовать, зависит от целей моделирования конкретного процесса и правил, которые вы для себя приняли.
Получение сообщения
Операция, связанная с получением сообщения. Пример - получить письмо на почте.
Выполнение сценария
Операция, которая подразумевает выполнение сценария. Сценарий создается заранее и представляет собой последовательность действий. По сути , сценарий - это тоже процесс. Проще всего понять сценарий как процедуру. Например, проверить документ. Эта операция подразумевает выполнение ряда действий, т.е. мы проверяем конкретные пункты в документе. Это и есть сценарий. Если вы используете этот тип операции, то нужно обязательно указать, какой сценарий используется. Кстати, когда для проверки используется чек-лист, то такая операция явно имеет тип «выполнение сценария», а чек-лист - это сценарий.
Сценарий - это очень удобный элемент, который позволяет «облегчить» модель за счет уменьшения количества отображенных операций. Т.е. мы убираем операции, которые можно преобразовать в сценарии.
Выполнение бизнес-правила
Операция, которая запускает действие какого-то правила. Сценарии и правила схожи. И то, и другое создается и известно заранее. Но есть и разница. Сценарий - ряд действий, который нужно выполнить, чтобы завершить задачу. Правило же предполагает наличие определенных условий и вариантов действий. Сценарий выполнять обязательно. Правило дает выбор. Пример операции, связанной с бизнес-правилом - принять решение о закупке. В качестве правила будет выступать условие - закупка разрешена в рамках определенной суммы. Если сумма закупки выше, то нужно согласовать с вышестоящим руководством. Кстати, в этом примере операция «правило» может запустить операцию «сценарий».
Бизнес-правило - это уникальная штука! И с точки зрения моделирования бизнес процессов, и с точки зрения выполнения. Есть мнение, что описанные бизнес процессы строги и не дают свободу действий сотрудникам. Это неверно. И как раз бизнес-правила дают допустимую свободу действий модели - с точки зрения развития процесса, сотруднику - с точки зрения действий.
Операция-ссылка
Операция ссылается на другой процесс и фактически выполняет его. Т.е. процесс уже где-то существует и здесь он тоже выполняется. В таком случае чтобы не копировать процесс из одного места в другое, просто дается ссылка на него.
Операция-вызов
Отличается от ссылки тем, что если вы используете операцию-вызов, то еще и используете ресурсы этой операции или процесса. Т.е. "одалживаете" сам процесс из другого места.
Процессы в BPMN 2.0
Повторно используемый процесс
С помощью данного элемента определяется место в процессе, где используется сторонний подпроцесс. Например, по ходу приготовления ужина возникает ситуация, когда для его продолжения нужно сходить в магазин. Соответственно "Сходить в магазин" будет повторно используемым подпроцессом.
Процесс-ссылка
В некоторых ситуациях нужно сослаться на процесс. В таком случае используется этот элемент. Например, вы можете указать, что процесс-ссылка является источником некого документа или события.
Событийный процесс
Особый вид процесса. Особенность заключается в том, что такой процесс не имеет входящих/исходящих потоков. Т.е. на диаграмме он не соединен стрелками с другими процессами/операциями. А запускается он, когда в процессе наступает событие, такое же, какое указано в событийном процессе в качестве старта. Зачем это нужно? Иногда не нужно включать процесс в основной поток.
Например, потому что событие, запускающее процесс, возникает крайне редко. При этом ход основного процесса может как прерываться и переходить в событийный подпроцесс, так и нет. Т.е. событийный процесс выполняется параллельно. Например, в процессе обслуживания клиента в банке оператор видит, что клиент является мошенником. В таком случае он подает сигнал службе безопасности, который служит стартом для соответствующего процесса в СБУ. Однако оператор не прерывает процесс, а продолжает обслуживание с целью удержания мошенника на месте до прибытия сотрудников СБУ.
Спонтанный процесс (ad-hoc)
Еще один вид особого процесса. В спонтанном процессе операции не имеют последовательности действий. Т.е. они могут выполняться спонтанно, в любом порядке, с любым количеством повторений. Выполнение такого процесса полностью определяется его исполнителем. Например, спонтанный процесс "Приготовить кофе" имеет в своем составе операции: "Насыпать кофе", "Насыпать сахар", "Налить воду". Порядок действий не важен, т.к. в любом случае мы получим один результат. Что еще важно - не все действия в спонтанном процессе обязательны для выполнения. События начала и окончания не могут включаться в спонтанный подпроцесс.
Циклы
Циклическими могут быть как операции, так и процессы.
Стандартное повторение
В основе стандартного цикла лежит простая мысль. Процесс будет повторяться до тех пор, пока не получен нужный результат. Например, вы будете добавлять соль в блюдо до тех пор, пока не посчитаете, что ее достаточно. Только не забывайте указывать условия выхода из повторения.
Множественный цикл
Этот тип цикла отличается от предыдущего тем, что количество повторений известно и задано заранее. Т.е. для завершения процесса и перехода к следующему, его нужно выполнить несколько раз. Например, нужно дважды проверить первичные документы, прежде чем передать в архив.
Компенсация
Операция или процесс компенсации выполняется в том случае, если в процессе произошло что-либо, что требует дополнительных действий для его завершения. Например, при согласовании документа необходимо внести поправки. В таком случае выполняется компенсирующее действие "внести поправки", которое позволяет завершить процесс согласования. Форма компенсации очень удобна для моделирования. Компенсация - отличительная черта нотации BPMN 2.0.
События в BPMN 2.0
Все виды событий - стартовые, промежуточные и события окончания - тоже делятся на типы. Точнее, они имеют разные тригеры - спусковые крючки. Спусковой крючок - это тип условия, при котором наступает событие. Например, событие - получение сигнала. Тип события - сигнал. Спусковой крючок - его получение.
Тригеры событий схожи во всех типах, но имеют свои особенности. Поэтому каждое событие рассматривается с точки зрения трех типов.
Входящие / исходящие события
Перед тем, как приступить к тригерам, объясню, что такое входящие и исходящие события.
Событие с входящим тригером (входящее событие) означает, что оно наступает, если мы получаем какой то сигнал, сообщение и т.д. Например получение письма - входящий тригер.
Событие с исходящим тригером (исходящее событие) означает, что событие свершается, если что-то отправлено. Опять же - отправлено письмо. Исходящими событиями удобно отображать выполнение условия по передаче информации.
А теперь самое важное. Стартовые события могут быть только входящими, а события окончания - только исходящими. Логика очень простая - стартовое событие запускает процесс, а запуск может происходить только при получении информации. Событие окончания, которое отражает факт завершения процесса, может только передавать информацию. Ведь если информация продолжает поступать, то процесс не завершен.
Промежуточные события могут быть как входящими (получение информации), так и исходящими (отправление информации). К таким событиям относятся: сообщение, эскалация, компенсация, ссылка, сигнал, множественное.
Спусковые крючки событий
Сообщение
Событие наступило, когда было получено или отправлено какое-то сообщение. Событие начала - поступило письмо от заказчика с подтверждением оплаты (только входящее).
Промежуточное событие - отправлен отчет (исходящее). Получена спецификация заказа (входящее)
Событие окончания - отправлено подтверждение отгрузки товара клиенту (только исходящее)
Время
Событие, обозначающее время. Это может быть конкретное время или дата - 10:00 А может быть интервал - каждый понедельник. При наступлении определенного времени процесс начнется.
Пример - событие "последний рабочий день месяца" запускает процесс "инвентаризация". Таймер не может быть событием окончания. Это противоречит сути процессного подхода - каждый процесс производит продукт. А если процесс может быть завершен просто по времени, то это дает возможность не получить продукт в итоге.
Ошибка
Сигнал об ошибке. Такой тип события всегда связан с другим процессом. Т.е. в каком-то процессе возникла ошибка, которая запускает последующий процесс. Пример: событие "ошибка соединения", запускает процесс проверки интернет-соединения с компьютером.
Событие начала "отсутствуют сопроводительные документы" является ошибкой в процессе "отгрузка товара", но запускает процесс "Повторно подготовить сопроводительные документы".
Промежуточное событие "клиент не подтвердил бронирование номера" направляет процесс по другой ветке, и после этого события следует операция "связаться с клиентом для подтверждения брони".
Событие окончания - из примера со стартовым событием "отсутствуют сопроводительные документы" завершает процесс отгрузки товара.
А еще с помощью промежуточного события "ошибка" отображают риски в процессе. Ну и способы работы с ними.
Эскалация
Запускает процесс, который ускоряет выполнение другого процесса, если тот выполняется неправильно. Событие "Эскалация" всегда связано с другим процессом, который передает (эскалирует) выполнение процесса другому человеку или системе, а тот его принимает.
Событие начала "на заявку клиента не был дан ответ в течение суток" запускает процесс рассмотрения заявки у руководителя отдела вместо специалиста по обслуживанию. Событие может быть только входящее.
Промежуточное событие может отображать тот же переход заявки от специалиста к руководителю, но в рамках одного процесса. В таком случае промежуточное событие отправки у специалиста будет переходить в соответствующее событие приема у руководителя.
Событие окончания - тот же пример, что и в стартовом событии - "на заявку клиента не был дан ответ в течение суток" завершает процесс и отправляет заявку другому человеку. Событие только исходящее.
Отмена
Такое событие отменяет дальнейшее выполнение процесса, при этом все, что было выполнено в процессе до этого, должно быть компенсировано. Техника и инструменты должны быть возвращены на место, отправленные сообщения аннулированы и т.д.
Промежуточное событие. В случае промежуточного события процесс направляется по другой ветке. Например, после события отмены клиентского заказа необходимо еще выполнить ряд действий, связанных с указанием причин отмены.
Событие окончания "никто не пришел" отменяет подготовку вечеринки и все, что было для нее сделано.
Событие отмены не может быть стартовым.
Компенсация
Понятие компенсации означает, что в случае наступления события компенсации в процессе для его завершения должны быть выполнены дополнительные действия.
Событие начала запускает процесс, который должен компенсировать обстоятельства, возникшие в другом процессе. Такое событие тоже всегда связано с другим процессом. Пример: событие начала "проверить сборку узла" запускает соответствующий процесс и компенсирует процесс "сборка узла".
Промежуточное событие, обозначающее, что тесто слишком жидкое, является исходящим событием компенсации, т.к. запускает операцию "добавить еще муку". После выполнения компенсирующей операции процесс "приготовить тесто" будет завершен. Если добавление муки выполняет другую роль в процессе, то в одной роли это будет исходящее событие, а в другое - входящее.
Событие окончания "клиент просит скидку за пределами лимита" заканчивает процесс продаж у менеджера и запускает процесс "рассмотрение клиентской заявки" у сотрудника, ответственного за подобные решения.
Состояние
Событие, обозначающее некое состояние объекта. Состояние относится к параметрам. Например, стартовое событие "температура процессора превысила 70 градусов" запускает процесс охлаждения процессора. Или стартовое событие, обозначающее состояние вашей второй половины как "плохое настроение", запускает процесс приготовления его/ее любимого блюда. То же касается и промежуточных событий - состояние какого-то объекта определяет ветку развития процесса.
Событие окончания не может иметь тригер состояния.
Сигнал
Событие сообщает о поступлении или отправке какого-то сигнала. Сигнал похож на сообщение, но разница заключается в том, что сообщение содержит информацию, а сигнал нет.
Событие начала "свисток чайника" - это сигнал, который запускает процесс заваривания чая.
Промежуточное событие "поднятый флажок проводника" передает сигнал машинисту о готовности к отправке. Соответственно, для машиниста сигнал является входящим.
Событие окончания "выключение света на сцене" передает сигнал об окончании выступления и завершает процесс.
Множественное
Событие предполагает множество вариантов, но для его наступления достаточно хотя бы одного. Или какой-то одной комбинации событий. Бывают такие случаи, когда нет необходимости конкретизировать каждое событие и можно их объединить в группу. В таком случае достаточно просто перечислить, какие варианты наступления события могут быть.
Событие начала - "процесс начнется, если клиент позвонит по телефону, придет в офис или обратится через форму связи в интернет". Все это отображается одним значком. Список событий задается или в названии события, или с помощью текстовой аннотации, или в описании элемента диаграммы. Событие начала может быть только входящим.
То же касается и промежуточного и события окончания. Единственный нюанс - промежуточное событие может быть как исходящим, так и входящим. Событие окончания может быть только исходящим.
Параллельное множественное
То же самое, что и множественное, но событие произойдет, только если будут выполнены все заданные условия. Например, мы начнем процесс подготовки к лыжной прогулке в том случае, если сейчас зима, на улице есть снег и температура составляет не выше 5 градусов.
Ссылка
Используется для связки процессов или частей. Если событие окончания одного процесса ссылается на другой процесс, то это же событие является началом другого процесса. Только типы событий разные.
Пример: событие "ужин закончился", которое является завершающим событием процесса "ужин", ссылается на процесс "помыть посуду" и запускает его. Промежуточные процессы могут ссылаться как на внешние процессы, так и на процессы внутри себя.
Ссылки могут быть как входящими, так и исходящими.
Терминация
Событие окончания, которое говорит о том, что выполнение всех операций в процессе должно быть немедленно завершено. Самый простой пример "срабатывание пожарной сигнализации в здании" является событием терминации, потому что надо все бросить и эвакуироваться.
Прерывающее и непрерывающее событие
Ну и последнее, что надо знать о свойствах событий. Каждое событие в нотации BPMN 2.0 может прерывать или не прерывать процесс. Это относится только к событиям начала и промежуточным событиям. Прерывание означает что наступление события необходимо для продолжения процесса. Если же событие не влияет на ход процесса, не определяет или не изменяет его, то оно просто учитывается. Например, автоматическая фиксация какого-нибудь KPI не влияет на процесс, но тем не менее может быть отображена на схеме. Также непрерывающими событиями можно отображать совокупность условий, которые на данный момент не влияют на процесс, но будучи выполненными вместе собираются в Множественное или Множественное параллельное событие, которое уже влияет на процесс. Примеры подобных ситуаций я соберу в отдельной статье.
Шлюзы BPMN 2.0
Шлюз "Исключающее ИЛИ", основанный на данных (XOR)
Развилка подобного типа означает, что дальнейшее развитие процесса зависит от определенных данных или решений. При этом процесс может развиваться только по одному пути развития событий. Самый простой пример - любой вопрос, ответ на который может быть "да" или "нет". На улице идет дождь? Если да, то берем зонт. Если нет, то не берем.
Шлюз "Исключающее ИЛИ", основанный на событиях (XOR)
Как и в предыдущем варианте, процесс может развиваться только по одному пути, но теперь он определяется на основании событий. Т.е. в зависимости от того, какое событие произойдет, дальше процесс и будет развиваться. Например, если клиент перезвонил в оговоренный срок, то дальше просто происходит беседа с ним. Если же звонка не было, то менеджеру самому необходимо связаться с клиентом.
Шлюз ИЛИ (OR)
Данная развилка используется, когда необходимо показать, что процесс может развиваться в результате наступления нескольких событий. Например, вы можете пойти гулять с собакой в случаях: если настало время прогулки, если собака просится на улицу или если оба эти события наступили. Т.е. наступление одного события и, как следствие, развитие процесса не исключает наступления другого события. Процесс запускается при любом сочетании событий.
Комплексное решение, объединение
В нотации BPMN 2.0 во всех случаях множественных решений требуется заранее заданное условие, чтобы развилка сработала. Почему-то в голову пришел вот такой пример - для того чтобы сработало заклинание, его необходимо произнести (выполнить процесс) только в полнолуние, в апреле високосного года, или при убывающей луне 29 февраля. Т.е. вы сможете пройти развилку и выполнить операцию, только если выполнен один из наборов условий.
Параллельная развилка, объединение (AND)
Здесь все просто. Для того, чтобы процесс стал развиваться дальше, необходимо выполнение всех условий, входящих в развилку. Если же из развилки выходит несколько потоков, то они развиваются параллельно. Пример: чтобы войти в дверь, закрытую на 3 замка, вам нужно открыть каждый из них. Дверь - это и есть развилка))
Объекты данных BPMN 2.0
Исходящие данные
Отображает появление данных в результате выполнения процесса или операции. Например, в результате обслуживания клиента появляются данные о времени обслуживания. С помощью этого элемента можно показывать фиксацию показателей эффективности.
Входящие данные
Используется чтобы показать, что для выполнения процесса или операции необходимы некоторые данные. Например, для идентификации клиента, обратившегося в колл-центр, необходим номер договора.
Потоки BPMN 2.0
Поток по умолчанию
Такой поток, который считается верным в процессе. Из таких потоков складывается верный и желаемый путь всего процесса.
Условный поток
Развитие процесса происходят исходя из определенных условий. Но если вы не обозначили условия событиями или развилками, то можно воспользоваться таким элементом. Тогда в описании потока необходимо указать условия его возникновения.
На сегодня все. Я рассказал почти обо всех элементах нотации BPMN 2.0. Хотите освежить в памяти описание базовых элементов? Оно находится здесь. Есть еще дополнительные типы диаграмм и элементов, например диаграмма Хореографии и Диаграмма взаимодействия, но они используются не так часто. О них как-нибудь потом.
Нотация BPMN давно является стандартом моделирования бизнес-спроцессов. Мы подготовили для вас более 100 иллюстраций, с описанием наиболее распространенных вопросов, связанных с практическим использованием нотации BPMN и моделированием бизнес-процессов
Читать
Поток по умолчанию: "верный и желаемый". Верный и желаемый для кого? Для нас? Для клиента? У вас не указано, где (при использовании каких шлюзов) его желательно указывать, где нет и почему.
Нет определения токена. В BPMN 2.0 - это одно из ключевых определений.
У вас на модели-примере в начале статьи есть ряд достаточно существенных стилистических ошибок:
Стартовое (как и конечное) событие стилистически некорректно называть "Дата такая-то", а "Наступила дата".
Нет эксклюзивных собирающих шлюзов последовательных.
Внутри действий упомянуто название базы данных CRM, хотя в нотации есть специальный символ для этого "База данных". Он для этого и существует от части, чтобы в действиях лишнюю информацию не писать.
Основная ось процесса "Happy path" непонятна.
Типы действий не указаны.
В одном действии указано 3 действия.