Сравнение RPA-платформ: UiPath, AA, Power Automate на практике

Зачем вообще сравнивать RPA-платформы

RPA обычно берут, чтобы снять ручную рутину: перенос данных между системами, обработку счетов, сверки, выгрузки, работу с почтой и порталами. На бумаге все звучит просто: «бот делает как сотрудник». В реальности ожидания упираются в детали: нестабильный интерфейс, разные права доступа, капча, ночные обновления и то, что «процесс один», а вариантов исключений десятки.

Сравнение RPA-платформ важно не ради красивых диаграмм. У разных решений по-разному устроены поддержка, управление роботами и лицензирование. Это напрямую влияет на стоимость владения: один бот требует минимального внимания, а другой будет регулярно «падать» из-за мелочей и съедать время команды.

Чаще всего проекты «ломают» четыре вещи: поддержка (как быстро возвращают ботов в работу), стабильность (как переживают изменения и сбои), лицензирование (что именно оплачивается и как растет счет), контроль изменений (как обновлять сценарии без хаоса и откатываться назад).

Для госорганов и крупных компаний добавляются требования к аудиту и прозрачности: журналы действий, контроль доступа, разделение сред (тест и прод), предсказуемые релизы. В таком контексте сравнение RPA-платформ становится проверкой управляемости, а не только ответа на вопрос «умеет ли бот нажимать кнопки».

Простой пример: робот обрабатывает входящие счета. После обновления портала поставщика меняется форма. В одной платформе бот аккуратно уйдет в исключение и создаст понятный инцидент. В другой может «молча» пойти дальше и отправить данные не туда. Разница здесь не в одной функции, а в надежности и контроле.

Сначала задайте рамки: какие процессы и условия у вас

Чтобы сравнение RPA-платформ было честным, сначала опишите, что именно вы автоматизируете и в каких условиях это будет работать. Иначе на демо все выглядит одинаково, а в эксплуатации всплывают ограничения: доступы, окна обслуживания, разные версии приложений, правила ИБ.

Начните с простого паспорта процесса. Важно не только «что делает бот», но и нагрузка: сколько раз в день запускается, сколько параллельных прогонов нужно, сколько пользователей зависит от результата, насколько критично время (например, закрытие дня в бухгалтерии).

Дальше уточните, с чем бот будет работать. Desktop и веб ведут себя по-разному, а Citrix или VDI могут резко усложнить распознавание элементов. Отдельно отметьте «тяжелые» системы и форматы: SAP, 1С, почта, PDF, сканы, таблицы, порталы с капчей и многофакторной аутентификацией.

Затем соберите ограничения среды. Для многих организаций в Казахстане, включая госсектор и крупные предприятия, важны закрытые контуры, строгие права, журналирование действий и понятные следы изменений. Если вы планируете внедрение через интегратора (как это часто бывает в крупных проектах системной интеграции), эти требования стоит зафиксировать до пилота.

Удобно закрепить рамки в виде четырех критериев успеха:

• время выполнения процесса и «узкие места»
• процент успешных запусков (без ручной помощи)
• время восстановления после сбоя (и кто это делает)
• требования к логам и отчетности (что увидит аудитор)

Пример: если бот обрабатывает счета каждый час и задержка влияет на оплату, формулировки уровня «работает на демо» недостаточно. Нужен целевой процент успешных запусков и понятный сценарий, что происходит при сбое в 17:55.

Как сравнить поддержку: не только «есть ли саппорт»

В поддержке RPA важно не то, что она «существует», а то, как быстро вы возвращаете ботов в работу после сбоя. Для практического сравнения RPA-платформ заранее решите, какой простой для вас приемлем: 30 минут, 4 часа или «до завтра».

Вендор, партнер и ваш внутренний саппорт

У большинства платформ есть поддержка вендора, но на практике вы часто общаетесь с партнером-интегратором. Проверьте каналы (почта, портал, телефон), SLA по времени реакции и решения, а также понятную схему эскалации, если тикет «застрял».

Не пропускайте вопрос языка и часового пояса. Если команда работает в Казахстане, а поддержка отвечает только по европейскому времени и на английском, мелкие инциденты начнут копиться, особенно в конце месяца.

Также честно оцените внутреннюю поддержку. Кто будет администратором (права, обновления, очереди), кто разработчиком (исправления, тесты), кто владельцем процесса (принимает изменения и отвечает за результат). Без этих ролей даже сильная поддержка вендора не вытащит проект.

