Нотация BPMN: как описать процесс, чтобы его поняли исполнители

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

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

Главное за неделю — в дайджесте

Подпишитесь, чтобы не пропустить

Подписаться

Почему именно нотация BPMN стала общим языком

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

• Юристы. Последовательность действий живет в текстовом регламенте.
• Финансисты. Она же — в таблице с колонками согласований.
• ИТ. И еще раз — в наборе экранов и настроек системы.

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

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

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

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

Брюс Сильвер, автор книги «BPMN Method and Style», преподаватель BPMN, перевод с английского

Минимальный набор: чем описывается почти любой процесс

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

Принцип отбора один: если элемент нельзя объяснить исполнителю одной фразой, на диаграмме для людей ему не место. Такой фильтр оставляет пять групп.

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

Такого набора хватает на процессы бэк-офиса, продаж, закупок и сервиса.

• Задача. Единица работы: «проверить комплект документов», «согласовать условия поставки». Название задачи начинается с глагола и отвечает на вопрос, что делает исполнитель за один заход. На диаграмме задачу обозначают прямоугольником со скругленными углами. Если внутри прячется день работы трех человек, такую задачу пора разворачивать в подпроцесс.
• Событие. Что запускает процесс и чем он заканчивается. Стартовое событие фиксирует повод: заявку клиента, наступление даты, сообщение от смежника. Конечное событие называет результат, ради которого процесс существует. Вариантов завершения бывает несколько: заказ отгружен, заказ отменен, заявка отклонена. Промежуточное событие отмечает ожидание внутри процесса: ответ клиента, поступление оплаты, сообщение от подрядчика. События изображают кругом: у стартового и конечного он одинарный, у промежуточного двойной.
• Шлюз. Развилка с явным условием: «сумма выше порога», «клиент подтвердил заказ». В зависимости от условия эксклюзивный шлюз отправляет работу по одной ветке из нескольких, а параллельный шлюз запускает ветки одновременно. Каждая ветка подписана, и по диаграмме видно, куда уходит работа в каждом исходе. Обратно ветки сводит шлюз того же типа. Точки ветвления и слияния не приходится угадывать.
• Дорожка и пул. Пул очерчивает границы одного участника, дорожки внутри пула делят работу между ролями: менеджер по продажам, бухгалтер, руководитель направления. Отдельный пул отводится внешнему участнику: клиенту, подрядчику, банку. Дорожку подписывают ролью, не фамилией и не отделом, и тогда диаграмма переживает кадровые перестановки.
• Поток управления и поток сообщений. Поток управления идет сплошной стрелкой и задает последовательность действий внутри пула. Поток сообщений идет пунктиром и показывает передачу сообщения наружу, между пулами. Различие двух линий и есть тот минимум, по которому читатель отличает внутреннюю передачу работы от внешнего взаимодействия.

Какие элементы BPMN в описательную диаграмму не берут

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

• Компенсации и транзакции. Механика отката группы шагов при сбое нужна движку процессов — системе, которая исполняет модель. Человеку хватает отдельной ветки «вернуть деньги и закрыть заявку».
• Множественные экземпляры. Значок повтора шага для набора элементов нужен настройке системы. На описательной диаграмме та же мысль выражается словами: «по каждой позиции заказа».
• Объекты данных и артефакты. Значки документов, хранилищ данных и ассоциаций уточняют, с чем работает задача, но логику процесса не меняют. Для договоренности между людьми достаточно назвать документ прямо в названии задачи, а артефакты оставить исполняемой модели.
• Событийные подпроцессы, сигналы и эскалации. Разные способы прервать процесс различают там, где ход работы задает система. В описании порядка работы их место занимает обычная развилка с понятным условием.

Пул и поток сообщений: процесс с внешними участниками

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

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

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

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

