Владимир Репин

Моделирование бизнес-процессов в нотации BPMN

Пособие для начинающих. Часть I

Шрифты предоставлены компанией «ПараТайп»

© Владимир Репин, 2019

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

16+

ISBN 978-5-4496-6989-6 (т. 1)

ISBN 978-5-4496-6990-2

Создано в интеллектуальной издательской системе Ridero

Оглавление

1. Моделирование бизнес-процессов в нотации BPMN
2. 1. Введение. Что такое нотация BPMN?
   1. 1.1. Нотация BPMN
   2. 1.2. Процесс и его контекст
   3. 1.3. Цель, точка зрения и метод
3. 2. Графическая схема процесса. Основы
   1. 2.1. Пул, дорожки, роли, должности
   2. 2.2. События. Запуск и остановка процесса
   3. 2.3. Операции процесса и стрелки
4. 3. Логика процесса
   1. 3.1. Шлюз исключающее «ИЛИ»
   2. 3.2. Шлюз «И»
   3. 3.3. Типовые примеры. Логические ошибки
   4. 3.4. Некорректное использование шлюзов
   5. 3.5. Шлюзы для старта процесса
   6. 3.6. Головоломная задача
5. 4. Движение документов на схеме процесса
   1. 4.1. Движение документов внутри процесса
   2. 4.2. Потоки документов между процессами
   3. 4.3. Разница между потоком работ и потоком документов
6. 5. Межпроцессное взаимодействие
   1. 5.1. Понятие экземпляра процесса
   2. 5.2.Старт процесса по событию получения сообщения
   3. 5.3. Завершение процесса событием отправки сообщения
   4. 5.4. Промежуточные события отправки и получения сообщений
   5. 5.5. Типовые ошибки при использовании событий отправки и получения сообщений
7. 6. Использование промежуточных событий-таймеров
8. 7. Граничные события. Таймер. Эскалация. Ошибка
   1. 7.1. Граничные события-таймеры
   2. 7.2. Граничное событие-эскалация
   3. 7.3. Граничное событие-системная ошибка
9. 8. Сложные шлюзы в процессе
10. 9. Декомпозиция процессов
11. 10. Описание сквозных процессов
12. 11. Анализ качества графических схем процессов
    1. 11.1. Формальный анализ качества схемы
    2. 11.2. Содержательный анализ схемы процесса
13. 12. Комплексный пример описания группы процессов
14. 13. Организация работы по описанию процесса
15. 14. Что почитать по BPMN и процессному подходу?
16. 15. Правильные ответы на задачки
17. 16. Приложение №1. Основные элементы нотации BPMN
    1. 16.1. Основные элементы нотации BPMN
    2. 16.2. Примеры использования элементов нотации BPMN

1. Введение. Что такое нотация BPMN?

1.1. Нотация BPMN

Вы держите перед собой книгу — краткое методическое пособие по освоению нотации BPMN для целей практического описания и анализа бизнес-процессов компании.

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

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

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

BPMN (Business Process Model and Notation — нотация и модель бизнес-процессов) разработана компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 г. Последняя версия 2.0 вышла в 2012 г. В 20013 году BPMN утверждена в качестве международного стандарта ISO/IEC 19510.

В настоящее время большинство компаний, поставляющих системы автоматизации бизнес-процессов — BPMS, используют нотацию BPMN для проектирования исполняемых процессов.

Фактически, BPMN сегодня — это лучшая, признанная на международном уровне и активно используемая многими компаниями нотация. Но она, как любая другая нотация, имеет ограничения применимости. Например, для формирования архитектуры процессов компании (т.н. модели верхнего уровня) лучше использовать нотацию IDEF0.

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

Рекомендую последовательно выполнять все задания без исключения, даже если что-то уже покажется вам знакомым и слишком простым. Для выполнения заданий можно использовать MS Visio, Business Studio, Bizagi BPM Modeler или любую другую программу, которая поддерживает создание графических схем в нотации BPMN.

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

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

1.2. Процесс и его контекст

Обратите внимание на определение процесса (бизнес-процесса):

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

Входы и выходы — это информационные и материальные потоки.

