BPMN не для оптимизации процессов: что действительно важно для улучшения процессов

Оптимизация — это про числа, а не про стрелки

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

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

Видеоверсия статьи.

Откуда пришла теория очередей и почему она важна

Понимание массового обслуживания начинается в начале XX века с Эрланга. Он математически описал поведение телефонных очередей и вывел формулы, которые позволяли предсказывать, сколько операторов нужно при заданном трафике вызовов. Дальше идеи развивали в Bell Labs и другими математиками — появились законы и понятия, на которых строятся проектирование банков, аэропортов, складов и современных IT-систем.

Бизнес-процессы как система массового обслуживания

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

• поступают заявки (поток);
они встают в очередь;
• есть исполнитель с ограниченным временем и рабочим графиком (ресурс);
• заявка обслужена и покидает систему.

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

Базовая терминология, которую должен знать аналитик

Чтобы говорить языком оптимизации, нужно знать несколько терминов:

• Интенсивность потока (arrival rate) — сколько заявок приходит в систему за период (например, 100 заявок в день).
• Время обслуживания (service time) — сколько времени занимает обработка одной заявки в среднем.
• Ресурс (server) — кто или что обрабатывает запрос: человек, станок, сервер.
• Заявка (application) — то, что проходит через процесс: контракт, тикет, рекламация.
• Пропускная способность (throughput, capacity) — максимальное число заявок, которое система может обработать за период.

Почему BPMN не показывает главное

Даже идеально нарисованная BPMN-модель не даст ответов на вопросы вида:

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

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

Законы очередей, которые спасут от неверных решений

«Нельзя оптимизировать то, что не измерено»

Практические следствия теории массового обслуживания:

• чем выше загрузка ресурса, тем дольше среднее время ожидания;
• при загрузке выше ~70% система начинает вести себя хуже: задержки растут нелинейно;
• при загрузке около 90% очереди могут расти экспоненциально и выйти из-под контроля.

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

Какие данные нужны для реальной оптимизации

Для того чтобы переход к оптимизации был не верой, а знанием, необходимы четыре группы данных:

1. Поток входящих заявок — интенсивность и распределение по времени: когда пиковые часы, есть ли сезонность.
2. Корректная end-to-end BPMN модель — модель должна описывать путь заявки от начала до конца и содержать вероятности переходов между ветвлениями и распределения длительностей.
3. Информация о ресурсном пуле — сколько людей обрабатывают заявки, их ставки, графики работы, мультизадачность и приоритеты.
4. Целевые SLA и KPI — что в компании считается хорошим и плохим, какие уровни обслуживания вы хотите достигнуть.

Практические рекомендации

• начните с измерений: соберите данные о входящем потоке и времени обработки;
• постройте модель, где BPMN дополняется распределениями и ресурсами, а не заменяет их;
• ищите узкие места через анализ загрузки ресурсов, а не только по визуальным «бутылочным горлышкам» в диаграмме;
• планируйте изменения с прогнозом: симулируйте добавление ресурса или изменение расписания и смотрите на ожидаемую динамику очередей;
• держите целевые загрузки ниже ~70% для стабильной работы.

Итог

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

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