Где ломается RPA: потолок сложности процессов

Роботизация бизнес-процессов (RPA) уверенно развивалась в конце 2010-х. Обещание было конкретным: автоматизировать рутинные клики и перенос данных, которые сотрудники делают ежедневно, без переписывания базовых систем. Никакой интеграции по API, никаких изменений в исходном приложении. Бот записывает действия и воспроизводит их.

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

Где RPA реально хороша

RPA хорошо работает, когда у процесса есть все три следующих признака:

• Большой объём повторяющихся шагов, следующих в фиксированной последовательности.
• Стабильные базовые приложения, которые редко меняют интерфейс.
• Низкая доля исключений - подавляющее большинство случаев идёт по стандартному пути.

Хороший кандидат - извлечение данных из инвойса фиксированного шаблона и ввод их в поле ERP. Или проверка наличия записи о заказе в двух системах перед отгрузкой. Или формирование ежемесячного отчёта из фиксированного SQL-запроса и отправка его по электронной почте в виде PDF.

Где это начинает ломаться

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

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

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

Организационная ловушка

Я видел компании, которые автоматизировали процесс, не починив его сначала. Процесс имел шесть типов исключений, потому что никогда не был нормально спроектирован. RPA-проект превратился во фреймворк для обработки исключений - это хрупкая и дорогая вещь в обслуживании.

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

Как честно оценить кандидата на RPA

Перед тем как браться за RPA-проект, я задаю вопросы:

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

Правильное место для RPA в 2021 году

RPA не умерла и не переоценена для всего. Она хорошо подходит для конкретной задачи: стабильные, высокообъёмные, низкоисключительные воркфлоу, где API-интеграция недоступна, а её создание не стоит затрат. За пределами этой зоны накладные расходы на обслуживание и хрупкость, как правило, перевешивают экономию на труде в течение восемнадцати месяцев.