Разработка AI-ассистента для ERP: аналитика, прогнозы, рекомендации

Где ломается AI-ассистент ERP на реальных данных

Почти каждый запуск AI-ассистента ERP начинается одинаково: пилот на вычищенной демо-базе показывает внятные прогнозы и рекомендации, а через месяц в рабочей учётной системе те же запросы возвращают противоречивые ответы. Причина не в модели, а в том, что демонстрационные и боевые данные — два разных мира. Разбираем, где рвётся связь между ответами ассистента и реальностью.

Первый слом — разрозненные справочники. Номенклатура в одной подсистеме ведётся полными наименованиями, в другой — сокращениями, у контрагентов копятся дубли с разным написанием реквизитов. Ассистент разносит продажи одного клиента по двум карточкам, и ошибки прогноза растут не из-за алгоритма, а потому что объект учёта не определён однозначно.

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

Третий слом — разные правила расчёта. Один и тот же показатель в отделах считается по-разному: где-то с возвратами, где-то без. Ассистент усредняет трактовки, а качество данных в учётной системе никто не проверяет до запуска — отсюда расхождение с тем, что видит руководитель в отчёте.

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

Как AI-ассистент ERP меняет отчётность и прогнозы

Ассистент не дублирует учётный контур, а читает его: подключается к базе 1С:ERP или другой корпоративной системе по регламентированному доступу, сопоставляет справочники и собирает витрину для расчётов. Отчёт формируется по запросу из первичных данных, а не из копии в таблице, которую кто-то обновил вручную на прошлой неделе.

Отсюда два эффекта, которые видны уже в первый месяц. Доля отчётов, собираемых по запросу, вырастает до 80–90%, остальное закрывают редкие формы с ручной сверкой. Каждый показатель раскрывается до исходного документа: переход по отклонению ведёт к проводке, партии или договору, поэтому вопрос «откуда цифра» решается за минуты, а не за день переписки.

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

Вместе с ручными выгрузками уходит целый класс отказов: разъехавшиеся версии файлов, потерянные при копировании строки, отчёты на неполном периоде. Снижение ручных операций здесь не самоцель, а следствие — чем меньше шагов между данными и решением, тем меньше мест, где цифра может испортиться.

Варианты подключения к учётной системе и их ограничения

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

На практике чаще выбирают гибрид: ассистент читает только нужные сущности, а расчёт прогнозов идёт на стороне сервиса. Тогда ограничения интеграции перестают быть риском — нагрузка на учёт предсказуема, а ответы ассистента не зависят от того, идёт ли закрытие периода.

Этапы внедрения: аудит данных, схема, настройка, проверка

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

1. Аудит данных. Смотрим полноту справочников, дубли контрагентов и номенклатуры, пустые обязательные поля, расхождения в единицах измерения. На выходе — перечень дефектов с оценкой, как каждый из них исказит ответ ассистента.
2. Проектирование схемы. Описываем связи документов, регистров и справочников: какие поля ключевые, какие движения учитывать, за какой период данные сопоставимы между собой. Схему согласуем с вашими учётчиками до начала настройки.
3. Настройка запросов. Под каждый тип вопроса — остатки, задолженность, динамика, отклонения — собираем ограниченный набор проверенных выборок с фильтрами по периоду и правам пользователя. Ассистент выбирает из готовых, а не строит произвольно.
4. Разграничение доступа. Роли переносятся в ассистента: руководитель направления не увидит данных, закрытых для него в учётной системе. Проверяем на тестовых учётках каждой роли.
5. Проверка качества ответов. Прогон на исторических периодах со сверкой с отчётами учётной системы. Фиксируем долю расхождений и отдельно разбираем вопросы без данных: ассистент должен сказать «недостаточно данных», а не подставить похожее число.
6. Передача в эксплуатацию. Регламент обновления при изменении справочников, журнал запросов и правок формулировок, ответственный за качество, обучение пользователей на их же данных.

На выходе остаётся согласованная схема, набор проверенных вопросов и измеренная точность ответов — вместо демонстрации на подготовленном примере.

Регламенты, схемы и документация после внедрения

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

