Моделирование бизнес-процессов в нотации BPMN в Business Studio 5. Практическое руководство

В Главе 1 представлены понятия токена и экземпляра, а так же базовые элементы нотации BPMN, необходимые для моделирования бизнес-процессов.

1.1. Понятие токена и экземпляра процесса

Токен – это виртуальная фишка (например, шарик), которая движется по схеме процесса от одной задачи к другой.

Каждый раз, когда возникает стартовое событие, возникает новый, уникальный токен и запускается новый экземпляр процесса.

Экземпляр процесса – это однократное выполнение процесса от начала до конца, характеризующееся уникальным стартовым событием, информационными входами и результатом выполнения.

Рис. 1 иллюстрирует понятия токена и экземпляра. Представьте себе, что мы описали некоторый процесс под названием «Подготовка ответа на запрос», сформировали, утвердили и ввели в действие его регламент. Теперь нужно его выполнять.

В 9—00 утра поступает первая заявка и сотрудница Юля инициирует 1-й экземпляр процесса «Подготовка ответа на запрос».

В 10—10 утра поступает вторая заявка, но Юля еще занята работой. Поэтому за дело берется Оля и инициирует 2-й экземпляр процесса «Подготовка ответа на запрос». К этому моменту Юля уже выполняет 6-ую операцию в 1-м экземпляре процесса.

В 11—58 поступает третья заявка. Юля уже освободилась. Она берет заявку и инициирует 3-й экземпляр процесса. В это время Оля выполняет только третью задачу во 2-м экземпляре процесса.

Таким образом, до 12—00 были запущены три экземпляра процесса.

Понятия токена и экземпляра процесса являются ключевыми для освоения методов моделирования бизнес-процессов, которые можно исполнить в строгом соответствии с разработанной схемой.

Рис 1. Токены и экземпляры процесса.

1.2. Базовые элементы нотации BPMN

Рассмотрим базовые элементы нотации BPMN. На рис. 2 показана схема процесса, созданная в нотации BPMN в Business Studio 5. Слева видна панель, на которой можно выбирать объекты для вставки на схему процесса: стрелки, задачи, события и шлюзы. Ниже (по вертикали) представлены ссылки на справочники, которые содержат объекты, часто используемые при моделировании.

Обратите внимание на кнопку «Автоматическое связывание элементов» в верхнем меню. Рекомендую ее включать – это сильно ускоряет процесс моделирования за счет того, что при вставке один объект помещается сверху другого до появления перекрестия. После этого объекты автоматически выравниваются по горизонтали и связываются между собой стрелкой. Это удобно.

На рис. 2 использован красный шрифт для сносок. Сноски – это объекты, которые можно использовать для представления рабочей информации на схеме процесса, например, для обсуждения. В готовой модели в Business Studio сносок быть не должно, так как их невозможно вывести в отчет (регламент). Всю значимую информацию рекомендуется заносить в атрибуты объектов модели. Например, текстовое описание процесса можно заносить в атрибут «Описание». Посмотреть атрибуты объектов в Business Studio вы можете, выделив задачу, нажав правую кнопку мышки и выбрав внизу «Свойства объекта».

В нотации BPMN схема процесса представляет собой пул, разделенный для лучшего восприятия информации на несколько дорожек. В Business Studio эти дорожки создаются с использованием объектов справочника «Оргединицы»: должностей и ролей. Выбор должности или роли определяется целями создания модели и используемым подходом к созданию архитектуры в целом. Довольно часто оказывается удобным использовать роли, только нужно грамотно их именовать.

В Business Studio любой процесс в нотации BPMN должен обязательно начинаться, как минимум, с одного стартового события (Start event)1. На рис. 2 показано стартовое событие неопределенного типа. Процесс должен завершаться одним или несколькими событиями (End event). Как стартовых, так и завершающих событий у процесса может быть несколько. Но есть определенные правила, которых нужно придерживаться при их создании. Мы рассмотрим их ниже.

