RPA: где роботизация процессов работает, а где нет
Разбираю RPA без хайпа - какие задачи поддаются роботизации, а где ожидания расходятся с реальностью.
Robotic Process Automation, или RPA, - одна из тех технологий, вокруг которых накопилось много ожиданий. Обещание простое: робот-программа делает то, что раньше делал человек за компьютером - заходит в системы, копирует данные, заполняет формы, отправляет файлы. Никакой интеграции API, никаких изменений в исходных системах.
Звучит привлекательно для компаний с большим количеством ручных операций. Но я видел достаточно RPA-проектов, чтобы сказать: ожидания и реальность расходятся заметно. И расходятся они не потому что технология плохая - а потому что её применяют не там.
Где RPA работает хорошо
RPA создана для очень конкретного класса задач. Задач, у которых есть несколько обязательных характеристик:
- процесс стабильный и хорошо задокументированный. Если каждый раз он выполняется немного по-разному - робот будет ломаться.
- Интерфейсы стабильные. Если системы обновляются часто и интерфейс меняется - роботы нужно постоянно перепрограммировать.
- Объём достаточный. Если процесс занимает два часа в неделю - автоматизация не окупится.
- Данные структурированные. Если на входе неструктурированные документы или свободный текст - RPA нужно дополнять другими инструментами.
Классические примеры, где это работает: ежедневная выгрузка данных из нескольких систем в одну таблицу, ввод данных из форм в корпоративную систему, формирование стандартных отчётов в заданное время.
Где ожидания не совпадают с реальностью
Первая проблема - хрупкость. Роботы работают с интерфейсом, а не с логикой. Изменился цвет кнопки, сдвинулось поле в форме, обновилась версия браузера - и робот перестал работать. Это создаёт постоянную нагрузку на поддержку.
Вторая проблема - процессы оказываются менее стандартными, чем казалось. В реальности каждый сотрудник делает одну и ту же задачу немного по-разному. Роботизировать такой процесс сложнее, чем описать его в ТЗ.
Третья проблема - RPA автоматизирует симптом, а не причину. Если данные приходится переносить вручную из одной системы в другую - это симптом отсутствия интеграции. RPA автоматизирует перенос, но не убирает архитектурный разрыв. Через год количество роботов растёт, а архитектурная проблема никуда не делась.
Как принимать решение
Перед тем как запускать RPA-проект, стоит ответить на несколько вопросов:
- Насколько стабилен этот процесс? Когда он последний раз существенно менялся?
- Существует ли возможность решить эту задачу через API или прямую интеграцию? Если да - почему мы выбираем RPA вместо этого?
- Кто будет поддерживать роботов после внедрения? Это внутренняя компетенция или зависимость от вендора?
- Как мы будем узнавать, что робот сломался или начал делать что-то неправильно?
- Какой процент случаев будет требовать исключений и ручного вмешательства?
Если интеграция через API возможна - я почти всегда её предпочту RPA. Она надёжнее, дешевле в поддержке и не ломается при обновлении интерфейсов. RPA оправдана там, где API нет, интеграцию невозможно построить в разумные сроки, а ручной процесс достаточно объёмный и стабильный.
Итог
RPA - полезный инструмент для узкого класса задач. Проблема не в инструменте, а в том, что его часто воспринимают как универсальное решение для автоматизации, а не как специализированный инструмент с конкретными условиями применения.
Хороший вопрос перед любым RPA-проектом: если бы мы решали эту задачу с нуля сегодня, мы бы снова выбрали RPA - или попробовали бы что-то другое?