Нотации бизнес-процессов: BPMN, EPC и что выбрать

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

Зачем вообще нужна нотация

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

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

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

Нотации бизнес-процессов: три, которых хватает

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

Как выглядит рабочее описание

1. Границы. Где процесс начинается и чем заканчивается. «От входящей заявки до подписанного акта» — это граница, «работа отдела продаж» — нет.
2. Участники. Дорожки: клиент, продажи, производство, бухгалтерия. Сразу видно число передач между ними.
3. Действия и решения. Глагол плюс объект: «проверяет наличие на складе». Решения — вопросом с двумя выходами.
4. Время и данные. Сколько занимает шаг и где фиксируется результат. Без этого схема красивая, но бесполезная для поиска потерь.
5. Исключения. Что происходит, если клиент не ответил, если товара нет, если оплата не пришла. Обычно именно в исключениях живёт половина реальной работы.

Из чего состоит схема: минимальный набор элементов

Чтобы команда читала схемы одинаково, достаточно договориться о пяти обозначениях. Всё остальное добавляется по мере надобности.

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

Как собирать данные для схемы

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

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

Главная ошибка: рисовать как должно быть

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

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

Когда нотации бизнес-процессов не нужны

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

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

Что обычно находится при описании

Описание редко заканчивается словами «всё и так было хорошо». Четыре находки встречаются почти в каждой компании.

Двойной ввод данных. Одни и те же сведения о заказе вносятся в две-три системы разными людьми. Каждый ввод — это время и источник расхождений.

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

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

Никому не принадлежащий участок. Между двумя отделами есть зона, за которую формально не отвечает никто, и именно там теряются заявки.

Что делать после схемы

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

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

Как не утонуть в схемах

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

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

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