Управление исключениями в RPA

В RPA-проектах работает неприятное правило: 80% случаев автоматизируются легко, а оставшиеся 20% съедают 80% бюджета и нервов. Многие думают, что это преувеличение. Пока сами не столкнутся.

Типичная история. Команда описывает процесс, делает робота, тестирует на стандартных данных — всё летает. Запускают в бой. И тут — документ в странном формате, система выдала невиданную ошибку, данные заполнены криво, интерфейс поменялся после ночного обновления. Робот встал, процесс встал, все бегают.

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

Что такое исключение в контексте RPA

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

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

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

Бывают системные: обновили приложение, интерфейс поменялся, появилось новое обязательное поле. Тут без переделки робота не обойтись.

Главное: исключение — не ошибка робота. Это нормальная часть реальности. Как у людей бывают нестандартные ситуации, так и у роботов. Зрелый RPA-процесс — не тот, где исключений нет. А тот, который умеет с ними справляться.

Почему исключения так критичны для ROI

Посчитаем.

Робот обрабатывает 1000 транзакций в день. Заявлено, что автоматизирует 95% случаев. То есть 50 транзакций в день — исключения. На разбор одного уходит 15 минут. Итого: 12,5 часов ежедневно только на исключения. Полторы ставки.

А если процент вырос до 10%? После обновления системы или появления новых типов документов это запросто. 100 исключений в день. 25 часов работы. Три человека только на то, чтобы разгребать за роботом.

Это ещё не всё. Необработанные исключения — это задержки. Робот встал и не знает, что делать — весь поток за ним стоит. Клиент ждёт ответа, поставщик ждёт оплаты, сотрудник ждёт справки.

А ещё — репутационные риски. Робот тихо «проглотил» ошибку и пошёл дальше с кривыми данными. Потом выясняется: платёж ушёл не туда, документ оформлен неправильно, заявка потерялась. Разбираться — долго и больно.

Типология исключений: классифицируем, чтобы управлять

Первый шаг к управлению — классификация. Разные типы исключений требуют разных подходов.

Транзиентные исключения — временные проблемы, которые решаются сами. Система была перегружена и не ответила, но через минуту ответит. Сеть моргнула. Сервер перезагружался. Для таких случаев нужна логика retry — подождать и попробовать снова. Обычно 3-5 попыток с увеличивающейся паузой.

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

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

Бизнес-исключения второго уровня — случаи, которые требуют человеческого решения. Данные противоречивы, ситуация неоднозначная, нужна экспертная оценка. Робот должен собрать контекст и передать человеку с максимумом информации.

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

Паттерны обработки исключений

Теперь к практике. Как правильно обрабатывать каждый тип.

Retry с exponential backoff. Для транзиентных ошибок — пробуем снова, увеличивая паузу между попытками. Первая попытка через 5 секунд, вторая через 15, третья через 45. Если после N попыток не получилось — эскалируем. Важно логировать каждую попытку.

Circuit breaker. Если система начинает массово отказывать — не нужно долбить её бесконечными запросами. Это только усугубит проблему. После определённого количества ошибок подряд «выключаем» это направление на время. Даём системе отдохнуть, потом пробуем снова.

Graceful degradation. Если какая-то часть процесса не работает, но основной поток можно продолжить — продолжаем. Не получилось отправить email-уведомление? Записываем в лог, но транзакцию завершаем. Уведомление пошлём позже.

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

Human-in-the-loop. Для бизнес-исключений второго уровня — передаём человеку. Но не просто «посмотри», а с полным контекстом: что пытались сделать, какие данные, что пошло не так, какие варианты решения. Чем больше информации — тем быстрее человек разберётся.

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

Частая ошибка — думать об исключениях потом. «Сначала сделаем основной сценарий, обработку ошибок добавим позже.» Это путь к боли.

На этапе анализа процесса задавайте «а что, если?» на каждом шаге. Система не ответила? Данных нет? Формат странный? Значение за пределами нормы? Соберите все «что, если» и для каждого пропишите действие.

Поговорите с людьми, которые делают процесс руками. Они знают все грабли. «Бывает, клиент шлёт счёт без БИН», «Система иногда виснет после большой выгрузки», «В старых записях телефон в другом формате». Золотая информация — берите её.

Покопайтесь в истории. Логи, тикеты поддержки за последний год — какие проблемы возникали? Это готовый список исключений, которые точно случатся снова.

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

Организация работы с очередью исключений

Исключения собраны в очередь — отлично. Но кто и как их обрабатывает?

Назначьте владельца очереди. Это человек (или команда), который отвечает за то, чтобы исключения не накапливались. У него есть SLA — например, все исключения должны быть разобраны в течение 4 часов. Или в течение рабочего дня. Зависит от критичности процесса.

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

Стандартизируйте разбор. Для типовых исключений — готовые инструкции. Открыл карточку исключения — видишь, что делать. «Ошибка X: проверить поле Y, если пусто — заполнить Z из справочника, пересоздать транзакцию.» Чем меньше думать — тем быстрее обрабатывать.

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

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

Метрики и мониторинг

Что измерять, чтобы понимать здоровье процесса.

Exception rate — процент транзакций, ушедших в исключения. Норма зависит от процесса, но обычно стремятся к 5% или меньше. Если выросло резко — сигнал тревоги.

Mean time to resolution — среднее время от возникновения исключения до его разрешения. Должно укладываться в SLA. Если растёт — очередь не справляется.

Queue depth — сколько исключений в очереди сейчас. Если растёт быстрее, чем уменьшается — проблема накапливается.

Exception по типам — распределение исключений по категориям. Помогает видеть, где основные проблемы. Если 70% исключений — один тип, его стоит автоматизировать.

Retry success rate — какой процент автоматических повторных попыток успешен. Если низкий — логика retry неэффективна.

Визуализируйте эти метрики на дашборде. Смотрите каждый день. Отклонения от нормы — повод разобраться.

Типичные ошибки в управлении исключениями

На что напарываются чаще всего.

Молчаливое проглатывание. Робот поймал ошибку и пошёл дальше. Транзакция потерялась, никто не в курсе. Худший вариант. Любое исключение — в лог, любое исключение — видимо.

Универсальный обработчик. На всё один ответ: «Что-то пошло не так». Без подробностей, без контекста. Человек получает уведомление и не понимает, что делать. Исключения должны быть конкретными.

Бесконечные попытки. Робот долбится снова и снова, без лимита. Грузит систему, блокирует очередь, ничего не добивается. Всегда ставьте потолок на количество ретраев.

Нет эскалации. Исключение висит в очереди неделю — всем пофиг. Нет алертов, нет ответственных. Нужны триггеры: не обработали за X часов — уведомление менеджеру. За Y часов — директору.

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