Схема бизнес процесса BPMN: как описать схему бизнес-процесса за 7 шагов

У собственника всегда два варианта. Либо все процессы у него в голове — и он точка отказа. Либо процессы описаны и работают без него. Третьего нет. BPMN — это просто язык, на котором фиксируется второй вариант. Шесть значков, лист в draw.io, час времени с командой — этого достаточно, чтобы начать.

В статье разберём, зачем собственнику вообще описывать процессы, что такое схема бизнес процесса BPMN на практике, какие 6 элементов закрывают 90% задач и что делать после того, как схема нарисована. Без академизма, нотаций ISO и продажи BPM-движков.

Внимание: По данным Harvard Business Review, компании с зафиксированными процессами на 30% эффективнее. Forrester (2023) добавляет: 60–80% внедрений BPMS проваливаются — не из-за кривой схемы, а потому что не меняются роли и ответственность.

Зачем описывать бизнес-процессы

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

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

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

Пример: Сеть магазинов сотовой связи в работе с Business Commandos выросла с 12 до 18 точек. Собственник сократил рабочий день с 10–12 часов до 8 часов в неделю. Текучка персонала упала с 40% до 15% за год. Драйвер всех изменений — описание ключевых процессов и их перенос в CRM и регламенты.

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

Что такое BPMN простыми словами

BPMN расшифровывается как Business Process Model and Notation. Перевод — «нотация моделирования бизнес-процессов». Это техническая деталь, которую можно забыть сразу после прочтения. Важно другое: BPMN — это язык схем, на котором рисуют, как у вас в компании всё устроено.

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

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

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

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

Минимальный набор элементов: 6 значков на 90% задач

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

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

1. Дорожка (lane). Горизонтальная полоса с именем роли. Сверху — менеджер, ниже — производство, ниже — бухгалтерия. Каждая дорожка показывает, кто чем занят в этом процессе.
2. Задача (task). Квадратик с действием. Внутри — глагол: «согласовать заявку», «выставить счёт», «упаковать заказ». Одна задача — одно действие.
3. Событие начала. Кружок-старт. Сигнал, что процесс пошёл: пришла заявка, клиент оформил заказ, наступила дата.
4. Событие конца. Кружок-финиш. Что получилось на выходе: договор подписан, заказ отгружен, отчёт сдан.
5. Шлюз И/ИЛИ. Ромб с развилкой. «ИЛИ» — это выбор: или принимаем заказ, или отклоняем. «И» — параллельные действия: и проверяем оплату, и согласовываем доставку.
6. Сообщение. Конверт между дорожками. Менеджер передал заказ производству, производство сообщило бухгалтерии о готовности к отгрузке.

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

Совет: Если в процессе участвует CRM, ERP или Битрикс — выделяйте программу как отдельного «участника» процесса. Так сразу видно, что делает человек, а что — система. Это сильно помогает при последующей настройке автоматизации.

Где брать остальные 144 элемента? Для малого и среднего бизнеса — нигде. Если в каком-то конкретном процессе вам понадобится экзотический шлюз или специальное событие — изучите его по ходу. Учить всю нотацию заранее — пустая трата времени.

Мнение эксперта

Павел Котов

Эксперт по систематизации бизнеса

Задать вопрос

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

Пошаговый алгоритм: как описать схему бизнес-процесса в BPMN

Хороший способ испортить себе жизнь — сесть в одиночку с ноутбуком и начать рисовать процесс «как должно быть». Хороший способ получить рабочую схему — действовать по чек-листу ниже. Семь шагов от выбора процесса до фиксации результата. Подробный разбор сходного алгоритма мы давали в материале «Как описать бизнес-процесс: 7 шагов и пример продаж» — там акцент на текстовое описание, здесь — на нотацию BPMN.

Шаг 1. Выберите процесс. Не пытайтесь описать всю компанию сразу. Начните либо с основного бизнес-процесса (тот самый процесс конвертации клиента в деньги), либо с самого болезненного — где чаще всего возникают сбои, потери и претензии.

Шаг 2. Соберите исполнителей. Тех, кто реально выполняет этот процесс каждый день. Менеджер по продажам знает про процесс продажи в десять раз больше любого внешнего аналитика и в пять раз больше собственника. Без этих людей схема превратится в фантазию о том, как «должно бы быть».

Шаг 3. Определите роли (дорожки). Кто участвует в процессе? Если в компании уже есть организационная структура — берём роли оттуда. Если нет — фиксируем по факту: кто чем занят. Каждой роли — отдельная горизонтальная дорожка.

