ИИ для прогнозирования сроков поставки: от данных до точного плана

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

Какие сроки поставки прогнозируют и из чего состоит Lead Time

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

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

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

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

Срок как распределение, а не одна дата

Главная методическая ошибка в работе со сроками — попытка получить одно число. Реальный срок поставки ведёт себя как случайная величина с правым хвостом. Большинство поставок приходит в узком диапазоне, но небольшая часть опаздывает сильно, и именно она создаёт основные убытки. Среднее значение по такой выборке бесполезно, потому что оно одновременно и слишком оптимистично для планирования запаса, и слишком пессимистично для оценки типичной ситуации.

Правильный выход — прогнозировать квантили. Модель выдаёт не дату, а несколько уровней уверенности. Например, с вероятностью пятьдесят процентов груз придёт к 12 числа, с вероятностью восемьдесят процентов — к 16, с вероятностью девяносто пять процентов — к 23. Дальше решение принимается осознанно. Для дешёвой расходной позиции достаточно медианы, для критичного комплектующего, остановка из-за которого стоит миллионы, планируют по девяносто пятому квантилю.

Компания не страдает от того, что средний срок поставки равен восемнадцати дням. Она страдает от того, что в одном случае из двадцати он равен сорока пяти, и об этом никто не знал заранее.

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

Почему ручной расчёт сроков даёт сбой

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

• Договорной срок — это обязательство, а не прогноз. Поставщик ставит в договор величину, которую готов защищать юридически, и она слабо связана с его фактическим поведением в конкретный месяц.
• Норматив не реагирует на контекст. Один и тот же срок применяется в низкий сезон и в предновогодний пик, при заказе одной паллеты и при заказе фуры.
• Усреднение по поставщику скрывает различия между товарными группами. Один и тот же завод может стабильно отгружать серийные позиции и регулярно опаздывать с позициями под заказ.
• Человек плохо работает с редкими событиями. Задержка, которая случается раз в сорок поставок, выпадает из памяти планировщика между двумя случаями, а статистика её фиксирует.
• Обратная связь искажена. Если после срыва норматив увеличили, заказы стали размещать раньше, часть поставок начала приходить с запасом, и система потеряла возможность понять, насколько реально сократился риск.

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

Скрытые потери от экстренных закупок и простоев

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

1. Экстренные закупки у альтернативных поставщиков по цене, превышающей плановую на десятки процентов, плюс срочная доставка. Эти сделки проходят мимо тендерных процедур и почти не анализируются post factum.
2. Простой производства или ограничение ассортимента на полке. Стоимость часа простоя линии знают немногие предприятия, а именно она превращает трёхдневную задержку в понятную сумму.
3. Штрафы и снижение показателя исполнения заказов перед сетями и маркетплейсами. Для продавца на маркетплейсе позднее пополнение склада означает ещё и просадку в выдаче, которую потом приходится выкупать рекламным бюджетом.
4. Избыточный страховой запас как плата за незнание. Здесь теряются деньги в замороженном оборотном капитале, в стоимости хранения и в списаниях по истечении срока годности или морального устаревания.
5. Рабочее время людей. Постоянное ручное отслеживание грузов, обзвон поставщиков и пересогласование планов отнимают у категорийных менеджеров значительную часть недели.

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

Слепые зоны в оценке поставщиков

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

• Он считается относительно согласованной даты, а её нередко переносили по ходу дела. Формально поставка пришла в срок, фактически потребность была закрыта на две недели позже.
• Он не учитывает величину отклонения. Поставщик, опаздывающий на один день в половине случаев, получает худшую оценку, чем поставщик, срывающий одну поставку из десяти на месяц, хотя второй опаснее.
• Он не различает причины. Задержка из-за загруженности производства и задержка из-за закрытия пограничного перехода требуют разных управленческих реакций.
• Он игнорирует динамику. Ухудшение в последние два месяца тонет в годовой статистике, хотя это самый сильный предиктор следующего срыва.
• Он не видит незавершённых поставок. Заказы, которые ещё в пути и уже выбиваются из графика, в отчёт не попадают, а именно они содержат свежую информацию.

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

Как ИИ прогнозирует сроки поставки

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

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

Факторы, на которых учится модель

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

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

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

Предиктивное моделирование задержек и сценарии что если

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

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

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

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

• Что произойдёт со сроком и вероятностью срыва, если разбить заказ на две партии и первую отправить автомобильным транспортом.
• Как изменится риск, если перенести размещение заказа на неделю раньше, и какой дополнительный запас это создаст.
• Какой уровень страхового запаса обеспечит заданную доступность при текущей дисперсии сроков по этому поставщику.
• Что будет, если перевести часть объёма на альтернативного поставщика с более высокой ценой и меньшим разбросом сроков.
• Как изменится картина, если пункт пропуска, через который идёт половина импорта, замедлится вдвое.

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