Прежде чем описывать процесс в виде графической схемы, очень важно определить его контекст — см. рис. 1.

Запомните принцип: процесс может:

• получать входы от других процессов;

• передавать выходы другим процессам.

Процесс НЕ может:

• получать входы от отделов, сотрудников, физических лиц и прочих сущностей, кроме процессов;

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

Почему это так? Процесс — это не сферический конь в вакууме. Он существует среди других процессов в общей архитектуре процессов организации. Если вы будете рисовать на схеме взаимодействие процесса с «Ивановым» или «Отделом закупки», то вместо системы взаимодействующих процессов получите управленческий винегрет.

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

Будет здорово, если вы также выявите управляющие воздействия (планы, приказы, распоряжения) и нормативные требования к процессу (ГОСТы, регламенты, положения и т.п.). Это важно для анализа контекста. Но управляющие воздействия не всегда целесообразно показывать на схеме процесса.

Затем нужно указать состав участников процесса, но об этом несколько позже.

Кроме входов и выходов очень важно идентифицировать события, инициирующие процесс, и события, завершающие процесс. Например, стартовое событие — «Получена заявка на выставление счета», завершающее событие — «Выставлен счет на оплату».

События отличаются от входов/выходов. Они определяют условия запуска (продолжения, завершения) процесса.

Если начать описание процесса без определения его контекста, границ и событий, то с вероятностью 99% вы нарисуете не то, что нужно. Работу придется переделывать несколько раз.

1.3. Цель, точка зрения и метод

Перед тем как описывать процесс, важно определиться с тремя вопросами:

• цель;

• точка зрения;

• метод.

Определите цель. Для чего вам нужно описание процесса? Если читателями процесса будут только люди, то схема может быть простой, построенной с использованием минимального количество графических элементов.

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

Пример укрупненного представления процесса открытия депозита в банке:

1. прийти в банк;

2. открыть депозит;

3. уйти из банка.

Достаточно ли такого описания для решения практических задач? Смотря каких…

Определите точку зрения (как правило, — это точка зрения бизнес-заказчика модели). Ее выбор существенно повлияет на результат. Приведу пример. Как будет выглядеть процесс открытия банковского депозита в банке?

С точки зрения клиента последовательность такая:

• прийти в банк;

• получить талончик в электронной очереди;

• дождаться своей очереди (увы, операция ожидания — это тоже часть процесса);

• объяснить пожелания сотруднику банка, передать паспорт;

• подписать договор;

• перейти в кассу и внести деньги;

• получить квитанцию о внесении средств;

• покинуть банк.

Тот же процесс с точки зрения сотрудника банка (операциониста):

• выяснить потребность клиента;

• проверить паспорт;

• оформить договор и сберкнижку;

• оформить депозит в системе;

• выдать бирку на внесение денег в кассе, передать документы кассиру.

А каким будет процесс оформления депозита с точки зрения председателя совета директоров банка? Нам придется описать взаимодействие всех участников: клиента, операциониста, кассира и, кроме того, информационной банковской системы (она тоже может рассматриваться в качестве участника процесса). Дело в том, что руководителю важно увидеть картину сквозного процесса в целом, чтобы иметь возможность его целенаправленно улучшать.

Определите метод описания. Можно, например, вместо процесса просто описать функции подразделений. Но тогда получится структура функций, а не процессы (тем более, сквозные).

Можно описать движение документов между операциями (шагами) процесса. Но тогда получится не исполняемый процесс, а схема информационных потоков между операциями процесса. Это, в частности, отличает процесс от документооборота.

Для целей анализа времени выполнения процесса и подготовки к автоматизации необходимо описывать реальный поток работ (Work Flow), причем с использованием понятия «Токен» (можно визуально представить себе зверька, бегущего по стрелкам от одной операции процесса к другой и передающего управление — запускающего операции процесса на выполнение).

Замечу, что если вы приступаете к описанию процессов на самом верхнем уровне, то сначала крайне важно понять цепочку создания ценности организации и построить структурную модель, например, в нотации IDEF0. В данной книге метод построения структурных моделей не рассматривается.

