Самая проблемная часть TMS — исполнение перевозки

Крайне злободневная статья одного из создателей вероятно самой успешной системы и компании на рынке TMS — Митча Визли (Mitch Weseley, см на linkedin). Подпишусь под каждым словом. Также в эту копилку уже добавляют негативные примеры внедрения TMS на просторах нашей Родины (например один ведущий российский ритейлер, название которого довольно легко может подсказать любой поисковик =).  Мы боремся с подобными проблемами при помощи крайней скурпулезности при рекомендации продукта клиенту и прочими проактивными мероприятиями как до, так и в ходе проекта. Есть еще ряд методик по борьбе с такими эффектами.

Оригинал статьи я нашел на logisticsviewpoints.com, рекомендую туда заглядывать почаще… Читаем перевод:

Самая проблемная часть перевозки — исполнение

24 октября 2013

Этот текст является по-сути продолжением моей предыдущей статьи, которая фокусирует внимание на  построении системы маршрутизации. А также непреложном факте, что реально нет никаких других «оптимизационных» алгоритмов, кроме эвристических, также как же как тщательный выбор ограничений очень важен для получения минимальных затрат в ходе такой оптимизации. Но сейчас я хочу сместить фокус на наиболее сложную часть системы управления перевозками (TMS) — как раз на исполнении этих самых «рекомендаций» по выполнению перевозки, полученных на предыдущей стадии планирования.

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

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

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

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

  1. Изменения в заказе – Большинство компаний разрешают клиентам делать изменения в заказе максимально близко к дате отгрузки. Эти изменения обычно передаются из ERP системы и могут случиться даже когда заказ уже собран  на складе. И иногда даже вывезен в зону отгрузки.

  2. Изменения на стороне склада – интеграция между WMS/TMS довольно хлопотное дело. Могут быть пересортицы, недостачи, возвраты по качеству. В некоторых ситуациях (смешанные паллеты и разноформатные коробки) расчет кубатуры или укладки на паллет может привести к неправильному пониманию реального количества груза на стадии планирования. В некоторых случаях вес может сильно измениться. Как в притче о курице и яйце: склад не может сказать как он упакует, пока нет информации как заказ будет отгружен. С другой стороны, количество и упаковка груза может меняться вплоть до момента, пока машина не выехала за территорию склада. Поэтому никакие алгоритмы в этой области не дают 100% точности планирования.

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

  4. Переназначение окон приемки – Еще одна «курица-яйцо» ситуация. В случае с отгрузкой из уже известного нам Мемфиса, грузоотправитель может иметь два заказа на восточное побережье. Оба заказа имеют одно окно для выгрузки, назначенное на четверг.  Тем не менее, когда перевозка уже сформирована,  выяснилось, что первый клиент попросил однократно сдвинуть доставку на пятницу, но второй так и остался в четверг. Опять же, такой случай не подпадает под действия схем.

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

  6. Поток операций в реальном масштабе времени – Я хотел бы видеть этот процесс как если бы заказы несло течением в виде предметов по реке. Заказы создаются, затем следуют по потоку операций и в конце отгружаются.  Процесс корректив может выглядеть как например заказы «разрушаются» изменениями, похожими на описанные выше. И эти изменения могут привести к изменению направления течения потока. Но в конце концов они должны сгруппироваться в некий единый объект, что означает что они запланированы корректно.

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

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

Прежде всего, потенциальные выгоды огромны. Я работал с рядом клиентов, которые экономили 10-20% от их расходов на транспорт, используя подобные методики. Многие компании готовы поработать в этом направлении, чтобы сэкономить эти деньги. Во-вторых, проблемы, требующие перепланирования, не происходят слишком часто. И могут быть решены довольно быстро и безболезненно, если иметь для этого подходящий инструмент. Тем не менее, если эти проблемы не решены корректно, все эти выгоды могут исчезнуть или даже груз может быть доставлен с опозданием, либо отправка будет сорвана. В третьих, маршрут с несколькими остановками должен улучшить клиентский сервис с помощью более быстрых и надежных доставок с меньшим уровнем проблем. Если ответ «да» на любые из этих вопросов, то этим действительно стоит заниматься, имея подходящие инструменты.

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

В итоге индустрия нуждается в решении, которое эффективно работает с такими проблемами, как:

  1. Эвристические алгоритмы, которые не могут быть нормальным образом «оптимизированы».

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

  3. Реализация этих алгоритмов должна работать на основе постоянно меняющихся данных.

  4. Есть ряд сценариев типа «курица-яйцо» в которых решение подлежит значительному пересмотру в зависимости от дальнейших действий и результатов расчета.

  5. Рекомендации должны вводится в действие немедленно включая подбор на складе и погрузку в транспортные средства.

 

This entry was posted in Информационные технологии, Управление перевозками. Bookmark the permalink.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


*