AI в логистике: где рушится прогноз и растут затраты
Прогноз спроса редко расходится с фактом из-за слабой модели. Чаще он ломается на стыке данных: склад считает остатки по своим документам, транспорт — по своим, а план собирают в сводной таблице, куда часть цифр заносят вручную. К моменту, когда расхождение становится заметным, партия уже отгружена не туда, где возник дефицит. Точность планирования при этом падает не на проценты, а в разы — по отдельным группам позиций расхождение плана и факта доходит до трети.
Второй источник ошибки — допущения, которые никто не перепроверяет. Сезонность берут по прошлому периоду, срок поставки — по договорному, а не по фактическому времени в пути, всплески от промо закладывают «на глаз». Каждое такое допущение сдвигает план, и дефицит на складе возникает ровно там, где прогноз обещал избыток. Разбирать это постфактум бессмысленно: причина теряется между версиями файла.
Третий — скорость реакции. Всплеск спроса виден в данных фактических отгрузок почти сразу, но решение о дозаказе принимается на недельном совещании. Пока согласуют объёмы, срывы поставок становятся фактом, а ручное планирование превращается в непрерывную борьбу с последствиями вместо работы с причиной.
Ниже разбираем, как это закрывается: где ставить контроль расхождений между складами и транспортом, какие сигналы брать из фактических отгрузок вместо допущений и как перевести план из ручного режима в пересчитываемый — с понятным временем реакции на отклонение.
Что даёт прогнозная модель: измеримый эффект на потоке
Эффект начинается с точности прогноза, а не с отчётности. Первый замер — ошибка прогноза по позиции на день на том горизонте, который нужен планированию: от суток для пополнения склада до квартала для закупки. Считаем её на исторических данных с той же сезонностью и промо-календарём, что и текущая базовая линия, — иначе улучшение останется в отчёте и не дойдёт до запаса.
Дальше ошибка превращается в запас. Страховой запас пересчитывается от фактической ошибки и времени пополнения, а не «на глаз», поэтому оборачиваемость запасов растёт при том же уровне сервиса. Эффект тут не в урезании склада, а в перераспределении: неликвид уходит, критичные позиции перестают проваливаться в дефицит.
На транспорте связка другая. Горизонт прогноза по отгрузкам позволяет консолидировать заказы в рейс и заранее планировать окна, поэтому растёт загрузка транспорта и сокращаются пустые пробеги: машина не возвращается порожней, когда следующий заказ известен до выхода из точки. Показатели уровня сервиса и оборачиваемости считаем по SCOR — так цифры сопоставимы с отраслевыми и не зависят от того, кто и как их считал.
Автоматизация планирования измеряется долей ручных правок плана: сколько строк плановик переписывает после того, как модель отдала свой вариант. Падение этой доли — самый честный признак, что прогноз встроился в процесс, а не идёт отдельным файлом. Человеку остаются исключения: крупные клиенты, промо, новые позиции без истории.
Сравниваем до и после на одном периоде и одной номенклатуре — тогда видно, какая часть эффекта пришла от модели, а какая от сезонности. Модель даёт полезный результат, когда её метрики привязаны к этим показателям потока, а не живут отдельно от плана.
Варианты построения: готовая модель, доработка, своя система
Выбор режима определяется не желанием «сделать по-своему», а зрелостью данных и уникальностью процесса. Если история событий собрана за несколько сезонов, атрибуты заказов заполнены, а обновления приходят регулярно, можно двигаться к дообучению или своей модели. Если журнал фрагментарный, а решения принимаются по нескольким типовым маршрутам, готовая модель даст результат быстрее и без риска.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Готовая модель | Типовые задачи: прогноз спроса, времени прибытия, маршрутизация по стандартным правилам. Своей истории пока мало для обучения. | Слабая настройка под нестандартные тарифы, приоритеты клиентов и внутренние регламенты. |
| Доработка под процесс | Есть особенности: свои правила приоритетов, несколько складов, смешанный парк. Накоплены размеченные данные за прошлые периоды. | Нужны регулярное переобучение, контроль дрейфа и владелец модели на стороне заказчика. |
| Собственная разработка | Логика уникальна и является конкурентным преимуществом; объёмы и требования к скорости ответа не покрываются готовыми сервисами. | Долгий цикл, своя инфраструктура, мониторинг качества и команда сопровождения. |
Внедрение прогнозирования редко начинается с собственной модели — обычно это постепенный переход: старт на готовом решении, накопление размеченных данных по факту исполнения, затем доработка под процесс. Перед выбором мы оцениваем зрелость данных: глубину истории, полноту полей, частоту обновлений и наличие обратной связи по фактическим результатам.
Внедрение AI в логистике: этапы инженерной работы
Логистика — процесс, где ошибка прогноза обходится дороже, чем стоит сама модель. Поэтому внедрение мы строим как последовательность инженерных шагов, каждый из которых можно остановить и оценить результат до перехода к следующему.
- Аудит данных. Разбираем, что есть на самом деле: история отгрузок, остатки, сроки поставок, отмены, ручные правки диспетчеров. Проверяем полноту по периодам и частоту обновления — слабые места здесь определяют потолок точности.
- Схема решения. Определяем, куда модель встраивается в процесс: прогноз спроса по складам, приоритизация рейсов, оценка риска просрочки. Фиксируем входы, выходы и то, кто принимает финальное решение.
- Подготовка и настройка. Приводим справочники номенклатуры и адресов к единому виду, убираем дубли и разрывы в истории — иначе модель учится на шуме, а не на закономерностях.
- Пилотный запуск. Одно направление или группа складов, ограниченный горизонт планирования: эффект виден на живом процессе, а зона влияния ошибки остаётся узкой.
- Проверка точности. Сравниваем прогноз с фактическими отгрузками и с прежним планированием: доля попаданий, средняя ошибка, число ошибок в критичную сторону.
- Передача модели и обучение команды. Отдаём схему решения, регламент переобучения, контуры контроля качества прогноза и разбираем с вашими специалистами, как читать метрики.
Дальше новые направления подключаются по уже отработанному контуру — без повторного аудита с нуля.
Что заказчик получает на руки: модели, схемы, регламенты
Передача решения — это не архив с кодом, а комплект документов, по которому ваша команда ведёт систему сама: переобучает модели, разбирает инциденты и объясняет решения бизнесу. Ниже — обязательный минимум, который уходит на руки вместе с работающим контуром.
- Описание моделей и правил — целевая метрика, горизонт прогноза, значимые признаки и границы применимости: где модель деградирует (нетиповые маршруты, новые типы груза, сбои в источнике телеметрии).
- Схема потоков данных — от учётной системы и телеметрии через слой обогащения до хранилища истории, с пометками, где данные теряются и как это отслеживается.
- Регламент переобучения — триггеры (дрейф входных распределений, смена сезонности, накопленная ошибка), порядок запуска, проверка на отложенном периоде и откат на предыдущую версию модели.
- Инструкции для диспетчеров и планировщиков — как читать прогноз с интервалом, в каких случаях решение переопределяется вручную и как фиксируется причина отклонения.
- Матрица ролей — владелец модели, владелец данных, ответственный за инциденты и точка эскалации: без неё через пару месяцев непонятно, кто чинит сбой.
- Регламенты сопровождения — что мониторится, при каких отклонениях срабатывает оповещение, как ведётся журнал решений.
- Документация решения — карта сервисов, точки интеграции с учётными системами, форматы обмена, порядок развёртывания в чистом окружении.
Разрабатываем так, чтобы этот комплект был полным с первого дня, а не собирался задним числом при передаче.
Разбор проекта: прогноз против пустых пробегов и дефицита
Планирование держалось на средних значениях за прошлые периоды и ручной сводке: менеджер сопоставлял заявки, остатки на складах и доступный парк. Сбой поставки или всплеск спроса ломал план за сутки — часть направлений уходила порожняком, а по критичным позициям включались авральные дозакупки.
Что было и что сделали
Собрали единый слой данных: история отгрузок, сезонность, сроки поставщиков, ограничения по складам и маршрутам. Поверх — прогноз спроса по каждой паре «склад — товар» и оптимизатор рейсов, который сводит направления с учётом обратной загрузки. Планировщик остался в контуре: система предлагает план, он подтверждает или правит, и каждая правка возвращается в модель как сигнал. Проект для «ТрансЛайн» шёл итерациями: сначала прогноз на узкой группе позиций, затем оптимизация рейсов, потом расширение на весь парк.
Что сдвинулось
Точность прогноза по ключевым группам выросла с 68% до 89% на двухнедельном горизонте. Порожний пробег сократился на треть, дефицит критичных позиций — почти вдвое. Доля ручных правок в плане упала с большинства строк до одной шестой: время планировщика уходит на нестандартные ситуации, а не на пересчёт базового плана.
Модель переобучаем по расписанию, и если качество прогноза на проверочном периоде проседает, схема автоматически возвращается к консервативному плану — дефицит не возникает из-за того, что модель «поехала».
Чем прогнозирование спроса отличается от оптимизации маршрутов?
Прогнозирование спроса отвечает на вопрос «сколько», оптимизация маршрутов — на вопрос «как везти». Горизонты у них разные: прогноз живёт неделями и месяцами и агрегируется по товарным позициям, точкам и каналам, а маршрут пересобирается раз в сутки под конкретные заказы, окна доставки и загрузку транспорта.
Данные тоже разные. Прогнозу нужна история отгрузок, календарь акций, сезонность и внешние факторы; маршрутизации — граф дорог, ограничения по времени работы водителя, вместимость машин и режим работы точек. Пересекаются оба контура в планировании запасов.
| Задача | Какие данные нужны | Что решает | Где пересекается |
|---|---|---|---|
| Прогнозирование спроса | История продаж, акции, сезонность | Объём спроса на горизонте недель | Задаёт ограничения по запасу |
| Планирование запасов | Прогноз, сроки поставки, страховой запас | Сколько и когда дозаказывать | Связывает спрос с загрузкой транспорта |
| Оптимизация маршрутов | Заказы, окна, вместимость, граф дорог | Порядок объезда, распределение по машинам | Получает объёмы из плана пополнения |
Ошибка прогноза не остаётся в отчёте — она превращается в пустые рейсы или срочные довозки, которые ломают уже собранный маршрут. Задачу маршрутизации решаем решателем класса OR-Tools: он держит ограничения по окнам и вместимости одновременно.
Единый контур планирования — это последовательность: прогноз спроса → план пополнения → распределение по складам → маршрут → фактические отгрузки, возвращающиеся в модель. Коррекция прогноза тогда автоматически пересчитывает и запас, и рейсы, а не живёт отдельной таблицей.
Технические сомнения: данные, точность, интеграции
Прогноз ломается не на обучении, а на стыке с реальностью: смены в учётной системе закрывают по факту, аномальные всплески уходят в историю как норма, а после смены номенклатуры признаки начинают значить не то, что раньше. Ниже — короткие ответы на вопросы, которые чаще всего поднимают на техническом разборе.
Что делать, если история заказов «грязная»?
Начинаем с профилирования: доля пропусков, дубли, отрицательные остатки, разрывы рядов, смещённые часовые пояса. Правила очистки согласуем с вашей командой и фиксируем письменно, а не правим на глаз: спорные записи не удаляем, а помечаем. Модель учится на агрегатах, а источники с низким доверием идут отдельными признаками с весом.
Как модель ведёт себя при аномалиях — резком всплеске или провале спроса?
Аномалия — это сигнал, а не мусор: промо, отмена рейса, сбой поставщика учитываются отдельным событием, иначе модель запомнит выброс как норму. Поверх ставим предохранители — пороги по остаткам, лимиты роста заказа, ручное подтверждение крупных отклонений, — поэтому единичный выброс не превращается в закупку «в никуда».
Как понимаете, что модель не переобучена?
Проверяем по времени: обучение на старом периоде, проверка на будущем, без случайного перемешивания строк. Качество сравниваем с простым ориентиром и с текущим планированием, а метрику смотрим отдельно по горизонтам — день, неделя, месяц. Если результат держится и на отложенном периоде, и на новых точках, это рабочая модель, а не подгонка.
Как стыкуетесь с учётными системами и что с сопровождением?
Обмен идёт по согласованному контуру: выгрузки по расписанию и событийные обновления, повторная загрузка не дублирует данные, каждое сообщение логируется и откатывается. На старте работаем только на чтение. Дальше — сопровождение: следим за качеством прогноза и дрейфом данных, переобучаем по отклонению метрик, а не по календарю, храним версии моделей и можем вернуть предыдущую.
Обсудим вашу задачу и вернёмся с планом работ
Первый разговор — это сбор вводных, а не презентация. Чтобы вернуться с планом этапов и оценкой решения, а не с общими словами, нужен минимум по данным, ограничениям и текущему процессу. Ниже — что уточняем и какие материалы просим показать.
- Задача и метрика успеха: доля прогнозов в пределах допуска, время реакции на отклонение, доля решений, которые система предлагает без ручного вмешательства.
- Исходные данные: выгрузки из систем управления транспортом и складом, история заказов, телеметрия, справочники маршрутов и тарифов — за какой период хранятся и в каком виде лежат сейчас.
- Качество данных: пропуски, дубли, расхождения между справочниками, разные единицы измерения и часовые пояса — от этого зависит объём подготовительного этапа.
- Замкнутый контур: где разрешено обрабатывать данные, какие внешние сервисы недоступны, кто выдаёт доступы и в какие сроки.
- Точки стыковки: с какой системой решение обменивается данными, в каком формате и с какой периодичностью, кто принимает данные на вашей стороне.
- Встраивание в процесс: кто и на каком шаге смотрит прогноз, что делает при отклонении, нужен ли режим подтверждения человеком.
Возвращаемся документом: состав этапов, что делаем на каждом, какие исходные данные нужны от вас на входе и какой результат показываем на выходе. Рядом — оценка решения: трудозатраты, сроки, ключевые риски и условия, при которых оценка пересматривается. Опишите задачу — вернёмся с этой картиной и планом работ.
