Системы оптимизации цепочки поставок

Что такое “промышленные системы оптимизации”, которые я здесь упоминаю? Вкратце – это системы, в которых можно построить модель цепочки поставок, внести физические ограничения цепочки поставок, такие, как возможные маршруты, логистические узлы разных типов, ограничения транспорта, возможности склада – вместимость, обработка, доступность спецтехники и человеческих ресурсов и т.д. А также задать затраты на всех операциях логистических узлов и маршрутов, например, стоимость транспорта, стоимость обработки товара, стоимость хранения.

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

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

Почему в данном случае JDA PSO? В JDA PSO, в отличие от достаточно многих промышленных систем оптимизации цепей поставок, есть такая сущность, как транспорт, конкретно – единица транспорта. Есть наличие функциональности моделировать возможности (ограничения), доступность и стоимость транспортной единицы. Так, например, можно наиболее точно смоделировать поставки груза разными типами транспорта или даже в контейнерах, задав при этом возможности контейнера (такие, как вместимость и минимальный уровень утилизации) и стоимость за контейнер, а не за объем / вес грузопотока, как это часто делается.

Более того, JDA PSO обладает богатым функционалом, о котором в будущем я напишу в другой статье.

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

От двух производителей из Китая везем продукцию на РЦ в России.

Китай.Завод-1 поставляет товар Позиция-1 (ITEM-01)

Китай.Завод-2 поставляет товар Позиция-2 (ITEM-02)supply chain model

Китай.Завод-1 -> РЦ Москва, варианты потоков:

  • Вариант 1: Китай.Завод-1 – Владивосток – Москва.
  • Вариант 2: Китай.Завод-1 – консолидационный склад в Тяньзинь – Котка – РЦ Москва.

Китай.Завод-2

  • Вариант 1: Китай.Завод-2 – консолидационный склад в Тяньзинь – Котка – РЦ Москва

model-design-china

От заводов до консолидационной точки товар в примере перевозится автотранспортом.

Маршруты с заводов до консолидационной точкиТранспортные ресурсы

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

  • Максимальная загрузка 20фт – 500 единиц продукции (ITEM01 или ITEM02)
  • Максимальная загрузка 40фт (ЖД и Море) – 1000 единиц продукции (ITEM01 или ITEM02)

Через Владивосток товар едет ЖД-транспортом, при этом есть выбор 40фт и 20фт контейнера. Цены контейнеров:

pso-container-prices

Из Тяньзинь – морской транспорт через Котку в Москву. Стоимость контейнера:

pso-container-prices-sea

Период планирования – неделя, горизонт – год

Забукированные мощности поставщиков:

Позиция-1: 1100

Позиция-2: 500

pso-mfg

Спрос на товар на уровне РЦ в Москве:

pso-demand

Запускаем оптимизацию сценария.

Итак рассмотрим результаты поставки 900 единиц позиции-1 от Китай.Завод-1.

model-design-china-item1

Поток должен пойти ЖД-транспортом, т.к. от начальной точки планирования недостаточно времени для отправки груза морем.

Маршрут Китай - Владивосток - Москва

Рассмотрим, как система рекомендует везти груз.

Система выбрала 40фт контейнер

Вполне предсказуемо система выбрала 40фт контейнер $4500, вместо двух 20фт:

(1) 500 sku + (2) 400 sku = $2500 + $2500 = $5000

Рассмотрим результаты поставки 500 единиц позиции-2 от Китай.Завод-2.

Позиция-2 перемещается в консолидационную точку

Мы видим, что система предсказуемо направила 500 единиц позиции-2 на консолидационную точку в Тяньцзинь. Примечательно, что при этом 200 единиц позиции-2 было также отправлено на данную консолидационную точку.

Посмотрим на карте, как был отправлен груз позиции-2.

Выбранный маршрут позиции-2

Т.е. груз пошел морем через Котку в РЦ Москва.

груз отправлен морем через Котку в РЦ Москва.

При этом мы видим, что система спланировала одновременную поставку позиции-1 и позиции-2 из Котки в Москву

Поступление груза в Котку

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

Отправка груза из Котки

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

Консолидация груза

Система консолидировала груз по двум позициям в один морской контейнер стоимостью $4000.

И в завершении – отображение итогов на картографическом отчете.

Итоговый товаропоток

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

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

Comments are closed.

Post Navigation