Как найти узкие места в бизнес-процессе до автоматизации

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

Как найти узкое место: короткий алгоритм

Выберите один повторяемый результат — например, обработанную заявку, согласованный договор или заведённый в 1С документ. Установите начало и конец процесса. Затем восстановите маршрут AS-IS и для каждого этапа запишите пять вещей:

1. Сколько времени выполняется работа. Это touch time — время, когда с объектом действительно что-то делают.
2. Сколько объект ждёт. Это очередь между этапами, ожидание ответа, согласования или свободного сотрудника.
3. Сколько раз объект возвращается назад. Возврат обычно означает неполный вход, неясное правило или ошибку передачи.
4. Где теряются статус и контекст. Например, данные остаются в переписке, а CRM или учётная система их не получает.
5. Кто отвечает за решение. Если ответственного нельзя назвать однозначно, процесс будет зависеть от личных договорённостей.

Узким местом становится не этап с максимальной длительностью сам по себе, а ограничение, которое создаёт очередь и влияет на конечный throughput — количество завершённых операций за период. IBM описывает анализ процесса как последовательность от определения границ и сбора данных до карты, анализа шагов, выявления bottleneck и проверки первопричин. Это важный порядок: автоматизация до анализа может ускорить лишний шаг и закрепить плохую схему.

Зафиксируйте границы одной операции

Фраза «процесс продаж» слишком широка для диагностики. Внутри неё находятся привлечение, квалификация, подготовка предложения, согласование условий, договор, оплата и передача в производство. У каждого подпроцесса свои входы, владельцы и причины задержек.

Рабочая единица анализа должна иметь:

• объект: заявка, договор, счёт, обращение или заказ;
• событие старта: письмо получено, форма отправлена, документ загружен;
• проверяемый результат: заявка квалифицирована, договор согласован, данные записаны в 1С;
• владельца результата: роль, которая отвечает не за отдельный шаг, а за end-to-end исход;
• единицу измерения: один кейс процесса и его timestamps.

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

Постройте карту AS-IS: вход → обработка → ожидание → решение → передача → результат

Карта AS-IS показывает не регламент, а то, что происходит на практике. IBM разделяет process mapping и process mining: первая методика опирается на интервью и опыт участников, вторая восстанавливает процесс из event logs информационных систем. Для надёжной диагностики полезно соединить обе перспективы: сотрудники объясняют причины, а журналы подтверждают маршрут и длительность.

Для каждого шага добавьте в таблицу:

Разделите время обработки и время ожидания

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

Для каждого этапа нужны отдельные показатели:

• touch time — активная работа;
• wait time — ожидание начала или продолжения;
• queue length — сколько объектов накоплено перед этапом;
• throughput — сколько объектов этап завершает за период;
• return rate — доля возвратов на предыдущие шаги;
• variation — насколько длительность отличается между похожими кейсами.

UiPath в документации Process Mining выделяет bottleneck по throughput time и отдельно показывает ручную обработку. Это полезное разделение: автоматизация ручного действия не уберёт очередь, если причина находится в приоритизации, отсутствии входных данных или лимите согласований.

Найдите дублирование и повторную работу

Дублирование редко выглядит как точная копия одного действия. Чаще один и тот же смысл повторно вводят в разных форматах: менеджер переносит данные из Telegram в CRM, бухгалтер перепечатывает реквизиты из PDF, руководитель собирает статус из переписки, хотя он уже есть в системе.

Отмечайте три вида повтора:

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

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

Проверьте, где теряются статус и данные

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

Для каждой передачи задайте вопросы:

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

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

Составьте карту ответственности

Если на вопрос «кто отвечает за результат?» команда перечисляет несколько отделов, значит процесс управляется по функциям, но не end-to-end. Передачи становятся серой зоной: отправитель считает работу завершённой, получатель ещё не принял объект.

Минимальная карта ответственности содержит:

• владельца процесса — отвечает за outcome и метрики;
• исполнителя шага — выполняет конкретное действие;
• владельца решения — определяет правила и исключения;
• контролёра — проверяет качество и риск;
• получателя результата — подтверждает, что outcome пригоден.

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

Какие данные нужны для объективного анализа

Интервью дают контекст, но timestamps показывают фактическую картину. Начните с доступных следов:

• история статусов CRM, ERP, Service Desk или 1С;
• даты создания, назначения, изменения и закрытия;
• ответственный на каждом переходе;
• причина возврата или отмены;
• источник обращения и канал передачи;
• идентификатор объекта, позволяющий соединить события.

Process mining применяет event logs для восстановления реальных вариантов процесса. Если журналов нет или они неполны, используйте выборочное наблюдение: возьмите несколько десятков недавних кейсов, вручную восстановите путь и сопоставьте его с регламентом. Не смешивайте разные типы операций в одну среднюю длительность.

Не лечите симптом вместо ограничения

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

Используйте связку «наблюдение → причина → проверка → изменение → повторный замер»:

1. Наблюдение: перед этапом накапливается очередь.
2. Гипотеза: этап имеет недостаточную пропускную способность.
3. Проверка: сравнить touch time, wait time, нагрузку и возвраты.
4. Изменение: убрать неполный вход, изменить правило приоритета или автоматизировать конкретное действие.
5. Повторный замер: убедиться, что throughput процесса вырос, а проблема не переместилась дальше.

Как приоритизировать найденные ограничения

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

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

Пошаговый план диагностики до автоматизации

1. Выберите один outcome. Не «улучшить продажи», а «принять и квалифицировать входящую заявку».
2. Определите границы и владельца. Зафиксируйте событие старта, результат и роль, отвечающую за end-to-end процесс.
3. Соберите карту AS-IS. Интервьюируйте участников и восстановите реальные варианты, включая исключения.
4. Добавьте измерения. Touch time, wait time, очередь, возвраты, throughput и потерянные статусы.
5. Сверьте карту с данными. Используйте логи систем или выборку реальных кейсов.
6. Найдите первопричину. Не путайте перегрузку с неполным входом, плохим правилом или потерей контекста.
7. Выберите минимальное изменение. Удалить шаг, изменить правило, интегрировать системы, автоматизировать действие или добавить AI.
8. Определите контроль и fallback. Что система делает при низкой уверенности, ошибке данных или недоступности интеграции.
9. Запустите ограниченный пилот. На одном типе операций, с baseline и критериями приёмки.
10. Повторно измерьте весь поток. Убедитесь, что ограничение устранено, а не переместилось.

Связанный материал «Какие процессы автоматизировать первыми» поможет сравнить несколько процессов после диагностики. А статья о process-first подходе объясняет, почему архитектуру решения выбирают после фиксации процесса, baseline и исключений.

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

Сколько кейсов нужно изучить?

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

Нужно ли сразу покупать process mining?

Нет. Если процесс небольшой и не имеет качественных event logs, начните с интервью, наблюдения и выгрузки истории статусов. Process mining становится особенно полезным, когда операций много, маршруты отличаются, а события уже фиксируются в нескольких системах.

Узкое место всегда находится у самого загруженного сотрудника?

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

Когда можно переходить к автоматизации?

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