Бизнес-процессы и BPMN: как описать и не утонуть

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

Что это простыми словами

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

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

Теперь о том, как процессы рисуют. Можно, конечно, описать словами или нарисовать стрелочки как попало, но тогда каждый поймёт схему по-своему. Чтобы все читали схему одинаково, придумали общий язык значков — нотацию. Самая распространённая в мире — BPMN, Business Process Model and Notation, что переводится как «нотация моделирования бизнес-процессов». Это международный стандарт: набор условных обозначений, которые означают одно и то же и для аналитика в Москве, и для разработчика в Берлине.

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

Зачем это нужно

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

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

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

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

Как применить у себя

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

Базовых элементов всего четыре, и они интуитивны. События — это кружки, они обозначают начало и конец процесса (тонкий кружок — старт, жирный — финиш). Задачи (или действия) — прямоугольники со скруглёнными углами, внутри глагол: «принять заявку», «выставить счёт». Шлюзы — ромбы, это развилки, где процесс ветвится по условию: «оплата прошла?» — да идём сюда, нет идём туда. И дорожки (swimlanes, дословно «плавательные дорожки») — горизонтальные полосы, каждая закреплена за ролью или отделом, и задача лежит на той дорожке, чей это участок работы. Соединяют всё это стрелки — поток процесса. Этих четырёх элементов хватает, чтобы описать большинство процессов в малом и среднем бизнесе.

Теперь пошаговый порядок. Первое — выберите один процесс, самый болезненный или частый, и не хватайтесь сразу за все. Второе — опишите его «как есть», as-is: пройдите по реальным шагам так, как они происходят сегодня, со всеми костылями, ожиданиями и ручной вознёй. Это важнейший этап: вы фиксируете правду, а не мечту. Третье — определите границы: где процесс начинается (событие-старт) и чем заканчивается (событие-финиш), чтобы не утонуть в бесконечности. Четвёртое — расставьте роли по дорожкам и разложите задачи. Пятое — найдите развилки и обозначьте их шлюзами. Шестое — посмотрите на готовую схему as-is и спросите: что здесь лишнее, что тормозит, что можно упростить. Так рождается версия to-be — «как должно быть».

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

Про инструменты. Начать можно вообще на бумаге или маркерной доске — это нормально для первого черновика. Для аккуратной схемы есть бесплатные онлайн-редакторы: например, draw.io (он же diagrams.net) с готовым набором фигур BPMN. Есть и специализированные среды вроде Camunda Modeler или bpmn.io — они нужны, когда схему планируют не просто рисовать, а исполнять и автоматизировать. Для старта берите самое простое: задача — понять свой процесс, а не освоить программу.

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

Самая частая и дорогая ошибка — рисовать идеал вместо реальности. Человек садится за схему и описывает, как должно бы быть в идеальном мире: всё гладко, никто не ошибается, оплата проходит сразу. А потом удивляется, почему схема не помогает: она не имеет отношения к тому, что происходит на самом деле. Всегда начинайте с as-is, честной картины со всеми костылями. Идеал (to-be) рисуют вторым шагом, оттолкнувшись от правды. Без честного as-is улучшать нечего — вы просто фантазируете.

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

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

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

Частые вопросы

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

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

Что такое as-is и to-be? As-is («как есть») — это описание процесса в его текущем, реальном виде, со всеми недостатками. To-be («как должно быть») — это улучшенная, желаемая версия после оптимизации. Правильный порядок всегда один: сначала честно зафиксировать as-is, затем на его основе спроектировать to-be. Прыгать сразу к to-be — значит улучшать то, чего не понимаешь.

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

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

Коротко о главном

Бизнес-процесс — это повторяющаяся цепочка действий от запроса на входе до результата на выходе, и она есть у любого дела, даже самого маленького. Пока процесс живёт только в головах, бизнес держится на людях и ломается при первом сбое; описанный процесс превращает личный опыт в общий ресурс команды. BPMN — это удобный международный язык схем из четырёх базовых элементов: события-кружки, задачи-прямоугольники, шлюзы-ромбы для развилок и дорожки для разделения ролей. Описывать процесс нужно в два захода: сначала честный as-is, как всё работает на самом деле, потом to-be, как должно быть после улучшений. Описанная схема — это фундамент для оптимизации и автоматизации: видно, какие шаги отдать программе, а какие оставить человеку. Главное — не рисовать идеал вместо реальности, не прятать схему в стол после создания, не переусложнять и начинать с одного процесса, а не со всех сразу. Тогда BPMN станет не модной картинкой, а рабочим инструментом, который реально наводит порядок.