RPA (Robotic Process Automation) — это программа, которая выполняет операции в пользовательском интерфейсе так же, как это делал бы человек: открывает окно, находит поле, вводит значение, нажимает кнопку, копирует результат в другое приложение. Она работает не с данными, а с экраном. Никакого искусственного интеллекта в классическом RPA нет: сценарий — это записанная и отлаженная последовательность действий, и робот повторяет её буквально, пока экран выглядит так, как в момент записи.
Из этого одного факта следует всё остальное. Робот запускается быстро, потому что ему не нужны ни разрешение владельца системы, ни доступ к её внутренностям — достаточно учётной записи обычного пользователя. Он же и ломается быстро, потому что интерфейс для того и существует, чтобы меняться: дизайнер переставил поля, вендор выкатил релиз, ИТ-служба обновила браузер — и сценарий, который вчера отрабатывал за ночь 600 документов, сегодня стоит на первом же шаге.
Дальше — механика: как именно робот находит кнопку и почему одни способы привязки живут годами, а другие ломаются от смены шрифта. Затем разница с интеграцией по четырём осям, две модели лицензирования, четыре российские платформы и расчёт месяца владения роботом в трёх сценариях. В конце — пять задач, где робот оправдан почти всегда, пять, где это ошибка, и раздел о том, когда не надо ставить робота вообще.
Робот — это сотрудник, который кликает по экрану
Программная роботизация: автоматизация операций через пользовательский интерфейс, без доступа к данным системы напрямую. Робот не знает, что такое заказ, накладная или контрагент, — он знает последовательность действий и признаки, по которым находит на экране нужный элемент. Поэтому он работает с любой системой, у которой есть окно, и зависит от каждого изменения этого окна.
Полезно держать в голове бытовую аналогию, потому что она предсказывает поведение робота точнее любого описания вендора. Робот — это очень исполнительный стажёр, которого научили одной операции показом. Он не устаёт, не отвлекается и не ошибается в рутине. Но он и не понимает, что делает: если форма изменилась, он не догадается поискать кнопку рядом; если в поле «сумма» пришёл текст, он введёт текст; если система показала предупреждение, которого не было при обучении, он либо остановится, либо нажмёт «ОК» и продолжит вводить данные не туда.
Отсюда сразу два практических следствия. Первое: робота нельзя оценивать по демонстрации — на демонстрации всегда показывают идеальный путь без исключений. Второе: любой сценарий должен заканчиваться проверкой результата, а не фактом «робот отработал». Проверка — это отдельная строка сметы и отдельная строка регламента, и именно её чаще всего вырезают ради экономии, а потом обнаруживают расхождение в конце месяца.
Робот автоматизирует не процесс, а способ, которым человек обходил отсутствие интеграции.
Как робот находит кнопку: три способа привязки
Всё поведение робота в бою определяется тем, как он опознаёт элемент на экране. Способов ровно три, они отличаются устойчивостью на порядок, и хороший подрядчик расписывает их долю в сценарии ещё в техническом задании. Плохой — не расписывает, и вы узнаёте о доле координатных привязок через полгода, когда в компании поменяли масштаб интерфейса и робот начал нажимать соседнюю кнопку.
- 1Селектор элемента — самый устойчивый
Робот обращается к элементу по его имени или идентификатору в дереве интерфейса: «поле с именем ContractNumber в форме DocumentEdit». Такая привязка переживает смену шрифта, темы, разрешения экрана и перестановку блоков — до тех пор, пока разработчик не переименовал сам элемент. Работает в браузере и в приложениях, которые отдают дерево интерфейса операционной системе. Это тот случай, когда сценарий живёт годами.
- 2Координаты точки — самый хрупкий
«Нажать в точке 640 на 480 от левого верхнего угла окна». Применяется там, где дерева интерфейса нет: часть настольных приложений, окна на технологиях отрисовки без доступной разметки, удалённые сессии, картинка с камеры терминала. Ломается от всего: другое разрешение, другой масштаб системы, лишняя панель, окно открылось не в том же месте. Координатные привязки допустимы точечно, но их доля в сценарии — это прямой прогноз частоты поломок.
- 3Распознавание изображения — между ними
Робот ищет на экране картинку кнопки, которую ему показали при записи, и нажимает в её центре. Устойчив к перемещению элемента, но ломается от смены шрифта, темы оформления, сглаживания и масштаба — то есть от вещей, которые ИТ-служба меняет, не считая это изменением. Отдельно стоит распознавание текста прямо с экрана: им читают значения, которые нельзя достать из дерева, и это самая медленная и самая ошибкоопасная часть любого сценария.
Схема из трёх горизонтальных дорожек. Слева в каждой — иконка способа, справа — одинаковое схематичное окно программы с полем и кнопкой «Провести». Дорожка 1 «Селектор элемента»: стрелка идёт к кнопке через дерево из трёх узлов с подписью «имя элемента», сбоку метка «срок жизни 24–48 месяцев». Дорожка 2 «Координаты точки»: стрелка идёт к перекрестью с подписью «640 × 480», сбоку метка «срок жизни 6–12 месяцев». Дорожка 3 «Распознавание картинки»: стрелка идёт к прямоугольной рамке вокруг кнопки с подписью «образец», сбоку метка «ломается от смены шрифта». Приглушённая палитра, чертёжная штриховка, подписи по-русски.
Практический вывод для переговоров с подрядчиком простой. В техническом задании должно быть написано, что привязка делается по селекторам элементов, а координаты и распознавание картинок применяются только там, где иначе нельзя, с перечислением этих мест. Это одна строка, но именно она отделяет сценарий, который переживёт два обновления, от сценария, который придётся переписывать после первого. Подробнее про формулировки для договора — в отдельном разборе про хрупкость роботов и стоимость поддержки.
RPA против интеграции: четыре оси сравнения
Интеграция по API работает на другом слое: система отдаёт заказ, документ или остаток в машинном формате, и обмен не зависит от того, как этот заказ нарисован на экране. Контракт данных вендор меняет редко, обычно с предупреждением и с сохранением обратной совместимости, — интерфейс меняют когда угодно и без объяснений. Всё остальное — производные от этой разницы.
| Ось сравнения | RPA-робот | Интеграция по API |
|---|---|---|
| Срок запуска | 3–5 недель: сценарий пишется по экранам, доступ уже есть | 6–12 недель: обследование, согласование доступов, разработка, тесты |
| Надёжность | Ломается при изменении интерфейса; в среднем 3 переделки в год на активной системе | Ломается при изменении контракта данных — редко и с предупреждением |
| Цена первого года | Дешевле на старте, дороже в эксплуатации: лицензия, машина, переделки | Дороже на старте, почти без переменной части дальше |
| Стоимость изменения процесса | Переписывание участка сценария: обычно 20 000–40 000 ₽ за эпизод | Правка одного обработчика, часто силами своей ИТ-службы |
| Скорость работы | Как у человека: по одному окну за раз, рост объёма требует второго робота | Ограничена лимитами смежной системы, объём растёт без новых копий |
| Нужно разрешение владельца системы | Нет, достаточно учётной записи пользователя | Да, нужны доступы и согласованный контур |
Строка про разрешение владельца системы объясняет, почему роботов покупают чаще, чем они нужны. Интеграция требует переговоров: с вендором, со своей ИТ-службой, со службой безопасности. Робот не требует ничего — его можно запустить на машине в бухгалтерии в обход всех согласований. Это не техническое преимущество, а организационное, и цена у него отложенная: расходы на переделки начинаются со второго квартала и дальше идут постоянно.
Парная столбиковая диаграмма по четырём осям, для каждой оси два столбца: тёмный «робот» и светлый «интеграция». Ось 1 «Срок запуска, недель»: робот 4, интеграция 9. Ось 2 «Переделок в год»: робот 3, интеграция 0,5. Ось 3 «Владение, тысяч рублей в месяц»: робот 38,6, интеграция 23,4. Ось 4 «Порог окупаемости, часов ручной работы в месяц»: робот 56, интеграция 33. Под осью 1 подпись «здесь робот выигрывает». Приглушённая палитра, чертёжная сетка, подписи по-русски.
Полное сравнение стоимости владения на трёхлетнем горизонте, с точкой перелома и с расчётом переплаты за крюк «сначала робот, потом интеграция», разобрано в отдельном материале про выбор между RPA и обменом через API. Короткий вывод оттуда: робот дешевле на старте примерно на 260 000 ₽ и отдаёт эту экономию обратно за восемь месяцев. Здесь важнее другое — понимать, что вы выбираете не между двумя технологиями, а между работой с данными и работой с картинкой данных.
Attended и unattended: разница в лицензии и в применении
Роботы делятся на два вида, и путаница между ними — источник половины неприятных сюрпризов в смете. Attended-робот работает на машине сотрудника и в его сессии: человек нажимает кнопку, робот делает свою часть, человек проверяет и продолжает. Unattended-робот работает сам, на отдельной машине, по расписанию или по событию, под собственной учётной записью, и человек его в норме не видит.
| Параметр | Attended | Unattended |
|---|---|---|
| Где выполняется | На рабочей машине сотрудника, в его сессии | На отдельной виртуальной машине, круглосуточно |
| Кто запускает | Человек кнопкой или горячей клавишей | Расписание, событие в системе, очередь заданий |
| Учётная запись | Личная запись сотрудника — и в этом главный риск | Отдельная служебная запись с правами под операцию |
| Ориентир по лицензии | Примерно вдвое дешевле unattended | 150 000–400 000 ₽ в год за одного робота |
| Нужен оркестратор | Нет, пока роботов единицы | Да, начиная с трёх-четырёх роботов |
| Типичная задача | Помощник оператора: подготовить карточку, собрать данные к звонку | Ночной перенос документов, выгрузка отчётов, ввод в портал |
Сотрудник уходит в отпуск, меняет пароль по требованию политики безопасности или увольняется — и парк роботов встаёт целиком. Хуже другое: все действия робота в журнале системы выглядят как действия этого человека, и при разборе ошибки отвечать будет он. Служебная учётная запись с правами ровно под операцию — обязательное требование к проекту, а не пожелание.
Практическое правило выбора: attended берут, когда в операции остаётся человеческое решение и робот снимает только механическую часть; unattended — когда решение принимать не нужно и всю операцию можно выполнить ночью. Смешанный вариант — «робот готовит, человек подтверждает» — на практике самый частый и самый живучий, потому что человек в контуре ловит те самые исключения, из-за которых чисто автоматические сценарии останавливаются.
Российские платформы на 2026 год
На сентябрь 2026 года в России четыре платформы, которые можно закладывать в проект без риска остаться без поддержки: PIX RPA, Sherpa RPA, ROBIN от SL Soft и Primo RPA. Функционально они близки: у каждой есть среда разработки сценариев, робот-исполнитель и сервер управления парком. Различия начинаются в лицензировании, в работе с конкретными приложениями и в наличии интеллектуальных модулей.
| Платформа | На что смотреть при выборе |
|---|---|
| PIX RPA | Зрелая платформа с полным набором: студия, оркестратор, инструменты анализа процессов. Проверяйте модель лицензирования — счёт складывается из роботов и сервера управления отдельно |
| Sherpa RPA | Отличается связкой с собственным модулем интеллектуальной обработки документов Sherpa IDP. Имеет смысл, если робот должен читать неструктурированную первичку, а не только переносить поля |
| ROBIN (SL Soft) | Часть большого российского вендорского стека. Плюс — сопровождение и совместимость с остальными продуктами группы, минус — платформу редко берут изолированно от него |
| Primo RPA | Ориентирована на корпоративные внедрения с крупным парком роботов. Смотрите требования к инфраструктуре: отдельные машины, домен, права служебных записей |
Три вещи, которые стоит выяснить до подписания, независимо от выбранного вендора. Первая: как считается лицензия — за робота, за одновременно выполняемый процесс или за машину, и входит ли в неё среда разработки. Вторая: включён ли конкретный продукт в реестр отечественного ПО на дату закупки — реестровые записи меняются, и для госзаказчика это блокер, а не формальность. Третья: что происходит с вашими сценариями при отказе от подписки — останутся ли они у вас в читаемом виде или превратятся в набор, который нельзя открыть.
Схема из четырёх блоков со стрелками. Слева блок «Студия разработки» — рисование и отладка сценария. Стрелка вниз к центральному блоку «Оркестратор» с подписями «расписание, очередь заданий, учётные записи». От оркестратора три стрелки вправо к блокам «Робот 1», «Робот 2», «Робот 3», каждый на своей виртуальной машине. От роботов стрелки вниз к блоку «Журнал выполнения» с подписью «что сделано и где остановились». Пунктирной рамкой обведены оркестратор и роботы, у рамки подпись «чаще всего лицензируется отдельно». Приглушённая палитра, чертёжная штриховка, подписи по-русски.
Пять задач, где робот почти всегда оправдан
Общий признак у всех пяти один: интеграции нет не потому, что её не сделали, а потому, что её нельзя сделать — система не ваша, вендора нет, или процесс закончится раньше, чем окупится нормальная разработка.
- 1Перенос данных в закрытую систему контрагента
Портал клиента, кабинет заказчика, площадка, у которой нет интеграционного контура для поставщиков. Вы не можете потребовать API у чужой компании, а вводить туда по 200 строк в неделю руками — это полторы ставки. Робот здесь не компромисс, а единственный способ.
- 2Операции в госсистеме, которые не покрыты штатным обменом
Часть операций в ЕГАИС, ФГИС «Меркурий» и Честном знаке делается только через личный кабинет. Там, где штатный обмен есть, его берут всегда; там, где его нет, остаётся робот — с обязательным регламентом реакции на смену формы.
- 3Регулярная выгрузка отчётов из кабинета без API
Банк-клиент, кабинет маркетплейса, личный кабинет оператора связи. Задача узкая, стабильная и хорошо описываемая: зайти, выбрать период, скачать файл, положить в папку. Такие сценарии живут дольше остальных, потому что задевают минимум экранов.
- 4Процесс с известной датой окончания
Миграция между системами, разбор архива после слияния, сезонная кампания, разовая сверка за три года. Сценарий пишется на срок, окупается объёмом и выключается. Интеграцию под такую задачу делать дороже, чем терпеть её отсутствие.
- 5Мост на 6–12 месяцев, пока делается настоящая интеграция
Боль есть сейчас, доступы согласуются месяцами. Робот закрывает разрыв — при одном условии: дата вывода его из эксплуатации записана в договоре. Без этой даты мост становится постоянным сооружением и переплата уходит за миллион.
Пять задач, где робот — ошибка
- 1Между своими системами, у которых обмен есть
Самый частый случай и самый дорогой. 1С, CRM и сайт умеют обмениваться данными штатно; робота ставят не потому, что нельзя иначе, а потому, что согласовать доступы дольше, чем поставить робота. Через два года компания платит за это ежемесячно.
- 2Процесс с большой долей исключений
Робот уверенно тянет типовые 60–70 % случаев, остальное всё равно уходит человеку. Проблема в том, что разбор нетиповых случаев после робота обычно дороже, чем обработка их же в общем потоке: человек теряет контекст и перепроверяет то, что робот уже сделал.
- 3Процесс, который меняется каждый квартал
Сценарий не успевает окупить собственное переписывание. Если регламент операции за последний год правился больше двух раз, робот будет догонять изменения, а не экономить время. Сначала процесс стабилизируют, потом автоматизируют.
- 4Операция объёмом меньше 40 часов в месяц
Ниже этого порога владение роботом дороже самой ручной работы при любом разумном варианте — расчёт ниже. Здесь работают регламент, шаблон, готовая выгрузка в файл или просто отмена лишнего шага.
- 5Место, где решение принимает человек
Согласование скидки, выбор проводки, налоговый расчёт, разбор спорной претензии. Робот может подготовить данные к решению, но не принять его: у него нет ответственности, а у компании — способа объяснить проверяющему, почему решение выглядит именно так.
Две вертикальные колонки. Левая с заголовком «Робот оправдан», пять строк с короткими подписями: «закрытая система контрагента», «операции в госсистеме без обмена», «выгрузка отчётов из кабинета», «процесс с датой окончания», «мост на 6–12 месяцев». Правая с заголовком «Робот — ошибка», пять строк: «свои системы, обмен есть», «много исключений», «процесс меняется каждый квартал», «меньше 40 часов в месяц», «решение принимает человек». Между колонками вертикальная разделительная линия с подписью «вопрос: интеграцию нельзя сделать или её не сделали». Приглушённая палитра, чертёжная штриховка, подписи по-русски.
Сколько живёт робот и сколько стоит месяц его жизни
Срок жизни сценария — главная величина в экономике RPA, и её почти никогда не называют на этапе продажи. Считать надо не «сколько стоит внедрение», а «сколько месяцев этот сценарий проработает до переписывания». По нашим оценкам, медиана — около 20 месяцев, а разброс по типам автоматизируемых систем трёхкратный.
- Внутренняя система с замороженным интерфейсом, которую компания сознательно не обновляет: 3–5 лет
- Типовая 1С с регулярными обновлениями конфигурации: 18–30 месяцев
- Корпоративная браузерная система своей компании — CRM, портал, внутренний сервис: 15–24 месяца
- Госпортал: Честный знак, ЕГАИС, ФГИС «Меркурий» — 9–15 месяцев
- Портал вендора, кабинет банка, маркетплейс с частыми релизами: 6–12 месяцев
Горизонтальная диаграмма-диапазон: пять полос разной длины по оси «месяцы» от 0 до 60. Сверху вниз: «Замороженная внутренняя система» 36–60; «Типовая 1С» 18–30; «Корпоративная браузерная система» 15–24; «Госпортал: Честный знак, ЕГАИС, Меркурий» 9–15; «Портал вендора, кабинет банка, маркетплейс» 6–12. Вертикальная штриховая линия на отметке 20 месяцев с подписью «медиана». Приглушённая палитра, чертёжная сетка, подписи по-русски.
Теперь месяц владения. Считаем один unattended-робот, который переносит документы между корпоративной браузерной системой и учётной системой: разработка сценария 180 000 ₽, срок жизни 24 месяца, лицензия 180 000 ₽ в год, три переделки в год по 30 000 ₽, восемь часов ручного добора в месяц по 700 ₽ — потому что вставший ночью робот обнаруживается утром, и документы за ночь кто-то вводит руками.
Та же арифметика для двух других профилей даёт разброс более чем вдвое. На замороженной внутренней системе срок жизни 48 месяцев, одна переделка в год и пять часов простоев — владение выходит 27 750 ₽ в месяц и порог в 40 часов. На портале вендора срок жизни 12 месяцев, шесть переделок в год и четырнадцать часов простоев — 57 800 ₽ в месяц и порог в 83 часа. Тот же порядок величин получается и в отдельном разборе стоимости владения роботом против интеграции: около 57 500 ₽ в месяц и 82 часа порога для активно развивающегося портала.
| Автоматизируемая система | Срок жизни сценария | Переделок в год | Владение, ₽/мес | Порог, ч/мес |
|---|---|---|---|---|
| Замороженная внутренняя система | 48 месяцев | 1 | 27 750 ₽ | 40 |
| Типовая 1С или корпоративный браузерный сервис | 24 месяца | 3 | 38 600 ₽ | 56 |
| Портал вендора, кабинет банка, площадка | 12 месяцев | 6 | 57 800 ₽ | 83 |
«У нас 3 000 документов в месяц» — это не аргумент. Аргумент — сколько часов на них уходит: 3 000 документов по 40 секунд это 33 часа, и робот на них не окупится ни при какой платформе. Первый вопрос перед проектом всегда один: сколько часов в месяц занимает операция и по какой ставке считается час с налогами.
Что нужно от компании до старта
Робот не терпит неопределённости: то, что человек делает «по ситуации», сценарий обязан делать одинаково. Поэтому подготовка к роботизации — это на две трети работа с процессом и на треть работа с доступами. Шесть пунктов ниже — то, без чего проект уходит в переделки на этапе приёмки.
- 1Процесс, описанный по шагам, с исключениями и их долей
Не «менеджер заносит заявку», а последовательность экранов и полей, плюс список нетиповых случаев с оценкой доли. Если доля исключений выше 25 %, до разработки стоит упростить сам процесс — иначе платите за сценарий, который закрывает три четверти работы.
- 2Служебная учётная запись и права ровно под операцию
Отдельная запись для робота, не личный логин сотрудника. Права выдаются под конкретные действия, а не «как у главного бухгалтера». Заранее решается вопрос смены пароля по политике безопасности: она не должна останавливать парк.
- 3Тестовый контур или тестовый объект в боевой системе
Отлаживать на боевой базе нельзя: первый же неверный клик создаёт документ, который потом ищут и сторнируют. Если тестового контура нет физически, договариваются о тестовом контрагенте, складе или периоде, в которых допустим мусор.
- 4Владелец процесса с именем и телефоном
Человек, который принимает результат, отвечает на вопросы про исключения и получает уведомление, когда робот встал. Проекты без владельца процесса — самая частая причина, по которой робот работает три месяца, а потом тихо останавливается.
- 5Договорённость об уведомлении при обновлениях
Со своей ИТ-службой — обязательно: обновление браузера, смена политики экрана и переезд на другой сервер планируются заранее. С вендором автоматизируемой системы — по возможности: подписка на release notes и статус-страницу стоит ноль и даёт день форы.
- 6Способ проверить результат, не пересчитывая всё заново
Контрольная сумма, сверка количества строк, отчёт «сколько принято и сколько проведено». Проверка встраивается в сценарий и делает поломку заметной в тот же день, а не в конце месяца, когда расхождение уже разъехалось по отчётности.
Горизонтальная лента из шести отметок слева направо, каждая с подписью сверху и результатом снизу. Отметки: «Процесс по шагам» — результат «доля исключений в процентах»; «Служебная учётная запись» — «права под операцию»; «Тестовый контур» — «место, где допустим мусор»; «Владелец процесса» — «имя и телефон»; «Уведомление об обновлениях» — «день форы»; «Проверка результата» — «поломка видна в тот же день». Первые пять отметок объединены скобкой сверху с подписью «делается силами компании». Приглушённая палитра, чертёжная штриховка, подписи по-русски.
Многое из этого списка нужно и для обычной интеграции — например, описанный процесс и владелец. Разница в том, что интеграция прощает неточности, а робот нет: обмен данными переживёт перестановку колонок в отчёте, сценарий робота — не переживёт. Поэтому подготовка к роботизации дороже подготовки к интеграции, и эту разницу тоже стоит держать в смете, а не открывать её на третьей неделе проекта.
Когда не надо ставить робота вообще
Есть четыре ситуации, в которых честный ответ — не выбирать между роботом и интеграцией, а не автоматизировать. Они встречаются чаще, чем хотелось бы вендорам, и распознаются за час.
- 1Объём меньше порога. При ставке 700 ₽/час и владении от 27 750 ₽ в месяц робот не окупается ниже 40 часов ручной работы в месяц ни при каких платформах и скидках. Ниже этой отметки дешевле регламент, шаблон или отмена лишнего согласования.
- 2Процесс существует по инерции. Прежде чем автоматизировать сбор отчёта, стоит спросить, кто его читает. Регулярно выясняется, что отчёт не открывали полгода, и вместо робота за 240 000 ₽ достаточно письма об отмене.
- 3Систему меняют в ближайший год. Если в планах переход на другую учётную систему, сценарий не доживёт до окупаемости: он привязан к экранам, которых через восемь месяцев не будет. Ждать неприятно, но дешевле.
- 4Нет владельца процесса. Робот без человека, который получает уведомление о сбое и отвечает за результат, останавливается в среднем на третьем-четвёртом месяце и обнаруживается это не сразу. Это не техническая проблема, и подрядчик её не решает.
И последнее, что стоит сказать прямо, потому что это позиция бюро, а не общая мысль. Робот — это костыль, и в этом нет ничего оскорбительного: костыль иногда единственный способ связать систему, у которой нет и не будет обмена данными. Проблема начинается там, где костыль ставят вместо нормальной интеграции, потому что так быстрее согласовать. Первый шаг любого проекта роботизации — не выбор платформы, а письменная проверка того, существует ли у смежной системы интеграционный контур. Как эта проверка делается за один день и где обмен находится там, где «API нет», разобрано в отдельном материале про системы без API. День на неё стоит ноль и регулярно экономит сумму с шестью нулями.