Шаг 4. Зафиксируйте вход и выход. Что запускает процесс — звонок, заявка с сайта, дата в календаре? Что должно получиться на выходе — оплаченный заказ, подписанный акт, обученный сотрудник? Без чёткого «начала» и «конца» схема расползётся.

Шаг 5. Распишите шаги по дорожкам. Каждый шаг — это квадратик-задача на дорожке нужной роли. Менеджер принял заявку — квадратик на дорожке менеджера. Передал производству — стрелка-сообщение на дорожку производства. Производство собрало заказ — квадратик там. И так до выхода.

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

Шаг 7. Проверьте со всеми участниками. Прогоните схему по реальным ситуациям прошлой недели. Найдите разрывы и утечки: где задача «зависает», где никто не понимает, кто отвечает, где сотрудники по факту делают не то, что на схеме. Эти разрывы — самое ценное, что даст описание.

Совет: Уровни детализации — рабочий приём. Иногда сначала рисуем процесс широкими мазками: 5–6 крупных подпроцессов на одной схеме. Потом детализируем каждый. Иногда наоборот — рисуем большую схему, а потом упрощаем. Главный критерий — чтобы со схемой было удобно работать. Если глаза разбегаются — упрощайте, объединяйте, делите на подпроцессы.

Мнение эксперта

Павел Котов

Эксперт по систематизации бизнеса

Задать вопрос

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

BPMN и оргсхема: как дорожки превращаются в функционал

BPMN-схема не висит в вакууме. У неё есть прямой и обязательный мост к оргсхеме компании и должностным инструкциям. Этот мост — дорожки.

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

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

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

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

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

В чём рисовать: draw.io, Miro и без излишеств

Один из самых частых вопросов: «Какую программу взять для BPMN?». В магазине BPM-инструментов глаза разбегаются — Bizagi, Camunda, ELMA, Visio, IBM, Comindware. Для описания процессов в малом и среднем бизнесе всё это избыточно.

Мы пользуемся ровно двумя инструментами: draw.io и Miro. Всё остальное — на полку.

draw.io — бесплатный онлайн-редактор схем. Есть готовая палитра BPMN: дорожки, задачи, шлюзы, события. Удобно для документирования: схема живёт в файле, файл лежит в облаке или в Git. Подходит, когда схема уже устаканилась и нужно просто её зафиксировать. На простую схему процесса в draw.io уходит около часа.

Miro — онлайн-доска для совместной работы. Идеально, когда схему делаем командой: собрались с менеджером, производством, бухгалтерией в одном онлайн-окне и рисуем вместе. Все видят правки в реальном времени, можно оставлять комментарии. Когда процесс описан и проверен — переносим финальную схему в draw.io для архива.

К сведению: Bizagi, Camunda, ELMA и подобные — это не редакторы схем, а полноценные BPM-движки. Они нужны, когда процесс не просто описывается, а исполняется системой: задачи автоматически летают между сотрудниками, роботы выполняют шаги, метрики собираются автоматически. Для малого и среднего бизнеса в большинстве случаев это пушка по воробьям — стоимость, обучение и поддержка не окупаются.

Совет — начните с draw.io. Откройте, выберите шаблон BPMN, нарисуйте первую схему за час. Если потом процесс окажется живым и понадобится совместная работа — переносите в Miro. Не наоборот.

Когда BPMN не нужен

BPMN — мощный инструмент. Но не универсальный. Половина задач, ради которых собственники открывают draw.io, на самом деле решаются проще. Честный фильтр сэкономит вам неделю работы.

Три признака, что BPMN избыточен:

1. Процесс выполняется одним человеком от начала до конца. Бухгалтер один сдаёт отчёт, кладовщик один проводит инвентаризацию, дизайнер один рисует баннер. Нет передач между ролями — нет смысла в дорожках. Достаточно простого регламента-инструкции «делай 1, 2, 3».
2. Действия повторяющиеся и простые. Открыть смену, закрыть кассу, провести утреннюю планёрку. Здесь не нужна нотация — достаточно чек-листа в Google-документе или в задачнике.
3. Нет передачи между ролями и нет развилок. Если на схеме всё помещается в одну дорожку и нет ромбов «или/или», это не BPMN, это просто нумерованный список шагов. И список будет понятнее любой схемы.

Частая ошибка: Описывать в BPMN всё подряд — от продажи до полива цветов в офисе. Получается сто схем, которые никто не читает. Лучше десять схем ключевых процессов, чем сто на все случаи жизни.

Когда BPMN точно нужен:

