Запрос «внедрить ИИ в 1С» на диагностике нередко оказывается задачей для интеграционного скрипта, который ваш программист 1С напишет за неделю. Бывает и наоборот: RPA-робота ставят разбирать письма клиентов, и он ломается на каждой новой формулировке. Скрипт, робот и языковая модель решают разные задачи, и ошибка в выборе стоит месяцев. Разберем, как отличить одно от другого на типовых задачах из 1С и CRM и когда наш прототип за 600 тыс. ₽ вам не нужен.
Три инструмента и где каждый на своем месте
Интеграция или скрипт
Данные переходят между системами через программный интерфейс (API) по жестким правилам. Пришла оплата — изменить статус сделки. Создан заказ в CRM — создать документ в 1С. Это самый дешевый в эксплуатации и самый предсказуемый вариант. Условия: вход структурирован, правила известны, у систем есть API.
RPA-робот
Программа, которая нажимает кнопки в интерфейсе вместо человека: открывает окно, копирует поле, вставляет в другое. Нужна, когда API нет: старая система, внешний портал, банк-клиент. Слабое место — зависимость от интерфейса. Сдвинулась кнопка после обновления — робот кликает не туда.
Языковая модель
Читает неструктурированный текст — письма, сканы, сообщения в свободной форме — и превращает его в структуру: поля, категории, черновик ответа. Ошибается вероятностно, поэтому рядом с ней всегда нужен контроль качества и маршрут для спорных случаев.
Главный вопрос: какой у задачи вход
Если человек на шаге процесса работает с полями — номер договора, сумма, контрагент из справочника, — вход структурирован, и модель не нужна. Если он читает текст, написанный другим человеком, и сам решает, что в нем важно, вход неструктурирован. Именно на этом шаге модель может пригодиться.
Второй вопрос: можно ли записать все правила. Если правила помещаются на две страницы и не меняются каждый месяц, их дешевле запрограммировать. Модель нужна там, где вариантов столько, что перечислить их нельзя.
Шесть признаков для выбора
На диагностике мы оцениваем процессы по объему, повторяемости и цене ошибки. Для выбора инструмента к ним добавляются признаки, связанные с самой задачей и системами.
- Вход: поля в системе или свободный текст, скан, голос.
- Правила: можно ли перечислить их полностью.
- Объем: сколько операций в день и сколько минут человека уходит на каждую.
- Вариативность: сколько форматов входа и как часто появляются новые.
- Цена ошибки: что случится, если операция выполнена неверно, и можно ли ее отменить.
- Доступ: есть ли у системы API или только экранный интерфейс.
Структурированный вход, полные правила и API — интеграция. Тот же вход без API — RPA. Свободный текст и бесконечная вариативность — модель на шаге чтения. Малый объем при любом входе — скорее всего, автоматизация не окупится вовсе.
Когда хватит интеграции без ИИ
Вот типовые задачи, где модель только добавит стоимость и вероятность ошибки там, где ее не было.
- Перенос оплат из банковской выписки в 1С и смена статуса сделки в CRM.
- Создание сделки в CRM по заявке с сайта, где поля уже заполнены формой.
- Синхронизация справочника контрагентов между CRM и 1С.
- Ежедневный отчет по фиксированному списку показателей.
- Напоминания менеджерам о просроченных счетах.
Такие задачи решает ваш программист 1С или интегратор за дни. Заказывать их у ИИ-студии — переплата, и мы говорим об этом на диагностике, даже если теряем проект.
Когда RPA оправдан, а когда это заплатка
RPA нужен, когда у системы нет API и не будет: старая учетная программа, личный кабинет на внешнем портале, банк-клиент, система, которую поставщик не открывает. Робот работает там, где интеграция невозможна в принципе.
Цена — постоянный ремонт. Обновили конфигурацию 1С, поменяли дизайн портала, добавили поле в форму — робот ломается и ждет, пока его перенастроят. Поддержка RPA — регулярная работа после каждого обновления, и ее надо считать сразу, а не после первого сбоя.
Практический прием: прежде чем заказывать робота, проверьте, нет ли у системы интерфейса, о котором вы не знаете. У многих систем, включая типовые конфигурации 1С, есть стандартные программные интерфейсы, которые просто не включены. Час разговора с администратором иногда экономит проект RPA целиком.
Когда без языковой модели не обойтись
- Письма с заказами в свободной форме: каждый клиент пишет по-своему, вложения в разных форматах.
- Обращения в поддержку, которые надо разобрать по типам и передать в нужный отдел.
- Сканы документов от контрагентов: счета, акты, накладные, из которых надо извлечь поля.
- Вопросы руководителей к данным: «сколько отгрузили по объекту за квартал». Здесь модель составляет запрос к базе.
- Сводки длинной переписки и звонков для менеджера, который подключается к сделке.
Общее у этих задач — вход на человеческом языке и непредсказуемая форма. Парсер на правилах, написанный под пятьдесят вариантов письма, сломается на пятьдесят первом. Модель извлекает поля и из письма, какого в примерах не было.
Как это выглядит в одном процессе
На практике ответ редко звучит как «только одно». Возьмем заказ, пришедший письмом. Модель читает письмо и извлекает клиента, позиции, количества и даты. Скрипт сверяет извлеченное со справочниками 1С: есть ли такой контрагент, есть ли позиции в номенклатуре, есть ли на них цены. Спорное — позиция не найдена, количество необычное — уходит менеджеру. Остальное скрипт проводит через API как заказ.
Модель работает на одном шаге — чтении. Все остальное — обычная автоматизация с жесткими правилами. Процесс остается вашим, меняется один шаг, и поэтому такой проект запускают за недели, а не перестраивают учет.
Модель пишет черновик, а в учет его проводит скрипт
Отсюда правило, которого мы придерживаемся в проектах с учетными системами: модель не пишет в 1С и CRM напрямую. Она готовит данные, скрипт проверяет их по справочникам и правилам и только потом создает документ. Так ошибка модели превращается в задачу на проверку, а не в неверную проводку.
В нашем проекте отчетов по вопросу на русском этот принцип доведен до предела. Средняя строительная компания: менеджеры спрашивают обычным языком, сервис генерирует SQL-запрос к корпоративной базе, запрос проверяется перед выполнением, а доступ ограничен чтением. Отчет готов за 5 минут вместо 2–3 дней, нагрузка на ИТ-отдел снизилась на 70%. Цифры при этом считает база, а не модель: модель только пишет запрос.
Частая ошибка: модель там, где нужен справочник
Сопоставить наименования из документов поставщика со своей номенклатурой — похоже на задачу для языковой модели, ведь это текст. На деле это сверка с известным справочником, и лучше ее решают нормализация наименований и сравнение по характеристикам. Модель подключают только к трудным случаям.
В нашем проекте для производителя ферросплавов продукцию конкурентов сопоставляли по химическому составу, фракции и показателям качества — классической моделью машинного обучения, без языковой. Отчет, на который уходило несколько дней, готовится за 30 минут, цены обновляются ежедневно, маржа по ключевым контрактам выросла на 5–7%.
Труднее всего давались позиции, различающиеся одним параметром. Помогли признаки из паспортов качества и штрафы за расхождение критичных характеристик, а спорные сопоставления подтверждает аналитик.
Четыре типовые задачи и чем их решать
Входящие счета, акты и накладные
Сканы и PDF от контрагентов. Шаг чтения — распознавание и извлечение полей: номер, дата, сумма, контрагент, позиции. Дальше — сверка с договором и справочниками по правилам и создание документа через API. Модель нужна только на первом шаге, а для документов с постоянной формой иногда хватает обычного распознавания по шаблону.
Разбор обращений в CRM
Обращения приходят текстом, их надо разложить по типам и назначить ответственного. На старте с этим справляется языковая модель с инструкцией и примерами — обучать ничего не нужно. Когда накопятся тысячи разобранных обращений, частые типы можно перевести на классическую модель классификации: она дешевле на потоке, а языковая остается для новых и трудных случаев.
Ответы клиентам о статусе заказа
Бот берет статус из 1С и отвечает клиенту. Модель здесь простая, а риск — в данных: если отгрузка отражена в одной системе и не отражена в другой, бот уверенно сообщит неверный статус. Прежде чем строить такого бота, проверьте, что статусы в системах совпадают с реальностью.
Сверка взаиморасчетов
Сопоставить документы в вашей системе с данными контрагента, найти расхождения, подготовить список для разбора. Основа — правила и нечеткое сравнение по суммам, датам и номерам. Модель помогает разобрать комментарии и назначения платежей, записанные в свободной форме. Решение по каждому расхождению принимает бухгалтер.
Если API нет, а на входе свободный текст
Бывает и такое сочетание: письма приходят в свободной форме, а результат надо внести в систему без API — например, во внешний портал заказчика. Тогда модель читает письмо и готовит поля, а робот вносит их через интерфейс. Схема рабочая, но у нее два источника сбоев вместо одного: ошибки модели и поломки робота после обновлений. Следить надо за обоими, и бюджет поддержки закладывать с учетом этого.
Сколько стоит каждый вариант в эксплуатации
- Скрипт: почти ничего на каждую операцию, ремонт — когда меняются сами системы.
- RPA: лицензии платформы, если она коммерческая, и регулярная перенастройка после обновлений интерфейса.
- Модель: оплата каждого обращения — токенами облачного сервиса или временем своего сервера, мониторинг качества и время людей на спорные случаи.
Поэтому модель окупается там, где человек тратит минуты на операцию, а операций сотни в день. Если на операцию уходит полминуты и их два десятка в день, автоматизировать нечего, разве что скриптом.
Условный пример для расчета. В отдел приходит 300 писем с заказами в день, на ручной разбор каждого уходит около 4 минут — это 20 часов работы ежедневно. Если связка модели и проверки по справочникам пропускает без человека две трети писем, а треть уходит менеджерам как спорные, высвобождается около 13 часов в день. Против этого ставят оплату обращений к модели, поддержку и время на разбор спорных. Реальную долю спорных показывает только прототип на ваших письмах.
Как понять, что автоматизация сработала
Эффект меряют в единицах процесса, а не в точности модели. Метрики фиксируют до пилота и сравнивают после.
- Доля операций, прошедших без участия человека.
- Доля спорных случаев и время на разбор каждого.
- Ошибки, найденные позже: возвраты, исправленные документы, жалобы.
- Время от поступления письма или документа до проведения в системе.
Последняя метрика бывает важнее сэкономленных часов: заказ, проведенный за десять минут вместо полудня, клиент замечает сразу, а высвобожденные часы видны только в отчете.
Что сделать до того, как заказывать ИИ
- Опишите процесс по шагам и отметьте шаг, на котором человек читает свободный текст.
- Проверьте, есть ли у систем API и включен ли он.
- Посчитайте объем: операций в день и минут на каждую.
- Соберите 50–100 реальных примеров входа: писем, сканов, обращений.
- Решите, кто будет разбирать спорные случаи и сколько времени у него на это есть.
Если в процессе нет шага, где человек читает свободный текст, вам, скорее всего, нужна интеграция, а не ИИ. Это хорошая новость: она дешевле и надежнее.
Где автоматизация не нужна вовсе
- Регламента нет, и процесс меняется каждый месяц. Сначала регламент, потом автоматизация.
- Операций мало: десяток в день не окупит даже скрипт с поддержкой.
- Решение требует ответственности, которую нельзя передать системе: согласование скидок, кадровые решения, спорные претензии.
В таких случаях модель можно использовать как помощника — подготовить сводку, найти похожие случаи, — но решение и действие остаются за человеком.
Сроки, бюджет и команда
Прототип — от 600 тыс. ₽: один сценарий, одна интеграция, до двух недель. Этого хватает, чтобы проверить шаг с моделью на ваших настоящих письмах или документах и увидеть долю спорных случаев. Пилот — 1,5–3,5 млн ₽ и 3–6 недель: 3–5 сценариев и от трех интеграций.
С нашей стороны работают ML-инженер, бэкенд-разработчик и аналитик. С вашей нужны владелец процесса и администратор 1С или CRM, который дает доступ к тестовой среде и знает, где в системе что лежит.
Коротко
- Структурированный вход и известные правила — интеграция или скрипт, без ИИ.
- Нет API — RPA, но с поправкой на постоянный ремонт после обновлений интерфейса.
- Свободный текст, сканы и письма — языковая модель, но только на шаге чтения.
- Лучшее решение обычно гибридное: модель извлекает, скрипт проверяет по справочникам, человек разбирает спорное.
- Модель не пишет в учет напрямую, а цифры считает база.
- Если в процессе нет шага, где человек читает свободный текст, ИИ вам, скорее всего, не нужен.