2. Графическая схема процесса. Основы

Пулы. Дорожки. Исполнители (роли, должности). События. Запуск и остановка процесса. Правила именования событий. Описание операций процесса на схеме. Правила именования операций. Пример схемы простого линейного процесса.

2.1. Пул, дорожки, роли, должности

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

Внутри рамки (пула) созданы три дорожки (Lane). Дорожки принято называть в терминах исполнителей процесса. Ими могут быть:

• должности;

• роли.

Например, «Начальник отдела продаж» — это должность. «Инициатор договора» — это роль. «Начальник отдела» — это тоже… роль, т.к. не указано, какого именно отдела начальник.

Роли лучше назвать контекстно. Это означает, что нежелательно называть роль просто «Ответственный», а нужно, например, «Сотрудник, ответственный за подготовку отчета о продажах».

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

Дорожки на схемах BPMN принято располагать горизонтально, хотя вертикальное расположение также допустимо.

2.2. События. Запуск и остановка процесса

День рождения — это событие? Еще какое! Вообще, в нашей жизни все начинается с событий. Так и на схемах процессов нужны стартовые события. Первый и самый простой тип стартового события — неопределенное событие (см. рис. 4).

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

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

В реальной же ситуации стартовые события могут возникать в следующих случаях:

• наступление определенного времени;

• получение важной информации;

• исполнение некоторого условия.

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

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

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

2.3. Операции процесса и стрелки

На рис.5 показана схема простого линейного процесса. Процесс начинается со стартового события-таймера «Ежедневно, 10—00». Внутри зеленого кружка показана пиктограмма часов. Такого рода пиктограммы в BPMN принято называть маркерами. Наличие маркера может существенно изменить смысл объекта на схеме процесса. В BPMN используется много разных типов маркеров. Хорошо то, что для начала можно обойтись их малым количеством.

С содержательной точки зрения стартовые события-таймеры могут быть абсолютные и относительные. Примеры. «23 февраля 2018 года, в 17—00», «Ежедневно, в 9—00» — абсолютные таймеры. «Через 2 часа после начала термической обработки» — относительный таймер. Некорректно именовать стартовые события-таймеры, например, так: «Наступило утро» или «Не позднее второй половины дня».

Вернемся к рис.5. Четырехугольники со скругленными краями на схеме — это шаги процесса. Их можно называть действиями, функциями, задачами, но лучше — операциями процесса (в нотации BPMN они называются Task — задача).

Принято именовать операции процесса глаголами, например: «Выполнить…», «Подготовить…», «Рассчитать…» и т. п. Категорически нельзя называть операции процесса так: «Заявка», «Договор», «Коммерческий отдел», т.е. использовать названия документов, отделов и т. п.

Нежелательно в названии процесса указывать роли или должности других исполнителей, например: «Передать документ Начальнику Коммерческого отдела». Название должности в модели организационной структуры[1] может измениться, а в названии операции процесса этот факт не отобразится.

Общее количество операций на схеме процесса целесообразно ограничивать — до 12—15. Общий критерий — схема должна нормально смотреться и легко читаться человеком с нормальным зрением при распечатке на листе формата А4. Конечно, если для ознакомления со схемой процесса используется web-страница[2] и 24-дюймовый монитор, то это ограничение становится не таким жестким.

Как быть, если схема не умещается на один лист А4? Агрегировать шаги процесса, а потом создавать модели нескольких подпроцессов, взаимодействующих между собой.

Операции процесса на схеме соединены стрелками. Эти стрелки имеют тип «Sequence flow» — они показывают последовательность выполнения операций во времени. Можно сказать, что они управляют «потоком операций» — Work Flow.

Хотя нотация BPMN допускает ситуацию, когда в одну операцию процесса одновременно входит несколько стрелок (выходит несколько стрелок) типа sequence, рисование таких схем может запутать неопытного пользователя. Поэтому я рекомендую взять на вооружение и использовать следующее правило: «У операции может быть только одна стрелка запуска и одна стрелка продолжения». Данный принцип проиллюстрирован на рис. 6:

Итак, на рис. 5 представлен простой линейный процесс. На практике процессы редко бывают линейными. По разным причинам возникают возвраты на предыдущие операции процесса. Как быть в этом случае? Об этом — в следующем разделе.

[1] При использовании Business Studio.

[2] Просмотр моделей процессов в BS Portal.

3. Логика процесса

Операторы логики (шлюзы). Шлюз исключающее «ИЛИ». Как правильно показывать возвраты. Шлюз «И». Типовые примеры. Логические ошибки. Шлюзы для старта процесса. Хитрые шлюзы. Головоломная задача.

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

Может ли сотрудник, ответственный за подготовку документа, ошибиться? Да. Может ли Специалист по проверке документов пропустить эту ошибку, а начальник выявить? Тоже да. Конечно, такой процесс эффективным назвать нельзя. Он явно нуждается в оптимизации. Но сначала нужно корректно отобразить на схеме ситуацию «как есть», т.е. показать возвраты и переделки предыдущих операций. На рис. 7 показан такой процесс.

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

Например, после выполнения операции «Проверить проект документа» может быть две ситуации: 1) «Документ проверен. Ошибок нет» и 2) «Выявлены ошибки в документе». Во втором случае возникает возврат и переделка операции «Подготовить проект документа».

«Почему нельзя рисовать ветвления процесса и возвраты безо всяких там шлюзов?» — вопрос, которым задается обычное рабоче-крестьянское сознание. Да, можно рисовать как попало, как душе угодно. Только это уже будет не BPMN, не инженерный подход к проектированию процессов, а свободный полет фантазии на тему… И да, потом схему понять не сможет никто, кроме автора.

На рис. 8 показан фрагмент схемы с возвратом. Нотация BPMN допускает такой возврат, но я рекомендую использовать «Правило двух стрелок» (см. выше). С точки зрения этого правила возврат, представленный на рис. 8 является некорректным.

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

Обратите внимание, что шлюзы можно подписывать. Удобно формулировать вопрос, в зависимости от ответа на который возможны различные альтернативные ветки процесса. Кстати, стрелки с этими альтернативными ветками так же желательно подписывать. Для компьютера это всё равно, а вот для человека схема становится существенно более информативной и удобной в работе.

И последнее. Если внутри шлюза нет никакого маркера, то это тоже шлюз «Исключающее ИЛИ».

3.2. Шлюз «И»

На рис. 9 представлена более сложная схема.

На ней показано, что два сотрудника одновременно выполняют расчеты для разных разделов документа. Затем первый сотрудник включает расчеты в документ и передает его второму на проверку.

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

Первый такой шлюз разветвляет процесс на параллельно выполняющиеся ветки, второй — объединяет процесс.

В примере, изображенном на рисунке 9, это означает, что операция «Включить расчеты в проект документа» не будет запущена, пока не будут выполнены обе операции «Выполнить расчет по разделу А» и «Выполнить расчет по разделу Б».

Кстати, стрелка перехода от операции «Включить расчеты в проект документа» выходит из нижней грани четырехугольника и входит слева в операцию «Проверить проект документ». Можно ли так рисовать? Да, можно.

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

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

Вариант А. После первого шлюза «И» возникает два параллельных потока А и Б. Затем после второго шлюза поток А разделяется на потоки С и Д. Затем все три потока сливаются в последнем шлюзе «И», который служит для объединения трех потоков.

Схема Варианта Б — полностью эквивалентна схеме Варианта А. Возможно, визуально она выглядит нагляднее. Но это вопрос довольно субъективный.

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

• слишком много операций на схеме — необходимо укрупнять, объединяя или исключая операции;

• поток работ движется на схеме зигзагом (справа — налево, слева — направо и т.п.), это запутывает пользователя;

• названия событий — «Начало» и «Конец» — плохо потому, что мы моделируем не сферического коня в вакууме, а процесс в рамках системы взаимосвязанных и взаимодействующих процессов организации.

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

3.3. Типовые примеры. Логические ошибки

В этом разделе вы познакомитесь с типовыми примерами использования шлюзов и наиболее часто возникающими при этом логическими ошибками.

