BPMN-схема бизнес-процесса: пример из производства мебели и как описать свой процесс

Зачем рисовать схему

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

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

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

Восемь элементов BPMN, которых хватает

В стандарте больше сотни элементов. Для процессов компании до 30 человек хватает восьми.

1. Событие начала. Тонкий круг. Что запускает процесс: пришёл запрос, наступило первое число, клиент позвонил.
2. Задача. Прямоугольник со скруглёнными углами. Одно действие одного исполнителя: «Согласовать чертежи», «Выставить счёт». Если в названии есть союз «и», это две задачи.
3. Развилка «или». Ромб с крестиком. Из неё выходит несколько стрелок, но процесс идёт только по одной: «Клиент прислал чертёж?» — да или нет.
4. Развилка «и». Ромб с плюсом. Всё, что выходит из неё, делается параллельно: «Заказать материалы» и «Запланировать монтаж».
5. Стрелка. Порядок действий. Одна входит, одна выходит. Если из задачи выходят две стрелки без развилки, вы что-то забыли.
6. Дорожка. Горизонтальная полоса с названием роли или этапа: «Менеджер», «Производство», «Битрикс24». Задача лежит на дорожке того, кто её делает. Дорожка «Битрикс24» показывает, что система делает сама.
7. Подпроцесс. Прямоугольник с плюсом внизу. Свёрнутый кусок процесса, который живёт по своим правилам и рисуется отдельно: «Дизайн-проект», «Производство». Без подпроцессов большая схема не помещается ни на один экран.
8. Событие конца. Жирный круг. Чем процесс заканчивается: документы подписаны, отказ зафиксирован.

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

Пример BPMN-схемы: производство мебели на заказ

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

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

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

• этап заказа
• задача, которую ставит система
• условие, влияющее на маршрут
• причина отказа

Фрагмент 1. Старт заказа и первая развилка

Три вещи, на которые стоит смотреть. Красный блок «Причины отказа» висит сразу после обработки запроса: если клиент ушёл, менеджер обязан выбрать причину, иначе через полгода никто не скажет, почему половина запросов не стала заказами. Синие блоки «Клиент прислал чертёж» и «Дизайн-проект» это не задачи, а условия: они определяют маршрут. И «Дизайн-проект» нарисован подпроцессом с плюсом, потому что внутри у него собственная цепочка: ТЗ, оплата, визуализация, чертежи, со своими причинами отказа.

Фрагмент 2. Тип оплаты

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

Фрагмент 3. Производство: ветвление по материалу

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

Как схема превращается в настройку Битрикс24

Легенда работает как таблица соответствия. Если она есть, интегратору не нужно ничего додумывать.

• Зелёные этапы становятся стадиями сделки или смарт-процесса «Заказ». Переход между ними и есть движение заказа.
• Жёлтые задачи становятся автоматическими задачами и роботами: заказ перешёл на стадию, система поставила задачу с ответственным и сроком.
• Синие условия становятся полями сделки: «Тип оплаты», «Есть чертёж». Роботы читают их и ведут заказ по нужному маршруту.
• Красные причины отказа становятся обязательным полем на стадии «Отказ» и отчётом по причинам.
• Подпроцессы становятся отдельными смарт-процессами или группами задач со своими стадиями, связанными с основным заказом.

Так и произошло у мебельной компании: процесс, который жил в чатах и таблицах, переехал в Битрикс24 по этой схеме. Настройка при этом заняла меньше времени, чем сама схема, потому что спорные вопросы решили на этапе рисования.

Как описать бизнес-процесс за час: чек-лист

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

1. Выберите один процесс. Не «работа компании», а «заказ от запроса до отгрузки». Один процесс, одна схема.
2. Назовите начало и конец. Что запускает процесс и чем он заканчивается. Если концов несколько, например «оплачено» и «отказ», нарисуйте оба.
3. Соберите шаги у исполнителей, а не у руководителя. Спросите менеджера, что он делает с запросом на самом деле. Записывайте глаголами: «принял», «уточнил», «отправил».
4. Разложите шаги по дорожкам. Кто делает каждый шаг. Шаг, который не ложится ни на одну дорожку, это найденная проблема.
5. Найдите развилки. Везде, где вы сказали «зависит от», поставьте ромб и напишите условие: «Есть чертёж?», «Предоплата?».
6. Отметьте, что может делать система. Напоминания, задачи, письма, расчёт сроков. Это будущие жёлтые блоки, они же список автоматизации.
7. Проверьте схему по четырём вопросам. У каждой задачи есть исполнитель и срок? Из каждой развилки выходят все варианты? У каждого шага есть, куда идти дальше? Понятно, что делать при отказе?

Что обычно всплывает на схеме

• Нет срока у задачи. «Согласовать чертежи» без «в течение двух дней» означает «когда-нибудь».
• Задача висит между дорожками. Никто не понимает, кто отвечает за закупку материалов.
• Из развилки выходит одна стрелка. Что происходит при «нет», никто не думал.
• Условие есть в голове, а на схеме нет. Тип оплаты влияет на запуск производства, но нигде не записан.
• Нет дорожки «Битрикс24». Значит, всё делается руками, и автоматизировать пока нечего.

В чём рисовать

Для первой схемы хватит листа бумаги или доски. Из бесплатных инструментов: Storm BPMN, в нём нарисована схема из примера, diagrams.net и bpmn.io. Все работают в браузере и знают нотацию. Не тратьте время на выбор инструмента, тратьте на разговор с исполнителями.

Как я использую схемы в проектах

Аудит начинается с двух схем: «как есть» и «как будет». Первую рисуем вместе с командой за одну-две встречи, вторую я предлагаю после разбора. Разница между ними и есть план настройки Битрикс24. Каждая жёлтая задача превращается в робота, поле или интеграцию, а каждая задача на дорожке исполнителя получает срок и напоминание.