Описание бизнес-процессов: как это делается на деле

Интегратор, который внедрял Битрикс24 на заводе железобетонных изделий, начал не с настройки системы. Сначала ему нужно было понять, как завод работает сейчас: кто считает стоимость нестандартного изделия, когда заказ уходит в производство, что происходит, если формы под изделие нет. Отвечать на эти вопросы по ходу внедрения было бы дорого, и описание процессов «как есть» он заказал отдельно. Я описал шесть процессов завода за 15 часов вместе со встречами.

Описание — это схема «как есть» и перечень проблем

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

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

Зачем описывать процессы

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

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

Какие процессы описывать первыми

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

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

Как описать бизнес-процесс: по шагам

1. Определите границы

С какого события процесс начинается и каким результатом кончается. «Продажа от заявки до передачи заказа в производство» — граница; «работа с клиентами» — нет. Без границ описание расползается: начинают с продажи, а через час обсуждают бухгалтерию.

2. Поговорите с теми, кто делает работу

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

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

3. Нарисуйте черновик

Шаги по порядку, у каждого — роль, которая его делает. Черновик рисуют сразу после интервью, пока детали свежи, и не стремятся к красоте: на следующей встрече его всё равно будут править.

4. Найдите развилки и исключения

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

5. Покажите схему участникам

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

6. Составьте перечень проблем

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

Сколько подробности нужно

Подробность выбирают под задачу, и у разных процессов одной компании она может быть разной. На заводе ЖБИ четыре процесса расписаны подробно, по ролям и с развилками: продажа от заявки до передачи заказа в производство, подготовка договора и спецификации, производство железобетонных изделий и производство товарного бетона. Аренду спецтехники я нарисовал укрупнённо: интегратору подробнее было не нужно. Шестая схема общая — по ней видно, как заявка проходит между отделами.

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

Пример: продажа нестандартного изделия

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

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

Чем рисовать: BPMN, VAD, EPC или список

Нотацию выбирают под задачу. VAD — для общей схемы: цепочка процессов на одном листе, без подробностей. BPMN — для подробной схемы по ролям и с развилками; её хорошо читают интеграторы, поэтому завод ЖБИ описан в BPMN. EPC — тоже подробная схема, но через события и функции; её стоит выбрать, если в компании уже есть схемы в EPC.

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

Сколько это занимает

Шесть процессов завода ЖБИ — от первой встречи до сдачи схем — заняли 15 часов вместе со встречами. Работа шла с февраля по апрель 2025 года. Часов немного, а календарных месяцев — три. Так бывает почти всегда: срок зависит от того, как быстро руководители находят время на интервью.

Частые ошибки

«Как должно быть» вместо «как есть». Проблемы, ради которых всё затевалось, на схему не попадают.

Описание по оргструктуре. Получается схема компании, которой нет: кто кому подчиняется, видно, а как идёт заявка — нет.

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

Схему не показали участникам. Она остаётся версией аналитика, и те, кто делает работу, её не узнают.

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