По состоянию на сентябрь 2026 года в России четыре RPA-платформы, которые можно закладывать в проект без риска остаться без поддержки: PIX RPA, Sherpa RPA, ROBIN от SL Soft и Primo RPA. Функционально они близки — у каждой есть среда разработки сценариев, робот-исполнитель и сервер управления парком. Сравнивать их по спискам действий бессмысленно: списки длинные и почти совпадают.
Расходятся они там, где это видно в смете и в отчёте о простоях: единица лицензирования, состав платных модулей, способ привязки к элементам интерфейса, наличие интеллектуальных модулей внутри стека и присутствие в реестре отечественного ПО. Ниже — методика из восьми параметров, применённая ко всем четырём, годовая стоимость лицензий на реальный ландшафт из трёх сценариев и три профиля компаний с подходящим выбором.
Оговорка, без которой этот материал был бы нечестным: цены у всех четырёх вендоров — по запросу и зависят от числа роботов, модулей и срока. Все суммы ниже — ориентиры для планирования бюджета, а не прайс. Сама механика роботов, срок жизни сценария и структура расходов разобраны отдельно в разборе что такое RPA и где он ломается.
Почему сравнение по списку возможностей ничего не даёт
Возьмите три вендорские презентации и попробуйте найти в них пункт, которого нет у остальных. Не найдёте: чтение почты, работа с Excel, запуск по расписанию, распознавание текста, работа в браузере, интеграция с 1С есть у всех. Это не обман — это зрелость рынка: базовый набор действий RPA сложился десять лет назад и с тех пор не меняется.
«Работает с 1С» у одной платформы означает привязку через объектную модель платформы, у другой — поиск кнопки по картинке на экране. Обе строчки в презентации выглядят одинаково, а на дистанции года дают три переделки против шести и разницу в поддержке около 140 000 ₽ на один сценарий. Проверяется это одним экспериментом на стенде, а не чтением буклета.
Поэтому методика ниже устроена иначе: каждый параметр сформулирован как то, что он меняет в деньгах или в числе поломок. Если параметр не меняет ни того, ни другого, его в сравнении нет.
Вторая ловушка — демонстрация на данных вендора. На презентации робот бодро проходит сценарий за полторы минуты, потому что показывают идеальный проход: типовой документ, чистая форма, ни одного исключения. Ваши данные ведут себя иначе, и разница вылезает не на демонстрации, а на второй неделе эксплуатации. Просите не показ, а стенд: свою конфигурацию, свои двести документов, своё худшее приложение. Три дня такой проверки заменяют месяц переговоров и снимают большую часть будущих споров о том, что именно было обещано.
Восемь параметров и что каждый решает
Первые четыре параметра определяют сумму счёта, следующие три — число ремонтов, последний — саму возможность закупки. Порядок не случайный: две трети сюрпризов на приёмке приходятся на первую группу.
| Параметр | На что влияет | Чем измеряется |
|---|---|---|
| Единица лицензирования | Во сколько раз итоговый счёт отличается от «цены за робота»: считают за робота, за одновременно выполняемый процесс или за машину | Сумма в рублях за ваши сценарии, а не за абстрактных роботов |
| Attended и unattended в одной лицензии | Можно ли перевести дневной сценарий в ночной без доплаты. Ночная обработка возможна только на unattended | Разница в цене между двумя типами, ₽/год |
| Лицензия среды разработки | Сколько стоит писать и править сценарии своими силами вместо вызова подрядчика | Стоимость одного рабочего места студии, ₽/год |
| Оркестратор | Расписание, очередь заданий, журнал выполнения, управление учётными записями. Без него парк роботов неуправляем | Отдельная позиция в счёте, ₽/год |
| Привязка к элементам настольных приложений | Число переделок сценария в год: объектная модель окна против координат и картинки | Прогон сценария до и после обновления приложения |
| Работа с 1С | Переживает ли сценарий плановое обновление конфигурации или падает на каждом релизе | Прогон на вашей конфигурации, затем обновление тестового контура и повторный прогон |
| Интеллектуальные модули | Может ли робот читать неструктурированные документы внутри того же стека или нужен внешний контур распознавания | Доля ваших сканов, прошедших без правки человеком, на выборке 200 документов |
| Инфраструктура и реестр отечественного ПО | Требования к машинам, домену и правам, а для госзаказчика — сама допустимость закупки | Число виртуальных машин, лицензии ОС, запись в реестре на дату закупки |
Схема из трёх вертикальных групп. Левая группа «Сумма счёта» — четыре блока: «Единица лицензирования», «Attended и unattended», «Студия разработки», «Оркестратор», под группой подпись «две трети сюрпризов на приёмке». Средняя группа «Число ремонтов» — три блока: «Привязка к элементам», «Работа с 1С», «Интеллектуальные модули», под группой подпись «3 или 6 переделок в год». Правая группа «Допустимость закупки» — один блок: «Инфраструктура и реестр отечественного ПО», под ним подпись «проверяется на дату закупки». От каждой группы стрелка вниз к общему блоку «Решение по платформе». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Лицензирование: как «250 000 ₽» превращаются в миллион
Самая частая ошибка бюджета — взять вилку за одного unattended-робота и умножить на число сценариев. Считаем реальный ландшафт средней компании: три сценария, два из которых работают ночью без человека, третий запускает сотрудник днём по кнопке; один сценарий читает сканы; сценарии правит свой инженер, а не подрядчик.
Разница между 750 000 ₽ («три робота») и 1 070 000 ₽ — это 320 000 ₽ в год на позициях, которых обычно нет в первом коммерческом предложении: оркестратор, студия, модуль распознавания. Ни один вендор их не прячет — просто в презентации показывают робота, а не счёт. Полная смета первого года с разработкой, инфраструктурой и поддержкой разобрана в материале сколько стоит один RPA-робот; там же — почему разброс по рынку такой большой.
Три вопроса, которые задаются до подписания любому из четырёх вендоров. Первый: как считается лицензия — за робота, за одновременно выполняемый процесс или за машину, и что произойдёт, когда три сценария не поместятся в одно ночное окно. Второй: входит ли среда разработки в стоимость исполнителя. Третий: что случится со сценариями при отказе от подписки — останутся ли они у вас в читаемом виде. Ответы просите письмом и приводите предложения разных вендоров к одному составу строк — иначе вы сравниваете не платформы, а формы коммерческих предложений.
Четыре платформы: что можно утверждать без пилота
Ниже — только то, что устойчиво и проверяется публично: состав стека и типовая причина, по которой платформу берут в проект. Всё, что касается точности распознавания на ваших документах и числа падений на вашей 1С, в таблице отсутствует намеренно — эти величины из презентации узнать нельзя.
| Платформа | Состав стека | Типовая причина выбора | Что проверять обязательно |
|---|---|---|---|
| PIX RPA | Студия разработки, робот-исполнитель, оркестратор, инструменты анализа процессов | Зрелость оркестратора и предсказуемость на офисных и настольных сценариях | Модель лицензирования: роботы и сервер управления считаются отдельно |
| Sherpa RPA | RPA вместе с собственным контуром распознавания Sherpa IDP и Sherpa AI Server | Сценарий упирается в чтение неструктурированных документов, нужен один вендор на весь контур | Долю ваших сканов без ручной правки и настройку порога уверенности |
| ROBIN (SL Soft) | Часть большого вендорского стека SL Soft | Совместимость и единое сопровождение с остальными продуктами группы | Условия, на которых платформа берётся отдельно от остального стека вендора |
| Primo RPA | Платформа с ориентацией на корпоративные внедрения и крупный парк роботов | Планируется больше десяти сценариев и управление ими как парком | Требования к инфраструктуре: отдельные машины, домен, права служебных записей |
Отдельный параметр, которого нет в таблице, потому что он не про технику: скорость и предметность ответа вендора на этапе переговоров. Практическое правило простое — как вам отвечают до подписания договора, так будут отвечать и после. Если на письменный вопрос о единице лицензирования приходит ответ «зависит от конфигурации проекта», а на просьбу развернуть стенд — предложение сначала подписать соглашение о намерениях, это тот же уровень поддержки, который вы получите при остановке ночного прогона. Фиксируйте сроки ответов в переписке и переносите их в договор.
Пара PIX и Sherpa — самое частое сравнение на российском рынке, и различие между ними архитектурное: собираете вы стек из частей или берёте целиком у одного вендора. Разбор именно этой пары, включая методику пилота на 6–8 недель, вынесен в отдельный материал PIX RPA или Sherpa RPA. Если ваш сценарий не читает документы, различие между ними в основном сводится к лицензированию.
Сравнение в две колонки. Левая «Единый контур одного вендора»: три соединённых блока «RPA» — «Распознавание документов» — «ИИ-сервер», обведены общей рамкой с подписью «один договор поддержки, один ответственный». Правая «Сборка из частей»: блок «RPA-платформа» и отдельно стоящий блок «Внешний контур распознавания», соединены стрелкой с подписью «интеграция и второй договор». Под обеими колонками одинаковая пометка «доля документов без ручной правки проверяется на 200 своих сканах». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Слабое место общее: настольные приложения и нетиповая 1С
На браузерных системах все четыре платформы ведут себя похоже: у страницы есть структура, элемент находится по имени поля, сценарий переживает перекраску. Расхождение начинается на настольных приложениях — там платформа либо умеет читать объектную модель окна, либо скатывается к координатам и распознаванию картинки.
- Типовая конфигурация 1С — как правило, работает у всех: платформа обращается к объектам формы, а не к точкам экрана. Проверяется на вашей конфигурации, а не на демонстрационной.
- 1С с доработками и нестандартными формами — здесь начинается разница. Управляемая форма, собранная программно, может не отдавать имена элементов, и робот съезжает на координаты со всеми последствиями.
- Отраслевые настольные приложения — медицинские, складские, банковские клиенты, приложения на устаревших графических библиотеках. Самый сложный класс: объектной модели часто нет вообще, и сценарий изначально строится на распознавании изображения.
- Терминальный доступ и удалённый рабочий стол — робот видит не приложение, а картинку сеанса. Объектная модель недоступна по определению, число переделок вырастает вдвое, срок жизни сценария падает.
- Приложения с защитой от автоматизации — банковские кабинеты и часть государственных клиентов прямо противодействуют эмуляции действий пользователя. Проверяется юридически и технически до, а не после выбора платформы.
Практическое следствие: пилот делается на самом неудобном из ваших приложений, а не на самом простом. Сценарий в браузере запустится на любой из четырёх платформ, и такой пилот ничего не покажет. Как эта разница превращается в деньги, посчитано в материале почему роботы ломаются и сколько стоит поддержка: парк из пяти роботов на координатах обходится на 702 000 ₽ в год дороже того же парка на устойчивых селекторах.
Абстрактное окно настольного приложения, разделённое вертикальной линией пополам. Левая половина подписана «объектная модель»: у трёх полей формы выноски с именами «Контрагент», «Дата», «Сумма», от них тонкие линии к блоку «сценарий находит элемент по имени». Правая половина подписана «координаты и картинка»: поверх той же формы наложена координатная сетка, отмечена точка 640 на 380 с выноской «сценарий находит элемент по точке». Под левой половиной подпись «2–3 переделки в год», под правой — «5–8 переделок в год». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Интеллектуальные модули и реестр отечественного ПО
Классический робот работает только со строго одинаковыми формами. Как только в сценарии появляются сканы, PDF и фотографии документов, нужен слой распознавания — и здесь у платформ разная стратегия: у Sherpa он свой (Sherpa IDP), у остальных подключается внешним модулем. Российские контуры распознавания — Content AI, Smart Engines, 1С:Распознавание первичных документов — сравнивались отдельно в обзоре российских OCR-решений.
Правило проверки одно и оно не зависит от вендора: доля документов, прошедших без правки человеком, замеряется на вашей выборке из 200 реальных сканов, а не на демонстрационной. Разница между цифрой из презентации и результатом на своих документах бывает кратной: вендор замерял точность на своей выборке, а работать вы будете на своей.
Наличие продукта в едином реестре российского ПО — не маркетинговая формулировка, а формальное основание для закупки у госзаказчика и у компаний с требованием импортозамещения. Реестровые записи меняются: продукт может быть внесён, переименован, разделён на несколько записей. Проверяется конкретная версия конкретного продукта на дату закупки, и результат сохраняется. Что даёт запись в реестре и кому она обязательна — в разборе реестра отечественного ПО.
Три профиля компаний и подходящий выбор
Выбор платформы почти всегда предопределён профилем компании, а не сравнением функций. Три типичных случая закрывают большую часть запросов.
- 120–60 человек, один-два сценария, кабинеты и бухгалтерия
Здесь платформа почти не имеет значения — важна цена входа. Берут attended-лицензию, сценарии пишет подрядчик, оркестратор не нужен, студия не покупается. Годовой счёт за лицензии и инфраструктуру держится в пределах 150 000–250 000 ₽. И самый частый честный ответ в этом профиле — робот вообще не нужен: сначала проверяются каналы обмена по методике из статьи система без API.
- 260–300 человек, 3–8 сценариев, 1С плюс браузерные кабинеты плюс сканы
Основной профиль для RPA. Нужны unattended-роботы, оркестратор и контур распознавания — это и есть расчёт на 1 070 000 ₽ в год выше. Здесь имеет смысл выбирать между единым стеком одного вендора и сборкой из частей, и решение принимается по тому, насколько критично чтение документов в сценариях.
- 3Госзаказчик или компания с требованием импортозамещения
Список сокращается формальными требованиями раньше технических: запись в реестре на дату закупки, размещение на своих серверах, требования к защите информации. Технические аргументы применяются уже к тому, что осталось. Кому переход на отечественное ПО обязателен и в какие сроки — тема отдельного разбора в журнале.
Три вертикальных столбца с подписями внизу. Первый «20–60 человек, 1–2 сценария» — высота соответствует 150 000–250 000 ₽, сегменты «attended-робот». Второй «60–300 человек, 3–8 сценариев» — 1 070 000 ₽, подписанные сегменты «unattended 500 000», «attended 100 000», «оркестратор 200 000», «студия 120 000», «распознавание 150 000». Третий «Госзаказчик» — столбец нарисован пунктиром без числа, с подписью «состав определяется требованиями закупки, а не техникой». Ось в рублях в год. Чертёжная сетка, приглушённая палитра, подписи по-русски.
Между вторым и третьим профилем есть промежуточный случай, о котором стоит сказать отдельно: компания без требований импортозамещения, но с планом на десять и более сценариев в горизонте двух лет. Здесь на первое место выходит не цена лицензии, а управляемость парка — очередь заданий, приоритеты, поведение при конфликте двух сценариев за одну сессию, качество журнала выполнения. Проверяется это единственным способом: на стенде запускают три сценария в пересекающиеся окна и смотрят, что произойдёт. Платформа, которая на этом эксперименте ведёт себя предсказуемо, сэкономит больше, чем скидка на лицензии.
Когда выбор платформы вообще не имеет значения
Четыре ситуации, в которых сравнение вендоров — потерянное время, потому что решение принимается на уровень выше.
- У системы есть интеграционный контур. Обмен по контракту дешевле робота примерно втрое в эксплуатации и не зависит от чужих релизов. Никакая платформа этого разрыва не закрывает — она может только сделать робота чуть менее хрупким.
- Один сценарий на всю компанию. При одном процессе счёт определяется не платформой, а тем, кто пишет сценарий. Разница между вендорами в годовом счёте здесь 30 000–60 000 ₽ — меньше стоимости одной переделки.
- Объём операции ниже порога окупаемости. Порог начинается с 40 часов ручной работы в месяц при ставке 700 ₽/час и доходит до 83 часов для активно развивающихся порталов. Ниже него не окупается ни одна платформа, и выбор вендора становится выбором способа потратить деньги.
- Процесс не описан и меняется на ходу. Сценарий переписывается вместе с процессом. Сначала процесс стабилизируют и фиксируют регламентом, потом выбирают платформу — обратный порядок даёт четыре разработки в год на одном месте.
И последнее правило, которое экономит больше всего денег. Пилот делается на своём худшем приложении, на своих реальных документах и на своей конфигурации 1С, и длится 6–8 недель. Всё, что можно узнать из презентации, вы уже знаете: у всех четырёх есть студия, робот и оркестратор. Всё, что определяет стоимость владения, узнаётся только на стенде.
