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

Я помню своё первое знакомство с нотацией BPMN: передо мной была целая галерея непонятных значков — «прямоугольники с плюсиками», «круги с молниями», «пунктирные линии в никуда». Я чувствовала себя так, будто пытаюсь читать древние руны без перевода. «Как этим вообще пользоваться?» — крутилось в голове.

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

Со временем я начала объяснять BPMN другим: коллегам, стажёрам, бизнесу. Каждый раз приходилось адаптировать примеры, искать простые слова, подбирать аналогии. Так потихоньку накопился мой архив практических советов — и это не теория из учебников, а то, что работает в реальности.

ПОЧЕМУ Я ИСПОЛЬЗУЮ BPMN?

В мире нотаций у каждого инструмента есть свои сильные стороны — можно рисовать процессы и в UML, и в IDEF, и в обычных блок-схемах.

Но BPMN создан специально для бизнес-процессов, и вот почему он стал моим основным инструментом:

  1. Специализированный язык процессов
    BPMN — как профессиональный фотоаппарат против камеры в смартфоне. Да, снимки можно делать и тем, и другим, но когда нужен точный контроль и детализация — для меня выбор очевиден

  2. Общий язык для бизнеса и IT
    Больше не нужно переводить требования с "бизнесового" на "технический". Схема BPMN становится тем самым мостом, где встречаются два мира.

  3. Визуальность = меньше ошибок+быстрее договариваемся
    Я — визуал, и для меня схема всегда передает суть лучше, чем длительные созвоны. Но главное — это работает и для коллег

  4. Единый стандарт для всех. Тот случай, когда стандартизация действительно работает:
    - Разработчики получают чёткие требования
    - Бизнес видит процесс целиком
    - Аналитики тратят меньше времени на разъяснения

BPM, BPMN и BPMS: разбираемся в терминах

Прежде чем погружаться в детали BPMN, давайте расставим точки над i в трёх похожих, но очень разных понятиях.

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

  2. BPMN — язык, который все понимают. Business Process Model and Notation — это нотация (то есть визуальный язык) для рисования процессов. Зачем? Чтобы: менеджер увидел логику, разработчик понял требования — без 100500 правок.

  3. BPMS — инструмент для процессов. Business Process Management System — это программа, которая превращает BPMN-схему в реальный рабочий процесс: с кнопками, уведомлениями и автоматизацией.

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

ПРОСТОТА vs. СЛОЖНОСТЬ: как не утонуть в деталях

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

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

Сложные схемы с множеством элементов оправданы только в двух случаях:

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

  2. Когда схема идёт напрямую в BPMS для автоматизации

Лучшая схема — не самая правильная, а та, после которой не возникает вопросов "А что здесь происходит?" и "Что делать дальше?". Иногда простой прямоугольник с чёткой подписью полезнее идеального, но перегруженного элемента BPMN.

Совет: Начинайте с простого — детали всегда можно добавить позже.

ЦИФРОВОЙ МОЛЬБЕРТ: выбираем инструмент для bpmn

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

Draw.io — это "швейцарский нож" диаграмм. Бесплатный, универсальный (рисуйте хоть BPMN, хоть блок-схемы, хоть архитектурные схемы), интегрируется с Confluence. Правда, у него есть недостатки — элементы иногда съезжают, а соединения могут "отлипать". Но поскольку у нас уже настроена работа в Confluence через Draw.io и переход на другие инструменты не планируется, он остаётся моим основным решением для визуализации процессов.

Camunda — идеален для тех, кто ценит точность, и он тоже интегрируется с Confluence, но на новых версиях плагина. Camunda как преподаватель: не даст нарушить стандарты BPMN, сразу укажет на ошибки. Но за эту "правильность" приходится платить: интерфейс менее гибкий, а часть полезных функций (вроде симуляции процессов) доступна только в платных версиях. Идеальный выбор для команд, которые всерьёз работают с BPMS и для тех, кто только начал работать с BPMN.

Конечно, мир инструментов для моделирования не ограничивается только Camunda и Draw.io. Если копнуть глубже, можно найти множество интересных вариантов:

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

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

И это лишь несколько примеров из множества существующих решений. Главное — понимать, что идеального инструмента "на все случаи жизни" не существует, зато всегда можно подобрать оптимальный вариант под конкретную задачу.

ПУЛЫ И ДОРОЖКИ: кто за что отвечает?

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

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

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

ПОТОК УПРАВЛЕНИЯ : маршруты нашего "мяча"

Продолжая нашу спортивную аналогию, представьте, что поток управления в BPMN — это траектория мяча, летящего между игроками. Он показывает, куда и в каком порядке должен перемещаться наш "мяч" — то есть процесс. Именно эти стрелочки указывают, кто когда вступает в игру и куда двигаться дальше.

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

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

Эти потоки создают понятную "карту маршрутов" для вашего процесса. Сплошные линии — ваша зона контроля, где вы определяете каждый шаг. Пунктирные — границы взаимодействия, где вы только инициируете действие и ждёте результат.

ТОКЕНЫ: или как процессы оживают

Прежде чем перейдём к тому, что должно жить в нашем пуле, немножко поговорим про токены.

Представьте, что процесс — это игровое поле, а токен — ваша фишка, которая перемещается от клетки к клетке. Каждый ход (шаг процесса) продвигает её дальше, пока она не дойдёт до финиша.

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

Почему это важно?

Без токенов схема — просто картинка. С ними — становится инструкцией для выполнения, где видно:

  • Какие шаги активны прямо сейчас      

  • Где процесс ждёт действий

  • Как шлюзы влияют на общий поток

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

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

