Роботизация процессов начинается с простого вопроса: на каждом шаге заранее известен правильный ответ или сотруднику приходится разбираться в ситуации? Если ответ известен и его можно записать в виде правила, подойдет программный робот RPA. Если для обработки документа или исключения нужно толковать смысл и задачу не удается описать правилами, стоит проверить, подойдет ли ИИ. Во многих процессах нужны оба инструмента.
Разница в цене появляется там, где правило перестает давать однозначный ответ. Для робота заранее описывают каждый шаг: откуда взять значение, куда его внести, что делать при расхождении. Модель подключают к документам, где одно и то же поле может выглядеть по-разному или требовать сопоставления со справочником. Ее результат приходится проверять на реальных примерах. Поэтому платить за ИИ имеет смысл только там, где обычного правила действительно недостаточно.
Нейропрем внедряет ИИ и автоматизирует бизнес-процессы и производство. По этой теме мы предлагаем распознавать счета, накладные, рукописные заявки и чертежи там, где нужно понять содержание документа. Проверенные данные можем передавать в 1С и другие действующие программы по точным правилам.
Чем программный робот отличается от модели ИИ?
Программный робот выполняет заранее заданный сценарий в других программах. Модель ИИ используют для распознавания и интерпретации текста, изображений или речи, а ее результат проверяют по заданным критериям. Робот может открыть письмо, скачать вложение, зайти в учетную систему, перенести данные в нужные поля и сформировать отчет. По сути, это цифровой исполнитель с мышью и клавиатурой.
RPA расшифровывается как роботизированная автоматизация процессов. RPA-робот работает с интерфейсами программ: нажимает кнопки, заполняет формы и считывает данные с экрана.
Модель ИИ решает другую часть задачи. Она может определить, что написано в документе свободной формы, сопоставить разные названия одного материала, выделить риск в договоре или понять смысл голосового сообщения. Ее ответ зависит от входных данных и контекста, поэтому один и тот же тип документа может потребовать разных решений.
Сравнение по шагам процесса:
| Что происходит на шаге | Что подходит |
|---|---|
| Действие всегда определяется точным условием | RPA или обычная программная автоматизация |
| Нужно понять текст, изображение или речь | ИИ |
| Есть несколько допустимых вариантов, выбор зависит от контекста | ИИ с правилами проверки |
| После распознавания нужно внести данные в старую программу | ИИ для распознавания плюс RPA для ввода |
| Ошибка может привести к платежу, отгрузке или остановке | Правила, контроль сотрудника и журнал действий |
Чем строже операция и выше цена неверного действия, тем полезнее робот: при одинаковом входе он выполняет один и тот же сценарий.
Как проверить свою задачу по исключениям из правил?
Пройдите один реальный процесс по шагам и на каждом шаге спросите: здесь есть заранее известный правильный ответ? Если да, шаг можно описать условием. Если сотрудник толкует смысл или каждый раз решает по обстоятельствам, перед вами исключение. Само наличие исключения еще не требует ИИ: для него тоже может быть заранее определено действие.
Возьмем обработку входящей накладной. Сотрудник получает файл, находит номер, дату, поставщика и позиции, сверяет их с заказом, затем переносит сведения в учетную систему.
Для проверки полезно выписать, что бывает в реальной работе:
- файл всегда приходит в одном формате или поставщики присылают сканы, фотографии и разные шаблоны;
- название поставщика и товара совпадает со справочником или написано по-разному;
- расхождение всегда обрабатывается одной командой или снабженец выясняет причину;
- после проверки данные попадают в одну и ту же форму или маршрут зависит от документа;
- спорный документ можно отложить сотруднику или система обязана провести его автоматически.
Если поля находятся в постоянных местах, справочники совпадают, а маршрут один, ИИ добавит стоимость без заметной пользы. Если документ нужно распознать, сопоставить со справочником и определить тип расхождения по контексту, стоит проверить модель на реальных примерах.
Формализуемое исключение выглядит так: если сумма в накладной не совпадает с заказом, документ всегда уходит снабженцу без проведения. Здесь робот способен выполнить правило. Для ИИ возникает работа другого рода: понять, что «лист х/к» в документе поставщика соответствует позиции «прокат холоднокатаный» во внутреннем справочнике, хотя точного совпадения нет.
Для проверки модели нужен набор документов с уже известным правильным результатом. В него стоит включить типовые формы, плохие сканы, редкие названия и спорные случаи. Затем отдельно смотрят, какие ответы система дала верно, где ошиблась и в каких ситуациях сама передала документ человеку. Такая проверка показывает границу применимости лучше, чем демонстрация на одном удобном файле.
При оценке учитывают и количество, и виды исключений. Десять одинаковых документов с одним понятным отклонением проще автоматизировать, чем два документа, для которых нужны разные экспертные решения.
Когда RPA будет дешевле и надежнее?
RPA подходит для стабильного процесса с предсказуемым входом и небольшим числом формализованных исключений. Особенно полезен робот, когда сотрудник переносит данные между программами, у которых нет удобной интеграции.
Типовые задачи выглядят так:
- скачать выписки и разнести их по заданным правилам;
- сверить две таблицы по одинаковому идентификатору;
- сформировать стандартный отчет;
- создать карточку по данным из утвержденной формы;
- перенести проверенные сведения из одной учетной системы в другую;
- собрать файлы из нескольких кабинетов в установленное время.
У RPA есть и слабое место. Робот часто привязан к расположению полей, названиям кнопок и порядку экранов. После обновления программы, появления нового окна или изменения формы сценарий может остановиться. Значит, в бюджет входит поддержка, а владелец процесса должен сообщать об изменениях заранее.
После запуска результат проверяют регулярно: считают, сколько операций робот довел до конца и сколько пришлось доделывать сотрудникам.
До выбора RPA стоит проверить, могут ли программы передавать данные напрямую. Например, если 1С сама принимает документы из другой системы по расписанию, такая связь часто устойчивее кликов по экрану. Робот полезен там, где программа закрыта, доработка затянется или временно нужно связать старую и новую системы. Это решение тоже требует расчета срока жизни: временный мост не стоит проектировать как постоянную платформу.
Стабильность процесса важнее его внешней простоты. Операция из трех кликов может быть плохим кандидатом, если экран меняется каждую неделю. Цепочка из двадцати действий может хорошо подойти роботу, если вход одинаков, правила утверждены, а программы обновляются предсказуемо.
Роботизация не исправляет сам процесс. Если сотрудники выполняют лишние согласования или несколько раз вводят одни сведения, робот лишь ускорит эту цепочку. Перед разработкой стоит убрать шаги, которые больше никому не нужны.
Когда стоит проверять ИИ?
ИИ стоит проверять на тех шагах, где входные данные меняются, а правильное действие нельзя полностью записать набором условий. Обычно это работа с текстом, изображением, речью и решениями, для которых сотрудник учитывает смысл. Если модель не дает приемлемого результата, решение остается сотруднику.
Например, модель может прочитать счет, накладную или рукописную заявку, найти нужные поля и сопоставить свободное название со справочником. В производстве она может разобрать чертеж или схему, чтобы подготовить маршрут на станок либо спецификацию.
Модель не следует воспринимать как сотрудника, которому можно отдать любую неоднозначность. Для нее нужно определить:
- Какие данные она получает.
- Как выглядит приемлемый результат.
- Какие ошибки допустимы.
- В каких случаях решение уходит человеку.
- Как проверить качество на реальных примерах.
Чем выше цена ошибки, тем уже должны быть полномочия модели. Она может подготовить данные, предложить классификацию или отметить риск, но платеж, изменение норматива или окончательное решение по сложному документу лучше проводить через утвержденное правило либо сотрудника.
Нужно ли выбирать одну технологию на весь процесс?
В одном процессе можно сочетать несколько технологий. ИИ разбирает неоднозначный вход, RPA исполняет точные действия, правила ограничивают допустимые операции, а сотрудник принимает редкие или рискованные решения.
Рассмотрим возможный сценарий с заявкой на закупку. Модель читает письмо и вложение, находит позиции, количество и желаемый срок, сопоставляет свободные названия с номенклатурой. Если модель не пометила ни одно поле как сомнительное и обязательные поля заполнены, робот открывает учетную систему и создает черновик заявки. Если поставщик указан неоднозначно, количество конфликтует с вложением или позиции нет в справочнике, документ получает ответственный сотрудник.
Нейропрем может связать распознавание документов с 1С, другими учетными системами и ЭДО. Если документы нельзя передавать за пределы компании, обработка может работать на сервере заказчика.
За что платят, когда ИИ стоит дороже робота?
В цене решения оплачивается не название технологии, а сложность неопределенной части процесса. Для RPA нужно описать сценарий, подключить программы, настроить права и поддерживать робота после изменений интерфейсов. Для ИИ к этому добавляются подготовка примеров, проверка качества, передача сотруднику полей, которые модель пометила как сомнительные, вычислительная инфраструктура и контроль ошибок.
Сравнивать только стоимость лицензий недостаточно. По исследованию аналитического центра «Круги Громова» за 2026 год, на лицензии приходится лишь 15-20% совокупных затрат на RPA. Остальные расходы связаны с содержанием компетенций и обслуживанием роботов. Для ИИ логика похожа: доступ к модели составляет только часть работающей системы.
Переплата возникает в трех случаях:
- ИИ ставят на шаг, который полностью описывается правилами;
- робота заставляют обходить постоянно меняющийся интерфейс, хотя доступна прямая интеграция;
- автоматизируют весь процесс сразу, не выделив дорогие исключения и проверяемый участок.
Есть и обратная ошибка. Попытка описать сотнями правил все варианты свободного документа может обойтись дороже, чем узкая модель с понятной передачей сложных случаев сотруднику.
Как принять решение до обсуждения платформы?
Сначала разметьте процесс, затем выбирайте технологию. Для первичной оценки достаточно одной повторяющейся задачи и нескольких реальных примеров, включая неудобные случаи.
- Запишите начало и конец процесса: что приходит на вход и какой результат нужен.
- Разделите работу на отдельные действия сотрудника.
- Для каждого действия отметьте, известен ли правильный ответ заранее.
- Соберите исключения за обычную рабочую неделю и сгруппируйте их по причинам.
- Отдельно выделите действия с высокой ценой ошибки.
- Проверьте, какие программы, документы и права доступа потребуются.
- Решите, какие случаи система обязана передавать человеку.
После такой разметки уже можно отделить правила от шагов, где стоит проверять модель. Следующий выбор возникает при сравнении решений: два предложения с одинаковой пометкой «автоматизация с ИИ» могут по-разному распределять работу между моделью, учетной системой и сотрудником. В одном варианте система только распознает документ, в другом еще и проводит его без подтверждения. От этого меняются риск ошибки, объем интеграции и ручная проверка после запуска.
Если вы выбираете решение для процесса, где рядом стоят свободные документы и точные действия в учетной системе, оставьте имя и телефон в форме ниже. Мы перезвоним в течение двух-трех часов и обсудим, как распределить работу между распознаванием, правилами и проверкой сотрудника. Это поможет определить границы первого внедрения и требования к нему: что система делает сама, что готовит как черновик и где останавливается до подтверждения человека.