Попросите у каждого поставщика ответы на несколько конкретных вопросов:

• Какие типовые инциденты покрывает SLA, а что считается «консультацией» без сроков?
• Как выглядит эскалация до инженеров второго уровня и сколько это обычно занимает?
• Есть ли поддержка на русском языке и работа в вашем часовом поясе?
• Кто помогает после обновления платформы, если часть ботов стала падать?
• Как вы получаете уведомления об инцидентах и статусах тикетов?

Документация, обучение и база знаний

Поддержка - это не только тикеты. Посмотрите, насколько документация понятна новичкам: «первый бот», типовые ошибки селекторов, действия при изменении интерфейса. Хороший признак - короткие практические уроки и примеры, а не только справочник.

Проверьте базу знаний и сообщество: легко ли найти решение типовой проблемы, например когда бот перестал нажимать кнопку после обновления учетной системы. Если ответ находится за 5 минут, вы экономите дни ожидания и меньше зависите от внешнего саппорта.

Стабильность ботов: как измерять и что просить на демо

Стабильность RPA-ботов чаще ломается не из-за «плохой платформы», а из-за реальной жизни: обновили интерфейс, поменялась подпись кнопки, окно загрузилось на секунду дольше, приложение зависло. Поэтому в сравнении RPA-платформ важно заранее договориться, как вы измеряете надежность, и попросить показать работу в «стрессовых условиях», а не идеальный ролик.

Как измерять стабильность

Выберите 3-5 процессов для пилота и зафиксируйте метрики, понятные бизнесу. Они быстро показывают разницу между инструментами и подходами команды:

• доля успешных прогонов без вмешательства человека
• среднее время восстановления после сбоя (MTTR)
• доля ручных вмешательств на 100 запусков
• количество падений из-за UI-изменений и «хрупких» селекторов
• время простоя процесса из-за недоступности систем

Полезно считать стабильность отдельно для «техники» (локаторы, таймауты, ретраи, обработка исключений) и отдельно для «среды» (VPN, RDP, обновления, зависания приложений).

Что спрашивать и просить на демо

На демо просите не только успешный проход, но и поведение при сбоях: где сработают ретраи, какие таймауты стоят по умолчанию, как выглядит лог, как происходит перезапуск.

Для проверки можно попросить сделать несколько простых вещей:

• намеренно изменить элемент интерфейса и показать, как чинится локатор
• симулировать «долгую загрузку» и посмотреть, что будет с таймаутами
• показать очереди, расписания, алерты и автоперезапуск в оркестраторе
• объяснить, как делают регресс-тесты перед релизом и есть ли тестовый стенд
• уточнить, как контролируются зависимости: версии приложений, браузера, расширений

Сценарий для быстрой проверки: бот забирает счета из почты, заносит данные в учетную систему и складывает файлы в папку. На демо «сломайте» один шаг (например, измените название поля) и попросите показать, сколько времени займет восстановление и сколько ручных действий потребуется.

Контроль изменений сценариев: что нужно для управляемых релизов

Если боты делают важные операции (платежи, заявки, доступы), контроль изменений нужен не «для галочки». Без него любая правка превращается в риск: бот начинает вести себя иначе, а причину сложно найти. При сравнении RPA-платформ смотрите не только на удобство разработки, но и на то, как платформа поддерживает управляемые релизы.

Роли, версии и аудит

Начните с простого вопроса: кто может менять сценарий, кто его утверждает, а кто имеет право запускать в проде. Понятная модель ролей снижает шанс случайной правки и помогает разделить обязанности между аналитиком, разработчиком и владельцем процесса.

Проверьте версионирование: историю изменений, комментарии к релизам, сравнение версий и быстрый откат. Это особенно важно, когда несколько человек правят одного бота или когда нужно срочно вернуть «вчерашнюю» рабочую логику.

Отдельно оцените аудит. Должны быть ответы на три вопроса: кто и когда запускал бота, что именно изменили в сценарии, какие ошибки возникали при выполнении. Без этого расследование инцидентов превращается в переписку в чатах.

Окружения и секреты

Для стабильных релизов нужны разные окружения: dev, test, prod. Уточните, как устроен перенос между ними и какие правила можно закрепить. Например: запрет прямых правок в проде или обязательный тестовый прогон перед публикацией.