1. Задать границы. Назвать стартовое и конечное события. Формулировка результата проверяется вопросом «кто получает и в каком виде»: заказ отгружен, договор подписан, претензия закрыта. Все, что происходит до старта и после результата, в эту диаграмму не попадает и уходит в соседние процессы.
2. Назначить владельца. Один человек отвечает за сквозной результат и за изменения в диаграмме. Без владельца описание превращается в общую собственность: споры о передачах между отделами остаются неразрешенными, а правки вносит тот, кто первым о них вспомнил.
3. Собрать участников за одним столом. Диаграмму рисуют вместе с теми, кто выполняет задачи. Аналитик держит нотацию, содержание дают исполнители. Расхождения вскрываются прямо в ходе сессии: два отдела впервые слышат, как на самом деле устроен шаг соседа.
4. Описать «как есть». Первая версия должна показать текущую работу со всеми обходными путями и ручными доработками. Целевую диаграмму рисуют отдельно и после, иначе сравнивать будет не с чем. Соблазн сразу нарисовать желаемое стоит компании самого ценного материала: списка мест, где работа расходится с регламентом.
5. Проверить диаграмму на исполнителях. Человека, не участвовавшего в моделировании, просят пройти по ней свой рабочий день. Место, где он останавливается, и есть дефект описания. Правки после такой проверки идут быстро: их формулирует сам исполнитель.

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

Признаки диаграммы, которую не будут читать

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

• Шлюз без выбора. Ромб стоит там, где решения нет, а есть обычная последовательность действий. Читатель ищет второй исход, не находит его и перестает доверять остальным шлюзам диаграммы.
• Дорожка вместо роли. Ее подписывают названием подразделения: «бухгалтерия», «юридический департамент». Исполнитель не понимает, кому адресована задача — ему или соседу за стеной. У передачи работы нет получателя.
• Диаграмма на несколько экранов. Процесс верхнего уровня развернут до кликов в системе. Путь заявки в такой модели не прослеживается, и вместо разговора о работе начинается разбор чертежа. Лечится декомпозицией: верхний уровень держится в пределах экрана, детали уходят под свернутый подпроцесс.
• «Как должно быть» под видом «как есть». Диаграмма показывает порядок из регламента, а работают в отделе иначе. Участники узнают об этом на первой же сверке и дальше считают все описание фантазией аналитика.
• Таймер на каждом шаге. Значок ожидания стоит у всех задач подряд и подменяет собой срок исполнения. Норматив в нотации так не описывают: срок задачи задают в таблице показателей процесса. Диаграмма превращается в план-график, а логика процесса из нее уходит.

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

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

«Если вы видите такое использование таймеров на модели, то это означает, что ее автор не знает нотацию BPMN».

Владимир Репин, консультант по управлению, член ABPMP Russian Chapter

Что меняется после описания

Описанный процесс сам по себе ничего не сокращает. Работу меняют решения, принятые по диаграмме: убрали лишнюю задачу, переназначили ответственного. Иногда исчезает и сам шлюз, который разводил работу по веткам. Набор таких решений после первой сессии моделирования обычно повторяется от компании к компании.

• Двойное согласование. Один документ визируют два руководителя подряд, и после разбора остается одна виза.
• Задача «на всякий случай». Шаг исчезает вместе с формой, ради которой его когда-то придумали.
• Проверка комплектности. Она переносится в начало процесса, потому что на диаграмме видно, сколько работы делается до момента отказа.
• Места ожидания чужого ответа. Владелец получает их списком и дальше решает по каждому отдельно.

Между диаграммой и результатом всегда лежит отдельная работа. Диаграмму показывают участникам, спорят о задачах, назначают ответственных за передачи между отделами. Затем описание переносят туда, где сотрудник увидит его в момент работы: в базу знаний, в карточку задачи, в интерфейс системы. Без последнего шага модель остается в редакторе, а сотрудник по-прежнему идет за ответом к коллеге.

