Привет, Хабр! Меня зовут Мирза, я руководитель проектов ROBIN и Robovoice компании SL Soft. «Сколько стоит автоматизировать наш процесс?» — один из самых частых вопросов, с которым к нам приходят компании. Для одного проекта достаточно робота на обычном компьютере. Для другого нужны распознавание документов, языковая модель и сервер с GPU. Даже при одинаковом числе часов разработки бюджеты будут различаться.

Разница становится еще заметнее после запуска. Робот требует доработки, когда меняется сайт. У решения с ИИ нужно разбирать ошибки на новых документах. Голосовой ассистент расходует минуты связи и ресурсы распознавания речи. Эти затраты стоит посчитать до подписания договора.

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

Из чего складывается стоимость

Бюджет проекта удобно разделить на шесть составляющих. Это помогает сравнивать предложения по одинаковому составу, а затем управлять затратами после запуска.

Разработка и покупка серверов формируют бюджет запуска. Подписки, аренда, потребление сервисов и сопровождение — регулярные расходы.

Бюджет первого года = внедрение + лицензии и подписки + инфраструктура + потребление сервисов + сопровождение и согласованные изменения.

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

Соотношение этих расходов зависит от технологии. Можно сэкономить на первоначальной настройке, но затем больше платить за вычисления и разбор ошибок. Или подробнее описать процесс при разработке и упростить дальнейшие изменения.

Почему выбор инструмента меняет бюджет

Роботы и процессы

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

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

Основная эксплуатационная нагрузка появляется при изменениях внешней среды: сайт поменял разметку, приложение обновило форму, API стал возвращать другое поле. Это отдельная работа, которую стоит закладывать в бюджет заранее.

Языковые модели и агенты

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

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

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

OCR и обработка документов

В задаче обработки документов нужно разделять распознавание текста и его смысловую обработку. Хорошо прочитать скан еще не означает правильно извлечь условие договора или применить юридическую правку.

На бюджет влияют качество изображений, количество типов документов, таблицы, специальные символы и требуемая точность. В эксплуатации добавляется стоимость страниц или вычислительных ресурсов, а при использовании внешней LLM — ее потребление. Отдельно учитывается время сотрудников на проверку сложных случаев.

Разработка с помощью ИИ

ИИ‑помощники разработчика меняют способ создания решения. При так называемом vibe coding значительную часть кода генерируется по описанию задачи на обычном языке. Вместо ручной сборки каждого действия разработчик описывает задачу, получает заготовку сценария или кода и дорабатывает ее. В ROBIN Copilot помогает собирать роботов по запросу. Отдельно созданные вайбкодерами сервисы можно подключать к процессам и навыкам ассистента, в том числе вместе с компонентами n8n и Dify.

Предположим, роботу нужно получать реестр счетов из Excel, проверять обязательные поля и создавать заявки в корпоративной системе. ИИ может подготовить чтение таблицы, проверки и обращение к API. Разработчику останется связать это с реальными реквизитами, доступами и правилами обработки ошибок. Это в несколько раз ускоряет разработку.

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

Готовый сервис можно использовать повторно: например, один модуль поиска документов подключить к нескольким роботам. Это сокращает разработку следующих процессов, если интерфейс и правила работы сервиса уже проверены.

Мы сочетаем эти подходы по участкам задачи. Для понимания текста используем модели, для повторяемых действий — роботов и процессы, для нестандартной функции — отдельный сервис. Так экономия достигается там, где она не ухудшает управляемость решения.

Как мы оцениваем проект

Первый ориентир можно получить еще до подробного обследования. Он помогает определить порядок затрат, но не заменяет оценку конкретного процесса. В нашей практике проект разработки RPA‑робота обычно требует 120–300 человеко‑часов с учетом технического задания, разработки и опытной эксплуатации. Проекты RPA + ИИ начинаются примерно от 240 часов. Корпоративный ассистент примерно с десятью навыками и интеграциями с системами и базами знаний — от 800 часов.

Затем уточняем, что стоит за названием задачи. «Обработать счет» может означать перенести строку из Excel. А может — прочитать скан, найти договор, сверить сумму и отправить расхождение на согласование. Во втором случае больше интеграций и проверок.

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

Чтобы перевести часы в рубли, нужен согласованный состав работ и ставка команды. Ставки для RPA, ИИ и интеграционной разработки могут различаться. Поэтому одинаковая трудоемкость еще не означает одинаковую стоимость.

Неизвестные условия проверяем до того, как закладывать запас:

• плохие сканы — тестируем выборку,

• неописанный API — проверяем нужные методы,

• сложные формулировки — испытываем модель на примерах. 

Время на эти проверки включается в оценку.

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

Следом считаем ресурсы. Для RPA проверяем, успеет ли робот завершить работу в отведенное время. Для модели важно какой сервер обеспечит нужную скорость при пиковом числе запросов. Для голоса — сколько разговоров нужно вести одновременно.

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