Данные для модели: источники и требования к качеству

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

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

Какие события нужно уметь восстановить

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

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

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

Источники данных по уровням

Данные приходят из разных контуров, и у каждого свои сложности с доступом. Распределим их по степени доступности.

Источник	Что берём	Типичная проблема
ERP или учётная система	Заказы, строки заказов, поставщики, номенклатура, приходные документы, цены	Перезапись дат, отсутствие журнала изменений, расхождение в единицах измерения
Складская система	Приёмка, разгрузка, входной контроль, время постановки на учёт, загрузка доков	Данные есть, но не связаны с номером заказа напрямую
Система управления поставщиками	Подтверждения, переписка, рейтинги, условия договоров, история переносов	Часть информации только в неструктурированном виде
Транспортные и логистические платформы	Отгрузка, маршрут, перевозчик, контрольные точки, таможенное оформление	Разные форматы у разных перевозчиков, нет единого идентификатора
Внешние открытые данные	Производственный календарь, праздники в стране поставщика, погода, статистика пунктов пропуска	Нужен регулярный автоматический сбор, разовая загрузка бесполезна

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

Сколько данных действительно нужно

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

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

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

Требования к качеству и типичный мусор в данных

Подготовка данных занимает от шестидесяти до восьмидесяти процентов трудозатрат проекта. Основные дефекты повторяются от компании к компании.

1. Приёмки задним числом. Склад провёл документы в понедельник за всю прошлую неделю, и сроки по этим поставкам оказались короче или длиннее реальных. Такие записи выявляются по аномальной группировке дат и либо исправляются по журналу весовой, либо помечаются как ненадёжные.
2. Технические заказы. Внутренние перемещения, возвраты, корректировки и переоформления попадают в ту же таблицу, что и реальные закупки, и портят распределение. Их нужно отфильтровать по типу операции.
3. Дубли поставщиков. Один и тот же контрагент заведён под тремя кодами после переименований и смены юридического лица. История разваливается на три короткие, ни одна не работает.
4. Отрицательные и нулевые сроки. Признак того, что документы оформлены в обратном порядке. Такие строки сигнализируют о проблеме в процессе, а не о быстрой поставке.
5. Выбросы на сотни дней. Обычно это отменённые или замороженные заказы, которые формально закрыли через год. Их исключают, но не молча, а с проверкой, потому что часть выбросов настоящая и как раз представляет интерес.
6. Смена единиц измерения. Переход с килограммов на тонны посередине истории обнуляет смысл признака объёма заказа.

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

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

Внедрение ИИ-прогноза: пошаговый план

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

1. Определение решения, которое изменится. До любой технической работы нужно назвать конкретное действие, которое будет приниматься иначе. Например, расчёт страхового запаса по двадцати критичным группам или формирование ежедневного списка заказов под риском. Проект без названного решения не имеет критерия успеха и умирает на этапе демонстрации красивых графиков.
2. Аудит данных. Одна-три недели. Результат — понимание, какие отрезки цикла поставки вообще измеримы.
3. Базовый расчёт для сравнения. Считается точность текущего способа планирования, то есть нормативов из карточек. Без этой цифры невозможно доказать эффект. Почти всегда базовая ошибка оказывается выше, чем все ожидали, и это полезный разговор с руководством.
4. Пилот на ограниченном контуре. Одна-две категории, один склад, один тип логистики. Три-шесть недель на построение модели и проверку на отложенной выборке.
5. Проверка на реальных решениях. Модель работает параллельно с действующим процессом, прогнозы фиксируются, но решения ещё принимаются по-старому. Через месяц-два сравниваются результаты. Этот этап пропускают чаще всего, и именно его отсутствие порождает недоверие у закупщиков.
6. Встраивание в рабочие процессы. Прогноз появляется там, где человек принимает решение, а не в отдельной системе, куда надо заходить специально.
7. Регламент переобучения и контроля. Расписание обновления моделей, пороги срабатывания оповещений о деградации точности, ответственный за качество прогноза.
8. Масштабирование. Расширение на остальные категории, склады и направления поставок.

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

Как выбрать платформу или сервис

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

