Бесплатный фрагмент - Моделирование бизнес-процессов в нотации BPMN в Business Studio 5

Введение

BPMN (Business Process Model and Notation) — это стандарт ISO с 2013 года и де-факто лучшая нотация для проектирования бизнес-процессов, которые можно автоматизировать в информационных системах класса BPMS (Business Process Management System).

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

Спецификация BPMN — сложный документ. В нем используются сущности и методики, непривычные обычному человеку. Понятия токена и экземпляра процесса, межпроцессного взаимодействия, архитектурные решения BPMN требуют вдумчивого изучения.

На практике, важнейшим фактором успеха является знание и грамотное применение инструмента для проектирования архитектуры и описания бизнес-процессов.

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

Если вы применяете другой инструмент, то книга будет полезна в части разъяснения правил использования нотации BPMN, типовых ошибок и правильных примеров.

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

Читателям, незнакомым с нотацией BPMN, рекомендую начать освоение материала по моей книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (это не является обязательным требованием). Так же желательно хотя бы поверхностное знакомство с функциональными возможностями программного продукта Business Studio 5.

Желаю вам успехов в освоении BPMN и проектировании бизнес-процессов в этой нотации с использованием Business Studio!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечу, что маркеры задач, используемые в конкретной BPMS, могут довольно существенно отличаться от принятых в нотации BPMN. Кроме того, могут использоваться различные цветовые решения, как например в BPMS Elma. Эти аспекты нужно учитывать, создавая ваш внутренний стандарт моделирования процессов (так называемое «Соглашение по моделированию»).

1.7. Типы циклов и их применение

Рассмотрим существующие в нотации BPMN и представленные в Business Studio типы циклов. Они показаны на рис. 19.

Стандартный цикл — это цикл «Do until» — повторное выполнение задачи до того момента, когда свойство объекта обработки не достигнет заданного значения. Например, Катя варит борщ. Пробует. Добавляет соль. Снова пробует и так далее до момента, пока соленость борща не достигнет заданного уровня.

Многоэкземплярный последовательный цикл. Представьте, что Петру нужно наклеить марки на сто конвертов. Конверты разные, но задача одна и та же. Последовательный цикл означает, что задача будет последовательно запущена столько раз, сколько объектов нужно обработать. «Где же они на схеме?» — спросите Вы. Этот аспект на модели визуально не показывается. Информация о структуре данных (документов) для обработки может быть определена вне схемы — в другом документе (или ER-модели), который является частью общей модели исполняемого процесса.

Многоэкземплярный параллельный цикл. Например, всем руководителям отделов нужно предоставить отчет о использовании рабочего времени за прошлый месяц. Задача одна и та же, но данные и исполнители задачи — разные. Такой цикл удобен, прежде всего, при моделировании процессов для автоматизации в BPMS. Если процесс выполняется вручную, то прежде чем использовать маркер, нужно продумать, как эта работа будет выполняться физически.

1.8. Вопросы для самопроверки

В данном разделе представлены вопросы для самопроверки и закрепления материала.

Вопрос 1. Нотация BPMN является (один вариант ответа):

1. ГОСТ-ом РФ;

2. стандартом серии IDEF США;

3. стандартом ISO/IEC 19510;

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

Вопрос 2. Выберите корректное определение экземпляра процесса (один вариант ответа):

1. подробный алгоритм процесса, который могут выполнить исполнители, включающий ряд последовательно выполняемых задач;

2. совокупное количество одинаковых задач, выполненных в процессе с разными стартовыми событиями и входами за определенный период (например, месяц);

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

4. графическая схема процесса с указанием последовательности выполнения задач.

Вопрос 3. Какая из представленных ниже схем процессов (рис. 20) соответствует следующему текстовому описанию процесса: «После выполнения задачи 1, одновременно выполнятся задачи 2 и 3, а затем после их завершения, в случае „А“ выполняется задача 4, а в случае „Б“ — задача 5» (1 вариант ответа)?

Вопрос 4. Какая из представленных ниже схем процессов содержит логическую ошибку (один вариант ответа)?

1. Вариант 1.

2. Вариант 2.

3. Вариант 3.

4. Вариант 4.