Перенос данных между системами: когда RPA — разумный компромисс

Один мой знакомый IT-директор любит повторять: «Интеграция через API — это правильно, интеграция через RPA — это костыль». И в целом он прав. API надёжнее, быстрее, масштабируемее. Но есть ситуации, когда «правильное» решение недоступно или неоправданно дорого. И тогда «костыль» становится вполне рабочим инструментом.

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

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

API vs RPA: в чём разница

Прежде чем выбирать — разберёмся, как это вообще работает.

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

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

Когда у обеих систем есть нормальные API — выбор очевиден. А если API нет? Или он покрывает 30% нужного функционала? Или его разработка обойдётся в бюджет годового проекта?

Когда RPA — правильный выбор

Иногда роботизация через интерфейс — вовсе не компромисс, а самое разумное решение.

У системы нет API. Программа 2005 года, legacy-система от вендора, которого уже не существует, специализированное ПО для вашей отрасли. API либо нет вообще, либо он настолько ограничен, что бесполезен. Заказывать разработку API — долго, дорого, иногда просто невозможно. RPA работает с тем, что есть.

Госпорталы и внешние сервисы. Налоговые сервисы, порталы госуслуг, различные реестры — у большинства нет API для бизнеса. Или есть, но чтобы получить доступ, нужно пройти бюрократический квест на полгода. Робот заходит на портал, заполняет формы, скачивает отчёты — делает то же, что делал бы человек.

Временная связка на период миграции. Переходите на новую ERP, но старая ещё в работе. Строить полноценную интеграцию между ними — бессмысленно, через год старую систему отключат. RPA на переходный период — достаточно быстро и достаточно надёжно.

Небольшой объём операций. Нужно переносить 50-100 записей в день — разработка API за несколько миллионов не окупится никогда. RPA справится с таким объёмом без проблем, а стоимость будет в разы ниже.

Нужен быстрый старт. API-интеграция — проект на месяцы. RPA-робот можно запустить за пару недель. Когда горят сроки — робот выигрывает.

Когда RPA — плохой выбор

А вот ситуации, когда роботизация действительно будет костылём. И этот костыль потом придётся долго подпирать.

Большой поток данных. Тысячи записей в реальном времени — RPA физически не потянет. Робот работает последовательно, кликает по интерфейсу, это медленно. Для таких потоков нужен API, без вариантов.

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

Постоянно меняющийся интерфейс. Целевая система регулярно обновляется, UI перекраивают каждый месяц — робот будет ломаться с той же регулярностью. Каждое обновление — переделка сценария. Поддержка превращается в бесконечный ремонт.

Mission-critical процессы. RPA по определению менее надёжен, чем API. Окно зависло, кнопка не нашлась, сессия оборвалась — робот встал. Для критически важных процессов такой риск может быть неприемлем.

API уже есть. Если у системы есть нормальный API — зачем использовать RPA? Это как вскрывать замок отмычкой, когда ключ лежит под ковриком. Дольше, сложнее, хуже.

Матрица принятия решения

Чтобы упростить выбор, вот практическая матрица.

Если большинство факторов указывает на API — делайте API. Если на RPA — робот будет работать нормально.

Как сделать RPA-интеграцию надёжной

Выбрали роботизацию — ок. Теперь пара практик, чтобы потом не было мучительно больно.

Устойчивые селекторы вместо координат. Не привязывайтесь к пикселям на экране — они поплывут при любом чихе. Используйте идентификаторы элементов, названия полей, структуру документа. Кнопка переехала на 50 пикселей вправо — робот всё равно её найдёт.

Обработка ошибок — обязательно. Робот должен понимать, что что-то пошло не так: окно не открылось, поле не заполнилось, сервер выдал ошибку. И уметь реагировать — повторить попытку, пропустить запись, позвать человека. Главное — не молчать. Логируйте и эскалируйте.

Логи на каждое действие. Робот сделал что-то — записал в лог. Когда (не «если», а «когда») что-то сломается, вы сможете разобраться: что происходило, на каком шаге упало, в каком состоянии были данные.

Верификация результата. Робот не должен слепо верить, что всё прошло успешно. Ввёл данные — проверил, что сохранились. Создал запись — убедился, что она появилась. Это страховка от неочевидных сбоев.

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

Типичные сценарии RPA-интеграции

Вот несколько примеров, когда RPA для переноса данных — оправданный выбор.

Синхронизация справочников. Новый контрагент появился в одной системе — нужно создать в другой. Объём небольшой (десятки в день), формат стандартный. Робот идёт по списку новых записей, создаёт в целевой системе, отмечает обработанные.

Выгрузка отчётов из legacy-систем. Старая система генерирует отчёт, который нужен для новой BI-платформы. API нет. Робот заходит, запускает формирование, скачивает файл, загружает в хранилище. По расписанию, каждый день.

Работа с госпорталами. Сдача отчётности, получение выписок, проверка статусов. Всё через веб-интерфейс. Робот авторизуется, заполняет формы, скачивает результаты. То, что бухгалтер делал руками.

Миграция данных. Переход на новую систему — нужно перенести исторические данные. Формат старой системы нестандартный, экспорт неполный. Робот «выкачивает» данные через интерфейс, запись за записью. Медленно, но работает.

Гибридный подход: RPA + API

Часто оптимальное решение — комбинация. API для того, что он умеет. RPA для остального.

Например: система имеет API для чтения данных, но не для записи. Читаем через API (быстро, надёжно), записываем через робота (медленнее, но работает).

Или: основной поток идёт через API, но есть нестандартные операции (особые типы документов, исключения), для которых API не приспособлен. Их обрабатывает робот.

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