Работа с секретами тоже часть контроля изменений. Нормальная практика выглядит так: учетные данные и ключи хранятся отдельно от сценария, доступ выдается по ролям, есть журнал обращений, пароль можно менять без правки логики, секреты не попадают в логи и экспорт пакетов.

Пример: бот обрабатывает счета и заходит в ERP под сервисной учеткой. Если пароль «зашит» в сценарий, любая смена пароля ломает релиз и плодит копии сценариев. Если секреты вынесены правильно, меняется только пароль, а сценарий остается прежним.

Лицензирование и стоимость владения: как не промахнуться

В RPA чаще ошибаются не в выборе «самой удобной» студии, а в бюджете на 1-3 года. Поэтому в сравнении RPA-платформ полезно сделать расчет: сколько стоит один стабильный процесс в работе, а не «пилот на ноутбуке».

Лицензии встречаются разные: «на бота» (исполнителя), «на запуск/транзакции», «на пользователя» (для attended), отдельно на оркестратор и иногда на среду разработки. На бумаге варианты могут выглядеть похоже, но итоговая сумма меняется из-за того, как именно вы запускаете роботов.

Attended и unattended почти всегда дают разный чек. Если бот помогает сотруднику в его сессии (attended), стоимость часто привязана к числу пользователей. Если бот работает по расписанию на сервере (unattended), бюджет упирается в количество одновременных исполнителей, очереди, расписания и требования к инфраструктуре. Пример: бухгалтерия обрабатывает счета в течение дня вручную, а ночью нужен пакетный прогон сверок. Это два режима и иногда две разные модели лицензирования.

Часть затрат обычно «прячется» не в лицензии. Помимо окружений и прав доступа, всплывают платные коннекторы, лимиты API, модули OCR/IDP, требования к аналитике и хранению логов, а также отказоустойчивость (второй сервер, резервное копирование).

Чтобы посчитать TCO на 1-3 года, сложите: лицензии + поддержка/обновления + инфраструктура (VM, БД, мониторинг) + разработка + сопровождение (починка после изменений, регрессионные проверки). И обязательно спросите заранее: как растет цена при увеличении команды, есть ли ограничения по функциям в разных редакциях, сколько стоит «добавить еще 10 процессов» без покупки лишних модулей.

Если вы внедряете RPA в регулируемых отраслях, полезно отдельно оценить стоимость требований по безопасности и журналированию. Такие расчеты часто делают вместе с интегратором, чтобы еще до пилота зафиксировать роли, среды и уровни поддержки.

UiPath, Automation Anywhere, Power Automate и аналоги: на что смотреть

Сводить выбор к «какая платформа популярнее» опасно: у UiPath, Automation Anywhere и Microsoft Power Automate разные сильные стороны, и они проявляются только на ваших процессах и ограничениях. Поэтому сравнение RPA-платформ лучше строить вокруг проверок, которые можно подтвердить пилотом и документами.

Сначала составьте короткий список кандидатов. Помимо тройки лидеров иногда уместны аналоги, если у вас жесткий контур безопасности, специфичная виртуализация или требования к локальному размещению. Для организаций с on-prem инфраструктурой и строгими регламентами (часто так бывает в госсекторе и финансах) заранее уточняйте, какие варианты развертывания реально поддерживаются и как проходит аудит.

Совместимость и поддерживаемость сценариев

Попросите показать не «витрину», а ваш типовой стек: офисные приложения, браузеры, почта, файловые шары, ERP/CRM, терминальные сессии. Затем оцените, насколько быстро команда сможет поддерживать сценарии:

• Готовые коннекторы и их стабильность на ваших версиях систем.
• Отладка: понятно ли, где и почему упал бот, есть ли логи, трассировка шагов, скриншоты.
• Повторное использование: библиотеки компонентов, шаблоны, стандарты именования.
• Работа с UI: устойчивость селекторов, поддержка браузеров, поведение после обновлений.
• Требования к правам: нужны ли разработчикам админские права и как это влияет на ИБ.

Оркестрация и развертывание

Сравните оркестрацию на одном и том же кейсе: очередь заявок, расписание, параллельный запуск, перераспределение нагрузки, изоляция команд (мультитенантность). Важно и то, где будет работать платформа: облако, on-prem или гибрид, и как закрываются требования по шифрованию, журналированию и ролям.

