Что в кейсе произошло на самом деле

Австралийский стартап Mentana продаёт платформу для управления цепочками поставок. По описанию Google Cloud, она объединяет сведения из ERP, CRM и кассовых систем, а агенты на базе Gemini разбирают входящие письма, сверяют остатки в ERP и предлагают изменения закупок или производства. Ещё один сценарий — поиск причин расхождений между фактическим и цифровым складским остатком. Сайт самой Mentana описывает анализ инвентаризации и предлагает запуск перемещения запасов по подтверждению пользователя.

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

В кейсе Google Cloud приведены 22% снижения инфраструктурных расходов после смены облачной платформы, 99,99% доступности системы и переход к двухнедельным циклам релизов. Это показатели инфраструктуры Mentana, а не точность распознавания писем, снижение недостач или окупаемость агента. Публичной выборки ошибок агента и стоимости одной успешно разобранной складской ситуации в этих источниках нет.

Какая задача подходит небольшому бизнесу

Для торговой компании с одним или несколькими складами разумная стартовая задача — разбор расхождения «в системе есть, на полке нет» или обратной ситуации. Менеджер обычно сводит выгрузки, ищет резервы по заказам, поступления, возвраты, перемещения и ошибки единиц измерения. Если сведения лежат в почте поставщика, учётной системе и таблице инвентаризации, поиск причины занимает больше времени, чем само исправление.

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

Например, агент может показать: «В акте указано 12 коробок, в ERP числится 120 штук, но карточка товара задаёт 10 штук в коробке. Разница может быть в единице измерения; проверьте накладную и партию». Это пример редакционного сценария, не цитата из внедрения Mentana и не обещание точности. Если ERP уже хранит единицы и конвертацию безошибочно, такую проверку лучше выполнить детерминированным правилом.

Как собрать минимальный контур

Пилот не требует передавать агенту право свободно редактировать склад. Достаточно одной категории товаров и одного типа расхождений. Рабочий поток может выглядеть так:

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

У каждой системы должен быть владелец данных. Если касса показывает продажу, ERP — резерв, а таблица склада — физический пересчёт, заранее установите, какое поле отвечает на какой вопрос. «Самая свежая запись» не всегда означает «истина»: продажи и возвраты могут догонять учёт с задержкой. Для спорных случаев полезен статус «недостаточно данных», а не уверенная догадка.

Нормализация справочника часто важнее выбора модели. Один товар может фигурировать под артикулом поставщика, внутренним SKU и сокращённым названием; коробка и штука могут смешиваться. На пилоте отдельно составьте таблицу синонимов, единиц и правил привязки партии. Без неё система будет убедительно обсуждать не тот товар.

Локальная модель, облако и границы доступа

В описанном кейсе Mentana использует Gemini и инфраструктуру Google Cloud; упоминание гибридного или on-premises развёртывания платформы не подтверждает локальный запуск самой модели Gemini. Для российского предприятия вариант с локальной моделью — самостоятельный архитектурный выбор, а не факт о Mentana. Он имеет смысл, если внутренние документы и остатки нельзя отправлять внешнему провайдеру, нагрузка достаточна для собственного оборудования или требуется предсказуемая граница доступа. Если процесс редкий и данные разрешено передавать по договору, API может оказаться проще и дешевле. Решение проверяют на фактическом наборе документов и с учётом полной стоимости эксплуатации.

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

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

Экономика без чужих процентов

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

Пример модельного расчёта: 200 исключений в месяц, 15 минут ручного разбора каждого и полная стоимость часа специалиста 800 ₽ дают 40 000 ₽ текущих трудозатрат. Если подсказка экономит в среднем 8 минут только на 70% случаев, освобождается около 18,7 часа, или 14 900 ₽ в месяц до расходов на внедрение и поддержку. Это арифметическая иллюстрация с допущениями, не результат Mentana и не прогноз для читателя. Если пилот и поддержка стоят дороже экономии и предотвращённых ошибок, автоматизацию в таком объёме не стоит разворачивать.

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

Следующий шаг

Возьмите 30–50 недавно закрытых расхождений одного типа и восстановите для каждого исходные документы, движения товара и окончательное решение человека. Если без знания нюансов переписки и правил нельзя объяснить существенную долю случаев, протестируйте помощника только в режиме чтения. Заранее установите порог качества и лимит стоимости принятого решения. Права на запись добавляйте лишь после того, как увидите повторяемое качество, журнал объяснений и работающий процесс подтверждения.

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