Александр Костин – ИИ в закупках и снабжении: как снизить дефициты и высвободить деньги из запасов (страница 3)

Третья проблема – отсутствие истории, либо ее непригодность. История продаж хранится, но без календаря акций, без учета изменения цены, без отметок о маркетинговых кампаниях, без фиксации дефицитов. На уровне данных это выглядит как «вчера продавалось 100, сегодня 20». Человек понимает, что вчера была распродажа или товар был в наличии, а сегодня нет. Модель видит только цифры и делает неправильный вывод о тренде.

Четвертая проблема – ручные корректировки без следов. Кто-то меняет остаток, кто-то «подчищает» возвраты, кто-то переносит поставки, и это не фиксируется как событие с причиной. ИИ видит скачки и трактует их как поведение спроса, хотя это поведение учета.

Пятая проблема – «нестыковка времени». Продажи фиксируются по кассе, склад по факту пересчета, закупки по дате счета, логистика по дате отгрузки. Для человека это терпимо, для модели это разрушительно: она строит причинно-следственные связи и ей важно, что было раньше, а что позже. Если временная шкала не согласована, модель путает причину и следствие.

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

На практике это означает, что вам нужен минимальный «скелет данных», который можно собрать даже без глобальных внедрений. Он включает несколько блоков.

Первый блок – поток спроса. Продажи по дням (а лучше по часам для отдельных категорий), возвраты, отмены, отказы из-за отсутствия товара, замены на аналоги. Важно фиксировать не только «сколько купили», но и «сколько хотели купить, но не смогли».

Второй блок – состояние запасов. Остаток по статусам, резерв по типам и срокам, товар в пути по стадиям, подтвержденные даты прихода, фактические даты прихода. Если вы умеете разложить «в пути» на стадии, точность резко растет: модель понимает вероятность и риск.

Третий блок – параметры поставок. Минимальные партии, кратность, упаковки, ограничения, цены, скидки, условия оплаты, графики отгрузки. ИИ должен понимать, что заказ не может быть любым числом. У заказа есть дискретность и ограничения. Если модель предлагает «дозаказать 17», а вы закупаете коробками по 24, система будет регулярно «ломаться» на последнем шаге.

Четвертый блок – надежность поставщика. Фактические сроки, частота задержек, разброс сроков, частота недопоставок, качество (процент брака/рекламаций), корректность документов, готовность к срочным отгрузкам. Предиктивное снабжение – это не только «что заказать», но и «у кого безопаснее заказать».

Пятый блок – контекст влияния. Календарь акций, изменения цен, запуски, выводы товаров, сезонные пики, регуляторные ограничения (если актуально), изменения логистических маршрутов. Модель должна понимать, что спрос меняется не из воздуха.

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

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

Рабочий подход другой: чистить ровно то, что дает эффект на решения уже сейчас, и расширять покрытие постепенно.

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

Важно понимать, что точность снабжения в реальности определяется не средним по больнице, а ошибками по ключевым позициям. Если вы научились точно управлять «ядром» ассортимента, вы уже снизили дефициты и высвободили капитал. Хвост можно подключать позже, когда процесс стабилен.

Следующий слой – объяснимость и доверие. ИИ в закупках опасен не тем, что он ошибается. Ошибается любой. Опасен он тем, что может ошибаться уверенно и быстро. Поэтому вам нужен механизм, который делает решения проверяемыми человеком и прозрачными для бизнеса.

В закупках объяснимость строится не философией, а конкретными «поясняющими полями». Для каждого предложения к заказу система должна отвечать на несколько вопросов.

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

Почему именно сейчас? Например: точка заказа достигнута, время поставки с учетом фактической статистики, риск задержки, ожидаемый рост спроса из-за сезонности или акции.

Почему у этого поставщика? Например: цена с учетом условий, фактическая надежность по срокам, качество, доступность, ограничения по минимальной партии, история недопоставок.

Что будет, если не заказать? Например: прогноз дефицита по датам, потеря продаж или риск простоя, влияние на сервис.

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

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

Дальше возникает важный вопрос: кто владелец данных? В компании часто все хотят, чтобы данные «были правильными», но никто не хочет быть ответственным. ИИ усиливает эту проблему, потому что цена ошибки данных становится выше: ошибка превращается в решение о закупке, а решение – в деньги.

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

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

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

Следующая опора – качество данных как управляемая метрика. Очень важно уйти от абстрактного «данные плохие» к измеримым показателям. Иначе вы не сможете понимать прогресс и не сможете управлять улучшением.

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

Доля позиций с корректной единицей измерения и упаковкой.

Доля остатков со статусами, где «доступно» отделено от «не доступно».

Точность подтвержденных дат прихода: насколько часто фактическая дата совпала с подтвержденной.

Доля заказов, где зафиксированы причины отклонений (задержка, недопоставка, брак, пересортица).

Доля продаж, попавших в дефицитные периоды, где спрос мог быть выше (оценка неудовлетворенного спроса).

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

Теперь о самом опасном месте: попытка построить прогноз по «продажам как есть», когда вы регулярно сталкиваетесь с out-of-stock. Многие компании делают именно так и удивляются, почему прогноз «не видит» будущий спрос. Потому что модель обучается на усеченной реальности. Если товара не было, продаж не было. Для модели это выглядит как падение спроса. Она снижает прогноз, вы еще меньше закупаете, и вы сами усиливаете дефицит. Возникает замкнутый контур деградации.

Чтобы разорвать его, нужна корректировка на неудовлетворенный спрос. Это можно делать по-разному, но принцип один: периоды отсутствия товара должны маркироваться как особые, а спрос в эти периоды должен оцениваться не по продажам, а по доступным сигналам: просмотры, добавления в корзину, отказы, обращения, замены, история до дефицита. Даже грубая корректировка лучше, чем отсутствие корректировки. Она возвращает модели способность «видеть» спрос там, где вы его потеряли.

Отдельная тема – сезонность и календарь. Люди хорошо чувствуют сезонность. Модель чувствует ее только если вы дали ей структуру. В закупках сезонность редко бывает «чистой». Она смешана с акциями, с изменениями цен, с логистическими пиками, с погодой в некоторых категориях, с праздниками, с началом учебного года, с отчетными периодами в B2B, с бюджетированием у клиентов. Важно не пытаться «объяснить моделью все сразу», а хотя бы дать ей базовый календарь событий, которые вы точно знаете. Если вы заранее отмечаете крупные промо, праздничные пики, запуск новых продуктов, изменение прайса, модель перестает считать эти всплески «аномалиями» и начинает воспринимать их как часть закономерности.