Прежде чем ставить робота на систему «без API», проверяются пять каналов обмена: партнёрская документация вендора, штатная выгрузка в файл, доступ к базе на чтение, конструктор отчётов внутри самой системы и ЭДО. Примерно у половины систем, которые заказчик на первом созвоне называет закрытыми, находится хотя бы один рабочий канал — и он дешевле робота в два-три раза на дистанции двух лет.
Это не придирка к формулировке. Робот, поставленный там, где был файловый обмен, обходится дороже на 594 400 ₽ за два года — расчёт приведён ниже. И деньги здесь не главное: вместе с роботом вы получаете сценарий, который падает от чужого релиза, и очередь ручного добора после каждого падения. Обмен файлами такого свойства не имеет.
Ниже — порядок проверки на три рабочих дня, три критерия, после которых робот становится обоснованным выбором, а не признанием лени, и разница между браузерной системой и настольным приложением, которая определяет, сколько раз в год вы будете чинить сценарий. Общая механика роботов, срок жизни сценария и структура расходов разобраны отдельно в материале как устроен RPA и чем он отличается от интеграции — здесь мы считаем, что она читателю уже известна.
Что на самом деле значит «у системы нет API»
Фраза «у системы нет API» в девяти случаях из десяти означает одно из трёх, и ни одно из этих трёх не равно «обмен невозможен». Первое: интерфейс есть, но он не в публичной документации, а в партнёрском разделе или в платном тарифе. Второе: программного интерфейса действительно нет, но есть выгрузка в файл — а это тоже канал обмена, просто медленный. Третье: спрашивали не тех и не так — вопрос «есть ли у вас API» техподдержка первой линии отбивает шаблонным «нет», а вопрос «как ваши клиенты переносят данные в 1С» тот же человек отвечает содержательно.
Любой штатный способ получить данные из системы или положить их в неё, не трогая экран: программный интерфейс, выгрузка в файл, доступ к базе, обмен через оператора ЭДО. Робот работает поверх экрана и потому в интеграционный контур не входит — он его имитирует. Подробнее о самих интерфейсах — в разборе что такое API и вебхук простыми словами.
Практическая разница между контуром и роботом одна: контур меняется тогда, когда договорились об изменении, а экран меняется тогда, когда вендору захотелось перекрасить кнопку. Поэтому один найденный канал обмена стоит недели поисков — он снимает не часть расходов, а весь класс расходов на переделки.
Пять мест, где обмен обычно всё-таки находится
Проверяются по очереди, от самого дешёвого в эксплуатации к самому спорному. Первые два дают полноценный контур, третий — быстрый, но юридически скользкий, четвёртый почти никогда не вспоминают, пятый работает только для документооборота с контрагентами.
- 1Партнёрская документация и платный тариф вендора
Интерфейс обмена часто существует, но живёт в партнёрском кабинете, в описании отдельного модуля или в старшем тарифе. Спрашивать надо не «есть ли API», а «как ваши клиенты выгружают данные в 1С и кто это уже делал». Второй вопрос менеджеру продлений: «сколько стоит модуль обмена и что в него входит».
- 2Штатная выгрузка в файл
CSV, XLSX, XML, DBF по кнопке или по расписанию — это полноценный канал. Файл кладётся в папку, обработчик разбирает его и грузит в учётную систему. Такой обмен переживает перекраску интерфейса, потому что не смотрит на интерфейс вообще. Способы приёма файлов на стороне 1С разобраны в материале про способы обмена с 1С.
- 3Доступ к базе данных на чтение
MS SQL, PostgreSQL, Firebird — если администратор может дать учётную запись только на чтение, данные забираются запросом за минуты вместо часов кликанья. Самый быстрый способ и самый рискованный по договору поддержки: об этом отдельный раздел ниже.
- 4Конструктор отчётов внутри самой системы
У большинства отраслевых и учётных систем есть встроенный генератор отчётов. Отчёт нужного состава, выгружаемый в файл по расписанию, — это фактически интерфейс обмена, написанный вашими руками внутри чужой системы. Он не ломается от смены вёрстки, потому что живёт на слое данных, а не на слое экрана.
- 5Обмен через ЭДО
Если между вами и контрагентом уже ходят УПД, акты и счета-фактуры через Диадок, Saby ЭДО или 1С-ЭДО, структурированные данные у вас есть — и робот, который перебивает те же цифры с экрана кабинета, это чистая потеря. Как устроен канал и что нужно для старта — в разборе обмена документами через ЭДО.
Есть и шестой, половинчатый вариант: почтовые уведомления системы. Если она умеет присылать письмо о новом заказе или изменении статуса, это событийный канал — небогатый, но достаточный, чтобы не опрашивать экран каждые десять минут. Разбор писем стоит дешевле робота и не зависит от вёрстки кабинета.
Карта связей. В центре прямоугольник «Учётная система контрагента» с табличкой «API нет». Вокруг пять узлов со стрелками к центру, у каждой стрелки подпись, что передаётся: «Партнёрская документация вендора — модуль обмена», «Выгрузка в файл — CSV, XLSX, XML», «База данных — доступ на чтение», «Конструктор отчётов — отчёт по расписанию», «ЭДО — УПД и акты структурно». Шестой узел «Робот по экрану» нарисован пунктиром, стоит в стороне и подписан «последний вариант». Приглушённая палитра, чертёжная штриховка, подписи по-русски.
Порядок проверки: три дня инженера против робота на два года
Проверка занимает 23 часа работы инженера и делается до того, как в смету попадает слово «робот». Порядок важен: первые два шага дают ответ примерно в половине случаев, и на них проверка часто заканчивается.
- 1Запрос вендору правильным вопросом: не «есть ли API», а «как ваши клиенты переносят данные в учётную систему и какой модуль для этого нужен». Ответ фиксируется письмом — он же пригодится, если позже придётся обосновывать выбор робота.
- 2Обход всех пунктов меню «Экспорт», «Выгрузка», «Обмен», «Отчёты», «Интеграции» с записью форматов и полей. Проверяется не наличие кнопки, а состав выгрузки: если в файле нет ключевого поля, канал не годится.
- 3Разбор того, чем система пользуется сама. У любой браузерной системы её собственный интерфейс ходит за данными по внутренним запросам — они видны в панели разработчика браузера и почти всегда структурированы. Это не публичный интерфейс, и использовать его можно только после проверки лицензионного соглашения.
- 4Разговор с администратором о базе: где она лежит, какая СУБД, можно ли выдать учётную запись на чтение и что об этом написано в договоре сопровождения.
- 5Проверка канала ЭДО и почтовых уведомлений: какие документы уже приходят структурированными и о каких событиях система умеет писать письмо.
Ставка 3 000 ₽/час — рыночная стоимость часа инженера-подрядчика; если проверку делает свой сотрудник, считайте по полной стоимости его часа — с налогами, отпуском и рабочим местом, — а не по окладу. Соотношение расходов на проверку и на ошибку здесь примерно 1 к 13 — редкий случай, когда обследование окупается арифметически, а не «в принципе».
Чтение базы напрямую: самый быстрый способ и самый спорный
Прямой запрос к базе автоматизируемой системы — соблазн, перед которым трудно устоять: данные забираются за минуты, ничего не ломается от смены интерфейса, разработка стоит в разы дешевле робота. Проблема не техническая, а договорная.
У большинства российских вендоров учётных и отраслевых систем в договоре сопровождения есть пункт о недопустимости прямого доступа к базе данных помимо интерфейса приложения. Формулировки разные, последствие одно: при обращении в поддержку вендор вправе сослаться на изменённый или неподдерживаемый контур и отказать в разборе инцидента. Даже если вы читали строго на чтение и ничего не меняли — доказывать это будете вы.
Отсюда правило: доступ к базе используется только после письменного согласования с вендором, и в согласовании фиксируются три вещи — учётная запись работает на чтение, список читаемых таблиц закрыт, при обновлении версии структура может измениться без уведомления. Последний пункт особенно важен: база — это внутренняя кухня продукта, вендор не обязан сохранять названия колонок между релизами, и обмен, построенный на ней, ломается не реже робота. Отдельная тема — персональные данные: выгрузка таблицы клиентов на свою сторону создаёт новое место хранения, которое надо описывать в политике обработки данных и защищать наравне с основной базой.
Схема-алгоритм сверху вниз. Пять пронумерованных блоков подряд: «1. Запрос вендору», «2. Обход выгрузок», «3. Внутренние запросы системы», «4. База на чтение», «5. ЭДО и письма». От каждого блока вправо отходит стрелка «нашли» к общему блоку «Обработчик обмена: 140 000 ₽ и 8 000 ₽/мес». От последнего блока вниз идёт стрелка «не нашли» к блоку «Робот: 926 400 ₽ за 24 месяца». Сбоку от всей цепочки скобка с подписью «23 часа, 69 000 ₽». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Веб-интерфейс против настольного приложения
Если канал обмена не нашёлся и робот всё-таки нужен, следующий вопрос — где он будет работать. Стабильность сценария различается кратно в зависимости от того, кликает робот в браузере или в настольном приложении, и это надо заложить в бюджет до старта.
| Что сравниваем | Браузерная система | Настольное приложение |
|---|---|---|
| Как робот находит элемент | По структуре страницы: идентификатор поля, имя, текст рядом | По объектной модели окна, а где её нет — по координатам и картинке |
| Что ломает сценарий | Переезд поля в другой блок, новое всплывающее окно, смена вёрстки | Смена версии, масштаб экрана, тема оформления, разрешение монитора |
| Поведение при обновлении | Часть сценария выживает: привязка по имени поля переживает перекраску | Чаще падает целиком: при сдвиге окна съезжают сразу все координаты |
| Нужна ли активная сессия пользователя | Нет, робот работает в отдельном профиле браузера | Да, нужна сессия операционной системы — отсюда отдельная машина и лицензия |
| Переделок в год на практике | 3–4 | 2–3 на объектной модели, 5–8 на координатах |
| Срок жизни сценария | 15–24 месяца во внутренней системе, 6–12 на портале вендора | 18–30 месяцев при регулярных обновлениях, 3–5 лет на замороженной версии |
Вывод из таблицы практический: если у системы есть и настольный клиент, и веб-кабинет, робота ставят на тот из них, который реже обновляют, а не на тот, который удобнее человеку. И отдельно проверяют, как именно платформа привязывается к элементам: разница между привязкой по объектной модели и по координатам — это разница между двумя ремонтами сценария в год и восемью. Что при этом стоит записать в договор с подрядчиком, разобрано в статье почему роботы ломаются и сколько стоит поддержка.
Сравнение в две колонки. Левая колонка «Браузерная система»: схематичное окно браузера с формой, выноски «привязка по имени поля», «3–4 переделки в год», «15–24 месяца жизни», «сессия пользователя не нужна». Правая колонка «Настольное приложение»: схематичное окно программы с сеткой координат поверх, выноски «объектная модель или координаты», «2–3 или 5–8 переделок в год», «18–30 месяцев жизни», «нужна активная сессия и отдельная машина». Внизу общая полоса-подпись «выбираем ту сторону, которую реже обновляют». Чертёжный стиль, приглушённая палитра, подписи по-русски.
Облачная система, которая меняется без предупреждения
Отдельный случай — облачный сервис, у которого релизы выходят раз в две недели и никто вас о них не уведомляет. В договоре с SaaS-вендором обязанности предупреждать об изменениях интерфейса обычно нет вообще: он меняет свой продукт, а не ваш. Робот здесь живёт 6–12 месяцев, и это надо принять как данность, а не бороться с ней.
- Запросить у вендора канал уведомлений о релизах — рассылку, канал, страницу изменений. Это бесплатно и иногда работает.
- Поставить контрольный прогон на тестовой записи в 6 утра, до основной нагрузки: сломанный сценарий обнаруживается за два часа до того, как в него пойдёт реальный поток.
- Сверять контрольную сумму: число обработанных строк на выходе должно совпадать с числом строк на входе, расхождение сразу уходит в уведомление ответственному.
- Сократить число задеваемых экранов: сценарий, который проходит два экрана вместо семи, ломается втрое реже — просто потому, что вероятность перерисовки распределена по экранам.
- Заложить в бюджет шесть переделок в год вместо трёх: на активно развивающемся портале владение уходит с 38 600 ₽ до 57 800 ₽ в месяц, и порог окупаемости поднимается с 56 до 83 часов ручной работы.
- Держать письменный ручной регламент на три дня: что делают люди, пока сценарий чинят. Без него первое же падение превращается в остановку участка.
И главное: если облачный сервис ваш, а не контрагента, — прежде чем строить робота, запросите у вендора интеграционный контур официально. У SaaS-продуктов он появляется чаще, чем у коробочных, и иногда включается в старший тариф за сумму меньше годовой лицензии робота.
Три критерия, после которых робот обоснован
Робот перестаёт быть признанием лени и становится инженерным решением, когда выполнен хотя бы один из трёх критериев. Не «нам так проще», не «интеграция долго» — а вот это.
- 1Система не ваша, и требовать интерфейс не у кого
Портал заказчика, кабинет банка, площадка, государственная система. Вы не сторона в решении о том, будет ли там обмен. Здесь робот — не компромисс, а единственный способ, и вопрос только в том, окупает ли объём его содержание.
- 2Вендор отказал письменно или назвал цену выше стоимости робота
Модуль обмена за 900 000 ₽ при процессе, который проживёт полтора года, — это отказ, оформленный как предложение. Считать надо не «модуль против разработки сценария», а полную стоимость владения обоими вариантами на весь срок жизни процесса; методика — в разборе стоимости владения автоматизацией.
- 3Процесс закончится раньше, чем окупится интеграция
Миграция между системами, разбор архива после слияния, сезонная кампания, сверка за три прошедших года. Сценарий пишется на срок, окупается объёмом и выключается. Дата вывода из эксплуатации записывается в договор — без неё временный мост становится постоянным сооружением.
Если ни один критерий не выполнен, а канал обмена нашёлся, дальше считается разница. Ниже — тот же процесс в двух вариантах: робот по методике владения из разбора механики RPA и обработчик найденной файловой выгрузки.
Обратите внимание на структуру, а не только на итог. У робота 100 % расходов — повторяющиеся: лицензия, переделки, простои. У обработчика файлов 42 % суммы приходится на разовую разработку, и дальше он почти не потребляет внимания. Именно поэтому робот выигрывает на коротком горизонте и проигрывает на длинном — и именно поэтому его нельзя оценивать по цене запуска.
Двухосевой график накопленных расходов за 24 месяца. Оси: месяцы от 0 до 24 и рубли от 0 до 1 000 000 ₽. Сплошная линия «Робот» стартует из нуля и растёт по 38 600 ₽ в месяц до 926 400 ₽. Штриховая линия «Файловый обмен» стартует с отметки 140 000 ₽ и растёт по 8 000 ₽ в месяц до 332 000 ₽. Точка пересечения линий около пятого-шестого месяца выделена и подписана «дальше робот дороже каждый месяц». Справа подписан разрыв «594 400 ₽». Чертёжная сетка, приглушённая палитра, подписи по-русски.
Когда не надо ставить робота даже при отсутствии API
Отсутствие интеграционного контура — необходимое условие для робота, но не достаточное. Шесть ситуаций, в которых мы отговариваем даже тогда, когда обмена действительно нет.
- Объём ниже порога. Самое дешёвое владение роботом — 27 750 ₽ в месяц на системе, которую вообще не обновляют. При ставке 700 ₽/час это 40 часов ручной работы. Операция на 25 часов не окупится ни при какой платформе и ни при каком подрядчике.
- Процесс меняется каждый квартал. Сценарий переписывается вместе с процессом, и вы платите за разработку четыре раза в год. Сначала процесс стабилизируют и описывают, потом автоматизируют — порядок обратный не работает.
- Цена ошибки выше экономии. Платёжные поручения, отгрузочные документы, налоговая отчётность: робот ошибается тихо и продолжает вводить. Либо закладывается сплошная сверка результата, либо операция остаётся человеку.
- Процесс проще отменить. Отчёт, который никто не открывает, сверка, дублирующая другую сверку, перенос данных в систему, из которой их потом никто не берёт. Обследование регулярно находит такие операции — и отмена стоит ноль.
- Систему планируют менять в ближайший год. Сценарий не переносится на новую систему: он привязан к экранам старой. Робот на систему, у которой уже утверждён проект замены, — это списание бюджета в чистом виде.
- Лицензионное соглашение запрещает автоматизацию интерфейса. У части вендоров, особенно у банковских и государственных кабинетов, есть прямой запрет на эмуляцию действий пользователя. Это проверяется до проекта, а не после блокировки учётной записи.
Общее правило простое: робот оправдан там, где отсутствие обмена — чужое решение, а не ваше. Если контур можно получить переговорами, деньгами или настройкой внутри самой системы, его получают. Робота ставят тогда, когда все пять каналов проверены, ответы записаны, и ни один из них не сработал.