• Собственная разработка. Требует аналитика данных и инженера на постоянной основе. Оправдана при большом объёме закупок, нестандартных схемах поставок и при наличии команды, которая уже обслуживает другие модели. Даёт полный контроль над логикой и признаками.
• Модуль в составе системы планирования или управления закупками. Быстрее стартует, потому что данные уже внутри, и не требует отдельной интеграции. Ограничение — набор признаков и логика обычно заданы разработчиком, и добавить свой фактор не всегда возможно.
• Отдельный специализированный сервис. Разумный компромисс, когда внутренней команды нет, а учётная система не умеет прогнозировать. Критичным становится качество обмена данными и скорость доработок под запросы.

Независимо от варианта проверять поставщика решения стоит по конкретным вопросам, а не по презентации. Список, который экономит время на переговорах.

• Выдаёт ли система квантили или только одну дату. Если только дату, расчёт страхового запаса на её основе некорректен.
• Пересчитывается ли прогноз при появлении новых событий по заказу или считается один раз при размещении.
• Как обрабатываются новые поставщики и новые позиции без истории.
• Можно ли посмотреть, какие факторы повлияли на конкретный прогноз. Без объяснимости закупщики не будут доверять числу и вернутся к своим таблицам.
• С какой периодичностью переобучаются модели и кто это инициирует.
• Какие метрики точности система показывает штатно и доступна ли история прогнозов для независимой проверки.
• Где физически хранятся данные и как оформлен доступ к коммерческой информации о поставщиках и ценах.
• Что происходит при расторжении договора, остаются ли у компании собственные исторические данные и прогнозы.

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

Интеграция с ERP, WMS и SRM

Техническая часть интеграции обычно проще организационной. Схема обмена в типовом проекте состоит из трёх потоков.

1. Исторический поток для обучения. Выгрузка за два-три года, разово, затем регулярное дополнение. Формат не принципиален, важна полнота полей и наличие уникальных идентификаторов строк заказа.
2. Оперативный поток событий. Новые заказы, подтверждения, отгрузки, приёмки передаются с задержкой не более суток, а лучше в течение часа. Именно свежесть событий определяет полезность раннего предупреждения.
3. Обратный поток прогнозов. Даты по уровням уверенности, вероятность срыва и рекомендуемый уровень запаса возвращаются в учётную систему и записываются в поля, доступные закупщику и планировщику.

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

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

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

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

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

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

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

Что конкретно пересчитывается

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

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

Переход от режима тушения пожаров к плановой работе

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

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

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

Оценка поставщиков по надёжности сроков

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

Показатель	Что показывает	Как использовать
Медианное отклонение от первой обещанной даты	Систематическое смещение, то есть склонность обещать быстрее, чем получается	Поправка к договорному сроку при планировании
Разброс отклонений	Предсказуемость поставщика	Прямой вход в расчёт страхового запаса
Доля поставок с отклонением сверх критичного порога	Частота тяжёлых срывов, а не мелких задержек	Решение о дублировании поставщика
Число переносов согласованной даты на одну поставку	Качество планирования у контрагента	Ранний индикатор проблем на его стороне
Срок подтверждения заказа	Загруженность и внимание к клиенту	Сигнал к превентивному разговору
Динамика за последние три месяца против года	Ухудшение или улучшение	Основание для пересмотра объёмов
Полнота поставки	Частота недопоставок и частичных приходов	Корректировка заказываемого количества

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

Как использовать оценку в переговорах

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

• Показать поставщику его собственное распределение отклонений и сравнить с группой сопоставимых контрагентов. Обезличенно, без названий.
• Перевести разброс в деньги. Фраза о том, что нестабильность сроков заставляет держать дополнительный запас на определённую сумму, работает лучше любой претензии.
• Предложить обмен. Более точная дата подтверждения и своевременное информирование о сдвигах в обмен на увеличение доли объёма или более ровный график заказов.
• Зафиксировать в договоре не только срок, но и обязанность сообщать о задержке заранее. Знание о сдвиге за две недели стоит дороже штрафа после факта.
• Разделить объём между двумя поставщиками в пропорции, рассчитанной по риску, а не поровну и не по цене.

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

KPI и точность прогноза: что измерять

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

Метрики качества модели

• Средняя абсолютная ошибка в днях. Самая понятная величина для бизнеса. Её считают отдельно по категориям и направлениям, потому что единое число по всей номенклатуре ничего не говорит.
• Медианная абсолютная ошибка. Устойчива к выбросам и лучше описывает типичную ситуацию.
• Процентная ошибка. Применяется с осторожностью, поскольку на коротких сроках в три-пять дней проценты раздуваются и картина искажается.
• Калибровка квантилей. Ключевая метрика для прогнозов с уровнями уверенности. Если девяностый квантиль обещает попадание в девяти случаях из десяти, а фактически попадает в семи, модель переоценивает надёжность, и расчёт запаса занижен.
• Смещение. Систематический оптимизм или пессимизм, который легко упустить, глядя только на абсолютную ошибку.
• Качество предупреждений о риске. Доля сработавших сигналов, которые привели к реальному срыву, и доля срывов, о которых система предупредила заранее. Между этими двумя величинами есть компромисс, и порог срабатывания настраивается под цену ложной тревоги.

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

