Коротко о главном
Первый контур запущен. Прошло 14 дней. Сняли метрики — и увидели, что вместо плановых 80% типовых заявок без остановки проходит 50–60%.
Это не провал. Это нормальная точка после первого запуска.
Вопрос не в том, работает ли AI. Вопрос в том, что конкретно делать дальше — как убрать узкие места, дотянуть автоматизацию до целевых показателей и выстроить работу сотрудника с теми заявками, которые система скидывает обратно на человека.
Именно об этом — настоящая статья.
В ней разберём:
- почему контур не выходит на 80% с первого раза и что это значит;
- три типовых узких места — и как каждое из них устраняется;
- как выстроить работу с 20% исключений, чтобы они не стали новым хаосом;
- что считать результатом донастройки и когда можно двигаться дальше.
Связка с предыдущими материалами
В прошлых статьях мы разобрали:
- как убрать ручную работу в заявках и документах за 14 дней;
- что такое AI-диагностика и как выбрать первый процесс;
- как подготовиться к диагностике и зафиксировать baseline до старта;
- как выглядят первые 14 дней внедрения изнутри.
Теперь — следующий логичный шаг: что делать, когда первый этап запущен, но метрики ещё не вышли на плановые показатели.
Почему 80% не достигается с первого раза
Это важно принять как факт, а не как ошибку команды или инструмента.
Любой реальный бизнес-процесс грязнее, чем схема на бумаге. Клиенты присылают данные в разных форматах. Сотрудники работают по привычке. Логика, которая казалась простой при разборе, на реальном потоке оказывается сложнее.
Именно поэтому первый этап — это не финал. Это точка отсчёта.
Задача донастройки: убрать конкретные узкие места, которые мешают контуру работать стабильно. Не перезапускать всё заново. Не добавлять новые процессы. Точечно устранить то, что держит показатель на уровне 50–60%.
Три типовых узких места — и как их устранить
1. Хаос на входе
Что происходит: Контур настроен под стандартный формат — PDF, таблица, структурированная форма. Но по факту заявки приходят по-разному: скан с телефона, письмо без структуры, скриншот из мессенджера, файл в нестандартной кодировке.
Система не распознаёт формат — и скидывает заявку на человека. Не потому что заявка сложная, а потому что данные пришли не в том виде.
Как устранить:
Зафиксировать минимальный входной стандарт. Не сложную форму с десятком полей — достаточно одного простого шаблона, который охватывает 80% типовых заявок.
Если клиент или подрядчик присылает данные самостоятельно — дать ему шаблон. Если заявки создаются внутри компании — договориться о едином формате внутри команды.
Это не технологическая задача. Это организационное решение, которое принимается один раз.
Результат: Доля заявок, которые контур распознаёт без остановки, вырастает без изменения самой логики автоматизации.
2. Слишком жёсткая логика фильтрации
Что происходит: Алгоритм настроен на идеальные входные данные. Одно пустое поле — и вся заявка блокируется. Система возвращает её сотруднику целиком, хотя 90% данных уже есть и корректны.
Итог: человек получает обратно всю рутину из-за одного пропущенного реквизита.
Как устранить:
Пересмотреть логику фильтрации. Разделить поля на критичные и некритичные.
Критичные — без них заявку нельзя обработать (например, контакт клиента или сумма). Их отсутствие оправданно блокирует процесс.
Некритичные — их отсутствие не мешает передать заявку дальше. Система должна пропускать максимум данных в CRM или 1С и оставлять сотруднику только точечный запрос: «уточни одно поле».
Не возвращать всё. Только то, чего реально не хватает.
Результат: Сотрудник перестаёт получать обратно полностью заполненные заявки с одним пустым полем. Нагрузка на ручную проверку снижается без изменения самой схемы.
3. Двойная проверка руками
Что происходит: Это самое частое узкое место — и оно не в технологиях.
Данные извлечены, структурированы, переданы в систему. Карточка в Битрикс24 или 1С создана без участия сотрудника. Но человек по привычке открывает исходное письмо и сверяет каждую строчку вручную — «на всякий случай».
На бумаге контур работает. По факту время цикла не меняется, потому что сотрудник добавился как лишнее звено туда, где его не должно быть.
Как устранить:
Разграничить зоны ответственности жёстко и письменно.
Типовые заявки — проходят без остановки. Сотрудник их не открывает, не сверяет, не трогает.
Нетипичные заявки — те, которые система пометила флагом «требует проверки». Только они уходят к человеку. И только по ним сотрудник принимает решение.
Это не вопрос доверия к технологии. Это вопрос чёткого регламента: кто делает что и при каком условии.
Результат: Реальное время цикла начинает совпадать с тем, которое показывает система. Сотрудник перестаёт дублировать работу контура.
Как выстроить работу с 20% исключений
Когда три узких места устранены, контур выходит на целевые 80% типовых заявок без остановки.
Остаются 20% — нетипичные случаи, исключения, заявки с нестандартной логикой.
Здесь возникает второй риск: исключения превращаются в новый хаос, если с ними не выстроена отдельная схема работы.
Что такое исключение в контексте первого контура
Исключение — это заявка, которую система не может обработать по стандартной логике. Причины разные:
- нестандартный запрос, не попадающий в типовой сценарий;
- данные, которых недостаточно для автоматической обработки;
- ситуация, требующая принятия решения, а не просто переноса данных;
- новый формат, с которым контур ещё не сталкивался.
Исключение — это не ошибка системы. Это сигнал: здесь нужен человек.
Три правила работы с исключениями
Правило 1. Исключение должно приходить с контекстом.
Когда система передаёт заявку сотруднику, она должна передавать не просто «что-то пошло не так», а структурированную карточку: что уже извлечено, чего не хватает, почему заявка помечена как нетипичная.
Сотрудник не начинает с нуля. Он получает готовую заготовку и принимает одно конкретное решение.
Правило 2. Исключения не накапливаются.
Нетипичные заявки не должны складываться в очередь. Если исключение пришло — сотрудник обрабатывает его в тот же день. Накопленная очередь исключений — это новый источник потерь, только теперь уже организованный.
Правило 3. Повторяющиеся исключения становятся новым сценарием.
Если один и тот же тип нетипичных заявок встречается три раза подряд — это не исключение. Это паттерн, который нужно добавить в логику контура.
Отслеживать это просто: сотрудник отмечает причину ручной обработки. Раз в две недели — просматриваем список. Повторяющиеся причины — кандидаты на включение в типовой сценарий.
Это и есть механизм, за счёт которого контур постепенно расширяется — не за счёт добавления новых процессов, а за счёт обучения на реальном потоке.
Как понять, что донастройка завершена
Донастройка — не бесконечный процесс. У неё есть чёткий критерий завершения.
Контур стабилен, если:
- 75–80% типовых заявок проходят без ручного вмешательства стабильно в течение пяти рабочих дней подряд;
- исключения приходят к сотруднику с контекстом и обрабатываются в день поступления;
- повторяющихся причин ручной обработки становится меньше — контур учится на реальном потоке;
- время цикла совпадает с тем, что показывает система, без двойной проверки руками.
Когда эти четыре условия выполнены — первый контур стабилен. Можно принимать решение о следующем шаге.
Что делать, если метрики всё равно не сходятся
Иногда после устранения трёх типовых узких мест показатель всё равно остаётся ниже целевого.
Это сигнал не для расширения контура, а для возврата к карте процесса.
Три вопроса для диагностики:
1. Правильно ли выбран процесс для первого этапа? Если в процессе слишком много исключений изначально — возможно, он не подходил для первого контура. Типовой процесс должен давать 80% стандартных операций уже на старте.
2. Не расширился ли scope незаметно? Часто в процессе работы к первому контуру добавляются смежные задачи. Это размывает логику и снижает стабильность. Если это произошло — вернуться к исходным границам.
3. Получают ли сотрудники достаточно контекста при работе с исключениями? Если нет — часть решений принимается без данных, что увеличивает время обработки и создаёт ошибки.
Итог
Первый контур редко выходит на целевые 80% сразу. Это не недостаток подхода — это реальность любого внедрения в живой бизнес.
Донастройка — это не второй проект. Это финальная часть первого этапа.
Три узких места устраняются по одному. Работа с исключениями выстраивается один раз — и потом работает как регламент. Повторяющиеся исключения постепенно становятся частью типового сценария.
Когда контур стабильно обрабатывает 75–80% потока без остановки — первый этап завершён. Не тогда, когда он запущен. А тогда, когда он работает предсказуемо.
Именно это и является точкой, с которой можно двигаться к следующему процессу.
