RPA: что это на самом деле решает и где упирается в стену

Роботизация бизнес-процессов (RPA) имеет очень сильный маркетинговый нарратив. Питч убедителен: программные роботы, работающие 24 часа в сутки, не допускающие ошибок и обходящиеся в долю стоимости штатной единицы. Для определённых задач это описание примерно точное. Для других разрыв между питчем и опытом значителен.

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

Для чего RPA хорошо подходит

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

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

Где он ломается

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

Вторая распространённая проблема - обработка исключений. Процессы, которые кажутся простыми, часто имеют длинный хвост пограничных случаев. Робот, автоматически обрабатывающий 90% транзакций, полезен. Но 10%, выпадающие за рамки «счастливого пути», должны куда-то попадать - обычно в очередь к человеку. Если эта очередь не спроектирована должным образом, исключения накапливаются и экономия времени частично нивелируется управленческими издержками.

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

Как решить, подходит ли этот инструмент

Прежде чем одобрять RPA-проект, я задаю три вопроса. Первый: есть ли реалистичный путь к построению нормальной интеграции с целевой системой, пусть и долгий? Если да, RPA - это краткосрочное решение, создающее технический долг. Второй: как часто меняется целевое приложение? Если часто, стоимость сопровождения будет высокой. Третий: что происходит, когда робот ломается? Если ответ «мы ещё не знаем», это пробел в проектировании.

RPA имеет смысл как тактический мост, когда нормальная интеграция откладывается на годы, а объём процесса достаточно высок, чтобы оправдать его. Он не имеет смысла как постоянный стратегический слой.

Замечание о рынке

Рынок RPA-инструментов в 2018 году активен: несколько зрелых платформ и агрессивные циклы продаж. Большинство корпоративных вендоров позиционируют RPA как шаг к интеллектуальной автоматизации и в конечном счёте к ИИ. Этот roadmap в принципе правдоподобен. На практике большинство компаний ещё не готовы к интеллектуальной автоматизации - они всё ещё работают над тем, чтобы сделать надёжными свои базовые процессы. Начните с этого, прежде чем добавлять ИИ к стеку автоматизации.