Описание бизнес-процессов: зачем, как и в какой нотации

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

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

Компании, которые описали свои процессы, получают конкретные преимущества:

1. Прозрачность

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

2. Выявление проблем

Визуализация процесса моментально показывает:

Дублирование операций (два отдела делают одно и то же)
Лишние согласования (5 подписей ради заказа канцелярии)
Потери времени (заявка ждёт 3 дня в очереди, хотя обрабатывается 15 минут)
Отсутствие контроля (никто не отслеживает, что заявка «зависла»)

3. Основа для автоматизации

Ни один интегратор не внедрит CRM, ERP или BPM-систему без описания процессов. Описание as-is (как сейчас) и to-be (как должно быть) — обязательный вход в разработку технического задания.

4. Онбординг сотрудников

Новый сотрудник изучает процессную карту за 2 часа вместо 2 недель наставничества. Это экономит ресурсы и снижает зависимость от ключевых людей.

5. Сертификация и аудит

ISO 9001, ISO 27001 и другие стандарты требуют документированного описания бизнес-процессов. Без моделей — нет сертификации.

Уровни описания процессов

Описание бизнес-процессов — это не одна диаграмма. Это иерархия:

Уровень	Что описывает	Кому нужно	Пример
L0 — Ландшафт	Все процессы компании на одной карте	Топ-менеджмент	«Продажи → Производство → Логистика → Поддержка»
L1 — Процессная область	Группа связанных процессов	Руководители направлений	«Продажи: Лидогенерация, Квалификация, Сделка, Постпродажа»
L2 — Процесс	Конкретный процесс от начала до конца	Владелец процесса, аналитик	«Обработка входящей заявки» в BPMN
L3 — Подпроцесс	Детализация отдельного шага	Аналитик, разработчик	«Проверка кредитоспособности клиента»
L4 — Операция	Инструкция по выполнению шага	Исполнитель	«Открыть карточку клиента → Проверить поле "Лимит" → ...»

Начинайте с L1–L2. Углубляйтесь до L3–L4 только для процессов, которые будете автоматизировать.

Нотации описания бизнес-процессов

BPMN 2.0 (Business Process Model and Notation)

Стандарт ISO 19510. Наиболее распространённая нотация описания бизнес-процессов в IT и бизнес-анализе.

Плюсы:

Понятна и бизнесу, и разработчикам
Исполняемая — современные BPM-системы (Camunda, Zeebe) запускают BPMN-диаграммы как код
Богатая семантика: события, шлюзы, подпроцессы, таймеры, сигналы
Международный стандарт — легко передавать между командами

Минусы:

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

Когда использовать: автоматизация процессов, разработка ТЗ, интеграционные проекты, описание сквозных процессов.

Подробнее — в статье «BPMN 2.0 для бизнеса: зачем моделировать процессы».

EPC (Event-driven Process Chain)

Нотация из методологии ARIS, популярная в SAP-проектах.

Элементы:

Событие (розовый шестиугольник) — состояние, которое запускает функцию
Функция (зелёный прямоугольник) — действие
Логическое правило (AND, OR, XOR) — ветвление

Плюсы:

Чётко привязывает функции к событиям (событие → функция → событие)
Хорошо интегрируется с SAP
Обширная методологическая база (ARIS)

Минусы:

Диаграммы получаются длинными
Нет понятия «дорожки» для ролей
Не исполняемая
Менее популярна за пределами SAP-экосистемы

Когда использовать: SAP-проекты, крупные предприятия с ARIS-инфраструктурой.

IDEF0 (Integration DEFinition)

Функциональное моделирование, фокус на входы-выходы-ресурсы-управление.

Элементы:

Блок (прямоугольник) — функция
Стрелка слева — вход (что обрабатывается)
Стрелка справа — выход (результат)
Стрелка сверху — управление (регламенты, правила)
Стрелка снизу — механизм (кто/что выполняет)

Плюсы:

Чётко показывает, что нужно для выполнения функции
Хорошо подходит для описания производственных процессов
Декомпозиция по уровням (A0 → A1, A2, A3)

Минусы:

Не показывает последовательность шагов
Сложно читается без обучения
Устаревает — в IT-проектах используется редко

Когда использовать: производственные предприятия, описание функций на верхнем уровне, госпроекты по ГОСТ.

Блок-схемы (Flowcharts)

Простейшая нотация, знакомая всем со школы.

Элементы:

Овал — начало/конец
Прямоугольник — действие
Ромб — решение
Стрелка — переход

Плюсы:

Максимально простая, понятна всем
Не требует специальных инструментов
Быстро рисуется

Минусы:

