Интеграция через API обращается к данным напрямую: система отдаёт заказ, документ или остаток в машинном формате, и обмен не зависит от того, как этот заказ выглядит на экране. RPA-робот работает на другом слое — он повторяет действия человека в интерфейсе: открывает окно, кликает по кнопке, копирует значение из поля, вставляет в другое приложение. Результат в обоих случаях один, а вот всё остальное — надёжность, стоимость поддержки и срок жизни решения — различается принципиально.
В модельном расчёте ниже, на процессе из 1 800 документов в месяц, владение роботом за три года стоит 2 290 000 ₽, а интеграцией — 1 323 600 ₽. Робот при этом дешевле на старте: 220 000 ₽ против 480 000 ₽. Разницу в 260 000 ₽ интеграция отыгрывает примерно за восемь месяцев, и дальше разрыв растёт линейно, потому что робот платит абонентскую плату за хрупкость — переделками после каждого обновления чужого интерфейса.
Но есть ситуации, в которых у интеграции нет шансов, потому что интегрироваться не с чем. Их ровно три, они разбираются ниже, и в них робот — не компромисс, а единственный работающий способ. Ещё есть четвёртая ситуация, самая частая: объём операций слишком мал, и не нужно ни то ни другое. Ей посвящён последний раздел.
Принципиальная разница: данные против интерфейса
Программный робот, который выполняет операции в пользовательском интерфейсе так же, как это делал бы человек: находит элемент на экране, нажимает, вводит, копирует. Робот не знает, что такое заказ или накладная, — он знает координаты, названия полей и последовательность действий. Отсюда его главное свойство: он работает с любой системой, у которой есть экран, и ломается при любом изменении этого экрана.
Интеграция обращается к контракту данных: список полей и правил, который вендор меняет редко и, как правило, с предупреждением и сохранением обратной совместимости. Робот обращается к внешнему виду, который меняют дизайнеры без всякого предупреждения, потому что интерфейс для того и существует, чтобы улучшаться. В этом вся разница: одно решение опирается на то, что специально сделано стабильным, второе — на то, что специально сделано изменяемым.
| Свойство | Интеграция через API | RPA-робот |
|---|---|---|
| С чем работает | С данными: заказ, документ, остаток | С экраном: поле, кнопка, окно |
| Что ломает решение | Изменение контракта данных — редко, обычно с предупреждением | Любая перерисовка интерфейса, всплывающее окно, смена разрешения экрана |
| Скорость запуска | 6–12 недель: обследование, доступы, разработка, тесты | 3–5 недель: сценарий пишется по экранам, доступ уже есть |
| Как ведёт себя при сбое | Ошибка обмена фиксируется, документ помечается, повтор по расписанию | Робот останавливается или, что хуже, продолжает вводить не туда |
| Нагрузка на смежную систему | Управляемая, ограничивается лимитами и расписанием | Как у обычного пользователя: медленно, по одному документу |
| Работает без разрешения владельца системы | Нет: нужны доступы и согласованный контур | Да, если у вас есть учётная запись пользователя |
| Кто может поддерживать | Разработчик интеграции или своя ИТ-служба | Тот, кто писал сценарий; чужие сценарии переписывают почти с нуля |
Из таблицы следует ещё одно свойство робота, о котором редко говорят на демонстрациях: он не масштабируется по объёму. Робот вводит документы с той же скоростью, что и человек, потому что физически работает в том же интерфейсе — по одному окну за раз. Если поток вырос вдвое, второй робот означает вторую лицензию и вторую машину. Интеграция в этом месте ведёт себя иначе: рост объёма упирается в лимиты смежной системы, а не в число копий решения, и обычно проходит без дополнительных расходов вовсе.
Схема из двух горизонтальных дорожек к одному прямоугольнику «Смежная система» справа. Верхняя дорожка «RPA»: блоки «Открыть окно» → «Найти поле» → «Скопировать» → «Вставить», над ними полоса «Интерфейс — меняется без предупреждения» с иконкой трещины. Нижняя дорожка «API»: блоки «Запрос» → «Данные» → «Проверка» → «Запись», под ними полоса «Контракт данных — меняется редко и с предупреждением». Слева общий вход «Ваш процесс». Чертёжный стиль, подписи по-русски.
Три ситуации, где API просто нет
Робот не является плохой технологией — он является технологией для конкретного случая. Этот случай один: доступа к данным нет и не будет в обозримом сроке. Практически он встречается в трёх видах, и полезно уметь их различать, потому что в двух из трёх отсутствие API временное.
- 1Устаревшая учётная система, которую нельзя обновить
Самописная конфигурация без документации, платформа, снятая с поддержки, отраслевая программа, автор которой недоступен. Характерный маркер сроков: Контур.Диадок прекращает поддержку модуля для 1С:Предприятие 7.7 с 1 сентября 2026 года — компании, оставшиеся на этой платформе, оказываются ровно в описанной ситуации. Здесь робот часто оказывается дешевле, чем обновление платформы, но это временное решение до переезда, а не архитектура.
- 2Портал или личный кабинет без интеграционного контура
Кабинет площадки, поставщика или ведомства, где есть только веб-интерфейс и выгрузка в файл. Проверять надо всегда: у многих порталов интеграционный контур существует, но не рекламируется и подключается по заявке. Если контура действительно нет, робот — единственный способ, и его сценарий надо сразу проектировать под нестабильность: с проверкой результата, журналом и уведомлением человека при отклонении.
- 3Чужая система под управлением контрагента
Вам выдали учётную запись пользователя, а доступ к обмену данными выдавать не станут — не потому, что технически нельзя, а потому что это чужая политика безопасности. Здесь важна юридическая сторона: убедитесь, что автоматизированный доступ не запрещён условиями использования, иначе робот в один день превратится в заблокированный аккаунт вместе с процессом.
В нашей практике примерно в половине случаев «у них нет API» означает, что его не искали: контур есть в документации вендора, подключается по заявке и стоит дешевле годовой лицензии робота. Прежде чем строить сценарий по экранам, потратьте день на письменный запрос владельцу системы и на просмотр раздела для разработчиков. Это самая дешёвая проверка во всём проекте.
Стоимость владения за три года: робот против интеграции
Считаем на одном процессе: перенос и сверка 1 800 документов в месяц между внешней системой и 1С. Вручную это 4 минуты на документ — 120 часов в месяц, или 84 000 ₽ при ставке 700 ₽/час с налогами. Оба варианта закрывают процесс полностью; различаются только структура расходов и поведение при изменениях на чужой стороне.
Разрыв за три года — 966 400 ₽ в пользу интеграции. Но обратите внимание на структуру: робот дешевле на старте на 260 000 ₽, и именно это делает его привлекательным в момент, когда бюджет утверждается. Разницу в месячном владении — 57 500 ₽ против 23 400 ₽, то есть 34 100 ₽ — интеграция отыгрывает примерно за восемь месяцев. Дальше каждый месяц робота стоит на 34 100 ₽ дороже, и на трёхлетнем горизонте это и складывается в почти миллион.
Самая недооценённая строка — переделки после обновлений интерфейса. Четыре раза в год — не пессимистичная оценка, а обычная для активно развивающегося портала; у стабильной внутренней системы будет меньше, у маркетплейса — заметно больше. Вторая недооценённая строка — ручной добор при простоях: робот, который встал ночью, обнаруживается утром, и документы за смену вводятся руками. Именно эти две строки, а не лицензия, делают владение роботом дорогим.
Комбинированная диаграмма. Слева два составных столбца за 36 месяцев: «RPA — 2 290 000 ₽» с подписанными сегментами «лицензия 750 000», «переделки 420 000», «сопровождение 432 000», «простои 252 000», «инфраструктура 216 000», «старт 220 000»; «Интеграция — 1 323 600 ₽» с сегментами «старт 480 000», «сопровождение 540 000», «переделки 120 000», «инфраструктура 108 000», «простои 75 600». Справа график накопленных расходов по месяцам: две линии пересекаются на восьмом месяце, точка подписана «интеграция отыграла стартовые 260 000 ₽». Чертёжный стиль, подписи по-русски.
Ещё одно различие видно только на трёхлетнем горизонте: у робота расходы растут вместе с чужим продуктом, а у интеграции — вместе с вашим. Каждый релиз портала, каждое новое всплывающее окно с уведомлением, каждая смена вёрстки — это ваш счёт, и вы на него никак не влияете. Обмен данными по контракту меняется тогда, когда меняетесь вы: добавили склад, ввели новую номенклатурную группу, изменили правило склейки. Второй тип расходов планируется, первый — нет, и именно поэтому бюджет на робота регулярно оказывается превышен, хотя лицензия была куплена ровно та, что обсуждали.
Российские RPA-платформы: что у них разное в лицензировании
На российском рынке по состоянию на сентябрь 2026 года реально ставят четыре платформы: PIX RPA, Sherpa RPA, ROBIN от SL Soft и Primo RPA. Функционально они близки — записать сценарий, распознать элементы интерфейса, запустить по расписанию, — а расходятся в том, за что именно берут деньги. В смете это важнее набора возможностей, потому что цена определяется не платформой, а тем, как считаются роботы.
| На что смотреть в лицензии | Что это значит на практике |
|---|---|
| Attended или unattended робот | Attended работает на машине сотрудника под его сессией и дешевле; unattended живёт на сервере и работает сам, но стоит заметно дороже. Ночная обработка документов возможна только на unattended |
| Единица лицензирования | У разных платформ считают по-разному: на робота, на одновременно работающего робота или на процесс. Один и тот же ландшафт в этих единицах даёт разную сумму — просите смету в ваших сценариях, а не в абстрактных роботах |
| Оркестратор или сервер управления | Отдельная лицензия, без которой невозможно расписание, очередь задач и мониторинг. В презентациях его часто не показывают, а в счёте он появляется |
| Среда разработки сценариев | Студия может лицензироваться отдельно от исполнителя. Если сценарии будет писать ваша команда, это ещё одно рабочее место в год |
| Дополнительные модули распознавания | Если робот должен читать сканы и PDF, нужен модуль распознавания — у Sherpa это отдельный продукт IDP, у остальных тоже отдельная позиция |
| Реестр отечественного ПО | Для госзаказчика и компаний с требованием импортозамещения проверяется отдельно и до выбора, а не после |
Цены у всех четырёх — по запросу и зависят от числа роботов и состава модулей. Для планирования используйте ориентир 150 000–400 000 ₽ в год за одного unattended-робота, а в расчёте выше взято среднее значение 250 000 ₽. Перед подписанием требуйте расчёт в ваших сценариях: типичная ошибка — купить одного робота, а на приёмке обнаружить, что три процесса не помещаются в одно расписание и нужен второй.
Гибрид: робот как временный мост
Есть схема, в которой робот полностью оправдан даже при наличии API: временный мост. Боль есть сейчас, интеграция требует 6–12 недель и согласования доступов с чужой ИТ-службой, а люди тонут в ручном вводе уже в этом месяце. Робот пишется за 3–5 недель, снимает нагрузку и работает, пока строится нормальный обмен.
- 1Недели 1–4: робот закрывает самую тяжёлую часть операции. Не весь процесс, а тот кусок, который даёт большую часть ручных часов.
- 2Параллельно: запрос доступа к API, обследование данных, согласование правил склейки и частоты обмена. Это самая долгая часть, и она не требует остановки работы.
- 3Недели 5–14: разрабатывается интеграция, робот продолжает работать. Расхождения между тем, что ввёл робот, и тем, что приходит по обмену, разбираются заранее, а не в день переключения.
- 4Переключение и две недели параллельной работы: обмен ведёт основной поток, робот остаётся как страховка и не вводит данные.
- 5Вывод робота из эксплуатации и отказ от лицензии. Дата этого шага записывается в договоре с самого начала.
Главный риск гибридной схемы не технический, а организационный: как только робот заработал, боль исчезает, и проект интеграции тихо уходит в конец очереди. Через полтора года компания платит и за лицензию робота, и за переделки, и за простои — и всё ещё не имеет обмена. Поэтому у моста должен быть срок жизни в договоре: 6–12 месяцев, с назначенным ответственным и контрольной точкой в календаре.
Горизонтальная лента времени на 16 недель с двумя дорожками. Верхняя дорожка «Робот»: отрезок «разработка, недели 1–4», далее сплошной отрезок «работает», затем на неделе 16 отрезок «страховка» и метка «вывод из эксплуатации, отказ от лицензии». Нижняя дорожка «Интеграция»: отрезок «запрос доступа и обследование, недели 1–5», далее «разработка, недели 5–14», далее «параллельная работа, 2 недели», далее «основной поток». Вертикальная линия на неделе 14 подписана «переключение». Под лентой пометка «срок жизни моста: 6–12 месяцев, записан в договоре». Чертёжный стиль, подписи по-русски.
Цена ошибки: крюк через робота длиной в полтора года
Посчитаем самый распространённый неудачный сценарий: API существовал, но робота взяли, потому что он дешевле на старте и запускается быстрее. Через 18 месяцев накопленные переделки и простои становятся заметны, и компания всё-таки строит интеграцию.
Переплата за полуторагодовой крюк — 1 133 850 ₽, то есть почти столько же, сколько стоит вся интеграция за три года. Разница возникает не из-за того, что робот плох, а из-за того, что решение принималось по стартовой цене, а не по стоимости владения. Это ровно та ошибка, которую мы разбираем в статьях о структуре смет: сравнивать надо горизонт, а не первый счёт.
Диаграмма из двух столбцов на общей оси в рублях, горизонт 36 месяцев. Левый столбец «Сначала робот, потом интеграция — 2 457 450 ₽» с выделенными сегментами «старт робота 220 000», «владение роботом 1 035 000», «переход 301 250», «интеграция 901 200». Правый столбец «Интеграция сразу — 1 323 600 ₽». Между ними горизонтальная выноска «переплата 1 133 850 ₽». Внизу подпись: «переключение на 18-м месяце». Чертёжный стиль, подписи по-русски.
Когда не нужно ни то ни другое
Самая частая ошибка в этой теме не «выбрали робота вместо API», а «автоматизировали то, что не стоило трогать». Порог считается просто: ежемесячная стоимость владения решением должна быть меньше стоимости ручных часов, которые оно убирает. При ставке 700 ₽ в час с налогами робот с владением 57 500 ₽ в месяц требует не менее 82 часов ручной работы, интеграция с владением 23 400 ₽ — не менее 33 часов. Это пороги безубыточности, а не окупаемости: чтобы вернуть ещё и стартовые вложения, нужен запас сверху.
- Меньше 33 часов ручной работы в месяц: не окупается ни один из вариантов. Работает регламент, шаблон документа, готовая выгрузка в файл или проверочный список — это стоит несколько десятков тысяч рублей и внедряется за неделю.
- 33–82 часа в месяц: интеграция окупается, робот — нет. Если API отсутствует, честный вывод — оставить операцию ручной и вернуться к вопросу при росте объёма.
- Операция выполняется реже раза в неделю: даже при большой длительности сценарий устареет между запусками, и вы будете чинить робота чаще, чем он работает.
- Процесс не описан и меняется каждый месяц: сначала регламент, потом автоматизация. Робот, написанный по нестабильному процессу, переписывается вместе с ним.
- Ручная работа — это на самом деле проверка и принятие решения. Робот скопирует значения, но не заметит, что поставщик прислал не тот документ; тогда автоматизация просто переносит ошибку дальше по цепочке быстрее прежнего.
Введите число сотрудников, занятых операцией, часы в день и стоимость часа с налогами. Стартовые значения подставлены под интеграцию из расчёта выше: 480 000 ₽ разработка с доступами и около 23 400 ₽ в месяц владения. Для робота поставьте 220 000 ₽ и 57 500 ₽ — и сравните сроки окупаемости.
Сколько стоит ручная работа в вашем процессе
Расчёт учитывает только время сотрудников. Возвращённые продажи, снятые ошибки и штрафы, скорость реакции — сверх этой модели. На диагностике считаем по вашим фактическим цифрам.
И последнее, что стоит проговорить прямо. Выбор между роботом и интеграцией почти никогда не является выбором между двумя одинаково хорошими путями: в подавляющем большинстве случаев правильный путь — обмен данными, а робот появляется там, где обмена нет по причинам, от вас не зависящим. Поэтому первый шаг — не сравнение платформ, а письменный ответ на один вопрос: существует ли у смежной системы интеграционный контур и на каких условиях он выдаётся. День на эту проверку экономит миллион на горизонте трёх лет — ровно ту сумму, которая посчитана выше.
Робот автоматизирует не процесс, а способ, которым человек обходил отсутствие интеграции.
