Задача — не угадать идеальный заказ
Небольшому магазину обычно не нужна обещающая «точный прогноз» система. Нужно заранее заметить позиции, которые могут закончиться до следующей поставки, и не заказать лишнее там, где товар медленно продаётся. Нейросеть может помочь собрать историю и указать на необычный ряд, но сама не знает о звонке поставщика, повреждённой коробке или локальном событии. Поэтому в пилоте мы проверяем не автоматическую закупку, а качество подсказки для человека. Начните с ограниченной группы товаров и заранее определите, кто подтвердит каждое изменение заказа.
Подготовьте данные, которым можно доверять
Выгрузите по дням фактические продажи, остаток на начало периода, закупки, цену, скидки и даты поставок. Отдельно отметьте дни отсутствия товара: ноль продаж из-за пустой полки не означает отсутствия спроса. Нужны также списания и возвраты, иначе цифры расходятся с реальным движением. Уберите имена покупателей и любые личные данные: для прогноза запасов обычно достаточно агрегатов по SKU. В таблице заведите словарь единиц измерения — коробка, штука, килограмм — и проверьте, что упаковка товара не менялась в середине истории.
Сначала посчитайте простой ориентир
Для каждого товара сделайте прогноз по прошлой неделе и по медиане последних сопоставимых недель. Это не передовая модель, зато понятно, что она делает. Затем на отдельном прошлом периоде сравните её с подсказкой ИИ. Не перемешивайте строки: прогноз должен видеть только то, что было известно на дату расчёта. Если модель обещает прирост точности, спросите, на каких позициях и на каком горизонте он появился. Один общий процент может скрыть, что результат улучшился только у ходового товара и ухудшился у сезонной мелочи.
Проверьте ошибку на последствиях
Считайте не только среднее отклонение в штуках. Отметьте случаи, когда прогноз привёл бы к пустой полке, и отдельно — к закупке, которая долго лежит. Для молока цена ошибки другая, чем для батареек. Владелец процесса может дать простой вес: сколько стоит срочная доставка, сколько — списание, что происходит при продаже ниже минимального остатка. Если данных о расходах нет, хотя бы посчитайте частоту дефицита и излишка. Это делает обсуждение конкретным: команда спорит не о «точности ИИ», а о том, какой вид ошибки для неё дороже.
Запустите подсказку рядом с привычным процессом
В течение двух-трёх циклов показывайте менеджеру рекомендованный диапазон заказа и объяснение, но не отправляйте заявку поставщику. Добавьте три кнопки в журнал: принял, изменил, отклонил. Для изменений попросите короткую причину из списка: акция, задержка, новая поставка, ошибка данных или другое. Через пару недель вы увидите повторяющиеся исключения и поймёте, какие сигналы надо подключить. Не оценивайте эксперимент только по времени подготовки заказа: важны пропуски дефицита, лишний остаток и число ручных исправлений.
Границы, которые надо прописать заранее
Система не должна сама менять количество, закупочную цену, ассортимент или условия оплаты. Если история неполная, товар новый или поставщик меняет срок доставки, пусть подсказка явно сообщает о низкой надёжности и предлагает ручную проверку. Установите верхний предел суммы пилотного заказа и оставьте возможность отключить подсказки без остановки торговли. Доступ к выгрузке выдайте только сотрудникам, которым он нужен. Для проверки похожих числовых данных пригодится практика сверки заказа и платежа, но в закупочном пилоте цель другая: оценить будущую потребность, а не согласовать уже выставленный счёт.
Когда переходить к следующему шагу
Продолжать имеет смысл, если модель стабильно лучше простого правила на нескольких товарах и сотрудникам не приходится постоянно исправлять рекомендации. Сначала расширьте тест на похожую группу, затем подключайте ещё один магазин, если условия действительно сопоставимы. После каждого расширения заново проверяйте качество. Модель, которая хорошо работала до сезонной распродажи, может ошибаться после смены цен или упаковки. Документируйте дату выгрузки, версию модели и порядок расчёта. Тогда решение о закупке можно объяснить задним числом, а не ссылаться на «так сказал алгоритм».
Короткий рабочий протокол и FAQ
Протокол для первой недели: назначить ответственного; выбрать 20–30 регулярно продающихся SKU; проверить единицы и пропуски; сохранить baseline; показать прогноз рядом с ним; записывать каждую правку; в конце недели обсудить случаи, а не только средний показатель. Если пилот начинается с процесса, а не инструмента, сначала пригодится наш материал как выбрать первый процесс для автоматизации. Для контроля исходных таблиц используйте также гайд о проверке ответов перед отправкой клиенту: это другая задача, но тот же принцип не принимать вывод без сверки. Можно ли начинать без отдельной команды данных? Да, если выгрузка небольшая и один сотрудник отвечает за качество таблицы. Должна ли модель сама заказывать товар? Нет, пилот этого не проверяет. Что делать при неожиданном событии? Зафиксировать его и принять решение вручную.