Load building: почему «полный кузов» не значит «лучше»

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

Что такое load building

Load building — это сборка заказов в рейсы/машины: какие заказы поедут вместе, в каком порядке, на каком типе ТС, с какими временными окнами и ограничениями по весу/объёму/паллетам/совместимости. В терминах исследований это частный случай shipment consolidation: управленческое объединение нескольких мелких отправок в более крупные ради экономии перевозки — но с побочными эффектами по сервису и времени цикла.

Какие входы нужны

Заказы (адреса, объём/вес/паллеты), ограничения совместимости, параметры автопарка, временные окна и SLA, время обслуживания точек, ограничения смен/доступности.

Какие решения принимает алгоритм

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

Почему это сложно

Потому что «оптимум по кузову» конфликтует с «оптимумом по сервису». Load building почти всегда живёт рядом с VRP/VRPTW и ограничениями реальной операционной логистики.

Ловушка «полного кузова»: где логика ломается

Полная загрузка часто выглядит как «очевидная эффективность», но в реальности — это лишь один показатель. В исследованиях по консолидации подчёркивают, что приоритет «сделать full truckload» не должен быть целью сам по себе: консолидация может удлинять цикл заказа и ухудшать сервис, а выигрыш по ставке перевозки съедается штрафами и косвенными затратами.

Цена ожидания

Чтобы «добить кузов», вы ждёте дополнительный объём: это добавляет задержку, повышает риск выхода за окна, увеличивает простои на точках и снижает предсказуемость выполнения.

Сервис и штрафы

«Почти полный кузов сегодня» иногда лучше, чем «полный завтра», если завтра вы платите penalties по SLA, теряете OTIF или ломаете закреплённые рейсы/графики.

Cost-to-serve важнее fill-rate

Два клиента могут иметь одинаковый объём, но радикально разный cost-to-serve из-за окон, расстояний, времени обслуживания, запретов совместимости и частоты «срочности».

Главная мысль: максимизация загрузки — это локальная цель. В логистике обычно нужно решать многокритериальную задачу: стоимость перевозки + стоимость сбоев/штрафов + стоимость ожидания/запасов + устойчивость расписания. Поэтому «полный кузов» должен быть не правилом, а результатом оптимального компромисса.

Метрики: что оптимизировать вместо «полного кузова»

Ниже — практичный набор KPI, который обычно делает решение «взрослым» для бизнеса.

• Сервис: OTIF/OTD, доля попадания во временные окна, SLA-штрафы, доля «срочных» доставок и переназначений.
• Производительность рейсов: empty miles, пробег, число точек, время в пути, dwell time (простои), service time (время на точке), выработка на ТС/смену.
• Экономика: стоимость рейса и стоимость стопа, cost-to-serve по клиентам/каналам, стоимость нарушений, эффект от консолидации vs стоимость ожидания.

В академических определениях shipment consolidation подчёркивается: экономия на перевозке — основная мотивация, но она всегда имеет «обратную сторону» в виде задержек/влияния на сервис. Поэтому KPI должны быть сбалансированы.

Практика load building: пошаговый playbook

Если коротко: сегментируем заказы, задаём окна консолидации и оптимизируем «стоимость обслуживания», а не «кузов».

1. Сегментация «must-ship vs can-wait». Разделите заказы на критичные по сервису (must-ship) и допускающие консолидацию (can-wait). Это сразу снижает риск «копить кузов ценой SLA».
2. Задайте окна консолидации. Например: «консолидируем в течение 2-6 часов», а дальше — отправляем. Это превращает load building в управляемое правило, а не в вечное ожидание «ещё одной паллеты».
3. Учтите реальные ограничения. Совместимость грузов, параметры ТС, сервисное время на точке, простои/очереди, окна, доступность смен. Без этого «идеальная загрузка» на бумаге станет провалом на земле.
4. Оптимизируйте cost-to-serve. Считайте стоимость решения целиком: рейс + штрафы + риск срыва + ожидание. Тогда «неполный кузов» может быть правильным ответом.
5. Правило «repair-first». Если вы пересчитываете план из-за событий, сначала чините локально (repair), а полный пересчёт — по расписанию. Это снижает нервозность плана и «качели».
6. Внедрите governance. Кто и когда принимает решение «ждать/не ждать», какие пороги по SLA, какие лимиты по перестройке маршрутов, что считается исключением.

Эффекты и примеры из источников

Важно: цифры зависят от отрасли, ставок, географии, дисциплины данных и политики сервиса. Ниже — ориентиры из публикаций.

• В работах по консолидации подчёркивают: строить FTL полезно, но это не универсальная цель — из-за влияния на цикл заказа и уровень сервиса.
• В публичных материалах встречаются примеры, где консолидация/перенастройка программ отгрузки описывается как источник существенных улучшений.
• В некоторых постановках оптимизации LTL-консолидации встречаются оценки потенциала сокращения транспортных затрат «до 80%» — как верхняя граница в конкретной модели/условиях.

В этой статье мы сознательно не обещаем «проценты» как гарантию. Мы используем публичные вилки как ориентир, а эффект в реальности фиксируем через KPI (сервис/стоимость/устойчивость).

FAQ

Источники и чтение

• Zaki Ali (2005): Shipment consolidation (анализ trade-off, примеры/оценки эффектов, тезис «FTL не всегда цель»).
• Cetinkaya (2000, JSTOR): формальная постановка shipment consolidation (определение, экономическая мотивация).
• Comparison of Typical Shipment Consolidation Programs (time/quantity/hybrid policies).
• Dynamic Directional Routing of Freight in the Physical Internet (2025): современный взгляд на баланс сервис и консолидация.