Когда RPA спасает старую систему

Есть системы, которые давно пора менять.

Но на практике «пора менять» и «можно заменить» — совершенно разные вещи.

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

Иногда ответом становится RPA — Robotic Process Automation.

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

Это звучит просто.

Когда система работает, но интегрироваться с ней невозможно

Представим типичную ситуацию.

В компании есть старая программа учёта:

При этом вокруг неё уже появились:

• › сайт;
• › CRM;
• › интернет-магазин;
• › мобильное приложение;
• › новые сервисы;
• › аналитические системы;
• › личные кабинеты;
• › автоматические уведомления.

Новая инфраструктура умеет работать через API, но старая программа — нет.

Получается разрыв:

Что делает RPA вместо API

Обычная интеграция выглядит примерно так:

RPA работает иначе:

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

Он использует доступный пользовательский интерфейс как точку взаимодействия.

Почему нельзя просто «сделать API»

Это первое возражение, которое обычно возникает.

Если система старая, почему бы не написать к ней API самостоятельно?

Иногда так и следует поступить.

Но для этого необходимо понимать внутреннюю структуру приложения и иметь безопасный доступ к данным или бизнес-логике.

А на практике может оказаться, что:

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

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

Например, создание заказа может запускать целую цепочку внутренних процедур.

это не гарантирует, что система:

• › пересчитала остатки;
• › сформировала связанные документы;
• › обновила статус;
• › зарегистрировала операцию;
• › выполнила проверки;
• › записала историю.

RPA — это не «бот, который кликает мышкой»

Так его часто воспринимают.

На самом деле промышленный RPA-процесс должен иметь гораздо более строгую структуру:

Робот должен понимать не только что нажать, но и:

• › какую задачу он выполняет;
• › какие данные получил;
• › какой результат ожидался;
• › что считать успешным завершением;
• › что делать при ошибке;
• › можно ли повторить операцию;
• › как сообщить о проблеме;
• › как доказать, что операция действительно выполнена.

Самая опасная ошибка — автоматизировать экран

Допустим, разработчик записал:

На демонстрации всё работает.

Через неделю пользователь меняет размер окна.

Кнопка немного перемещается.

Или разработчик старой системы меняет подпись.

Или появляется новое окно с предупреждением.

Робот больше не понимает, что происходит.

Поэтому надёжный RPA строится не вокруг координат мыши, а вокруг устойчивых элементов интерфейса и контролируемого состояния приложения.

Интерфейс становится частью интеграционного контракта

При обычном API интеграционный контракт выглядит примерно так:

{
  "customer": 184,
  "amount": 250000
}

• › Формат определён.
• › Поля известны.
• › Ошибки имеют структуру.

В RPA роль такого контракта частично начинает выполнять пользовательский интерфейс.

Например:

• › Поле «Клиент»
• › Поле «Сумма»
• › Кнопка «Провести»
• › Сообщение «Документ создан»

И это делает RPA уязвимым к изменениям интерфейса.

Поэтому старую систему нельзя воспринимать как неизменяемый объект.

Где RPA действительно оправдан

Есть несколько ситуаций, где применение RPA выглядит вполне рационально.

Старую систему нельзя заменить сейчас

Например, замена потребует двух лет миграции, а автоматизировать процесс нужно в ближайшие месяцы.

RPA может стать промежуточным решением:

Система критична, но используется для небольшого числа операций

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

Например:

Нет API, но есть стабильный интерфейс

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

Особенно когда процесс:

• › повторяемый;
• › последовательный;
• › хорошо формализован;
• › имеет понятные входные данные;
• › имеет проверяемый результат.

Где RPA начинает быть плохим решением

Теперь обратная сторона.

Если интерфейс постоянно меняется, робот превращается в источник постоянных доработок.

И каждый такой релиз требует проверки робота.

Ещё хуже, если процесс требует постоянного принятия решений человеком.

Такой процесс трудно качественно заменить простым RPA.

RPA плохо переносит неопределённость

Представим процесс:

«Открой заявку и реши, что с ней делать».

Для человека это понятная задача.

Для робота — нет.

Нужно формализовать:

• › Если A → действие 1
• › Если B → действие 2
• › Если C → отправить специалисту
• › Если неизвестно → остановиться

А если интерфейс старой программы работает через удалённый рабочий стол?

Это отдельная сложность.

