Шесть российских RPA‑платформ, более 300 критериев и тысячи страниц документации. В начале исследования мы ожидали увидеть привычный для enterprise‑рынка разрыв между несколькими лидерами и остальными участниками. Вместо этого обнаружили сформировавшееся ядро зрелых платформ, каждая из которых способна работать в крупном корпоративном контуре.
Это не значит, что продукты одинаковы. Наоборот, различия есть, но искать их нужно не в базовом списке функций. Они проявляются в архитектуре, эксплуатации, требованиях к команде, работе с отечественной инфраструктурой, ИИ‑возможностях и полной стоимости владения.
В конце июля июля мы опубликовали исследование «RPA Круг Громова 2026». В этой статье расскажу, как мы его делали, какие гипотезы не подтвердились и на что смотреть заказчику, если пункт «умеет создавать программных роботов» уже ничего не объясняет.
Почему взялись за RPA
Начиналось все банально. В течение года к нам несколько раз приходили заказчики с одним и тем же вопросом: как выбрать российскую RPA‑платформу для крупной организации. Причём сделать это, не опираясь только на презентацию вендора или результаты одного удачного пилота. Люди искали более рациональный подход: с учётом промышленной эксплуатации, закрытых контуров, безопасности, DevOps, кадров и экономики.
На первый взгляд, задача казалась не слишком сложно. RPA существует давно, класс решений хорошо описан, а отечественные продукты уже успели пройти волну импортозамещения. Но чем глубже мы погружались, тем меньше пользы приносило обычное сравнение функций. Почти у всех есть решений есть студия, оркестратор, attended‑ и unattended‑роботы, интеграции, OCR и средства централизованного управления. Но хоть галочки в списке опций совпадают, часто не совпадали реализация и последствия выбора.
Поэтому мы отказались от идеи сделать таблицу «есть или нет». Мы решили, что исследование должно ответить на другой вопрос: насколько полно реализована каждая возможность, чем она подтверждается и пригодна ли платформа для конкретной модели эксплуатации.
Кого исследовали
В основной сравнительный контур вошли шесть платформ:
PIX RPA
ROBIN
АТОМ.РИТА
Sherpa RPA
OneRPA
Puzzle RPA
При этом Primo RPA, Lexema‑RPA и GigaARPA описаны отдельно, в разделе платформ вне Круга. Такой формат позволил не смешивать результаты полного исследовательского цикла с профилями, собранными при других объёмах доступных материалов и взаимодействия.
Мы не ставили целью выявление одного победителя — в общем‑то это традиционный подход в наших исследованиях. Интегральный балл удобен для навигации, но плохо отвечает на вопрос заказчика. Ведь организации с жёсткими требованиями к КИИ, компании с большой 1С‑средой и команды, которым важна развитая AI‑составляющая, смотрят на разные части профиля. Поэтому основным результатом стали сравнительные профили, тепловые карты и разбор отдельных групп критериев.
Как считали
Финальная методика включает более 300 критериев, объединённых в 11 функциональных блоков и 60 с лишним подкатегорий. Мы оценивали архитектуру, безопасность, DevOps, Linux‑совместимость, интеграции, AI/LLM, IDP/OCR, Process Mining и Task Mining, лицензирование, TCO, ROI и другие аспекты корпоративной эксплуатации.
Методика нашей оценки менялась по ходу работы. Так, часть критериев мы объединили или убрали как дублирующие. Одновременно в анкете появились новые вопросы по no‑code‑разработке, Computer Use и интеграции ИИ. Такое изменение связано в том числе с тем, что за полгода сами платформы и набор требований к ним успели измениться, поэтому сохранять первоначальную анкету только ради формальной стабильности было бы неправильно.
Каждый критерий получал две независимые оценки:
Содержательность, S. Эта оценка показывает, насколько полно реализована заявленная возможность. Четыре балла означают полноценный функционал из коробки без существенных ограничений. Три балла означают рабочую реализацию с заметными ограничениями или неполным покрытием сценариев. Два балла ставятся, когда базовая возможность есть, но значимая часть задач требует доработки или кастомного кода. Один балл означает формальное наличие или низкую практическую применимость.
Верифицируемость, V. Здесь оценивается качество подтверждения ответа вендора. Мы использовали документацию, технические демонстрации, демостенды, публичные release notes и другие доступные материалы. Максимальная оценка ставилась, когда возможность удалось проверить независимо. Устное заявление или маркетинговое описание без технических деталей давало меньший балл.
Эти две шкалы нужны одновременно, ведь документация сама по себе не делает функцию полноценной, а убедительный рассказ о сильной реализации не заменяет проверку. Итоговая оценка отражает верифицируемую функциональную зрелость, а не рыночную долю, выручку или число внедрений.
Техническую часть исследования выполняла команда из четырёх специалистов, в том числе с практическим опытом внедрения RPA. Вендоры отвечали на опросники, проводили демонстрации, давали доступ к материалам и уточняли спорные моменты. Основной объём времени ушёл на сопоставление ответов и на их проверку, а вовсе не на сбор данных, как могло бы показаться. Когда критериев больше трёхсот, даже небольшая неоднозначность превращается в десятки часов дополнительной работы.
Первый сюрприз: рынок созрел
Главный результат: в России сформировалось ядро RPA‑решений, пригодных для enterprise‑эксплуатации. PIX RPA, ROBIN, АТОМ.РИТА и Sherpa RPA закрывают базовые требования крупного заказчика: масштабирование, отказоустойчивость, разделение Dev/Test/Prod, развитую ролевую модель, интеграционные механизмы и мониторинг.
Глубина реализации отдельных возможностей различается, но привычной картины, где половину участников можно исключить после первых десяти вопросов, мы не увидели. Так что в этом случае шорт‑лист формируется по соответствию конкретной инфраструктуре и операционной модели заказчика, а не по наличию или отсутствию основных функций.
Для рынка это хороший признак, а вот для покупателя задача, наоборот, становится сложнее. Когда несколько платформ проходят базовый технический порог, ошибки выбора возникают на втором уровне: в эксплуатации, требованиях к специалистам, интеграциях и стоимости развития.
Linux стал входным билетом
Ещё несколько лет назад поддержку отечественных операционных систем можно было воспринимать как дополнительное преимущество. Сейчас для госсектора, КИИ и крупных промышленных контуров это условие допуска. Astra Linux, Alt Linux, ROSA Linux, РЕД ОС, PostgreSQL и Postgres Pro уже нельзя оставлять в roadmap, если платформа претендует на соответствующий сегмент.
То же относится к on‑premise. Российская enterprise‑среда часто предполагает закрытый контур, отсутствие доступа к внешним API, локальные репозитории пакетов и собственные AI‑сервисы. Поэтому облачная архитектура сама по себе не является преимуществом. Важнее способность полноценно работать внутри периметра заказчика и не терять при этом управляемость, обновляемость и наблюдаемость.
ИИ оказался рабочим инструментом
Перед началом исследования мы ожидали увидеть в AI‑блоках много обещаний. Получилось иначе: у ряда платформ OCR, IDP, Computer Vision, NLP, LLM‑интеграции и Computer Use уже встроены в практические сценарии автоматизации. Конечно, это ещё не означает, что технология стала полностью автономной или перестала требовать контроля. Но граница между классическим RPA и интеллектуальной обработкой действительно размывается.
Робот всё чаще наделён достаточно широкими полномочиями: он забирает документ, распознаёт его, классифицирует, передаёт данные в модель, вызывает API, работает с интерфейсом старой системы и возвращает результат в процесс. RPA в такой схеме становится оркестратором цепочки, в которой участвуют разные технологии.
Особенно показательной была работа Sherpa RPA. Команда провела несколько отдельных демонстраций и собирала роботов с ИИ‑блоками в реальном времени, под наши вопросы. Это позволило оценить не только подготовленный сценарий, но и сам процесс разработки. В итоговом профиле Sherpa заметно выделяется интеллектуальной обработкой документов, русскоязычным NLP и средствами работы с LLM на собственной инфраструктуре.
У платформ разные характеры
Схожесть базовой функциональности не делает платформы взаимозаменяемыми. По результатам исследования у каждой сформировался собственный профиль.
ROBIN показал наиболее ровное покрытие функциональных, интеграционных и инженерных критериев. Развитый low‑ и no‑code, сильный API‑контур, оркестрация и DevOps‑практики формируют сбалансированный промышленный профиль. Отдельно отмечу работу команды в исследовании: ответы, уточнения и демонстрации были организованы образцово.
PIX RPA тяготеет к модели Enterprise Factory. Здесь заметны архитектурная зрелость, сочетание on‑premise и облачных контуров, Kubernetes‑подход и развитое управление жизненным циклом роботов.
АТОМ.РИТА в публичном позиционировании прежде всего ассоциируется с защищёнными контурами, КИИ и атомной отраслью. Исследование показало более широкий продуктовый профиль. При этом перед нами полноценная enterprise‑платформа, а не узкоспециализированное решение только для одного класса заказчиков.
Sherpa RPA выделяется AI‑составляющей, включая IDP, русскоязычный NLP, классификаторы и локальную работу с LLM. Для сценариев интеллектуальной обработки документов это один из наиболее заметных профилей среди участников.
Puzzle RPA смещена в сторону кросс‑системной интеграции. На профиль влияют использование Apache Airflow и модель лицензирования без поштучного учёта роботов.
OneRPA сфокусирована на быстром старте и нативной работе с 1С. Такой профиль может быть особенно важен там, где автоматизация строится вокруг российского прикладного ландшафта и нет задачи сразу создавать крупную фабрику роботов.
Эти описания не заменяют сравнение по конкретным критериям. Они показывают другое: выбирать между зрелыми платформами нужно по совпадению профиля продукта с профилем организации, не зацикливаясь на рейтинге в таблице.
Самая дорогая функция
После технического сравнения становится заметно, что лицензия сама по себе мало говорит о стоимости решения. На горизонте нескольких лет TCO складывается как минимум из трёх частей: лицензирование, внутренняя команда, инфраструктура и интеграции.
Платформа с низкой ценой лицензии может потребовать больше разработчиков, отдельную DevOps‑команду, дополнительный мониторинг, ручное сопровождение релизов или доработку коннекторов. Более дорогой продукт может оказаться экономичнее, если снижает трудозатраты на разработку и эксплуатацию. Обратная ситуация тоже возможна: богатая платформа не окупит себя, если организация использует лишь небольшую часть её возможностей.
Поэтому корректный вопрос, скорее, не в том, сколько стоит робот, а в стоимости поддержки выбранной модели автоматизации на определенный срок — например, три года. В эту стоимость входят специалисты, инфраструктура, обновления, отказоустойчивость, сопровождение интеграций и время вывода новых процессов в промышленную эксплуатацию.
Как выбирать платформу
Мы предлагаем начинать не с презентаций вендоров, а с собственной матрицы требований. В ней полезно отдельно зафиксировать:
масштаб внедрения сейчас и через три года;
целевые операционные системы, СУБД и требования к закрытому контуру;
необходимость Dev/Test/Prod, CI/CD, высокой доступности и аварийного восстановления;
структуру команды: профессиональные разработчики, citizen developers, центр компетенций;
ключевые интеграции, включая 1С, ERP, legacy‑системы, API и очереди сообщений;
сценарии OCR, IDP, LLM, Computer Use и требования к локальному исполнению моделей;
полную стоимость владения, а не только прайс на лицензии.
После этого имеет смысл проводить короткий пилот на собственном процессе. Причём сделать это на задаче с реальными ограничениями: нестабильным интерфейсом, правами доступа, журналированием, обработкой ошибок и передачей в сопровождение, а не на демонстрационном сценарии вендора. Именно на таком пилоте становятся видны различия, которые не помещаются в сравнительную таблицу.
Что в итоге
Российский рынок RPA уже не выглядит набором временных замен зарубежных продуктов. В нём сформировались зрелые платформы с промышленной архитектурой, средствами разработки, оркестрацией, безопасностью и работающими AI‑возможностями.
Впрочем, это не отменяет сложности выбора, ведь базовый функционал перестал быть главным фильтром. Теперь решение определяется архитектурным соответствием, моделью эксплуатации, требованиями к людям и экономикой на горизонте нескольких лет.
Если вы уже внедряли одну из этих платформ, расскажите в комментариях не только о том, что получилось, а что нет, но и о цене эксплуатации: сколько людей потребовалось, как устроено сопровождение и что оказалось сложнее пилота. Именно эти детали чаще всего определяют результат после красивого запуска.
