Как передавать исключения в автоматизированном процессе, чтобы они не терялись?
Исключения не нужно прятать внутри автоматизированного процесса. Их стоит заранее вывести в отдельный понятный маршрут: с причиной, владельцем, сроком и следующим действием. Тогда обычные операции идут быстро, а нестандартные не исчезают между системой и людьми.
Автоматизация хорошо справляется с повторяемой частью работы. Заявка пришла, данные заполнены, лимит не превышен — система назначает исполнителя и двигает задачу дальше. Но жизнь почти всегда добавляет «если»: клиент изменил условие, контрагент прислал неполный документ, цена вышла за лимит, склад подтвердил замену. Ошибка не в том, что такие случаи существуют. Ошибка — делать вид, будто их нет.
Сначала отделите исключение от обычной вариации
Не каждый редкий случай надо вести вручную. Если ситуация возникает регулярно и у неё есть одинаковое решение, это уже часть процесса. Её лучше описать правилом и включить в автоматизацию.
Исключение — это случай, где система не может безопасно выбрать действие без человека. Не хватает данных, последствия слишком дороги, правило конфликтует с другим правилом или решение зависит от контекста, который нельзя честно свести к галочке.
Например, заказ без ИНН — не всегда исключение: если без ИНН заказ просто нельзя оформить, это обычная проверка данных. А просьба отправить товар до подписания нестандартного договора — исключение, потому что решение затрагивает риск, деньги и ответственность.
Что должно случиться в момент исключения
У хорошего маршрута нет состояния «разберёмся потом». В тот момент, когда правило не сработало, система делает четыре вещи.
- Сохраняет исходные данные и причину остановки, чтобы человек не собирал картину из чатов.
- Назначает владельца решения, а не просто отправляет уведомление в общий канал.
- Показывает срок реакции и влияние на основной процесс.
- Даёт выбрать понятное продолжение: исправить данные, согласовать риск, вернуть на предыдущий шаг или отменить операцию.
Это похоже на развилку на дороге. Таблички нужны не потому, что все водители ошибаются, а потому, что на развилке нельзя молча ждать, пока кто-то угадает поворот.
Не отправляйте всё одному человеку
Частая ловушка — назначить все нестандартные случаи руководителю. В первые недели это кажется надёжным: опытный человек всё увидит. Потом у него появляется очередь из мелочей, срочные решения тонут среди несрочных, а команда перестаёт понимать границы своей ответственности.
Лучше разделить исключения по типу решения. Ошибку в карточке клиента может исправить менеджер. Несовпадение остатков — сотрудник склада. Скидку за пределами утверждённого диапазона — руководитель продаж. Техническую ошибку обмена — владелец интеграции. Одно исключение может затронуть несколько ролей, но финальное решение всё равно должно иметь одного владельца. Если эта роль ещё не названа, сначала стоит назначить владельца процесса, а не прятать неопределённость за новым статусом.
Если ролей много, полезна простая таблица: тип исключения, кто получает, кто решает, за какой срок, какие действия доступны. Это не бюрократия, а страховка от формулировки «я думал, этим занимается другой отдел».
Сохраните контекст, а не только красный статус
Статус «ошибка» почти бесполезен. Он сообщает, что где-то случилось неудобство, но не объясняет, что делать. Для решения обычно нужны идентификатор операции, входные данные, правило, которое не прошло, время, предыдущие шаги и понятная связь с клиентом или заказом.
Это особенно заметно при интеграциях. Если обмен не прошёл, человеку важно увидеть не технический набор символов, а человеческий ответ: «заказ 123 не передан в учётную систему, потому что у товара нет сопоставления; продажа не остановлена, нужно выбрать действие». Тогда исключение становится задачей, а не сигналом тревоги.
Полезно также сохранять принятое решение. Через месяц это позволит увидеть повторяющийся паттерн. Если десять раз подряд выбирают одну и ту же ручную развилку, её пора превратить в нормальное правило. Как именно отделить такие случаи, подробно разобрано в статье о работе с исключениями в автоматизированном процессе.
Задайте срок, но не маскируйте проблему таймером
Срок реакции нужен, чтобы исключение не жило неделями. Но сам по себе таймер не делает маршрут управляемым. Если владелец не понимает, какое решение от него ждут, он будет откладывать задачу или перекидывать её дальше.
Поэтому рядом со сроком стоит написать последствия: «через два часа заказ не уйдёт в сборку», «до закрытия дня документ не попадёт в реестр», «повторная отправка заблокирована, чтобы не создать дубль». Человек быстрее выбирает, когда видит цену ожидания.
Безопасный повтор — отдельное решение
Во многих процессах самая опасная кнопка называется «повторить». Если система не получила ответ от внешнего сервиса, это не всегда значит, что операция не состоялась. Платёж мог пройти, документ мог быть принят, уведомление могло уже уйти. Повтор без проверки иногда создаёт двойную отгрузку, второй счёт или две одинаковые задачи.
Поэтому в маршруте исключений стоит заранее отметить, какие действия можно повторять автоматически, какие — только после сверки, а какие вообще нельзя повторять. У человека должна быть не абстрактная команда «разобраться», а безопасный выбор: запросить статус, сопоставить запись, закрыть как дубликат, отправить на ручную проверку.
Это кажется технической деталью, но именно здесь встречаются процесс и архитектура. Одно и то же исключение должно быть понятно и сотруднику, который отвечает клиенту, и специалисту, который проверяет обмен. Если каждый видит свою половину без общей связи, очередь всё равно останется ручной.
Как понять, что маршрут пора менять
Через несколько недель посмотрите на журнал исключений. Если большинство карточек закрывают одинаковым действием, это уже кандидат на новое правило. Если они постоянно уходят между двумя ролями, не определена граница ответственности. Если срок соблюдён, но клиент всё равно ждёт, выбран неверный ориентир для срочности.
Не нужно стремиться к нулю исключений. Ноль может означать и то, что люди перестали их фиксировать. Цель другая: редкие и рискованные ситуации должны быть видны, иметь владельца и давать материал для улучшения процесса.
Как запустить без большого переписывания
Не обязательно сразу строить идеальный центр инцидентов. Выберите один болезненный тип исключений, который уже отнимает время. За неделю соберите реальные примеры, не переписывая их красивыми словами. Посчитайте, кто сейчас узнаёт о проблеме первым, где теряется контекст и кто принимает окончательное решение.
Затем сделайте маленький маршрут. Одно понятное состояние, один владелец, два-три допустимых действия и журнал решения. Проверьте его на нескольких реальных случаях. Важно не только то, прошла ли задача по экрану, но и смог ли следующий сотрудник без звонка понять, что происходило.
Когда маршрут заработает, смотрите не на количество красных карточек, а на качество: сколько исключений закрывается в срок, сколько возвращается по кругу, сколько повторяется по одной причине. Эти наблюдения помогают улучшать не только интерфейс, но и сам процесс.
Частые ошибки
- Автоматически продолжать рискованную операцию, чтобы не портить показатель скорости.
- Собирать исключения в общий чат без владельца и срока.
- Показывать техническую ошибку вместо следующего действия для пользователя.
- Разрешать всем закрывать исключение без следа о принятом решении.
- Не возвращаться к повторяющимся ручным обходам.
Короткий чек-лист
Перед запуском спросите себя: известно ли, что именно стало исключением; назначен ли один владелец; видит ли он контекст и последствия; есть ли безопасные варианты действия; попадёт ли решение в историю; станет ли повторяемый случай кандидатом на новое правило. Если на любой вопрос ответ «нет», автоматизация пока просто переносит неопределённость в другую очередь.
Связанные вопросы
- Как назначить владельца процесса перед автоматизацией?
- Как организовать работу с исключениями в автоматизированном процессе?
- Что делать, если после автоматизации процесс стал медленнее?
- Как передать заказ из продаж в исполнение без потери деталей?
Обсудим?