Руководитель направления систем бизнес-аналитики BIA Technologies Станислав Воронин рассказывает, как транспортной компании сэкономить миллионы рублей в месяц за счет оптимизации доставки сборных грузов.
В противовес FTL (full truckload) — доставке груза от одного клиента, LTL (less than truckload) означает доставку одной машиной грузов разных отправителей, которые консолидируются на складах. Во втором случае общая стоимость перевозки распределяется между всеми заказчиками, чьи заказы едут в машине.
В рамках этого блога я уже писал про оптимизацию маршрутов доставки, которая осуществляется путем решения классической задачи коммивояжера. На первый взгляд может показаться, что оптимизировать LTL-перевозки можно аналогичным образом. Однако на практике со сборными грузами всё оказывается гораздо сложнее.
Задача коммивояжера заключается в поиске наиболее выгодного маршрута, пролегающего через указанные города по одному разу с последующим возвратом домой. В случае с LTL, нам нужно понять, как доставить множество различных грузов с разными пунктами назначения, какие грузы можно временно оставить на складе, а какие лучше переправить на другой хаб, где и сколько раз осуществить перегруз, и какое количество машин потребуется для того, чтобы закрыть все заказы вовремя.
Предположим, что у нас есть коробка, которую необходимо доставить из Мурманска в Новосибирск. Отправлять практически пустой грузовик через всю страну — не рационально. Но и ждать несколько недель, пока на складе соберется достаточное количество грузов по этому направлению, мы не можем — клиент окажется недоволен и обратится к услугам конкурентов. Значит, нам нужно организовать другую схему перевозки по требуемому направлению, которая позволит сократить сроки доставки. Например, мы отправляем груз из Мурманска в Санкт-Петербург вместе с грузами, которые должны оказаться в Казани, Екатеринбурге и Владивостоке, пересортируемся на хабе и едем дальше.
Если в распоряжении транспортной компании имеется около 30 хабов, которые обслуживают 200 конечных складов, значит, система планирования должна будет перебрать до 40 000 вариантов направлений. При этом она должна будет учесть ограничения в пропускной способности складов, время их работы, хрупкость и габариты грузов, жесткость клиентских сроков и многое другое.
Сначала математическая модель анализирует исторические данные по грузопотоку за прошедший год и прогнозирует, какое количество груза будет сдано на конкретный склад в следующем месяце в разрезе каждого дня. После этого система перебирает все возможные варианты погрузки и выбирает оптимальный рейс. Задача оптимизации — увеличить утилизацию полуприцепов, сократить время в пути, а также уменьшить затраты на перемещения транспорта и на погрузку–выгрузку.
Система формирует расписание LTL-перевозок на месяц вперед. Это позволяет транспортной компании заранее определять необходимое количество ресурсов на довольно длительный горизонт. В случае, если закрыть все заявки собственным парком машин невозможно, планирование позволит договориться об аренде чужого транспорта по тендерной, а не спотовой цене, тем самым существенно снизив расходы.
Несбалансированность грузопотока по стране означает, что нам также нужно продумывать возвращение машин. Если в обратную сторону движения не нашлось LTL-грузов, необходимо заранее найти заявки на FTL-перевозку, чтобы зациклить рейс и обеспечить устойчивость грузопотока. В противном случае, через всю страну придется отправлять порожний грузовик. Планирование позволяет определить число необходимых FTL-заявок и дать соответствующее задание отделу продаж на месяц вперед. Наша практика показывает, что крупная транспортная компания только за счет этого может сэкономить до десятка миллионов рублей в месяц.
Понятно, что делая прогноз на месяц вперед в отсутствие реальных заявок, точность планирования не будет стопроцентной. На примере нашего клиента (одной из крупнейших транспортных компаний России), могу сказать, что порядка четверти рейсов корректируются в ручном режиме.
Напрашивается вопрос: почему нельзя было создать автоматизированную систему оперативного перепланирования? Отвечу. Во-первых, мы имеем дело с довольно большим количеством неоцифрованных данных (например, водитель договорился со складом по телефону о заборе небольшого груза вне плана, а информация об этом никуда не была занесена). Во-вторых, комбинаторика слишком сложна, а времени на принятие решений совсем немного.
Чтобы был понятен масштаб задачи, поясню, что речь идет о сотнях миллионов переменных и работе на пределе оптимизационного движка. Первая версия модели просчитывала месячный план за три недели, текущая модель делает это за 36 часов. Впрочем, это не значит, что автоматизировать суточное планирование невозможно. Вычислительные возможности компьютера постоянно совершенствуются — это лишь вопрос времени.