На рис. 13 показана самая простая, но часто возникающая логическая ошибка. После выполнения операции 1 выполняются либо операция 2, либо операция 3. Об этом нам говорит шлюз типа «Исключающее ИЛИ». Но далее мы видим шлюз «И» — объединение двух потоков работ. Но это объединение невозможно, и операция 4 никогда не будет выполнена.

На рис. 14 представлен пример еще одной логической ошибки, похожей на первую. Шлюз «И» разделяет процесс на две параллельно выполняемых ветки. Всё хорошо, но после операции 2 стоит шлюз «Исключающее ИЛИ». Т.е. в одном из случаев процесс никогда не дойдет до второго шлюза «И» и операция 4 никогда не будет выполнена.

Следующий пример можно назвать «Вечер пятницы».

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

3.4. Некорректное использование шлюзов

На рис. 16 показана типичная ошибка применения шлюзов. Важно помнить, что шлюз не может объединять и разветвлять несколько потоков одновременно! Это некорректно.

3.5. Шлюзы для старта процесса

Раздел 3.5. является сложным и может быть пропущен

при первом чтении.

Может ли процесс начинаться не одним событием, а несколькими событиями? Да, может. Если схема процесса разрабатывается для целей регламентации (т.е. передачи информации от человека — человеку), то наличие нескольких разных стартовых событий допустимо, хотя и весьма нежелательно. Например, мы хотим показать на одной схеме несколько разных процессов (стартующих при разных обстоятельствах) вместо того, чтобы формировать и описывать в регламенте несколько графических схем. Однако, такой подход совершенно не годится, если мы создаем схему процесса для целей имитационного моделирования и/или автоматизации. Для того, чтобы это понять, нужно освоить понятие экземпляра процесса (раскрывается чуть ниже). Система автоматизации должна четко понимать, какое событие запускает экземпляр процесса. Если событий несколько, то система не сможет запустить экземпляр процесса до тех пор, пока правило запуска не будет четко определено.

Ниже на рис. 17 показаны различные возможные варианты.

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

Если автоматизация процесса не является целью создания модели, то можно использовать Вариант 2.1.

Если необходимо показать, что процесс стартует только в случае возникновения сразу нескольких событий, т.е. объединить по «И», то можно использовать Вариант 3.1. и 3.2. Вариант 3.3. является ошибкой — так делать нельзя. Дело в том, что в случае Варианта 3.3. экземпляр процесса будет запущен одним из событий (тем, которое произойдет первым), но на шлюзе «И» процесс остановится и дальше не пойдет.

3.6. Головоломная задача

Предлагаем читателю выполнить небольшую задачку на освоение логики процесса. На рис. 18 представлен простой процесс.

Сначала начальник ставит задачу, затем два сотрудника одновременно собирают данные по разным агрегатам. Потом контролер проверяет полученные данные.

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

Ниже на рис. 19 представлена схема, которую обычно быстро рисуют, пытаясь найти ответ, но она неправильная. Предлагаю читателю самому ответить, почему.

4. Движение документов на схеме процесса

Как показать документооборот на схеме процесса. Почему нельзя оставлять «оборванные» входы и выходы. В чем разница между потоком работ и потоком документов.

4.1. Движение документов внутри процесса

Печалька — BPMN не предназначен для моделирования потоков информации и документов.

А уж о перемещении материальных объектов и говорить нечего. Однако кое-что полезное на схемах показать можно.

Схема процесса на рис. 20 дополнена потоком документов. Например, «Документ» является исходящим для операции «Подготовить проект документа» и входящим для операции «Включить расчеты в проект документа».

Для отображения документа (информации, данных) используется специальная, интуитивно понятная пиктограмма. Пунктирные стрелки (их тип в BPMN — association) используются для привязки документов к операциям процесса.

Существует два возможных способа показать поток документов между операциями процесса.

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

Второй способ (Вариант 2) — это привязать документ пунктиром к стрелке перехода между операциями процесса (это стрелка типа sequence).

При моделировании в Business Studio можно использовать оба эти варианта так, как удобно.

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