Пример для демо: бот получает 200 счетов, часть с ошибками в реквизитах, часть требует ручного подтверждения. Попросите показать, как платформа ставит элементы в очередь, как оператор видит исключения, как бот восстанавливается после перезапуска и что происходит при изменении шаблона документа.

Пошаговый план пилота: как сравнить платформы за 2-4 недели

Пилот нужен не для красивого демо, а чтобы быстро и честно проверить платформу в ваших условиях: ваши системы, ваши права доступа, ваши данные, ваши правила изменений. Для сравнения RPA-платформ важнее одинаковые задания и одинаковые метрики, чем обещания.

Начните с набора процессов, которые дадут разную нагрузку. Например: один простой (перенос данных между формами), один «с сюрпризами» (письма, вложения, разные форматы), и один рискованный (где ошибка заметна и дорого стоит). Если вы из госсектора или крупного предприятия, добавьте процесс с жесткими требованиями к доступам и журналам.

План на 2-4 недели, который обычно дает ясную картину:

• Выберите 2-3 процесса и заранее договоритесь о границах: что автоматизируем, что оставляем человеку, какие исключения считаем нормой.
• Подготовьте тестовые учетные записи, роли и входные данные (включая «плохие»), чтобы все платформы работали в одинаковых условиях.
• Зафиксируйте единые KPI: время выполнения, процент успешных запусков без ручной помощи, время восстановления после сбоя, понятность сопровождения (насколько быстро другой человек разберется в сценарии).
• На демонстрации требуйте мониторинг и разбор ошибок: логи, трейсы, поиск причины, откат изменений и восстановление предыдущей версии.
• Отдельно оцените нагрузку на ИТ: установка и обновления, управление доступами, хранение секретов, интеграция с AD/учетками, требования к серверам или облаку.

В конце сведите результаты в таблицу баллов, но обязательно добавьте колонку «риски и допущения». Платформа может быть дешевой на старте, но если она требует постоянных ручных правок или сложной поддержки, стоимость владения быстро вырастет.

Частые ошибки при выборе RPA-платформы

Первая ловушка - судить платформу по тому, как быстро собрали эффектное демо. На демо обычно нет реальных ограничений, боевой нагрузки и «грязных» исключений. В итоге выбирают самый удобный конструктор, а потом упираются в поддержку, обновления и релизный цикл.

Часто забывают про изменения в целевых системах. Любое обновление ERP, веб-кабинета или даже браузера может «сломать» селекторы, формы и авторизацию. Если обновления идут регулярно, спрашивайте не «насколько бот умный», а как платформа переживает изменения и сколько времени занимает восстановление.

Еще одна типичная ошибка - смешать требования attended и unattended. Команду устраивает бот «на рабочем месте», но бизнес ожидает ночную обработку без участия человека. Потом выясняется, что оркестрация, очереди, роботы и доступы считаются по другой модели, и лицензирование становится сюрпризом.

Почти всегда недооценивают сопровождение. Бот в проде - это не «настроили и забыли», а постоянная работа: мониторинг запусков и падений, алерты с понятными причинами ошибок, обработка исключений и ручная «подхватка», плановые проверки после обновлений, время владельца процесса на подтверждения.

Наконец, опасная практика - правки в проде «на коленке». Без правил контроля изменений сценариев вы теряете повторяемость и ответственность: должны быть отдельные среды (разработка, тест, прод), версионирование и согласование изменений, понятный чеклист релиза (что меняем и как откатываем).

Короткий чеклист перед финальным решением

Перед тем как выбирать платформу и подписывать договор, полезно остановиться и проверить, что вы сравниваете одно и то же. Этот чеклист закрывает типичные «дыры», из-за которых сравнение RPA-платформ выглядит красиво на демо, но разваливается в эксплуатации.

Проверьте, что у вас зафиксировано:

• Список процессов с приоритетом: где максимальная ценность, где максимальный риск, какие шаги нельзя «ломать» (финансы, отчеты, регуляторика) и что будет считаться успехом.
• Требования к работе в вашем контуре: доступы, хранение учетных данных, журналы действий, аудит, сегментация, ограничения по установке агентов и подключению к внешним сервисам.
• KPI стабильности и правила реакции: допустимый процент успешных прогонов, время восстановления после сбоя, кто дежурит, как выглядит эскалация, есть ли мониторинг с понятными уведомлениями.
• Модель лицензирования под ваши сценарии и рост на 1-3 года: сколько будет unattended и attended ботов, нужна ли отдельная лицензия на оркестрацию, разработку, тестовые среды, очереди, распознавание документов и другие платные опции.
• План контроля изменений и ресурсов: роли (владелец процесса, разработчик, администратор, поддержка), среды (dev, test, prod), порядок релизов и откатов, кто реально будет сопровождать решения, включая 24/7 при необходимости.

