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

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

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

Почему исключения нельзя прятать в переписке

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

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

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

Сначала опишите нормальный путь

Нельзя разумно управлять отклонениями, пока не ясно, от чего они отклоняются. Для начала возьмите один объект: заказ, заявку на закупку, счёт или обращение клиента. Опишите его обычный путь в пяти–семи шагах. Не схему всей компании, а то, что конкретный сотрудник делает сегодня утром.

Например: менеджер создаёт заказ → система проверяет обязательные поля → заказ получает цену → склад подтверждает наличие → клиент получает сообщение. После этого легко задать вопрос на каждом шаге: что бывает не так и кто способен исправить ситуацию?

Обычно хватает трёх групп исключений:

• данных не хватает или они противоречат друг другу;
• нужно деловое решение: согласование, приоритет, допустимое отклонение;
• не сработало техническое действие: обмен, проверка, доступ к внешнему сервису.

У этих групп разные хозяева. Сотрудник продаж может уточнить телефон, руководитель — подтвердить скидку, а техническая команда — восстановить обмен. Если свалить всё в одну очередь, люди начинают брать не свои задачи или ждать друг друга.

У каждой карточки исключения должно быть действие

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

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

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

Когда автоматизация должна остановиться

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

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

А вот технический краткий сбой можно обрабатывать иначе. Если внешний сервис недоступен, система повторит попытку по правилам и покажет случай человеку только после нескольких неудач. Ключевое слово здесь — «по правилам». Повтор не должен бесконечно создавать дубликаты.

Простой пример: заказ с нестандартной ценой

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

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

Это не про недоверие к сотрудникам. Это про память процесса. Через месяц можно увидеть, какие причины повторяются, и решить: изменить правила скидок, доработать форму или оставить исключение как осознанное решение.

Как не превратить очередь в новый склад нерешённых задач

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

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

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

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

• Нормальный путь процесса описан понятными шагами.
• Каждый тип исключения отнесён к данным, деловому решению или технике.
• У случая есть владелец, срок и простое действие.
• Важные решения сохраняются в карточке, а не только в чате.
• Повторяющиеся причины регулярно превращаются в улучшение процесса.

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

Связанные вопросы

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

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

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

Хороший момент для доработки наступает не после первого необычного случая, а когда видна повторяемость. Сначала соберите несколько примеров. Затем проверьте, одинаковы ли у них причина, действие и последствия. Так не появится «особая кнопка» для одной давней ситуации, которой потом никто не пользуется.

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

Кому показывать очередь руководителю

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

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