На схеме представлено шесть задач (операций). Термины «Задача» и «Операция» я буду использовать в книге в качестве синонимов. При именовании задач в нотации BPMN рекомендуется придерживаться правил, представленных в таблице 1. Почему это важно? Дело в том, что нечеткие, расплывчатые, некорректные названия препятствуют адекватной интерпретации схемы процесса ее читателями: руководителями, экспертами, исполнителями.

Таблица 1. Требования к формулировкам

На рис. 2 задачи связаны между собой стрелками типа «Sequence Flow» (последовательность потока). Они показывают, что одна задача запускается на выполнение сразу после завершения предыдущей задачи. Sequence Flow – это ключевая, с точки зрения построения исполняемой модели, стрелка в нотации BPMN. Именно по этим стрелкам «перемещаются» по схеме процесса токены.

На рис. 3 показаны два возможных визуальных представления шлюза «Исключающее ИЛИ».

Рис. 3. Возможные визуальные представления шлюза

«Исключающее ИЛИ».

Нотация BPMN допускает оба представления. Для того чтобы шлюз отображался без маркера, нужно убрать галочку, пройдя следующий путь в Business Studio: «Главная/Настройки для всех пользователей/Модели/Параметры диаграммы BPMN/Показывать маркер эксклюзивного шлюза». Лично я предпочитаю шлюз «ИЛИ» с косым крестом внутри.

Рис. 4 поясняет, как работает шлюз «Исключающее ИЛИ» («Эксклюзивный»). Слева показано ветвление потоков. Шлюз «Исключающее ИЛИ» пропускает процесс только по одной ветке из нескольких (минимум – две, максимум – не ограничено). Поток работы пойдет либо по стрелке с «Условием 1», либо с «Условием 2». Третья ветка не именована, но на ней показана небольшая косая черта – это так называемый «Поток по умолчанию» (Default Flow). В нотации BPMN это означает следующее. Если не выполнено ни одно из специфицированных условий на других стрелках после шлюза, то поток работы пойдет по стрелке Default Flow. Другими словами, этот поток можно назвать в терминах программирования – Else («Иначе»).

Рис. 4. Шлюз «Исключающее ИЛИ» («Эксклюзивный»).

Далее на рис. 4 показано слияние потоков при помощи шлюза «Исключающее ИЛИ»: любой из трех потоков далее будет продолжен как один.

Кстати, шлюзы можно сравнить с трамвайными стрелками, а движение токенов – с движением трамваев разных маршрутов по рельсам.

Далее на рис. 4 показан вариант, когда два потока сходятся и сразу расходятся на одном шлюзе «ИЛИ». В нотации BPMN это недопустимо. Необходимо использовать вариант с двумя шлюзами (показан на рис. 4 справа): сначала на объединение, а потом на ветвление потоков.

На рис. 5 показана схема с двумя вариантами моделирования возвратов. Вверху рис. 5 представлен вариант, допустимый нотацией BPMN. Многие так и делают. Но проблема в том, что при проектировании большой схемы можно допустить логическую ошибку. Например, там, где должно быть «И», есть риск не указать нужный шлюз, а просто присоединить стрелку к задаче. Но это уже будет не ситуация запуска по «И», а именно по «ИЛИ». Поэтому я рекомендую использовать вариант с «возвратным» шлюзом, то есть шлюзом «Исключающее ИЛИ» на слияние потоков. При таком стиле моделирования вероятность допустить логическую ошибку существенно ниже.

Рис. 5. Возвраты с использованием шлюза

«Исключающее ИЛИ».

На рис. 6 показан вариант, когда две стрелки выходят из одной задачи без какого-либо шлюза. Такой вариант допускается нотацией BPMN и интерпретируется, как логическое «И» (о нем поговорим немного ниже). Однако использовать такой подход при моделировании в Business Studio категорически не рекомендуется. Некоторые пользователи подписывают стрелки и считают, что получили ситуацию с «ИЛИ». Это тоже неверно. В BPMN – это «И», даже если подписать стрелки.

Рис. 6. Условные переходы.

Справа на рис. 6 показаны стрелки с небольшими ромбиками. Это так называемые условные переходы. В нотации BPMN, как это ни странно, существуют две альтернативные возможности показать ветвление процесса.