• В процессе участвуют 3+ роли и есть передачи между ними.
• Есть условные ветвления: сделка либо закрывается, либо отказывается; заказ либо в наличии, либо производится.
• Готовитесь к автоматизации в CRM или ERP — программистам нужна схема, а не словесный пересказ.
• Ищете «утечки» в основном бизнес-процессе — где теряются клиенты, деньги, время.

Если ничего из этого нет — закройте draw.io и напишите регламент в Word. Сэкономите себе и команде неделю.

Что делать после схемы: регламент, владелец, внедрение

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

После схемы должен идти цикл из пяти шагов:

1. Обсудить с командой. Те, кто будет работать по этой схеме, должны её увидеть и понять. Не «вот вам схема, делайте по ней», а живая встреча — где обсуждаются разрывы, исключения, реальные кейсы. Если люди не приняли схему как свою, она не заработает.
2. Назначить владельца процесса. Один конкретный человек, который отвечает за результат на выходе. Без владельца BPMN превращается в коллективную безответственность: все за всё и никто ни за что.
3. Зафиксировать регламентом. Текстовое описание правил: что делает каждая роль, какие сроки, что в каком случае. Схема показывает «как», регламент объясняет «почему» и «при каких условиях». Они не дублируют, а дополняют друг друга.
4. Связать с CRM или ERP, если нужно. Программисты пишут автоматизацию по схеме. Если процесс положен на BPMN — настройка системы идёт быстрее и без потерь смысла. Если нет — настраиваем вслепую, по словесным пересказам собственника.
5. Контролировать показатели. Сколько времени занимает процесс? Где задерживается? Какой процент сделок отваливается на конкретном шаге? Если эти цифры никто не смотрит, процесс деградирует обратно к стихийному состоянию за полгода.

Внимание: Forrester (2023) приводит цифру: 60–80% внедрений BPMS-систем проваливаются. Причина — не кривые схемы и не плохой софт. Причина в том, что не меняются роли и ответственность. Схема нарисована, программа куплена, а люди продолжают работать по-старому.

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

Мнение эксперта

Павел Котов

Эксперт по систематизации бизнеса

Задать вопрос

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

5 типичных ошибок при описании процессов

Эти ошибки повторяются у 90% собственников, которые впервые садятся описывать процессы. Сверьтесь со списком — и не повторяйте.

Ошибка 1. Рисовать в одиночку. Собственник закрывается на пару часов с draw.io и выдаёт «схему процесса продаж». Через неделю выясняется, что менеджеры по факту работают совсем не так. Шансы с первого раза без участия исполнителей попасть в реальный процесс — практически нулевые. Описывать — только с теми, кто реально выполняет.

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

Ошибка 3. Уходить в детализацию. «Менеджер открыл CRM, перешёл во вкладку „Сделки», нажал кнопку…» Так описывают не процесс, а инструкцию для нового сотрудника. Перегруженная схема не работает: глаза разбегаются, важное теряется. Если схема стала слишком большой — упрощайте, объединяйте мелкие шаги, выносите детали в подпроцессы.

Ошибка 4. Не назначить владельца процесса. Схема нарисована — все довольны, но за результат не отвечает никто. Через месяц процесс деградирует, ещё через два — возвращается к исходному бардаку. Без владельца BPMN — это просто рисунок. С владельцем — рабочий инструмент.

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

Частая ошибка: Описать процесс «навсегда» и закрыть тему. Процессы живые — они меняются вместе с бизнесом. BPMN — это не памятник, а карта, которую регулярно перерисовывают.

BPMN как инструмент: делать самому или с консультантом

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

Путь 1. Делать самому. Подходит, если у вас есть время на ошибки и переделки и вы готовы описывать процессы постепенно — один в месяц. Шансы с первого раза без набитой руки написать процесс грамотно — практически нулевые. Это не теория, а компетенция: нарабатывается на десятках схем. Я сам наломал дров, когда впервые описывал процессы по BPMN — много пришлось переделывать.

Путь 2. С внутренним аналитиком. Если в команде есть человек с опытом описания процессов — отлично. Полное описание ключевых процессов компании займёт 2–3 месяца. Главное — чтобы аналитик работал не в кабинете, а с исполнителями.

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

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

Часто задаваемые вопросы

Выводы

BPMN — не академическая дисциплина и не сертификат для аналитика. Это рабочий инструмент собственника. Шесть базовых элементов закрывают 90% задач описания. Полная нотация на 150 значков нужна энтерпрайзу с глубокой автоматизацией, а не малому и среднему бизнесу.

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

Схема без внедрения — ноль. После описания всегда идёт цикл: команда, владелец, регламент, автоматизация, контроль. Без этого BPMN превращается в файл в облаке, к которому никто не возвращается.

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