RPA-автоматизация: когда программный робот оправдан

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

Что такое RPA простыми словами

RPA, или роботизированная автоматизация процессов (Robotic Process Automation), — это программные «роботы», которые повторяют действия пользователя в интерфейсе: открывают окна, копируют значения, заполняют поля, нажимают кнопки.

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

Когда RPA оправдана

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

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

Почему при наличии API лучше интеграция

Робот опирается на интерфейс. Если в программе переехала кнопка или поменялось название поля, сценарий робота приходится править.

Интеграция через API работает на уровне данных, и у неё есть инструменты, которых нет у робота:

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

Как настраивают обмен данными через API, разобрано в статье настройка интеграции API.

Позиция KORVENIQ по RPA и интеграциям — на странице услуги.

Что проверить до того, как выбирать RPA

Отсутствие современного REST API ещё не значит, что остался только робот. У старых систем бывают другие способы обмена, и их стоит изучить в первую очередь: SOAP, файлы, доступ к базе данных, очередь сообщений или экспорт.

• Файловый обмен в CSV, XML или JSON допустим, если API нет, а данные обновляются пакетами.
• Прямой доступ к базе чужой системы используют только при обоснованной необходимости и с контролируемыми правами.

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

Если всё-таки RPA: как не сломать процесс

Робот — такой же участник процесса, как интеграция, и к нему применимы те же правила надёжности.

1. Вести журнал операций. Кто или что изменил данные, какой автоматический шаг сработал, где возникла ошибка, кто подтвердил переход статуса.
2. Отделить робота от бизнес-логики. Адаптеры внешних систем держат отдельно от правил процесса, чтобы изменение одной системы не ломало весь процесс.
3. Оставить человека на сложных решениях. Для финансовых, юридических и нестандартных случаев система готовит данные, а подтверждает уполномоченный сотрудник.
4. Запускать постепенно. Предусмотреть переходный период и план отката, не переключать все операции разом.

RPA и ИИ

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

Их можно соединить: модель извлекает и структурирует данные из документа, а дальше они уходят в систему по правилам. Где именно ИИ нужен в процессе, разобрали в статье ИИ-автоматизация бизнес-процессов.

RPA в автоматизации бизнес-процессов: с чего начать

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

Частые вопросы