Первый способ – это использование классических шлюзов «ИЛИ» («И/ИЛИ»).

Второй – использование условных переходов (стрелок с ромбиками). Категорически не рекомендую применять оба указанных способа одновременно на одной диаграмме (даже более того – в архитектурной модели в целом), так как это будет путать пользователей.

На рис. 7 показан шлюз «Неисключающее ИЛИ» («Неэксклюзивный»). Работает он следующим образом. После шлюза может быть выбран любой переход или любая их комбинация (от «0» до всех вместе). Однако в нотации BPMN рекомендуется проектировать модель так, чтобы хотя бы один переход всегда мог быть выполнен. В противном случае (при отсутствии потока по умолчанию) возможна ситуация, когда процесс «зависнет» (ошибка исполнения в BPMS).

Обратите внимание на следующую рекомендацию при использовании парных шлюзов на схеме процесса. Варианты ветвления, определенные для шлюза «Неисключающее ИЛИ», «запоминаются» процессом и должны использоваться при слиянии потоков на втором шлюзе «Неисключающее ИЛИ» парном первому (см. пример на рис. 7 – условия маршрутизации описаны текстом под шлюзами).

Рис. 7. Шлюз «Неисключающее ИЛИ»

(«Неэксклюзивный»).

Если на схеме процесса используется несколько пар «Неэксклюзивных» шлюзов, то желательно подписывать соответствующие пары для того, чтобы было наглядно видно, какая сходящаяся развилка соответствует расходящейся.

На рис. 2 показано, что шлюзы «ИЛИ» для ветвления потоков именованы. При моделировании в Business Studio это делать желательно, чтобы модель была наглядной и понятной участникам проекта оптимизации процесса и, в последующем, исполнителям регламента, сформированного на основе схемы процесса. Также рекомендуется указывать названия стрелок после такого шлюза. Текст на стрелках нужно формулировать кратко, но понятно. Недопустимо в названиях стрелок детально и длинно прописывать все нюансы маршрутизации. Это делается в Business Studio другими средствами, которые мы рассмотрим ниже. Для шлюза «ИЛИ» на объединение потоков название не указывается.

На рис. 8 показан шлюз «И». Слева показано ветвление потоков. Шлюз «И» работает следующим образом. После него будет одновременно запущено столько потоков (токенов), сколько показано исходящих стрелок. То есть после шлюза «И» будет выполняться несколько потоков работы одновременно.

Рис. 8. Шлюз «И».

Шлюз «И» также используется для слияния (объединения) потоков, как показано на рис. 8 справа. Пока все токены, бегущие по стрелкам, не соберутся на шлюзе «И», этот шлюз не сработает и процесс дальше не пойдет.

На рис. 9 показаны различные допустимые варианты использования шлюза «И».

Вариант 1 – шлюз «И» разветвляет процесс на два потока, которые заканчиваются различными End-ами.

Вариант 2 – показано параллельное выполнение двух потоков, которые потом сходятся на шлюзе «И», а процесс продолжается.

Варианты 3 и 4 отличаются одним шлюзом «И», но логически совершенно эквивалентны друг другу.

Рис. 9. Варианты применения шлюза «И».

Теперь вы понимаете, что на рис.2 задачи 4 и 5 выполняются исполнителями одновременно. Например, это может быть совместное обсуждение какого-то рабочего вопроса на совещании.

1.3. Типовые логические ошибки

При использовании логических операторов (шлюзов) возможны логические ошибки, которые приводят к тому, что процесс нельзя выполнить. Рассмотрим типовые, чаще всего встречающиеся ситуации.

На рис. 10 показана ситуация, когда после первого шлюза «Исключающее ИЛИ» запускается Задача 2 или Задача 3. Если будет запущена, например, Задача 3, то токен придет на шлюз «И» после этой задачи. Данный шлюз может пропустить поток процесса дальше только в том случае, если на него придут два токена. Но в рассматриваемой ситуации это невозможно – процесс застрянет на шлюзе «И». Если у вас возник вопрос: «Как правильно?», то ответ следующий. Нужно использовать либо два шлюза «ИЛИ», или два шлюза «И». Тогда схема будет рабочей.