СТАРТОВЫЕ СОБЫТИЯ: с чего начинается история

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

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

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

Типы стартовых событий

ПРОМЕЖУТОЧНЫЕ СОБЫТИЯ: паузы и другие повороты сюжета

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

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

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

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

Типы промежуточных событий

ЗАВЕРШАЮЩИЕ СОБЫТИЯ: ставим точку в истории процесса

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

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

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

Типы завершающих событий

ЗАДАЧИ: кирпичики, из которых строится процесс

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

Чаще всего используют эти варианты:

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

Пользовательская задача — когда нужно явно указать человеческое действие      

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

Это помогает:

  • Держать основную диаграмму чистой — вместо десятка мелких задач видна одна понятная группа

  • Быстро вносить изменения в схему — меняете детали внутри, не трогая общую картину

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

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

Типы задач

СОБЫТИЯ НА ЗАДАЧАХ: незримые наблюдатели

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

Первый вариант можно назвать "вежливым напоминанием" — оно обозначается прерывистой линией. В этом случае процесс продолжает идти своим чередом, а событие просто добавляет параллельное действие, не нарушая основного потока. Представьте, что вы спокойно заполняете отчёт — это ваша основная задача. Через два часа система присылает уведомление "Пора сделать перерыв", но вы можете продолжить работу над документом. Основной процесс не прерывается, просто параллельно появляется дополнительное уведомление.

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

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

РАЗВИЛКИ И ШЛЮЗЫ: как процессы выбирают дорогу

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

Совсем другое дело — параллельный шлюз. Это как энергичная мама, которая готова записать ребенка везде и всюду: «И в музыкальную школу, и на английский, и на танцы — всё сразу!» Он запускает все исходящие потоки одновременно, не спрашивая разрешения. Главное потом не забыть собрать все ветки обратно таким же параллельным шлюзом, иначе процесс рассыплется.

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

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

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

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

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

ПРАВИЛА РАБОТЫ СО ШЛЮЗАМИ: как не устроить хаос в процессах

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

Представьте, что вы запускаете три параллельных задачи (через параллельный шлюз "И"), но завершаете процесс исключающим шлюзом "ИЛИ". Что произойдет? Директор получит три одинаковых уведомления вместо одного — система просто не поймет, что эти потоки нужно свести обратно.

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

Отсюда золотое правило:

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

ПРАВИЛА ХОРОШЕГО ТОНА

BPMN — это язык, а не догма. Да, в нём есть строгие каноны, но иногда их стоит адаптировать под реальные задачи.

Но честно? Некоторые из них я позволяю себе игнорировать или интерпретировать по-своему — если это делает схему понятнее и логичнее для команды.

Схема должна работать на понимание, а не становилась поводом для бесконечных споров у кулера.

Но несмотря на это у меня есть ряд правил которые я стараюсь выполнять неукоснительно, чего и вам советую😊

Представьте, что открываете схему и видите стартовое событие где-то в правом нижнем углу, от которого стрелки скачут по диаграмме, как зайцы на кофеине. Так делать не надо — пусть ваш процесс течёт слева направо, как история про "Колобка": сначала бабка тесто замесила, потом Колобок убежал, в конце Лиса его съела. Просто и логично.

Названия задач должны быть как вывески в супермаркете — сразу понятно, что внутри. "Проверить документы" вместо "Верификация входных данных согласно п. 4.2 инструкции №153-ФЗ". Представьте, если бы в магазине вместо "Молочные продукты" висела табличка "Жидкие белковые продукты с ограниченным сроком годности".

Стрелки на шлюзах — это не философские вопросы, а простые и краткие ответы. "Клиент подтвердил заказ?" — "Да" ведёт к оплате, "Нет" — в корзину. Не надо превращать стрелки в научные трактаты: "В случае если клиент выразил согласие посредством нажатия кнопки подтверждения..." — это уже не BPMN, а диссертация.

Легенда — обязательный элемент любой схемы, даже если вы считаете её очевидной. Цвета, формы, обозначения — всё должно быть объяснено, чтобы даже человек, впервые увидевший BPMN, смог разобраться, что к чему.

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

BPMN — видеть, думать и договариваться

Всё, что я рассказала, — не про идеальные схемы «по учебнику». BPMN для меня — это язык, который превращает хаос в порядок. Он учит мыслить структурно, объяснять сложное просто и находить нестыковки ещё до того, как они станут проблемами.

Самая большая магия — когда после вашей схемы коллеги говорят: «Теперь всё понятно!» без лишних созвонов и длительных переписок.

И это дорогого стоит!

P.S. Процесс ловли зайца

Ну и напоследок я хочу поделиться прекрасным заданием, которое когда-то попалось мне на собеседовании. Причем само задание может быть выполнено разными способами. Попробуйте нарисовать этот процесс. Вариантов — десятки! Я выложу своё решение в комментариях — покажите и ваше. Интересно увидеть разные подходы 😊

Как только стрелки часов касаются шести утра, и если земля укрыта снежным покровом, Пётр первым делом проверяет, лежит ли на заднем дворе красный кирпич. Если кирпича нет — он стучится к соседу Андрею и одалживает один.

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

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

Заяц, завидев необычный предмет, думает: «Морковка!» — подбегает, вдыхает аромат, чихает, бьётся головой о кирпич и падает без чувств. Остаётся только подобрать добычу.

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

P.P.S. Точно последнее!

Если у вас есть подобные интересные задания, так же закидывайте в комменты, с удовольствием поразбираю :)