Небольшая проверка на практике: возьмите один критичный процесс (например, обработку счетов и сверку сумм) и пройдите по пунктам выше. Если на любой вопрос ответ звучит как «потом решим», риск почти всегда переедет в эксплуатацию.

Пример сценария из реальной жизни: обработка счетов и сверки

Представьте связку бухгалтерии и закупок. Каждый день приходят счета по почте: часть в PDF, часть сканами, иногда в письме только ссылка или просьба «поправьте реквизиты». Дальше нужно занести данные в учетную систему, сверить статус заказа в другой системе и проверить оплату в банке или казначействе. Если что-то не сходится, счет возвращают поставщику, а внутри компании ставят задачу на уточнение.

Для сравнения RPA-платформ сценарий хорош тем, что в нем есть и документы, и множество исключений. На пилоте важно не показывать «идеальный» поток, а заранее включить типичные проблемы: разные темы писем и цепочки переписки, документы с ручными правками (подписи, печати, сканы низкого качества), расхождения по сумме/НДС/валюте/ИИН-БИН/номеру договора, ситуации «заказ не найден», «дубликат счета», «платеж частичный», возвраты поставщику и повторная обработка после исправлений.

Стабильность бота удобнее мерить не впечатлениями, а числами. Попросите 100 прогонов на одном наборе кейсов. Пусть команда фиксирует каждое падение с причиной (селектор, таймаут, изменение формы, права доступа, сетевой сбой) и считает MTTR - время восстановления до следующего успешного прогона. Так быстро видно, где платформа «сыпется», а где проблема в окружении или в самом процессе.

Контроль изменений проверяется простым упражнением: выпускаете новую версию бота, меняя, например, правило сверки или формат выгрузки в Excel. Затем имитируете инцидент и делаете быстрый откат на прошлую версию с понятным журналом: кто изменил, что именно, когда и почему.

Вывод делайте по приоритетам. Если важнее скорость внедрения, выигрывает то, что быстрее собрать и поддерживать силами вашей команды. Если важнее управляемость и предсказуемые релизы, смотрите на версионирование, роли и аудит. Если критична стоимость, сравнивайте лицензирование не «по прайсу», а по реальному числу роботов, средам и режимам работы.

Следующие шаги: как перейти от выбора к внедрению

После пилота важно зафиксировать результаты так, чтобы их одинаково понял и бизнес, и ИТ. Иначе решение снова превратится в спор вкусов, даже если сравнение RPA-платформ прошло честно.

Сведите итоги в короткую таблицу на 1-2 страницы. Обычно достаточно:

• процессы из пилота и ожидаемый эффект (время, ошибки, SLA)
• риски и зависимость от ИТ (доступы, частота изменений, нестабильные системы)
• затраты и сроки (лицензии, инфраструктура, разработка, сопровождение)
• требования к безопасности и аудитам (логи, роли, хранение учетных данных)
• план развития на 3-6 месяцев (сколько ботов и какие команды нужны)

Дальше определите операционную модель. Самый частый провал не в технологии, а в том, что непонятно, кто владеет ботами и кто принимает изменения. Минимальный набор: владелец процесса со стороны бизнеса, ответственная команда (центр компетенций или выделенные разработчики), регламент релизов (кто согласует, как тестируем, как откатываем).

Параллельно запланируйте инфраструктуру и поддержку. Для бота сверки счетов нужны не только лицензии, но и стабильные рабочие станции или серверы для запуска, мониторинг, резервирование, а также понятный график обновлений Windows и офисных пакетов, чтобы не ломать сценарии.

Если внутри не хватает экспертизы, подключайте системного интегратора для оценки архитектуры и внедрения. В Казахстане это часто удобно совмещать с инфраструктурой: GSE.kz как производитель компьютеров, серверов и рабочих станций и системный интегратор может помочь собрать надежную среду под RPA (включая поддержку и требования к закрытым контурам), чтобы пилот сразу проверял реалистичную эксплуатацию, а не «демо на ноутбуке».