Заметим, что отображение потоков документов (информации) на схеме процесса Work Flow носит вторичный, вспомогательный характер. Документы делают схему более понятной, но не управляют потоком работ.

Даже если ваша главная цель моделирования в BPMN — описание документооборота (это странно, но вполне возможно), не забывайте грамотно отображать поток работ.

4.2. Потоки документов между процессами

На рис. 21 показана условная схема взаимодействия двух разных процессов. Представим себе ситуацию, что Процесс 1 запускается независимо от Процесса 2 — в разное время и при своих обстоятельствах. По ходу выполнения Процесса 1 создается Информация ABC, которая используется внутри процесса и, кроме того, помещается в общее хранилище информации. Это может быть база данных, файл на диске и т. п.

Через некоторое время, независимо от Процесса 1, стартует Процесс 2. По ходу выполнения Процесс 2 обращается к хранилищу данных, берет оттуда Информацию ABC и использует ее для каких-то своих целей.

Можно ли говорить, что Информация ABC является выходом Процесса 1 и входом Процесса 2? Да, вполне. Хотя понятно, что эта информация поступает из одного процесса в другой не сразу, а через некоторое время, причем через хранилище данных.

Каким образом показать обмен информацией между процессами в BPMN? Пример представлен на рис. 22.

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

Из свернутого пула «Процесс А» выходит пунктирная стрелка типа message. К ней тонкой пунктирной линией присоединен объект «Данные для расчета». Таким образом можно показать, что эта информация является выходом Процесса А и входом для Процесса подготовки Документа, в частности для его операции «Выполнить расчет по разделу А».

Справа внизу схемы показан другой свернутый пул, который символизирует Процесс Б. «Документ» является выходом операции «Утвердить проект документа» и входом для Процесса Б.

На рис. 22 показано, что «Документ» связан стрелкой с блинчиком под названием «Сервер компании (база документов). Возможная интерпретация такой картинки — Документ в качестве выхода операции «Проверить проект документа» попадает в конкретное хранилище данных.

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

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

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

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

4.3. Разница между потоком работ и потоком документов

На рис. 23 представлена разница между потоком работ (Work Flow) и потоком документов. Операция 2 и Операция 3 связаны при помощи перемещения Документа. Между двумя операциями процесса можно показывать движение документов, как говорилось выше. Проблема в том, что после завершения выполнения Операции 2 следующая Операция 3 никогда не начнет выполняться. Почему? Дело в том, что между ними нет связи типа sequence flow, т.е. эти две операции не связаны единым потоком работ. Связь типа sequence flow в нотации BPMN служит для запуска операций процесса. Потоки информации/документов внутри пула в нотации BPMN не используются для запуска операций на выполнение.

В нотации BPMN документооборот не заменяет собой поток работ. Это важно. Кстати, представленная на рис. 23 ошибка является довольно типичной для сотрудников, которые только приступают к освоению нотации BPMN.

5. Межпроцессное взаимодействие

Понятие экземпляра процесса. Межпроцессное взаимодействие. Использование события типа «Отправка/получение сообщения». Разница между запуском процесса и простым обменом информацией.

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

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

Далее по установленному алгоритму (состоит из 6 операций) по ходу процесса входы преобразуются в выходы, например, производятся счета на оплату.

Утром, в 9—00 возникает первое событие — «Поступила заявка» (сама заявка как документ является входом процесса). Стартует Экземпляр №1 процесса — начинается обработка заявки по установленному алгоритму. В 9—30 утра возникает второе событие (тоже «Поступила заявка», но документ уже другой) — запускается Экземпляр №2. В 10—00 поступает третья заявка и стартует Экземпляр №3. В это время, как показано на рис. 24, Экземпляр №1 находится уже на шестой, последней операции процесса. В то же самое время в Экземпляре №2 выполняется уже третья операция процесса.

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

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

Что влияет на эту величину? Как сам алгоритм, так и наличие ресурсов, которые нужны для его выполнения. Это люди, оборудование, информационные системы. Поскольку всегда есть конкретное, счетное количество ресурсов, то производительность процесса всегда ограничена определенным значением.

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

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