• Схема интеграции — какие модули ERP, справочники и регистры участвуют в обмене, в какую сторону идут данные, где точки отказа и как переигрывается неудавшийся запрос.
• Политики доступа — ассистент отвечает строго в границах прав сотрудника: роль, подразделение, уровень конфиденциальности. Отдельно описано, что происходит при смене роли и увольнении.
• Регламент обновления знаний — кто и с какой периодичностью переиндексирует базу при изменении номенклатуры, регламентов и справочников, как проверяется качество после загрузки.
• Техническая документация — состав сервисов, параметры конфигурации, контрольные метрики, журналы работы, порядок отката на предыдущую версию модели и правил.
• Эталонный набор вопросов — несколько десятков типовых запросов с проверенными ответами. Прогоняется после каждого обновления, чтобы поймать деградацию раньше пользователей.
• Инструкции для сотрудников — как формулировать запрос, как проверить первоисточник в ERP, что делать, если ассистент отвечает неуверенно или данных нет.
• Матрица ответственности — кто на стороне заказчика владеет базой знаний и правилами ответа, кто отвечает за контур, к кому идёт запрос при сбое.

Комплект получается компактным: он описывает не устройство «внутренностей», а действия — что делать при сбое обмена, обновлении справочника, изменении прав. Такой набор проходит проверку аудита и позволяет менять подрядчика по сопровождению без потери контекста.

Кейс: прогноз закупок и остатков в оптовой торговле

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

Что было до

Прогноз считался по среднему за три месяца, без сезонного профиля и всплесков спроса на акциях — на подъёме система закупок не успевала среагировать. По ходовым позициям фиксировали 30–40 случаев дефицита за квартал, а около 60% строк прогноза аналитик правил вручную, и логика этих правок нигде не сохранялась: каждую неделю reasoning начинался с нуля.

Что изменили

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

Что стало

Срок подготовки отчёта сократился с двух дней до 20–30 минут: выгрузка, расчёт и сводка идут одним прогоном. Доля ручных правок в прогнозе упала с 60% до 12–15%, случаев дефицита по ходовым позициям — до 4–6 за квартал, оборачиваемость склада ускорилась на 9 дней, а избыточный сток перестал расти. Через два квартала закупщики работают с рекомендациями ассистента как с базовым сценарием, а не как с проверкой чужого расчёта.

Что делать, если учётная система уже сильно доработана

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

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

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

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

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

Частые технические сомнения перед началом работ

Перед началом работ всплывают одни и те же вопросы: как ассистент получает доступ к учётной системе, что делает при неуверенном ответе и кто отвечает за него после запуска. Ниже — короткие ответы по существу.

Что происходит при ошибке модели?

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

Придётся ли дообучать модель на наших данных?

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

Что входит в поддержку после запуска?

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

Обсудим задачу и вернёмся с планом и оценкой

Чтобы разговор был предметным, готовое техническое задание не нужно — достаточно описания контуров и болевых сценариев. Мы разбираем их вместе с вашим ИТ-отделом и возвращаемся с планом: где AI-ассистент даёт эффект сразу, а где сначала нужна работа с качеством данных.

Пришлите то, что уже есть под рукой:

• перечень сценариев, которые съедают время: сверка остатков, сборка прогноза спроса, пояснения к отклонениям план-факт;
• карту данных: какие учётные системы и справочники участвуют, кто владелец мастер-данных, есть ли выгрузки в хранилище;
• ограничения по доступам: какие роли работают с ассистентом, какие поля закрыты, требования к обезличиванию;
• примеры эталонных ответов — 5-10 реальных вопросов и правильных ответов на них, они становятся основой набора для проверки;
• точки интеграции: интерфейсы, к которым ассистент подключается на чтение и, при необходимости, на запись;
• состав документации, который нужен вашему ИТ-отделу для приёмки и дальнейшего сопровождения.

Первый шаг — пилотный запуск на 2-3 сценариях и ограниченном наборе данных, изолированно от продуктивной системы. До старта фиксируем критерии приёмки в измеримых величинах: доля корректных ответов на тестовом наборе, время отклика, доля запросов, закрытых без передачи человеку. Если показатели достигнуты — расширяем набор сценариев и передаём документацию: схемы потоков данных, регламент обновления моделей и правил, инструкции для поддержки. Если нет — контур сворачивается без влияния на учёт, а вы получаете разбор причин.