Как настроить очередь исключений, чтобы автоматизация не скрывала проблему?

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

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

С чего начать: не со всех ошибок подряд

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

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

Например, заказ из CRM пришёл без ИНН. Его нельзя автоматически отправлять в учётную систему: это блокирующее исключение. Если ИНН есть, но адрес отличается от карточки клиента, заказ можно создать, но пометить для проверки. А если каждый день один и тот же менеджер указывает неполный адрес, это уже повод не ругать менеджера, а проверить форму и правило заполнения.

Какая карточка исключения помогает, а не мешает

Человеку не нужен технический текст вроде «ошибка 412 в модуле обмена». Нужен ответ на четыре вопроса: что произошло, на что это влияет, что можно сделать сейчас и кто отвечает за следующий шаг.

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

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

Кому принадлежит исключение

Назначить владельца — не значит навсегда повесить всё на одного сотрудника. Владелец нужен, чтобы у конкретного случая не было состояния «кто-нибудь посмотрит». Это может быть роль: оператор, бухгалтер, менеджер по работе с клиентами, руководитель направления.

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

Похожая ловушка бывает у ручных сверок после запуска изменений. Они нужны на переходе, но должны иметь критерий завершения; об этом подробнее — в статье о сроке отмены ручной сверки.

Не прячьте исключение в общий статус

У процесса может быть основной статус «в работе», «выполнено» или «требует внимания». Этого мало, если в нём скрываются разные причины. Сотрудник должен одним взглядом отличить: данные надо запросить у клиента, техническая попытка будет повторена автоматически или нужен разговор с владельцем правила.

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

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

Срок реакции зависит от последствий

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

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

Как проверить очередь на живом процессе

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

Если исключение закрыли, не удаляйте его бесследно. Через месяц это позволит ответить на простой вопрос: мы исправили правило или просто быстро разобрали последствия? Для расследования полезно начинать с последнего корректного шага, а не с первой тревожной строки журнала.

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

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

Короткий чек-лист

• Опишите 3–5 ситуаций, которые система не должна завершать молча.
• Для каждой назначьте владельца случая и владельца правила.
• Покажите человеку предмет и последствия, а не внутренний код ошибки.
• Задайте понятный срок реакции по влиянию на клиента, деньги и данные.
• Раз в неделю смотрите повторяющиеся причины, а не только число закрытых карточек.

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

Нужно ли создавать отдельную очередь для каждого процесса?

Нет. В начале достаточно одного места с фильтрами по процессу и ответственности. Отдельять очереди стоит только когда у них действительно разные владельцы и сроки реакции.

Можно ли автоматически закрывать исключение после повторной попытки?

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

Что делать с исключениями, которые появляются каждый день?

Не считать это нормой. Соберите несколько примеров, найдите общую причину и заведите работу на изменение правила, формы или интеграции.

Как не перегрузить сотрудников уведомлениями?

Уведомляйте о новых и просроченных случаях, а не о каждом техническом шаге. Остальное должно быть видно в самой очереди.

Хорошая очередь исключений не делает процесс сложнее. Она даёт автоматизации честный способ сказать: «здесь я остановилась, вот контекст и вот человек, который может решить». Именно так система помогает команде видеть проблему раньше клиента, а не маскирует её успешным статусом.