Кейс 1. Закупки и договоры на торговых площадках

Сотрудники крупной компании ежедневно собирали сведения о закупках и договорах на разных электронных площадках. Сотрудники переносили информацию в таблицы и CRM, следили за новыми процедурами и сроками подписания. Мы автоматизировали два процесса: поиск закупок и мониторинг договоров на площадках.

Роботы собирают сведения более чем с 40 электронных торговых площадок и передают их в CRM. Ежемесячно обрабатывается более 3 000 тендерных процедур и 100 договоров, а высвобожденное время эквивалентно занятости двух сотрудников.

Почему RPA, а не свободно действующий агент

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

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

Сколько потребовалось работ

Трудоемкость работ — примерно 720 часов. Оценка выше ориентира для одного простого робота, потому что здесь два процесса и множество площадок со своими интерфейсами и исключениями. Трудозатраты на основные этапы проекта распределяются так:

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

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

Покупать специальный сервер не требуется: робот может работать на обычном автоматизированном рабочем месте сотрудника. Если подходящий компьютер уже есть, дополнительных затрат на покупку оборудования может не быть. Для робота, управляющего мышью и клавиатурой, нужно выделить отдельный компьютер или если планируется запуск робота за рабочим местом сотрудника, то нужно выделить время, когда сотрудник не пользуется этим же компьютером, например вечер или ночь. На сопровождение закладываем 10–30 часов специалиста в месяц. Это мониторинг, исправление локаторов элементов на сайтах и доработки по новым требованиям.

Здесь основной источник эксплуатационных затрат — изменения площадок. В следующем кейсе сложность связана уже с содержанием самих документов.

Кейс 2. Внесение изменений в нормативные документы

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

Мы объединили OCR, языковую модель и RPA. OCR готовит текст, модель интерпретирует правки, робот получает исходные документы, скачивает закон из справочной системы и формирует обновленную версию. Юрист проверяет результат.

Почему одних правил недостаточно

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

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

Бюджет и результат

Трудоемкость — около 320 часов, примерно 200 часов из которых заняла работа с ИИ: настройка интерпретации правок и проверка результатов на документах.

Сервис корректно вносит 75–80% правок. Через решение проходит около 30 документов в день, экономия составляет примерно 15 минут на документ. При таком потоке это около 7,5 часа работы ежедневно.

Проверка юристом остается частью процесса.

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

Для вычислений нужны рабочее место робота, отдельный OCR‑сервер и GPU‑ресурсы для локальной модели. Для ИИ предусмотрен сервер с 80–96 ГБ видеопамяти, для OCR — 16 ядер и 32 ГБ RAM. При закупке с нуля ориентир для GPU‑сервера с двумя A6000 — 2–3 млн рублей, с H100 — 3–4 млн рублей. На отдельный сервер для OCR может потребоваться еще около 500 тыс. рублей. Если серверные ресурсы уже есть, вместо новой закупки достаточно выделить мощность под задачу.

На сопровождение подобного решения потребуется 20–40 часов в месяц (в зависимости от количества и сложности поступающих на обработку документов). Значительная часть этого времени может уходить на вопросы «почему документ обработан именно так» и «почему эта правка не внесена». Нужно воспроизвести ситуацию, разобрать контекст, уточнить промпт и проверить, что изменение не ухудшило обработку других документов.

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

Кейс 3. Корпоративный ассистент в документообороте

Следующее по масштабу решение — помощник, связанный с несколькими функциями корпоративной системы. Ассистент для крупной организации связывает содержание документа, его реквизиты, участников и доступные действия в системе.

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

Почему это больше, чем чат по базе знаний

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

Альтернатива — дать агенту больше свободы в выборе инструментов и порядка действий. Это полезно для разнообразных запросов, но требует дополнительных проверок полномочий, корректности последовательности и результатов операций. В текущей архитектуре ИИ используется внутри заданных процессов. Расширение до более самостоятельного агента может рассматриваться как отдельный этап развития.

Работы и эксплуатация

Трудоемкость такого решения — около 1 400 человеко‑часов.

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

Из лицензий нужны: BPM‑модуль для управления процессами, несколько исполнителей RPA, оркестратор, модуль ИИ и поиск по документам на основе RAG. Оркестратор распределяет задания между роботами. RAG находит фрагменты документов и передает их модели вместе с вопросом. При выборе лицензий отдельно считаем сотрудников, которые будут пользоваться ассистентом, и число роботов, работающих одновременно.