Рис. 10. Логическая ошибка. Процесс «застрянет»

на шлюзе «И».

На рис. 11 показана другая ситуация. После выполнения Задачи 1 на первый шлюз «И» приходит токен 1. После этого шлюза возникают токены 2 и 3. Если после шлюза «ИЛИ» токен 2 пойдет по стрелке А, то второй шлюз «И» не сработает никогда, так как токен 3 будет ждать токен 2, который уже «убежал» по стрелке А. Если же токен 2 пойдет по стрелке Б после «ИЛИ», то шлюз «И» сработает и процесс перейдет на Задачу 4. Таким образом, в одном из случаев возникает логическая ошибка и процесс «зависает». Это весьма распространенная ошибка при моделировании. В таком простом контексте она достаточно очевидна. Но в сложных схемах такую ошибку легко не заметить. Так что нужно быть аккуратнее.

Рис. 11. Логическая ошибка. Процесс «застрянет»

на шлюзе «И» в одном из случаев.

Рассмотрим следующую ситуацию, представленную на рис. 12. Она называется «Размножение токенов». После Задачи 1 шлюз «И» разделяет процесс на два параллельных потока (токены 2 и 3). Задачи 2 и 3 могу иметь разную длительность выполнения. Поэтому один из токенов первым прибежит на шлюз «ИЛИ». Этот шлюз сработает и будет запущена Задача 4. Потом прибежит второй токен и ситуация повторится. Даже если токены прибегут на шлюз «ИЛИ» одновременно, оба будут пропущены дальше и Задача 4 будет выполнена два раза.

Рис. 12. «Размножение токенов».

На рис. 13 показан пример схемы, в рамках которой ситуация с размножением токенов является практически целесообразной.

Рис. 13. «Размножение токенов». Практический пример.

В ряде случаев это действительно нужно. Например, Исполнитель 1 дает задание разным сотрудникам на одновременный сбор данных по Агрегатам А и Б. Задачи одновременно выполняют Исполнитель 2 и 3. Затем Исполнитель 1 вводит данные в базу. Задача «Занести данные в базу» будет выполнена два раза, но с разными данными на входе.

Конечно, в данном случае, можно было бы вместо «ИЛИ» поставить второй шлюз «И», а Исполнитель 1 мог бы вносить данные в рамках выполнения одной задачи. Выбор решения зависит от практических особенностей выполняемого процесса.

На рис. 14 показан фрагмент модели реального процесса (названия задач изменены). Обратите внимание, что шлюз «И», обведенный красным овалом, никогда не сработает, так как токен 2 никогда на него не придет. Почему? Задача «Дать предложения» не может запуститься, а значит и весь последующий фрагмент процесса никогда не будет выполнен и токен 2 никогда не прибежит на шлюз «И», обведенный красным овалом.

Рис. 14. Пример логической ошибки на схеме процесса.

1.4. Старт процесса несколькими событиями

Рассмотрим вопрос старта процесса несколькими событиями. Эта ситуация часто возникает на практике при создании схем для целей анализа и оптимизации, реже – для автоматизации.

На рис. 15 показано три варианта старта процесса двумя альтернативными событиями.

Рис. 15. Старт процесса несколькими событиями и шлюзом «ИЛИ».

Вариант 1 – возникает два события. После них стоит шлюз «Исключающее ИЛИ». Поток работы запускается одним из возникших событий.

Вариант 2. Процесс так же инициируется двумя событиями по альтернативе. Но шлюз «ИЛИ» стоит не в начале процесса. Этот вариант вполне допустим. Нужно только быть аккуратнее и не забывать про эту альтернативу.

Все стартовые события должны быть связаны с одним потоком работ в рамах пула. Недопустимо размещать на схеме несвязанные между собой потоки работ (например, два потока, которые запускаются разными событиями).

Вариант 3 – когда нужно на одной схеме показать два потока работ, которые вообще не связаны между собой и запускаются различными событиями. Для этого использованы два шлюза «Исключающее ИЛИ», стоящие друг за другом.