Например, описание довели до рабочего места в «МТС» при реинжиниринге процессов жизненного цикла продукта. До проекта порядок работы был расписан в многостраничных нормативных документах, до которых никто не доходил, и передавался в разговорах между коллегами. Масштаб компания описала сама, в заявке на отраслевой конкурс: более 300 сессий моделирования и 200 с лишним моделей в нотации BPMN, которые охватывают свыше 70 процессов и 170 подпроцессов. На моделях собрали приложение Product Guide, помощник продуктовых команд с шагами процесса, ссылками на инструкции и контактами ответственных. К нему регулярно обращаются больше 5000 пользователей из 500 с лишним продуктовых команд.

Что измеряют до и после описания процесса

Эффект считают на тех же данных, что собирали раньше. Четыре показателя снимаются без отдельной системы аналитики.

• Срок прохождения от старта до результата. Берется по десятку последних заявок: даты подачи и закрытия уже лежат в почте или в учетной системе.
• Число возвратов на доработку. Они собираются там, где комплект документов принимают без проверки и передают дальше неполным.
• Доля передач с просрочкой. Считается по задачам, у которых на диаграмме назначен срок. Опоздания скапливаются на двух-трех передачах — с них и начинают изменения.
• Количество ручных обходов. Сколько раз за месяц процесс шел мимо описанной последовательности. Рост показателя означает, что диаграмма разошлась с работой и ее пора пересматривать.

Например, замер до и после сделали в «ТМХ». Компания перестроила модель управления процессами качества, включая работу с поставщиками: ежеквартальная оценка по 20 показателям четырех групп, разбор несоответствий по методике 8D. Цифры она привела в собственной конкурсной заявке: средний срок урегулирования претензий снизился на 41%, трудозатраты по вопросам качества уменьшились вдвое, а количество несоответствий — на 44% при росте объема поставок на 15%.

Что меняется на масштабе реестра процессов

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

Например, в «Столото» до проекта реестр процессов вели в Excel, модели рисовали в трех графических редакторах, регламенты хранили в Word. Компания описала процессную архитектуру, владельцев, оргструктуру, документы и ИТ-системы, а управление изменениями автоматизировала. По собственному докладу компании, систематизировано более 600 процессов с назначением ответственных владельцев, длительность ряда бэк-офисных процессов сократилась на 50%, а скорость реализации изменений выросла на 30%.

Когда диаграмму делают исполняемой

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

Что владелец процесса решает до исполняемой модели

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

• Кто выполняет задачу, когда исполнителя нет на месте. Движку недостаточно фамилии: нужны роль и правило замещения на время отпуска или болезни. Пока правила нет, экземпляр процесса ждет конкретного человека.
• Как звучит условие развилки на языке данных. Формулировка «сумма выше порога» для системы ничего не значит, ей нужно поле и его значение. Порог согласовывает владелец процесса, разработчик его не выбирает.
• Сколько исключений закладывать в модель. Отказ клиента, недоступность смежной системы, истечение срока ответа: под каждый случай рисуют отдельную ветку. Список исключений закрывает владелец процесса, и длина списка задает объем разработки.

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

Разница между двумя уровнями видна на процессах с длинным циклом. Так, в «НБД-Банке» сквозного регламента у лизинговой сделки не было, порядок держался на текстовой методике. Основной процесс и шесть вспомогательных описали и автоматизировали на процессной платформе. Свои цифры банк подал на тот же отраслевой конкурс: длительность основного процесса уменьшилась с 30 до 14 дней, формирование документов сократилось с четырех часов до 40 минут. Модуль работает в 34 подразделениях.

Один процесс вместо карты всей компании

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

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

«Наличие регламента не решает всех проблем: нужен контроль за его соблюдением».

Анатолий Белайчук, BPM-евангелист Comindware, президент ABPMP Russian Chapter

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

Через месяц по описанному процессу видно главное: участники возвращаются к диаграмме или снова спрашивают соседа.