За полтора года на автоматизации процессов у меня набралось десятка два кейсов, где клиент приходил с запросом на RPA автоматизацию бизнес процессов, а после расчёта стоимости и сроков соглашался на обычный скрипт за 20 000 рублей вместо лицензии RPA-платформы за несколько сотен тысяч в год. Бывает и наоборот: там, где я советовал обойтись скриптом, через полгода процесс усложнялся настолько, что клиент возвращался за полноценной RPA-платформой. Разберу, по каким признакам выбирать между роботом и скриптом, на каких кейсах это видно в реальной работе и на каких цифрах считать окупаемость, прежде чем платить за разработку или лицензию.
Чем RPA отличается от обычного скрипта на практике
RPA работает через эмуляцию действий человека в интерфейсе: открывает окно, кликает по кнопкам, читает текст с экрана, вставляет данные в поля так, будто за компьютером сидит сотрудник. Инструменты вроде UiPath, Power Automate Desktop или Napoleon IT записывают последовательность действий на реальном рабочем столе и потом воспроизводят её раз за разом, без обращения к API целевой системы.
Скрипт работает иначе. Он обращается напрямую к API, базе данных или файлу выгрузки, без имитации кликов и без открытия окон. Если у сервиса есть документированный API, скрипт получает и отправляет данные напрямую, без риска, что кнопка на экране сдвинулась после обновления интерфейса и весь сценарий сломался посреди рабочего дня.
Отсюда и главный практический вывод, к которому я прихожу почти на каждом проекте: RPA нужен там, где API нет и не предвидится в обозримом будущем, а скрипт почти всегда быстрее и дешевле там, где API есть или его можно получить за разумные деньги у разработчика целевой системы.
Когда роботизация бизнес процессов через RPA окупается быстрее скрипта
RPA оправдан в нескольких конкретных ситуациях, которые я вижу у клиентов регулярно.
- Legacy-система без API: старая версия 1С, самописный банк-клиент, внутренний портал на технологиях десятилетней давности, где выгрузка данных возможна только через интерфейс и никакой документации по интеграции попросту не существует.
- Высокий объём однотипных ручных действий: сверка платежей, перенос данных между несколькими не связанными между собой системами, формирование отчётов из десятков разрозненных источников вручную каждый день.
- Требование к аудиторскому следу: в банках и страховых иногда нужны скриншоты и лог каждого шага робота как доказательство, что операция выполнена по регламенту, а не человеком с превышением прав доступа.
- Процесс редко меняется: если сценарий работы в интерфейсе стабилен и не пересматривается каждый квартал, риск поломки робота из-за изменения UI остаётся невысоким на годы вперёд.
Пример из практики смежной области: бухгалтерия распределённой розничной сети тратила три часа в день на перенос остатков из учётной системы поставщика без API в свою 1С. При зарплате бухгалтера около 80 000 рублей в месяц это примерно 30 000 рублей в месяц чистого времени на рутину, то есть 360 000 рублей в год. Внедрение RPA-сценария с лицензией и настройкой окупилось за 8-9 месяцев, а дальше экономило деньги каждый месяц без дополнительных вложений. Скрипт здесь был не вариант просто потому, что у системы поставщика не было ни API, ни экспорта в понятном формате.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Когда дешевле и быстрее написать скрипт вместо RPA
Как только у обеих систем есть API или хотя бы вебхуки, RPA почти всегда избыточен. Робот, который открывает браузер, логинится и кликает по кнопке «Экспорт», работает медленнее, ломается от любого обновления интерфейса и стоит в разработке и поддержке дороже, чем скрипт, дёргающий тот же самый функционал напрямую через запрос к серверу.
| Критерий | RPA-платформа | Кастомный скрипт |
|---|---|---|
| Доступ к данным | Через интерфейс, без API | Через API, базу или файл |
| Запуск | 3-6 недель с записью сценария | 3-10 дней в зависимости от сложности |
| Лицензия | от 300-400 тысяч рублей в год на рынке у вендоров | не нужна, только разовая разработка |
| Устойчивость | ломается при обновлении интерфейса целевой системы | ломается только при смене формата API |
| Скорость | ограничена отрисовкой интерфейса | ограничена пропускной способностью API |
Я обычно предлагаю скрипт на Python или сценарий в n8n именно потому, что у большинства современных сервисов вроде Tilda, СДЭК, Т‑Банка, WooCommerce и Bitrix24 API давно есть, и через них можно решить ту же задачу без покупки платформы и без риска, что робот увидит на экране не ту кнопку.
Кейсы из практики: где я выбирал скрипт вместо робота
WooCommerce и эквайринг Т‑Банка. Клиенту предлагали настроить RPA-бота, который заходил бы в личный кабинет банка и вручную сверял платежи с заказами в WooCommerce. Вместо этого я подключил API эквайринга Т‑Банка напрямую к WooCommerce через вебхуки: статус оплаты обновляется в заказе за секунды, без открытия браузера и без риска, что интерфейс банка обновится и сценарий перестанет работать. Такая интеграция у меня стоит от 40 000 рублей и окупается уже на первом месяце за счёт отсутствия ручной сверки платежей.
Зоны доставки на Tilda. Стоимость и сроки СДЭК по адресу штатный калькулятор Tilda считает сам, а вот ограничить доставку своими зонами на карте конструктор не умеет. Для этого я держу в библиотеке готовый скрипт ограничения доставки по зонам для Tilda: он сверяет адрес клиента с полигонами на Яндекс.Карте и блокирует оформление вне покрытия, без разработки с нуля. Кастомный скрипт с обращением к API СДЭК пишу только под сценарии сверх этого: договорные тарифы, несколько складов, автосоздание заказов.
Бот на aiogram для приёма заявок. Вместо RPA-сценария, который открывал бы CRM и вручную вбивал данные из чата, я собираю Telegram-бота на aiogram, который сразу пишет заявку в CRM через API и уведомляет менеджера в отдельном чате. Разработка такого бота у меня стоит от 30 000 рублей, срок обычно 1-2 недели вместе с тестированием.
Связка сервисов через n8n. Когда нужно синхронизировать Tilda, Bitrix24 и Telegram-уведомления без выделенного сервера под Python-скрипт, я собираю цепочку в n8n: вебхук из Tilda триггерит создание сделки в CRM и отправку уведомления в чат менеджеров. Это дешевле и быстрее любой RPA-платформы, потому что все три сервиса отдают данные по API без эмуляции интерфейса и без риска поломки при редизайне админки.
Типичные ошибки при выборе между RPA и скриптом
Первая ошибка, которую я вижу чаще всего: покупают RPA-платформу, потому что так посоветовал системный интегратор, который зарабатывает именно на лицензиях и внедрении, а не на экономии клиента. Если в компании есть штатный разработчик или подрядчик, способный написать скрипт под API за неделю, лицензия RPA на год окажется дороже задачи в разы.
Вторая ошибка обратная: пытаются сэкономить на скрипте там, где интерфейс целевой системы меняется каждый месяц и данных через API не получить никак. Тогда скрипт с парсингом экрана превращается в бесконечную поддержку, дороже, чем изначально выглядела RPA-платформа с готовым движком записи сценариев.
Третья история, с которой сталкивался у розничного клиента: выбрали RPA для интеграции Tilda и CRM, хотя у обеих систем был открытый API. Робот кликал по кнопкам в панели администратора Tilda, вместо того чтобы читать вебхук о новом заказе. В итоге сценарий ломался при каждом обновлении админки, а стоимость поддержки за полгода превысила бюджет, которого хватило бы на нормальную интеграцию по API с запасом на доработки.
Как посчитать окупаемость RPA или скрипта до старта разработки
Формула простая: сравниваю стоимость ручного труда за год со стоимостью разработки и поддержки автоматизации. Стоимость ручного труда считаю как часы в месяц на задачу, умноженные на стоимость часа сотрудника, умноженные на 12 месяцев.
| Показатель | Пример расчёта |
|---|---|
| Часы ручной работы в месяц | 40 часов |
| Стоимость часа сотрудника | 500 рублей |
| Экономия в год | 240 000 рублей |
| Стоимость скрипта или сценария n8n | от 25 000 до 40 000 рублей разово |
| Срок окупаемости скрипта | 1-2 месяца |
| Стоимость RPA-платформы с лицензией на год | 350 000-500 000 рублей на рынке у вендоров |
| Срок окупаемости RPA при том же объёме | больше года |
При таких цифрах RPA имеет смысл только если задача действительно не решается через API и объём ручного труда огромный, а не потому что RPA звучит солиднее в презентации для руководства. На практике я советую сначала проверить, есть ли API у обеих систем, и только при твёрдом отсутствии рассматривать RPA-платформу как рабочий вариант.
Если нужно быстро прикинуть, что выгоднее в вашем случае, разумнее заказать короткую консультацию за 3 000 рублей, чем сразу покупать лицензию RPA-платформы вслепую, или сразу обсудить задачу через раздел с услугами, где расписаны варианты автоматизации под разные бюджеты и сроки.
Частые вопросы
Можно ли совместить RPA и скрипты в одном процессе
Да, это нормальная практика. Например, забор данных из системы без API делает RPA-робот, а дальнейшая обработка и отправка в CRM или бухгалтерию идёт через скрипт или n8n-сценарий по API. Так вы платите за RPA только там, где без него правда не обойтись, а остальную цепочку ведёте дешевле.
Сколько времени занимает разработка скрипта вместо RPA-сценария
Простая интеграция вроде подключения API доставки или эквайринга занимает 3-7 дней. Более сложная связка из нескольких сервисов через n8n или отдельный Python-сервис занимает 1-3 недели в зависимости от количества источников данных и требований к обработке ошибок и повторных попыток.
Что делать, если у нужной системы нет API
Сначала стоит проверить, нет ли скрытого API, которым пользуется сам интерфейс системы, или экспорта данных в файл по расписанию. Если ни того ни другого нет, тогда действительно остаётся RPA либо ручной парсинг открытых данных с соблюдением rate-limit и правил целевого сервиса.
Подходит ли n8n для замены RPA-платформы
Для задач, где все системы работают через API или вебхуки, n8n почти всегда закрывает потребность дешевле и быстрее RPA-платформы. Для сценариев с эмуляцией интерфейса устаревших систем без API n8n не поможет, там нужен именно RPA-инструмент.