5.2.Старт процесса по событию получения сообщения

Рассмотрим рис. 25. Мы видим стартовое событие с маркером внутри. Это белый конверт. Событие соединено стрелкой типа message со свернутым пулом «Процесс-инициатор». Такая ситуация означает, что наш процесс запускается другим процессом путем отправки сообщения. Другими словами, экземпляр нашего процесса обязан стартовать сразу по факту получения сообщения из другого процесса. Дополнительно на схеме показано, что отправка этого сообщения сопровождается передачей документа «Заявка».

Как запомнить для себя пиктограмму (маркер) стартового события-сообщения? Конверт открыт. Всё, что находится внутри конверта, нам видно. Там светло, лежат белые листы и т. п. Такого объяснения нет в нотации BPMN, но для себя так запоминать можно.

5.3. Завершение процесса событием отправки сообщения

На рис. 26 представлен фрагмент Процесса-инициатора. Он заканчивается событием отправки сообщения. Это означает, что процесс не просто завершается, а при завершении запускает на выполнение другой процесс.

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

Как запомнить, что темный конверт — это всегда отправка сообщения? Конверт темный, запечатанный. Что внутри — не видно, темно. Лично мне так проще запоминать.

На рис. 26 видно, что Процесс-инициатор завершается отправкой сообщения. Запускаемый процесс (см. рис 25) стартует с момента получения этого сообщения. Таким образом, два процесса взаимодействуют между собой, причем не только информационно, а с точки зрения управления. В других нотациях моделирования (таких, как классический CFFC с ромбиками или eEPC) такого нет и в помине.

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

5.4. Промежуточные события отправки и получения сообщений

На рис. 27 показано два промежуточных события процесса. Тот факт, что событие промежуточное, отображается двумя окружностями.

Первое событие с темным конвертом — это отправка сообщения. Интерпретировать данную ситуацию нужно так. После выполнения Операции N, Процесс А отправляет сообщение в Процесс Б. Поток работ идет дальше до события с белым конвертом «Получен ответ». Это означает, что после отправки сообщения Процесс А будет ждать получения сообщения из Процесса Б. Только после получения сообщения из Процесса Б Процесс А сможет пойти дальше на Операцию N+1.

Фактически на рис. 27 представлена ситуация, когда по ходу выполнения работы необходимо инициировать экземпляр другого процесса, дождаться его выполнения, получить результаты и пойти дальше. Таким образом, процесс может управлять другими процессами по ходу своего выполнения.

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

Возможна ли ситуация, когда по ходу процесса мы останавливаемся и ждем получения сообщения из другого процесса? Да, вполне. Т.е. не всегда чтобы что-то получить, мы должны что-то отправить.

По ходу выполнения отравляется запрос в Процесс А (т.е. инициируется на выполнение экземпляр Процесса А). После получения ответа выполняется операция «Выполнить расчет по разделу А».

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

Процесс на рис. 28 завершается отправкой сообщения в Процесс Б, т.е. инициирует выполнение этого процесса.

Отметим, что не желательно злоупотреблять на схеме событиями отправки/получения сообщений. Их нужно использовать только тогда, когда это реально необходимо.

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

5.5. Типовые ошибки при использовании событий отправки и получения сообщений

На рис. 29 показаны типовые ошибки, которые часто допускают при освоении нотации BPMN неопытные пользователи.

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

На рис. 29 после операции «Подготовить расчет» показано событие отправки сообщения «Расчет». Это некорректно. Кстати, название этого события тоже не является корректным. Если вам очень хочется или вы уже назвали событие в терминах результата (существительное), то скорее всего вы допустили ошибку. Будьте внимательны.

В конце процесса показано событие отправки сообщения «Расчет утвержден». Формулировка события вполне адекватная, но на схеме не показано, какой процесс запускается этим событием. Это ошибка.

Еще одна ошибка случилась после операции «Подготовить запрос» и отправки сообщения. До этого места все правильно, но после события «Отправлен запрос» нет стрелки типа Sequence flow к событию «Получен ответ». Это означает, что процесс прервется и дальше не пойдет. Так делать нельзя.