По ресурсам это уже серверная инфраструктура с отдельным размещением процессов и моделей, балансировкой и несколькими исполнителями роботов. Для LLM предусмотрены два сервера с 96 ГБ видеопамяти каждый. Если каждый из двух LLM‑серверов комплектовать парой A6000, предварительный бюджет только этой части оборудования составит 4–6 млн рублей. Серверы процессов, хранение и резервирование считаются дополнительно. Имеющаяся виртуальная инфраструктура может закрыть часть этих потребностей без покупки отдельных машин.

Сопровождение и развитие требуют около 120 часов в месяц, или 1 440 часов за полный год. Это сопоставимо с первоначальным внедрением. В объем входят не только инциденты, но и развитие системы: новые функции, изменения интеграций, справочников и сценариев.

Следующий кейс про голосовых ассистентов.

Кейс 4. Голосовой ассистент для входящей линии клиники

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

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

Почему стоимость зависит от интеграции

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

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

Из чего складывается внедрение

Работы по описанному набору сценариев и интеграций требуют ориентировочно 650 часов команды внедрения:

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

Входящую линию рассчитываем на поток до 100 000 звонков в месяц и до 50 одновременных разговоров. На пилоте проверяем, завершает ли ассистент запись без помощи оператора, правильно ли передает сложные обращения и совпадает ли результат разговора с данными в медицинской системе.

Для решения нужны лицензия платформы голосовых ботов (например Robovoice), подключение телефонии, распознавание и синтез речи (SST, TTS). Если применяется LLM, добавляется соответствующий сервис или локальная модель. В этом проекте предусмотрено облачное размещение.

При размещении платформы голосовых ассистентов в контуре организации базовый ориентир для сервера: AMD EPYC серии 7000 или новее с 32 ядрами, не менее 32 ГБ RAM, два NVMe‑диска по 2 ТБ и сетевой интерфейс от 1 Гбит/с. Для первоначального бюджета такой сервер можно оценить примерно в 0,7–1,5 млн рублей. В эту сумму не входят отдельные GPU‑ресурсы для локальных моделей. При облачном размещении покупка сервера заменяется расходами на услугу.

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

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

Сколько закладывать на лицензии и оборудование

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

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

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

Например, минимальный набор — среда разработки и один исполнитель, дают ориентир около 550 тыс. рублей в год. Если добавить ИИ и OCR, сумма по такой модели составит примерно 1,5–1,8 млн рублей. Если имеющиеся лицензии покрывают нужную функциональность и нагрузку, для нового проекта достаточно приобрести недостающие компоненты. Продление уже используемых лицензий остается в общем эксплуатационном бюджете. Число процессов при этом не обязательно увеличивает число лицензий на исполнителей роботов: несколько роботов могут работать по очереди на одном рабочем месте.

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

На октябрь 2026 года российские поставщики публикуют цены порядка 0,55–0,75 млн рублей за A6000 на 48 ГБ, то есть 1,1–1,5 млн за пару, и от 2 млн рублей за H100 на 80 ГБ. Это цены ускорителей, к которым добавляются совместимая серверная платформа, память, диски, питание и охлаждение. На этой основе предварительно оцениваем готовый сервер с двумя A6000 в 2–3 млн рублей, а с H100 — в 3–4 млн.

Для обычных серверов разброс тоже значителен. Опубликованные предложения на 32-ядерные конфигурации дают порядок от 0,6 до 1,5 млн рублей. 

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

Что показывает сравнение проектов

Различия становятся нагляднее, если поставить рядом трудоемкость, бюджет работ и регулярную нагрузку.

У решения для обработки документов меньше часов внедрения, чем у набора RPA‑сценариев, но выше требования к вычислениям и сложнее разбор инцидентов. Корпоративный ассистент дороже за счет широты интеграций и пользовательских сценариев. В голосовом проекте существенная часть регулярных расходов зависит от потока разговоров.

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

Как посчитать поддержку и окупаемость

Чтобы перевести поддержку в деньги, умножаем месячные часы по каждой роли на ее ставку и на число месяцев. Для торговых площадок получается 120–360 часов в год, для документного решения — 240–480 часов, для корпоративного ассистента — около 1 440 часов. Для сопровождения базовых голосовых сценариев ориентир составляет 120 часов в год. Это объемы за полный год эксплуатации, а не автоматически за первый календарный год проекта.

Это бюджет труда, к которому добавляются лицензии, инфраструктура и потребление сервисов. Гарантийное устранение дефекта, поддержка платформы, адаптация конкретного решения и создание новой функции — разные работы. Их границы стоит зафиксировать в договоре, чтобы после запуска было понятно, кто отвечает за инцидент и из какого бюджета оплачивается изменение.

Расходы на ИИ зависят от размещения. В облаке считаем входные и выходные токены, повторные попытки и дополнительные операции. В локальном контуре — оборудование или аренду ресурсов, обслуживание и загрузку вычислений. Общий сервер может обслуживать несколько решений, но его стоимость все равно нужно распределить между ними.

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

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

Как принять решение о внедрении

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

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

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