RPA — это программа, которая работает в чужом интерфейсе вместо человека: открывает окно, находит поле, вводит значение, нажимает кнопку. Она нужна там, где нормального программного доступа к системе нет, и оправдана ровно при трёх условиях: источник закрыт, доступ к нему получить нельзя или дороже робота, а задача живёт недолго. Во всех остальных случаях робот — это способ сделать неудобный процесс терпимым и тем самым оставить его навсегда.
У класса две репутации, и обе заслуженные. Инженеры относятся к RPA плохо, потому что видели, как сценарий встаёт после перерисовки формы в пятницу вечером. Продавцы относятся хорошо, потому что робота можно показать через две недели, без согласований с владельцем чужой системы и без интеграционного проекта. Обе стороны правы, просто говорят о разных горизонтах: демонстрация действительно занимает две недели, а расплата наступает на втором году.
Класс систем, которые воспроизводят действия человека в интерфейсах других программ: браузере, клиенте учётной системы, личном кабинете портала. К искусственному интеллекту отношения не имеет — робот не понимает, что такое накладная, он знает координаты поля. Механика привязки к экрану и разница с интеграцией разобраны в материале что такое RPA и чем оно отличается от интеграции.
Чем RPA отличается от всех остальных классов
Разница не в функциях, а в том, чем класс владеет. У каждой системы в контуре есть предметная область — сущность, за которую она отвечает и которую хранит у себя. У RPA такой сущности нет. Это единственный класс, который ничего не хранит и ничем не управляет, и из этого одного факта следуют и его сильные стороны, и все его проблемы.
| Класс | Чем владеет | Что останется, если систему выключить |
|---|---|---|
| CRM | Карточка клиента, история касаний, этапы сделки | База клиентов и переписка — их можно выгрузить |
| ERP | План, остатки, себестоимость, проводки | Учётные данные, по которым работает бухгалтерия |
| WMS | Ячейка, партия, маршрут отбора | Адресное хозяйство склада и история движений |
| СЭД | Маршрут согласования, регистрация, архив | Документы и следы согласований |
| BI | Определение показателя и витрина данных | Формулы расчёта и сами данные в источниках |
| RPA | Ничего собственного | Ровно та же ручная работа, что была до |
Отсюда практическое следствие, которое экономит месяц обсуждений: вопрос «CRM или RPA» бессмысленен. Робот не альтернатива классу, он протез к чужому интерфейсу. Его не выбирают вместо системы — его ставят там, где система есть, но она не ваша и наружу ничего не отдаёт.
Схема в чертёжном стиле. В нижнем ряду три блока с подписями «CRM», «ERP», «WMS», под каждым нарисован цилиндр-хранилище с подписью сущности: «клиент», «остаток», «ячейка». Выше — узкая полоса с подписью «RPA», от неё стрелки идут не в хранилища, а к нарисованным экранам с формами ввода; под полосой RPA хранилища нет, вместо него пустая рамка с подписью «своих данных нет». Сбоку вынос: «протез к чужому интерфейсу, а не орган контура». Подписи по-русски.
Три условия, при которых робот честен
Решение принимается не по списку задач, а по трём проверкам. Они занимают полдня и отвечают на вопрос, который в коммерческом предложении не задают.
- 1Источник закрыт, и закрываете его не вы. Государственный портал, личный кабинет банка, система контрагента, кабинет площадки. Вы не влияете ни на интерфейс, ни на сроки его изменения. Если речь о вашей собственной системе, условие не выполняется: там правильный путь — доработка или обмен, и это отдельный разбор.
- 2Программного доступа нет или он дороже робота. Бывает, что API есть, но продаётся отдельным тарифом, требует сертификации или партнёрского статуса. Тогда сравнивают деньгами, а не принципами: методика сравнения — в материале RPA или интеграция по API.
- 3Горизонт задачи короче срока жизни сценария. Переезд между системами, параллельная работа старой и новой, отчётная кампания, разовая выверка за прошлый период. Робот на полгода — нормальное инженерное решение. Робот навсегда — это заявка на то, что чужой интерфейс не изменится никогда.
Выполняются все три — робот честен, ставьте. Выполняются два — считайте обе сметы на горизонте трёх лет и выбирайте по деньгам, а не по скорости запуска. Выполняется одно — почти наверняка есть путь дешевле: выгрузка файлом, доработка своей системы, изменение самого процесса.
Как робот закрепляет плохой процесс
Это главное возражение против класса, и оно не техническое. Плохой процесс держится на том, что кому-то больно. Боль — единственный двигатель, из-за которого руководитель однажды звонит поставщику и просит присылать не письмо с таблицей в теле, а файл. Робот снимает боль за две недели. Звонок не случается никогда.
Дальше происходит подмена, которую сложно заметить изнутри: процесс больше не выглядит проблемой, потому что им занят не человек, а подрядчик. Строка расходов переезжает из фонда оплаты труда в договор сопровождения и перестаёт попадаться на глаза. Через три года выясняется, что компания платила за обход препятствия, которое можно было убрать одним разговором.
Считаем на модели. Оптовая компания, 60 человек. Поставщик присылает отчёт о реализации таблицей в личном кабинете; оператор переносит строки в учётную систему — 32 часа в месяц. Вариант первый: робот забирает данные с экрана. Вариант второй: договориться с поставщиком о выгрузке файлом в согласованном формате и научить учётную систему его принимать.
Мы не утверждаем, что выгрузку дадут всегда. Утверждение другое: пока робот работает, об этом никто не спрашивает. Поэтому правило приёмки такое — прежде чем подписывать сценарий, надо получить письменный отказ владельца источника. Не устный на встрече, а письмо с ответом «выгрузки не будет». Эта бумага стоит одного письма и отделяет робота-инструмента от робота-обхода.
График накопленных расходов за 36 месяцев. Горизонтальная ось — месяцы от 0 до 36, вертикальная — рубли. Верхняя линия «робот» стартует с 240 000 ₽ и растёт по 28 000 ₽ в месяц до 1 248 000 ₽. Нижняя линия «выгрузка из источника» стартует с 120 000 ₽ и растёт по 3 000 ₽ в месяц до 228 000 ₽. Между конечными точками вертикальная выноска с подписью «1 020 000 ₽». Внизу вводные: «оптовая компания 60 человек, 32 часа ручного переноса в месяц». Чертёжный стиль, подписи по-русски.
Стоимость владения: три строки, которых нет в предложении
Порог входа у класса низкий, и в этом ловушка: смета внедрения честная, а смета жизни — нет. Три статьи появляются после запуска и не зависят от качества работы подрядчика.
- Починка после изменения интерфейса. Сценарий привязан к экрану, и любая перерисовка формы на стороне источника останавливает робота. Частота зависит не от вас: у замороженной внутренней системы это раз в год, у портала внешнего поставщика — раз в квартал и чаще.
- Наблюдение за очередью. Робот падает молча и в неудобное время. Нужен тот, кто увидит остановку в тот же день, а не на закрытии месяца, — и это отдельная функция, а не строчка в должностной инструкции бухгалтера.
- Разбор исключений. Робот проходит типовой путь и останавливается на всём нетиповом. Доля исключений редко опускается ниже 5–10 % потока, и эти случаи всё равно разбирает человек — значит, ручная работа уходит не полностью.
Считать надо не год, а срок жизни сценария — время до момента, когда его придётся переписывать целиком. У сценария на внутренней замороженной системе это годы, на портале внешнего вендора — месяцы. Бюджет, посчитанный на три года без переписывания, всегда занижен; типовые ошибки таких расчётов собраны в материале ошибки внедрения RPA.
Российские платформы и что у них спрашивать
На сентябрь 2026 года на российском рынке работают PIX RPA, Sherpa RPA и Primo RPA. Это порядок величин по составу рынка, а не рекомендация: набор живых платформ меняется, и сравнивать их надо на своём сценарии, а не по описаниям. Подробный разбор — в материале сравнение российских RPA-платформ.
Вопросы, которые отличают рабочее предложение от презентации, задаются до договора и касаются не функций, а поведения робота в плохие дни.
- Что произойдёт, когда форма на стороне источника изменится: кто узнает первым, за сколько часов чинится, входит ли починка в абонент или считается новой работой.
- Как робот ведёт себя при частичном сбое — остановится на середине пакета или доведёт до конца и оставит половину записей задвоенными.
- Где лежит журнал действий и можно ли по нему восстановить, что именно робот сделал в конкретный день. Без этого разбор расхождения превращается в гадание.
- Что происходит с паролями и подписями: под чьей учётной записью работает робот и как это выглядит с точки зрения разграничения прав сотрудников.
Когда робота ставить не надо
Четыре ситуации, в которых мы отговариваем, даже если задача формально решается роботом и деньги на неё есть.
- Источник ваш. Если систему, по которой будет кликать робот, вы можете доработать или заменить, робот здесь лишний слой. Дешевле обмен или доработка, даже если она выглядит дольше на старте.
- Процесс меняется чаще, чем раз в квартал. Сценарий переписывается под каждое изменение, и вы платите за поддержание в рабочем состоянии того, что и так нестабильно.
- Объём меньше порога. Если процесс занимает меньше двух-трёх десятков часов в месяц, робот не покроет даже собственное сопровождение. Границу по объёму мы считали отдельно — когда робот не нужен.
- Проблема в данных, а не в действиях. Если половина времени уходит на выяснение, какая позиция поставщика соответствует вашей, робот воспроизведёт ту же неопределённость быстрее и тише. Сначала справочники, потом автоматизация: как это делается — в материале синхронизация справочников между системами.
Робот — это инструмент доступа туда, куда вас не пустили. Если вас туда пустили, инструмент лишний.