Робот может не иметь прямого доступа к элементам интерфейса.

Вместо структурированных компонентов он фактически видит изображение экрана.

Тогда надёжность снижается:

В таких сценариях могут потребоваться дополнительные методы компьютерного зрения, OCR и контроля состояния.

Робот должен проверять result, а не просто нажимать «Сохранить»

Это один из ключевых принципов.

Например:

Самая сложная часть — ошибки

Допустим, робот начал создавать документ.

Он заполнил половину полей.

Что дальше?

Можно просто остановиться.

Но в промышленной автоматизации нужно понимать:

• › Что уже сделано?
• › Что ещё не сделано?
• › Можно ли повторить?
• › Не создался ли документ частично?
• › Куда сообщить об ошибке?
• › Кто должен её исправить?

Поэтому у процесса должны существовать состояния.

Например:

Повтор операции требует осторожности

Представим, робот не получил подтверждение после создания документа.

Можно предположить:

«Наверное, не создался. Запустим ещё раз».

И получить два одинаковых документа.

Это одна из типичных проблем автоматизации.

Поэтому для операций записи нужно заранее определить механизм защиты от дублей.

Например, использовать внешний идентификатор:

При повторном запуске:

RPA не должен быть единственным слоем системы

Если построить всё следующим образом:

Тогда робот отвечает преимущественно за одно:

А правила:

• › когда выполнять;
• › какие данные передавать;
• › как обрабатывать ошибки;
• › как связывать сущности;
• › что считать успехом;

RPA можно рассматривать как адаптер

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

Такое мышление помогает правильно определить границы технологии.

RPA не обязан становиться центром всей автоматизации.

Что делать, если старую систему всё-таки придётся заменить

Тогда особенно важно не строить RPA как вечную зависимость.

Хороший переходный проект должен позволять однажды убрать робота.

Например:

Как понять, что RPA пора заменять интеграцией

Есть несколько характерных признаков.

• › Робот приходится постоянно переделывать после обновлений интерфейса.
• › Количество сценариев растёт, и они начинают зависеть друг от друга.
• › Объём операций становится настолько большим, что производительность UI уже не подходит.
• › Появляется необходимость работать с данными напрямую.
• › Операции становятся критичными для бизнеса и требуют высокой гарантии доставки.
• › Или компания уже получила возможность использовать официальный API.

В этот момент стоит пересмотреть архитектуру:

Иногда RPA лучше, чем дорогостоящая переделка

Представим систему, которую используют 20 сотрудников.

Есть один процесс:

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

RPA в таком случае способен решить конкретную проблему за значительно меньший срок.

Не каждая старая система заслуживает немедленной замены.

Но RPA не должен маскировать плохой процесс

Есть ещё одна опасность.

Компания может сказать:

А после анализа выясняется:

Если сразу автоматизировать все десять шагов, компания просто получает автоматизированную неэффективность.

Поэтому перед разработкой стоит задать простой вопрос:

Когда RPA — хороший выбор

Можно использовать простой фильтр:

Это не математическая формула выбора.

Что должно быть в промышленном RPA-решении

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

Нужны как минимум:

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

Потому что в корпоративной среде вопрос уже не в том, может ли робот нажать кнопку.

RPA как временный мост — и как часть долгосрочной архитектуры

Есть распространённое мнение:

Иногда — действительно.

Если компания годами поддерживает десятки роботов, которые кликают по постоянно меняющимся интерфейсам вместо нормального API, архитектура явно требует пересмотра.

Но называть любой RPA костылём тоже неправильно.

Если старая система:

• › критична;
• › стабильна;
• › не имеет API;
• › не может быть быстро заменена;
• › содержит важную бизнес-логику;
• › а процесс вокруг неё хорошо формализован,

RPA может быть вполне рациональным интеграционным механизмом.

Итог

RPA особенно полезен там, где современная автоматизация сталкивается с наследием прошлых лет.

Старая программа может не иметь API, не поддерживать webhooks, не предоставлять нормальных механизмов интеграции и при этом оставаться важнейшей частью бизнеса.

В такой ситуации есть несколько вариантов:

Поэтому RPA стоит рассматривать не как замену API и не как универсальный способ интеграции.

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

Самый сильный вариант — когда робот становится аккуратным мостом:

А ещё лучше — когда этот мост построен так, чтобы однажды его можно было спокойно убрать.

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

🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).