Бесплатный фрагмент - Моделирование бизнес-процессов в нотации 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 — задача).

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

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

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

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

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

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

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

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 никогда не будет выполнена.

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