Как внедрить ИИ для отдела логистики: сценарии, кейсы, план

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

Какие проблемы отдела логистики решает ИИ

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

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

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

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

Логистика проигрывает не там, где сотрудники плохо работают, а там, где объем вариантов превышает возможности человеческого перебора. Именно в этом зазоре и живет эффект от ИИ.

Почему проблема не решается наймом людей

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

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

Где эффект появляется быстрее всего

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

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

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

Технологии, которые реально работают в логистике

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

Машинное обучение и предиктивная аналитика

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

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

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

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

Компьютерное зрение на складе и в транспорте

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

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

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

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

Языковые модели и ИИ-агенты

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

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

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

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

Оптимизационные алгоритмы и чем от них отличается роботизация

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

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

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

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

Сценарии применения ИИ в отделе логистики

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

Оптимизация маршрутов и планирование доставки

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

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

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

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

Прогноз спроса и управление запасами

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

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

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

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

Распознавание и проверка транспортных накладных и счетов

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

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

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

• Транспортная накладная с извлечением номера, дат, перевозчика, грузоотправителя, количества мест и веса.
• Международная накладная CMR с распознаванием латиницы и сверкой с данными таможенного оформления.
• Счет и универсальный передаточный документ с проверкой позиций против заказа по номенклатуре и цене.
• Акт о расхождении, который раньше заполнялся от руки на складе и терялся до конца месяца.
• Путевой лист с извлечением показаний одометра и расхода топлива для сверки с данными телематики.

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

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

Предиктивное обслуживание автопарка

Сценарий для компаний с собственным транспортом от двадцати единиц. Логика строится на данных телематики, истории ремонтов и показаниях бортовой диагностики. Модель ищет отклонения в поведении узлов и предсказывает отказ до того, как машина встанет на маршруте.

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

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

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

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

Контроль складских операций и выявление недостач

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

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

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

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

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

Работа с поставщиками и тендерами

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

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

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

Что сравниваем	Как было	Как становится
Критерий выбора	Тариф и личное мнение о контрагенте	Тариф плюс расчетная стоимость риска по истории
Обработка предложений	Ручное перенесение условий в таблицу	Извлечение условий моделью и проверка человеком
Память о проблемах	Хранится у конкретного логиста	Накапливается в системе и доступна всем
Скорость подбора под срочный рейс	Обзвон знакомых перевозчиков	Ранжированный список с учетом доступности

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

Разбор претензий и инцидентов

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

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

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

Аналитика и отчетность для руководителя

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

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

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

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

Как ИИ подключают к 1С, TMS и WMS

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

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

1. Данные из учетной системы выгружаются через программный интерфейс или промежуточную базу.
2. Модель обрабатывает запрос и возвращает результат в структурированном виде.
3. Результат записывается обратно в виде документа, задачи или рекомендации.
4. Человек видит результат в привычном интерфейсе, а не в отдельной системе.

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

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

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

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

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

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

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

Права доступа, логирование и контроль решений

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

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

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

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

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

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

Пошаговое внедрение: от пилота к рабочему процессу

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

Аудит процессов и выбор пилотной задачи

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

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

• Задача повторяется ежедневно или еженедельно, а не раз в квартал.
• Результат измеряется одной-двумя цифрами, которые уже считаются в компании.
• Данные для нее существуют в системе, а не в переписке и не в голове сотрудника.
• Есть сотрудник, который заинтересован в разгрузке именно этого участка.
• Неудача пилота не останавливает отгрузки и не ломает обязательства перед клиентами.

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

Подготовка данных

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

1. Выгрузите данные за период, достаточный для задачи, и посмотрите на них глазами, а не через отчет.
2. Посчитайте долю записей с незаполненными критичными полями и зафиксируйте ее как исходную точку.
3. Устраните дубли в справочниках, которые участвуют в пилоте, и назначьте ответственного за их ведение.
4. Разметьте аномальные периоды, то есть дефициты, акции, разовые крупные заказы и внешние события.
5. Настройте регулярную выгрузку, а не разовую, иначе модель будет учиться на устаревшей картине.

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

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

Выбор модели и инструмента под задачу

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

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

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

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

Замер результата и масштабирование

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

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

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

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

Эффект внедрения: что меняется в цифрах и в работе команды

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

Направление	Типичный эффект	От чего зависит разброс
Планирование маршрутов	Снижение пробега на десять-двадцать процентов, сокращение времени планирования в несколько раз	Плотность доставки, качество адресных данных, жесткость окон
Управление запасами	Сокращение запаса на десять-двадцать процентов при сохранении или росте доступности товара	Длина цикла поставки, ширина ассортимента, стабильность спроса
Документооборот	Автоматическая обработка от шестидесяти до девяноста процентов потока	Однотипность форм, качество сканов, доля бумажных контрагентов
Обслуживание парка	Снижение числа внеплановых остановок на десятки процентов	Возраст парка, полнота истории ремонтов, наличие телематики
Складские расхождения	Сокращение потерь по инвентаризации в разы на проблемных участках	Исходный уровень дисциплины, покрытие камерами, тип товара

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

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

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

Кейсы внедрения ИИ в логистике

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

Российские компании

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

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

Промышленность и перевозчики чаще говорят о другом наборе задач. РЖД и крупные операторы развивают планирование перемещения вагонов и прогноз сроков доставки, производственные холдинги внедряют предиктивное обслуживание транспорта и контроль погрузки по видео. Банковские и технологические платформы, включая решения Сбера и Яндекса, предоставляют инфраструктуру, на которой это собирается.

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

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

Зарубежный опыт

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

Amazon строит вокруг прогноза спроса всю модель размещения товара, перемещая запас между центрами исполнения заказов до появления заказа. DHL развивает компьютерное зрение на складах и предиктивную аналитику по срокам, Maersk применяет прогнозные модели к планированию загрузки судов и перераспределению контейнеров. В сельскохозяйственной и производственной логистике распространены модели предиктивного обслуживания техники, где отказ узла в поле стоит дороже самого ремонта.

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

Риски и сложности внедрения

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

Стоимость запуска и срок окупаемости

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

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

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

Сопротивление персонала

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

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

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

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

Нехватка исторических данных

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

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

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

Безопасность документов и коммерческой информации

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

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

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

Частые вопросы об ИИ для отдела логистики

Нужно ли уметь программировать, чтобы работать с такими системами

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

Подойдет ли это небольшой компании

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

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

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

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

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

Можно ли доверить системе принимать решения без человека

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

Как понять, что внедрение не окупится

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

С чего начать прямо сейчас

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

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