Метрики бизнес-эффекта

1. Уровень доступности товара или материала при заданном запасе. Если доступность выросла без увеличения запаса, эффект очевиден.
2. Средний запас в днях и в деньгах по пилотным группам в сравнении с контрольными.
3. Количество и сумма экстренных закупок. Один из самых быстрых индикаторов, реагирует уже во втором-третьем месяце.
4. Часы простоя производства или число дней отсутствия позиции на полке.
5. Доля заказов, исполненных в полном объёме к первоначально обещанной дате. Считать нужно к первой дате, иначе показатель легко улучшить переносами.
6. Штрафы и потери по обязательствам перед сетями и площадками.
7. Доля срывов, по которым было вмешательство до наступления факта. Эта метрика показывает, пользуются ли люди системой.
8. Списания по истечении срока годности и уценка неликвидов как следствие более точного планирования объёмов.

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

Точность в днях — это внутренняя характеристика модели. Бизнес платит за сокращение запаса, за отсутствие простоев и за решения, принятые вовремя. Если вторая группа показателей не двигается, высокая точность не имеет значения.

Ошибки внедрения и как их избежать

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

• Старт с выбора инструмента, а не с аудита данных. Решение куплено, лицензии оплачены, а выяснилось, что даты в системе перезаписываются и истории нет. Лечение простое, сначала две-три недели на проверку доступности событий.
• Прогноз одной датой вместо распределения. На такой прогноз нельзя опереться при расчёте запаса, и вся экономическая часть проекта рассыпается.
• Отсутствие базовой оценки. Если точность текущих нормативов не посчитана, доказать улучшение невозможно, и обсуждение уходит в субъективные мнения.
• Прогноз живёт в отдельном интерфейсе. Закупщик не ходит в сторонний портал, он работает в своей системе. Числа нужно возвращать туда.
• Непрозрачность. Если нельзя понять, почему модель дала именно такую дату, ей не доверяют. Объяснение вклада основных факторов для каждого прогноза обязательно, хотя бы в простом виде.
• Модель обучена один раз. Логистика меняется, поставщики меняются, маршруты закрываются. Без регламента переобучения точность деградирует за несколько месяцев, причём незаметно.
• Нет контроля деградации. Нужен мониторинг ошибки по неделям и оповещение при превышении порога, иначе о проблеме узнают после срыва.
• Попытка охватить всю номенклатуру сразу. Проект растягивается, результата нет, поддержка руководства заканчивается. Начинать нужно с узкого контура, где есть и данные, и чувствительность к сроку.
• Подмена прогноза подтверждённой датой поставщика в системе. Сигнал теряется, модель становится украшением.
• Игнорирование людей, которые работают с поставщиками. Их знание о контексте не содержится ни в одной таблице, и без него данные интерпретируются неверно.
• Отсутствие владельца процесса. Пока за качество прогноза никто не отвечает персонально, его никто и не улучшает.
• Оценка проекта только по точности. Приводит к ситуации, когда модель хороша, а решения принимаются по-старому.

Что делать, если данных заведомо мало

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

1. Начать с фиксации событий. Даже если модели ещё нет, настройте сохранение первой обещанной даты, всех переносов и отметок приёмки. Через полгода появится история, которой сейчас нет.
2. Построить простую статистическую оценку на том, что есть. Медиана и разброс по группе поставщик плюс категория уже лучше норматива из договора.
3. Использовать иерархическое наследование. Новая позиция получает оценку от своей группы, затем постепенно переходит на собственную статистику.
4. Добавить внешние данные, они доступны сразу и не требуют истории. Производственный календарь страны поставщика и праздничные периоды дают заметный вклад с первого дня.
5. Выделить двадцать-тридцать критичных позиций и вести по ним ручной учёт событий параллельно с системным. Это неэлегантно, но даёт качественную выборку за квартал.

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

Вопросы и ответы

Сколько истории нужно для старта

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

Чем прогноз отличается от даты, которую подтвердил поставщик

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

Нужны ли большие языковые модели для этой задачи

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

Что делать с новым поставщиком, у которого истории нет

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

Как часто переобучать модель

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

Можно ли обойтись без складской системы

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

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

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

Кто должен отвечать за прогноз внутри компании

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

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