Кейс, в котором правильным ИИ-решением стало не внедрять ИИ

Green Idea — чешский производитель косметики, пищевых добавок и ветеринарных продуктов со штатом от 50 до 249 человек. Компания росла по выручке, но прибыльность отдельных направлений перестала быть понятной. Руководство не могло уверенно объяснить, где именно теряется маржа и почему.

Кейс Европейской сети цифровых инновационных хабов описывает неожиданную причину. Десять лет Green Idea инвестировала в собственную внутреннюю систему, связанную с ERP Helios. Интерфейс выглядел рабочим, но фактически скрывал критически важные данные. Компания не могла нормально планировать производственные циклы, резервировать сырьё, рассчитывать себестоимость и сравнивать маржинальность.

Вместо нового аналитического ИИ Green Idea вернулась к основной ERP и отказалась от самописного слоя. После этого появились доступ к точным данным, расчёт затрат и маржи, планирование производства и KPI. Параллельно компания перераспределила ответственность между руководителями и снизила зависимость от основателя и единственного ИТ-специалиста.

Это редкий полезный анти-кейс: технология ИИ была в периметре программы, но первым результатом стала не модель, а устранение цифрового тупика.

Почему процесс был сложнее, чем кажется

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

Для такого решения нужны связанные данные:

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

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

Что подтверждено, а что осталось за рамками кейса

Публикация EDIH подтверждает организационные и функциональные изменения: отказ от самописной системы, возврат к Helios ERP, появление расчёта затрат и маржи, планирования циклов и KPI. Также заявлено, что компания стала стабильнее, а подготовка к передаче бизнеса следующему поколению вышла на управляемую траекторию.

Однако источник не приводит:

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

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

Почему «добавим RAG» не исправляет закрытую систему

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

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

Поэтому до RAG и агентов нужны обычные договорённости:

  • владелец каждого ключевого справочника;
  • единицы измерения и правила округления;
  • статусы заказов и партий;
  • время обновления и допустимая задержка;
  • правила исправления ошибок;
  • журнал изменений и ответственный за исключения.

Это не подготовительная бюрократия. Это спецификация будущего ИИ-продукта.

Какая архитектура уместна после наведения порядка

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

**1. Экспорт или read-only API.** Заказы, остатки, партии, рецептуры и фактические операции поступают в отдельное хранилище только для чтения. ИИ не получает прямого права менять производственный контур.

**2. Канонические представления.** Для пилота создаются несколько таблиц или представлений с понятными бизнес-терминами: доступный остаток, подтверждённый спрос, длительность серии, стоимость переналадки. Логика вычисления документируется и сверяется финансовой и производственной функциями.

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

**4. Узкий локальный сервис.** Локальная модель может объяснять отклонения, собирать черновик отчёта или отвечать на вопросы по утверждённым представлениям. RAG добавляет инструкции и технологические документы, но числа всегда приходят из структурированного источника.

**5. Человек подтверждает действие.** На первом этапе система предлагает производственный пакет, приоритет проверки или вопрос к данным. Руководитель производства утверждает изменение в ERP через существующий процесс.

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

Где локальная модель действительно полезна

После восстановления данных локальный ИИ уместен там, где важны коммерческая тайна, повторяемость и интеграция с внутренними документами:

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

Модель не должна самостоятельно рассчитывать себестоимость из текста или придумывать остатки. Числовые расчёты выполняются детерминированными правилами; модель получает готовые показатели и ссылки на строки-основания.

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

Как проверить, что самописный слой стал тупиком

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

  • отчёт нельзя воспроизвести без одного специалиста;
  • одно и то же понятие считается по-разному в разных экранах;
  • данные нельзя выгрузить в документированном формате;
  • справочники дублируются и синхронизируются вручную;
  • обновление ERP ломает интеграцию непредсказуемо;
  • стоимость изменения растёт, а время ответа на бизнес-вопрос не сокращается;
  • система скрывает происхождение показателя.

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

Экономика: считать прекращённые затраты, а не прошлые вложения

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

Сравните на горизонте 24–36 месяцев:

  • поддержку и развитие текущего решения;
  • риск ухода ключевого специалиста;
  • цену ошибок планирования и ручных сверок;
  • миграцию и обучение;
  • стоимость стандартной ERP-конфигурации;
  • ценность более быстрого управленческого решения;
  • будущие расходы на данные и ИИ-пилоты.

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

Практический пилот на четыре недели

**Неделя 1.** Выберите одно решение — например, формирование производственной серии. Зафиксируйте владельца, входные данные, источник истины и стоимость ошибки.

**Неделя 2.** Соберите read-only представление из ERP. Проверьте полноту, дубли, единицы измерения и историю изменений на реальных закрытых периодах.

**Неделя 3.** Сделайте отчёт без ИИ: ограничения, варианты и строки-основания. Если пользователи ему не доверяют, модель добавлять рано.

**Неделя 4.** Подключите локальную модель только для объяснения результата и поиска инструкций. Сравните время подготовки ответа, число исправлений и долю случаев, где руководитель смог проверить основание.

Успешный результат пилота — не красивый чат. Это сокращение времени до проверяемого решения без потери контроля.

Главный урок Green Idea

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

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