Выбирать между PIX RPA и Sherpa RPA по спискам возможностей бессмысленно: обе платформы записывают сценарий, распознают элементы интерфейса, запускают робота по расписанию и ведут журнал. Различия, которые действительно влияют на смету и на надёжность, лежат в шести местах — в модели лицензирования, в способе работы с 1С и веб-интерфейсами, в оркестрации, в том, что видно в логе после падения, в наличии собственного контура распознавания документов и в требованиях к инфраструктуре.
Заявленная разница в позиционировании такова: Sherpa RPA идёт вместе с собственным контуром обработки документов Sherpa IDP и ИИ-сервером Sherpa AI Server, то есть предлагает единый стек «робот плюс распознавание плюс модель». PIX RPA чаще берут за зрелость оркестратора и предсказуемость на офисных и десктопных сценариях. Это ориентир для гипотезы, а не вывод: проверяется он только на вашем сценарии и на вашем железе. Ниже — как устроить такую проверку, во что она обходится и какие цифры фиксируются до старта.
Шесть критериев, по которым платформы расходятся
Каждый критерий сформулирован как вопрос, который задаётся вендору до подписания, и как способ проверить ответ руками. Последняя колонка — цена того, что вопрос не задали: именно эти суммы и сроки всплывают на приёмке.
| Критерий | Что проверять на стенде | Цена недосмотра |
|---|---|---|
| Модель лицензирования | Попросить смету не в абстрактных роботах, а в ваших сценариях: attended или unattended, единица счёта, отдельные лицензии на оркестратор и студию разработки | Смета вырастает в полтора-два раза на приёмке, когда выясняется, что три процесса не помещаются в одно расписание |
| Работа с 1С и веб-интерфейсами | Как робот находит элемент: по координатам, по тексту или через объектную модель. Прогнать сценарий на своей конфигурации, затем обновить её и прогнать снова | После планового обновления 1С робот перестаёт видеть кнопки, и каждый релиз превращается в ремонт сценария |
| Оркестрация и расписание | Запустить три сценария в пересекающиеся окна: очередь задач, приоритеты, поведение при конфликте за сессию пользователя | Ночной прогон не проходит целиком, а утром никто не знает, какие документы обработаны |
| Обработка ошибок и логи | Намеренно уронить сценарий: сохраняется ли скриншот на момент падения, номер шага, входные данные и возможность повторить с этого места | Разбор одного инцидента занимает рабочий день вместо десяти минут |
| Распознавание документов | Подсунуть 200 своих реальных сканов, а не демонстрационных: замерить долю документов, прошедших без правки человеком, и посмотреть, как настраивается порог уверенности | Заявленная точность на чужой выборке не воспроизводится на вашей, и очередь ручной проверки съедает всю экономию |
| Требования к инфраструктуре | Развернуть стенд силами своего администратора: виртуальные машины с пользовательской сессией, ресурсы, лицензии ОС, наличие в реестре отечественного ПО | К смете добавляются сотни тысяч рублей на инфраструктуру, а госзаказчик упирается в требование реестра уже после выбора |
Про пятый критерий стоит сказать отдельно, потому что именно на нём чаще всего расходятся ожидания и результат. Методику честного замера точности на своих документах мы разбирали подробно в отдельном материале; здесь важно одно: цифра из презентации вендора относится к его выборке, а не к вашим сканам, и разница между ними бывает кратной. Требуйте замер на своих 200 документах до покупки — это три дня работы и единственный способ узнать реальную долю ручной доработки.
Второй критерий — работа с 1С — заслуживает отдельной проверки, потому что именно он определяет стоимость владения. Робот, который находит поля по координатам на экране, ломается от любого изменения формы: сдвинулась колонка, добавилась кнопка, поменялся масштаб — сценарий встал. Робот, работающий через объектную модель приложения, переживает косметические изменения и падает только на реальных изменениях структуры. Разница между этими двумя способами на дистанции года — это разница между двумя ремонтами сценария и двенадцатью. Проверяется она одним экспериментом: прогнать сценарий, накатить очередное обновление конфигурации на тестовый контур и прогнать снова.
Где эти две платформы расходятся по существу
Сравнивать построчно списки действий бессмысленно — они у обеих платформ длинные и почти совпадают. Содержательное различие одно, и оно архитектурное: собираете вы стек из частей или берёте его целиком у одного вендора. Ниже — то, что можно утверждать про эту пару без пилота, и то, что без пилота утверждать нельзя ни про одну из них.
| Что сравниваем | PIX RPA | Sherpa RPA |
|---|---|---|
| Состав стека | RPA-платформа с оркестратором и студией разработки | RPA вместе с собственным контуром распознавания Sherpa IDP и ИИ-сервером Sherpa AI Server |
| Обработка документов в сценарии | Внешний модуль или сторонний OCR: отдельная интеграция и отдельный договор поддержки | Внутри того же стека, без интеграции между вендорами |
| Типовая причина выбора в проектах | Зрелость оркестратора и предсказуемость на офисных и десктопных сценариях | Единый контур, когда сценарий упирается в чтение документов и работу модели |
| Что это меняет на дистанции | Меньше зависимости от одного поставщика, больше интеграционной работы и стыков | Меньше стыков и один ответственный, выше зависимость от одного поставщика |
| Что одинаково у обеих | Цены по запросу, оркестратор и студия лицензируются отдельно, сценарии не переносятся на другую платформу | То же самое |
| Что нельзя узнать из презентации | Долю ваших документов без ручной правки и число падений в месяц на вашей 1С | Ровно то же — проверяется одним сценарием на вашем стенде |
Карта связей в две части. Слева «Единый контур»: три соединённых узла «RPA» — «IDP (распознавание)» — «ИИ-сервер», обведены общей рамкой с подписью «один вендор, один договор поддержки». Справа «Сборка из частей»: узел «RPA» и отдельно стоящий узел «Внешний OCR» соединены стрелкой с подписью «интеграция и второй договор». Под обеими частями одинаковая пометка «точность проверяется на 200 своих сканах». Чертёжный стиль, подписи по-русски.
Пилот: как выбрать за 6–8 недель
Единственный работающий способ выбора — пилот на одном сценарии. Сценарий берут не самый болезненный, а самый показательный: массовый, стабильный по формату, с понятным результатом и с доступом к тестовому контуру системы. Хороший кандидат — перенос строк из входящих документов в учётную систему; плохой — процесс, который меняется каждый квартал, или тот, где половина случаев обрабатывается «по договорённости».
Двойной пилот на обеих платформах кажется расточительством, пока не сравнить его с годовой лицензионной платой. При парке в 8 unattended-роботов и ориентире 250 000 ₽ в год за робота годовые лицензии составляют около 2 000 000 ₽; лишние 180 000 ₽ на вторую реализацию — это 9 % от суммы, которую вы будете платить каждый год. При парке в один-три робота двойной пилот не окупается: берите одну платформу, но с правом отказаться по итогам пилота, зафиксированным в договоре.
- 1Метрики фиксируются до старта, а не после
Медиана времени операции у человека по 30 наблюдениям — именно медиана, потому что среднее вытягивают редкие тяжёлые случаи. Доля исключений: сколько случаев из 100 не укладываются в описанный сценарий. Число документов или операций в день. Без этих трёх чисел на входе результат пилота нечем сравнивать.
- 2Метрики снимаются в конце
Доля успешных прогонов за две недели, время восстановления после сбоя, доля случаев, ушедших человеку, и сколько времени занял разбор падений. Последнее число — самое важное и самое неудобное: именно оно определяет стоимость сопровождения парка роботов на следующий год.
- 3Решение принимается по трём числам
Доля успешных прогонов ниже 90 % при стабильном сценарии — платформа или сценарий выбраны неверно. Разбор одного падения дольше получаса — вы купите себе постоянного дежурного. Доля исключений выше 25 % — процесс не готов к роботизации, и его сначала надо упростить, а не автоматизировать.
Горизонтальная лента из четырёх отрезков: «Выбор сценария и замер как есть — 90 000 ₽, 2 недели», «Развёртывание стенда — 60 000 ₽, 1 неделя», «Реализация сценария — 180 000 ₽, 2–3 недели», «Опытная эксплуатация — 70 000 ₽, 2 недели». Над первым отрезком блок «Фиксируем на входе: медиана времени по 30 наблюдениям, доля исключений, объём в день». Над последним блок «Снимаем на выходе: доля успешных прогонов, время восстановления, доля случаев человеку». Справа итог «400 000 ₽, 6–8 недель». Чертёжный стиль, подписи по-русски.
Кого ещё держать в шорт-листе
Пара PIX и Sherpa — не весь рынок. По состоянию на сентябрь 2026 года в российских проектах регулярно встречаются ещё две платформы, и в шорт-лист их стоит включать не для галочки, а под конкретный тип задач.
- ROBIN от SL Soft — смотреть, когда парк планируется большой и на первый план выходят оркестрация, разграничение прав и встраивание роботов в существующий ИТ-ландшафт с собственной службой эксплуатации.
- Primo RPA — смотреть на компактных парках и офисных сценариях, где важнее скорость первой реализации и простота сопровождения силами одного человека, чем богатство платформы.
- Отдельным пунктом — проверка каждой платформы в реестре отечественного ПО. Для госзаказчика и компаний с требованием импортозамещения это первый фильтр, а не последний, и делается он до пилота.
Кто в компании отвечает за роботов после запуска? У парка обязан быть дежурный: человек, который утром смотрит журнал ночных прогонов, перезапускает упавшее и заводит задачу на исправление. Это 2–4 часа в неделю на парк до пяти роботов и полноценная роль от десяти. Если такой фамилии нет, роботы тихо останавливаются один за другим в течение полугода, а компания продолжает платить лицензии за неработающий парк — и никакая платформа от этого не спасает.
Сколько стоит смена платформы после запуска
Главное свойство этого выбора: сценарии между RPA-платформами не переносятся. Язык описания, библиотеки действий, способ адресации элементов интерфейса и модель обработки исключений разные, поэтому при переезде каждый сценарий пишется заново. Считать цену ошибки надо на парке, а не на одном роботе.
Эту сумму можно уменьшить почти вдвое, и делается это на первом же проекте. Если бизнес-логика сценария живёт отдельно от реализации — карта шагов, список исключений, правила проверки результата описаны в документе, а не только в редакторе платформы, — переработка одного сценария падает со 120 000 ₽ до 60 000–70 000 ₽. На парке из шести роботов это 540 000 ₽ вместо 870 000 ₽. Требуйте такую документацию по каждому сценарию при приёмке: это единственная часть работы, которая переживает смену платформы.
Столбчатая диаграмма с двумя группами столбцов, ось в рублях. Группа «Без документации сценариев»: столбец «Переработка 6 сценариев — 720 000 ₽» плюс «Оркестратор и расписания — 150 000 ₽», итог 870 000 ₽. Группа «С документацией сценариев»: «Переработка 6 сценариев — 390 000 ₽» плюс «Оркестратор и расписания — 150 000 ₽», итог 540 000 ₽. Отдельным серым блоком справа — «Задвоенные годовые лицензии: до 1 500 000 ₽» с пометкой «не зависит от документации». Чертёжный стиль, все числа подписаны, подписи по-русски.
Когда RPA не тот инструмент
Сравнение платформ имеет смысл только после того, как отвечен предыдущий вопрос: нужен ли здесь робот вообще. Мы разбирали противопоставление RPA и интеграции по API отдельно, и вывод там простой — робот работает с интерфейсом, интеграция работает с данными, и второе надёжнее всегда, когда доступно. Три признака, при которых выбор платформы можно не начинать.
- 1У системы есть API или штатный обмен. Тогда интеграция дешевле в сопровождении и не ломается от смены вёрстки или обновления конфигурации. Робот здесь — обход, за который вы платите каждый релиз.
- 2Операция выполняется реже нескольких раз в неделю. Лицензия, стенд и сопровождение стоят одинаково при 20 и при 2 000 операций в месяц, поэтому на редких операциях цена одного выполнения становится неприличной. Порог, ниже которого разговор не начинают, — примерно 200–300 операций в месяц.
- 3Процесс нестабилен: доля исключений выше 25 %, правила меняются каждый квартал, половина случаев решается «по ситуации». Робот зафиксирует текущий беспорядок и сделает его дороже. Сначала упрощение процесса, потом роботизация — в обратном порядке это не работает.
Типичная ошибка — выбрать платформу «на вырост», под план в 15 роботов, и оплатить оркестратор и студию разработки под этот план. Через год в эксплуатации оказывается три робота, а лицензии оплачены за инфраструктуру для пятнадцати. Покупайте под парк, который уже описан сценариями и у которого есть владелец процесса, а не под план развития.
Платформу выбирают на пилоте за 400 000 ₽, а расплачиваются за выбор годами лицензий и часами разбора падений.