Нет стандарта — каждый рисует по-своему
Не масштабируется для сложных процессов
Нет ролей/дорожек (если не изобретать своё)
Не исполняемая

Когда использовать: быстрые наброски, объяснение простой логики, презентации для людей без подготовки.

Сравнительная таблица нотаций

Критерий	BPMN 2.0	EPC	IDEF0	Блок-схемы
Стандартизация	ISO 19510	ARIS	NIST	Нет
Порог входа	Средний	Средний	Высокий	Низкий
Роли/дорожки	✅	❌	Частично	❌
Исполняемость	✅	❌	❌	❌
Масштабируемость	Высокая	Средняя	Высокая	Низкая
Популярность в IT	⭐⭐⭐	⭐⭐	⭐	⭐⭐
Инструменты	Camunda, Draw.io, Miro	ARIS	BPwin, Ramus	Любые

Рекомендация: для большинства проектов используйте BPMN 2.0. Это золотой стандарт, который понимают все стороны — от бизнеса до разработчиков.

Пошаговый алгоритм описания процесса

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

Ответьте на три вопроса:

Что запускает процесс? (триггер/событие) — «Получена заявка от клиента»
Что является результатом? — «Договор подписан» или «Заявка отклонена»
Кто участвует? — перечень ролей и подразделений

Шаг 2. Соберите информацию

Используйте три источника:

Интервью с участниками процесса (не руководителями, а исполнителями)
Наблюдение — посмотрите, как процесс реально выполняется
Документация — регламенты, инструкции, формы

Важно: регламент и реальность часто расходятся. Описывайте то, как процесс работает на самом деле (as-is), а не то, как он должен работать по документам.

Шаг 3. Постройте черновик

Начните с линейной последовательности шагов:

Клиент оставляет заявку
Менеджер видит заявку
Менеджер звонит клиенту
Менеджер формирует коммерческое предложение
...

Шаг 4. Добавьте ветвления

Найдите точки решений:

Если сумма > 500 000 ₽ → согласование руководителем
Если клиент отказывается → процесс завершается
Если документы не полные → возврат на доработку

Шаг 5. Распределите по ролям

Добавьте дорожки (swimlanes): кто выполняет каждый шаг. Это сразу покажет:

Передачи между подразделениями (каждая передача — потенциальная задержка)
Перегруженные роли
Шаги без ответственного

Шаг 6. Валидируйте с участниками

Покажите диаграмму тем, кто работает в этом процессе. Задайте вопросы:

«Я правильно понял последовательность?»
«Бывают ли исключения?»
«Что происходит, если что-то идёт не так?»

Обычно первая валидация выявляет 30–50% пропущенных шагов и ветвлений.

Шаг 7. Оформите финальную версию

Пронумеруйте версию (v1.0, v1.1, ...)
Укажите автора и дату
Добавьте легенду, если используете нестандартные обозначения
Зафиксируйте метрики процесса (если есть): среднее время, SLA, объём

Типичные ошибки при описании процессов

Ошибка 1: описывать «как должно быть», а не «как есть»

Руководитель рассказывает идеальный процесс. Исполнитель работает иначе. As-is должен отражать реальность — иначе to-be будет построен на ложных предпосылках.

Ошибка 2: слишком детально сразу

Процесс L2 из 30 шагов — это нормально. Процесс из 150 шагов — нечитаемый. Используйте подпроцессы для декомпозиции.

Ошибка 3: забыть про исключения

Основной поток — это 60% реальности. Остальные 40% — исключения, ошибки, возвраты, таймауты. Именно они создают проблемы при автоматизации.

Ошибка 4: рисовать в PowerPoint

PowerPoint не контролирует корректность нотации. Используйте специализированные инструменты:

Camunda Modeler — бесплатный, для BPMN
Draw.io (diagrams.net) — бесплатный, универсальный
Miro — для коллаборативной работы
Bizagi Modeler — бесплатный, для BPMN

Ошибка 5: описать и забыть

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

Что делать после описания

Описание бизнес-процессов — не самоцель. Дальше следует:

Анализ — найти узкие места, потери, дублирование (подробнее)
Оптимизация — спроектировать to-be, убрать лишнее, ускорить
Автоматизация — подготовить техническое задание на внедрение BPM/CRM/ERP
Мониторинг — отслеживать KPI процесса и непрерывно улучшать

Итог

Описание бизнес-процессов — фундамент любых изменений в компании. Без него автоматизация превращается в «автоматизацию хаоса». Используйте BPMN 2.0 как основную нотацию, начинайте с уровня L2, собирайте информацию от исполнителей, а не только от руководителей. И помните: модель — живой документ, который нужно поддерживать.

Нужна помощь с описанием процессов? Обсудим ваш проект — работаю с компаниями любого масштаба.