Когда для автоматизации закупок ИИ вообще не нужен

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

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

После этого появился следующий вопрос.

Если отчёт уже содержит продажи, остатки, оборачиваемость, историю и другие рассчитанные показатели, какая часть задачи вообще требует ИИ?

Чем подробнее я разбирал процесс, тем чаще ответ был: никакая.
Не потому, что ИИ бесполезен для закупок.
А потому, что часть работы, которую ему хотели отдать, уже можно описать данными, условиями и понятными правилами.

Первой идеей было отдать ИИ поиск аномалий

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

Например:

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

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

Там была история.
Были текущие показатели.

Можно было сравнивать периоды.
Можно было видеть изменение остатков и скорости продаж.

И в этот момент задача перестала выглядеть как задача на понимание неструктурированного контекста.
Она стала похожа на обычную задачу вычисления.

Если правило можно посчитать, я сначала считаю его без ИИ

Допустим, мне нужно найти позиции, у которых скорость продаж резко изменилась относительно предыдущего периода.
Для этого не нужно просить модель “посмотреть на данные и почувствовать аномалию”.
Можно определить:

1. какой показатель сравниваем;
2. с каким периодом;
3. какое изменение считаем существенным;
4. какие группы товаров сравниваем между собой;
5. какие позиции показываем человеку в первую очередь.

После этого система может сама построить список.
Например, сначала показать 5 товаров с наиболее сильным отклонением от своей обычной динамики.

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

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

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

С цифрами у меня есть ещё одна причина быть осторожным

В своих экспериментах я неоднократно пытался использовать разные модели для аналитики отчётов.
У меня получалась неприятная развилка.

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

Если позволить модели самой считать, сопоставлять и свободно интерпретировать большой массив чисел, риск ошибок становится для операционной задачи слишком высоким.

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

Получается странная конструкция:

программа считает цифры -> ИИ читает рассчитанные цифры -> ИИ формулирует правило -> человек читает формулировку.

Если правило уже известно, я предпочту короче:

программа считает цифры -> правило срабатывает -> человек получает сигнал или готовое действие.

Чем критичнее решение, тем ценнее для меня эта предсказуемость.

Даже приоритизация отчёта не обязана быть “умной”

Мне понравился один конкретный поворот разговора.

Клиенту хотелось, чтобы утро закупщика начиналось не с полного отчёта, а с отклонений.
То есть вместо просмотра условных сотен позиций человек сначала получает несколько случаев:

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

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

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

Пользователю важно получить 5 правильных приоритетов вместо 300 строк.
Ему не должно быть важно, модель нашла их или несколько надёжных правил.

Там, где правило устойчиво, можно автоматизировать уже не совет, а действие

Следующий шаг оказался ещё интереснее.

Если система не просто видит отклонение, а по существующим правилам уже определяет, что стандартную позицию нужно заказать, зачем ограничиваться рекомендацией?

В исходной задаче уже обсуждался более прямой сценарий: автоматически формировать в 1С документ “Заказ поставщику”, чтобы закупщик проверял готовый документ, а не заново проходил весь путь от строки отчёта до создания заказа.

Это меняет сам объект автоматизации.
Слабый вариант:

ИИ пишет: “Похоже, этот товар пора заказать”.

Более сильный вариант для стандартного случая:

система рассчитала потребность -> создала черновик заказа -> человек проверил и подтвердил.

Во втором варианте технология забирает работу, а не только добавляет ещё один текст рядом с отчётом.
И здесь снова может не понадобиться ИИ.

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

Но алгоритм не решает всю задачу закупщика

На встрече прозвучало важное возражение.
Нельзя всегда точно определить, сколько товара нужно привезти, только по одной формуле.
Закупщик может учитывать:

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

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

Или наоборот: в прошлом году товар продавался заметно быстрее, а сейчас скорость снизилась и текущего остатка достаточно ещё надолго. Формально сезонный ориентир может говорить “заказать”, а практическое решение будет другим.
Это уже не отменяет алгоритм.
Это показывает его границу.

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

Второй - случаи, где после этих расчётов остаётся выбор, зависящий от контекста и профессионального решения человека.
И вот этот второй слой нельзя просто спрятать под словом “ИИ” и считать задачу решённой.

Почему мне нравится начинать с обычного алгоритма

В этом конкретном кейсе у такого подхода для меня несколько преимуществ.

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

И главное - я не добавляю ИИ туда, где он не убирает работу и не повышает качество решения.
Это не означает, что обычный алгоритм всегда лучше модели.

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

Тогда зачем здесь вообще ИИ

После такого разбора может показаться, что от первоначальной идеи ничего не осталось. Не совсем.
ИИ всё ещё может быть полезен на исследовательском этапе.

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

Но это другая роль.
Не “нейросеть каждый день принимает решение по закупке”.
А:

ИИ помогает быстрее исследовать функцию и найти правила, которые после проверки могут стать частью обычной системы.

Эту идею я разберу отдельно дальше в серии, потому что для меня она оказалась одним из самых интересных выводов встречи.

После встречи у меня осталось три слоя решения

Вместо одного “ИИ-помощника закупщика” я бы теперь проектировал три разных слоя.

Первый - расчёты и алгоритмические сигналы.
Система считает показатели, сравнивает периоды, выделяет отклонения и формирует приоритеты.

Второй - автоматическое исполнение стандартных случаев.
Если правило достаточно надёжно, система готовит задачу или документ, а не ограничивается рекомендацией.

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

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

А иногда лучшая автоматизация заканчивается на том, что система за несколько секунд готовит человеку всё необходимое для решения, которое пока нельзя безопасно забрать у него.

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

Все материалы этого исследования собраны в серии “Автоматизация оптовой компании”.