Если вас смущает такая конструкция, то можно поместить еще одну задачу между этими шлюзами. Она будет, например, анализировать данные и определять, как маршрутизировать процесс дальше. Хотя в BPMS такие действия вполне можно «повесить» на сами шлюзы.

На рис. 16 показана ситуация, когда нужно запустить процесс при одновременном возникновении двух и более стартовых событий. Используется шлюз «И». С точки зрения моделирования процессов в Business Studio для целей анализа и регламентации так делать можно. Но с точки зрения нотации BPMN и автоматизации в BPMS такой вариант не является корректным. Имейте это в виду.

Рис. 16. Старт процесса несколькими событиями шлюзом «И».

Более сложные инструменты нотации BPMN, используемые для моделирования запуска процесса несколькими событиями будут рассмотрены ниже.

1.5.Использование терминатора

На рис. 17 показано применение конечного события-терминатора (Terminate). В Business Studio такое событие имеет так называемый триггер «Завершение». На рис. 17 терминатор – это End с черным кружком внутри.

После старта процесса и выполнения Задачи 1 одновременно начинают выполняться три потока. Если нижний поток (Задачи 8 и 9) завершается раньше других, то срабатывает терминатор. Оставшиеся два потока будут остановлены, а экземпляр процесса в целом завершен. Содержательно это можно интерпретировать так, что завершение одного потока делает бессмысленным выполнение оставшихся задач в других потоках процесса. Не используйте терминатор без четкого понимания его назначения.

Рис. 17. Использование «Терминатора» для завершения всех потоков в рамках одного экземпляра процесса.

1.6. Типы задач и их применение

В нотации BPMN существует несколько маркеров для задач. При моделировании в Business Studio они могут использоваться для визуального представления типа выполняемой задачи, что делает схему понятнее. На рис. 18 показаны представленные в Business Studio маркеры задач.

Рис. 18. Маркеры задач.

Как правило при моделировании в Business Studio используются абстрактные задачи, то есть обычные задачи (операции) выполняемые исполнителем в процессе.

Маркер сервисной задачи ставится тогда, когда эта задача выполняется полностью автоматически в определенной информационной системе, например в 1С. Если часть задачи все-таки выполняет пользователь, то использовать этот маркер нельзя, чтобы не запутать читателей схемы (в BPMS такая задача пользователю вообще не придет, так как выполнится автоматически).

Ручное выполнение – это задача, выполняемая полностью офлайн без использования какой-либо информационной системы.

Маркеры пользовательская задача, задача-сценарий и бизнес-правило можно использовать, если цель создания модели – подготовка ТЗ на автоматизацию процесса в BPMS.

Пользовательская задача означает, что эта операция выполняется с использованием экранной формы BPMS.

Задача-сценарий выполняется полностью автоматически при помощи скрипта – куска кода, написанного, например, на C# («Си-шарп») или JavaScript, и запускаемого в BPMS по ходу процесса. Такие скрипты бывают очень удобны для целей подготовки данных, выполнения относительно простых расчетов и проч.

Бизнес-правило – эта задача, выполняемая BPMS автоматически при помощи встроенного движка бизнес-правил, полностью или частично соответствующего стандарту DMN. По сути, это обработка данных и принятие решений по маршрутизации процесса на основе таблиц и алгоритмов принятия решений.

Отправка и получение сообщений – это задачи, в рамках которых в BPMS может быть осуществлено межпроцессное взаимодействие путем отправки и получения сообщений. Ошибочно было бы интерпретировать этот маркер как отправку сообщения коллеге по работе по e-mail. Такая интерпретация не соответствует нотации BPMN.

Таким образом, если вы создаете модель для анализа, оптимизации и регламентации, но BPMS у вас нет и задача автоматизации бизнес-процессов в такой системе не поставлена, то в Business Studio рекомендуется использовать только: Абстрактную задачу, Сервисную задачу и Ручное выполнение. Остальные типы маркеров задач могут быть использованы в том случае, если речь идет об описании процесса для целей автоматизации.