Для поддержания жизни форума хочу немного обсудить разные подходы к организации пополнения (где-то называют подпиткой).
Пополнение — это бизнес-процесс перемещения товаров из зоны хранения в зону отбора (где-то называют активной зоной) для возможности отбора продукции комплектовщиками под заказы от покупателей.
Само пополнение обычно делят на:
— Регламентное — пополнение освободившихся ячеек отбора или где осталось товара немного. При этом ячейки отбора зафиксированы за определенной номенклатурой.
— Под заказ (срочное) — пополнение ячеек отбора, где не хватает товара под запущенные заказы от покупателей. Более приоритетное, чем первое.
— В динамические ячейки — пополнение в динамические ячейки отбора под заказы. Ячейки не зафиксированы под определенные товары, а используются для осуществления процесса отбора для товаров, которым не назначены ячейки отбора.
В зависимости от склада, этот процесс может быть как второстепенный, так и очень важным.
Там, где ячеек отбора хватает и объем ячеек позволяет пополняться раз в неделю (например, по выходным) этот процесс не так актуален.
Ну а там, где ячеек отбора гораздо меньше чем номенклатурных позиций и оборот склада большой, приходиться пополнением заниматься на протяжении всего дня — процесс оптимального пополнения очень важен.
Теперь к реализации механизма — существуют два основных подхода в организации процесса в WMS (комбинированный пока не рассматриваем):
1. WMS периодически создает задачи для перемещения продукции из хранения в отбор. С заданным интервалом (или в определенный день) система анализирует минимальный и максимальный остаток в ячейке, находит для этого товара подходящую ячейку хранения и создает задачу на перемещение из ячейки А в ячейку Б (при этом товар заблокирован до окончания перемещения или его отмены).
Также задачи формируются при запуске заказов от покупателей.
+ Достоинства: есть возможность автоматической диспетчеризации задач по приоритетам
— Недостатки: возможны увеличения пробегов техники, блокировка ячеек процесса (например, не дает возможность вместо пополнения разместить в эту ячейку только что принятый товар), не всегда удобно создание задач по расписанию
2. WMS не создает задачи, а отслеживает потребность в каждой ячейке отбора, рассчитывает статус и необходимое количество (кто-то называет это «каналами»), а сами задачи формируются в момент запроса задания водителем ричтрака.
+ Достоинства: оптимальный пробег транспорта т.к. рассчитывается самое оптимальное перемещение в текущий момент времени в зависимости от места нахождения исполнителя и доступности товара не только в хранении, но и в других зонах где разрешено изъятие товара
— Недостатки: автоматическая диспетчеризация по разным типам задач затруднена т.к. сами задачи не создаются заранее.
Какой вариант более правильный, или есть другие решения?
Считаете ли вы процесс пополнения важным для обсуждения?
С какими способами оптимизации перемещений с помощью WMS вы сталкивались?
PS: свою практику буду раскрывать постепенно в ходе обсуждения ;)
Подключайтесь!
#Практика #Информационные_технологии_в_логистике
To Павлов Валерий: работа через буферное место перед рядом, когда эл/тележка «подвозит снаряды» хороша для узкопроходников. Для обычной равномерной нагрузки (ИМХО) 2-хсуставная передача товара — это использование 2-х единиц техники, плюс риски некорректного наполнения буферного места (либо место закончилось, либо нет «патронов» для ричтрака). Когда скорость во главе — тогда не спорю.. Но если пиковая нагрузка считается как норма — тогда и порваться недолго…
Насчет экономии 90% при встречных пакетах не буду спорить. У меня другие цифры, даже где-то файлик с данными секундомера есть. Я уже писал — доля «выбега из ряда» по сравнению с полным циклом не так велика. И если ричтрак берет паллету из той же вертикали, куда размещал поддон с поставки — еще может быть 90%, в остальных случаях — сильно сомневаюсь. На 10% меньше чем совокупное время двух «пакетов»- вероятно :) Если мне срок не важен — то я эти 30 отправлю кросс-доком. Ну то такое…
То Рубанов Сергей: Абсолютно согласен — ситуации бывают разные. Для обеспечения нормальной работы склада есть расписание. Чтобы не было нахлестов — не надо все планировать встык. Отправка является «главной» операцией на складе, место в зоне приема-отпуска — самое дорогое. Эти два постулата помогают определить стратегию. Я только «за» автоматизацию, которая исключит то самое человеческое «а я подумал что…» Но только если усилия по автоматизации дают свои плоды. А если решение не для всего склада и не для всех ситуаций — то лучше изменить расписание. Когда у нас 25/25 траков вход/выход — то работаем волнами. Если зоны отпуска не хватает — собираем сборные паллеты — полные вывозим в «онлайне» в кузов. Если дневной смены не хватает — включаем в расписание ночную. «Не надо экономить на заварке»(с) ;D А если ставить задачу все сделать за 2 часа — то однозначно нужна сверхоптимизация.
Андрей, Вы правы, когда речь идет о большой площади склада и нужном количестве техники.
Мы с Валерием, видимо, сталкиваемся с другими клиентами — те, кто пытается снять как можно меньшую площадь склада (рассчитывают впритык под текущий оборот + небольшой прогноз роста), заставить под завязку стеллажами (жалко же что площадь будет «простаивать» — нужно везде напихать стеллажи) и скупыми на дорогую технику.
Иногда доходит до абсурда — в целях экономии и попытки обойтись всего одним ричтраком, заказчики предлагают даже трехходовки — паллету с приемки вначале размещает сотрудник с тележкой — если можно вниз, то размещает вниз, если наверх, то перемещает в зону перехвата другой техники, а там, если возможно, паллету забирает водимый штабелер (который может поставить до 3-го яруса), ну и под конец только ричтрак.
Также на моей практике были предложения пополнения в два захода (при неполном пополнении, когда нужно доложить товар на паллету) — вначале ричтрак снимает в проход все нужные паллеты, далее сотрудники перекладывают товар в ячейки отбора, после чего ричтрак возвращает паллеты обратно. При этом никто не задумывается как будет проезжать другая техника и ходить комплектовщики…
Если провести аналогию, то можно сравнить с автомобилями — если у вас стоит двигатель в 500 лошадей, то вам все-равно какой у него КПД, а вот когда по закону страны вы не можете выпустить автомобиль более 280 л.с., то вы начинаете выжимать из того что есть максимум.
То же и с логистикой — при наличии площадей и техники многие 3PL-щики не задумываются над оптимизацией и после внедрение WMS занимаются только интеграцией с разными клиентами, порой даже отказывая некоторым клиентам из-за особенности складирования. А потом в кризис начинают заваливать спамом и предлагать демпинговые цены т.к. вся эта техника просто простаивает.
Когда же нужно получить максимум из имеющихся возможностей, то тут умные алгоритмы реально помогают справиться меньшим количеством персонала и техники.
Как раз в этой теме и идет попытка найти алгоритмы оптимизации перемещений (конкретно пополнения) когда минимальное количество техники и персонала делает максимально полезный объем работ.
PS: У вас стоит Qguar WMS?
Да, все склады работают под управлением Qguar Pro. Есть формат работы распределительного центра и дистрибуции. В каждом формате на каждом складе своя индивидуализация пополнения. Несмотря на большие площади у нас нет свободно-гуляющего места :) На одном из складов ширина проездов на 45мм больша ast ричтрака :) На каждом складе минимум две единицы подъемной техники, плюс всегда есть высотный и обычный ричтрак. Опять же — большое внимание уделяем предподготовке товаров. Некоторые паллеты «пилим» при приемке по высоте, чтобы пополнять без возврата остатка. Уже писал, для дистрибуции используем предварительное дневное пополнение мест комплектации.
Все средства оптимизации хороши, особенно когда они не генерят новых ошибок… И очень здорово, когда нагрузка на склад условно-равномерная. А если за час до окончания рабочей смены три машины не приехали на погрузку, а товар собран, вместо одной машины прихода приехало три после растаможки )))) Поэтому если оптимизация дает нам потенциальное увеличение эффективности на 5%, но при этом есть риски более 30% — то не внедряем. А все остальное — с огромной радостью. Как говорят за рубежом — «Be simple!» :)
Qguar, к сожалению, скуп на сложные алгоритмы и вынуждает применять другие механизмы оптимизации. Хотя это отдельный разговор — никакая WMS не способна «вытянуть» склад, если сам склад (процессы, сотрудники и оборудование) не оптимально использует доступные ресурсы.
По статистике, которую мне передал один из крупных вендоров, очень мало складов занимаются оптимизацией процессов в самой WMS после внедрения. На тот момент из пару десятков внедрений на складах, вендор выделил только две компании, которые интенсивно работали над совершением работы WMS — это одни из фармацептов, и компания, где я тогда еще работал :)
А в текущей своей практике часто сталкиваюсь с тем, что уже даже на этапе согласования будущих складских процессов чувствую отсутствие представителей заказчика желания вникать в процессы и оптимизировать их. Часто заказчик делает незначительные замечания и соглашается с предложенными процессами не пытаясь полностью в них разобраться. Приходиться брать эти обязанности на себя и пытаться расшевелить заказчика активней участвовать в проекте.
Также нужно понимать, что те технологии, которые мы хотим тут обсудить, не являются основополагающими — при нештатной ситуации (например, внеплановый приезд крупного клиента) всегда можно поднять срочность определенному заказу и кинуть дополнительные силы на его выполнение.
Также нельзя прогнозировать такие ситуации, а вот работать по факту приезда машины тоже не правильно — по любому нужно планировать работы заранее и выполнять работы на складе с учетом запланированных приездов.
Если же клиент не приехал — должна быть зона хранения собранных заказов в стеллажах.
Если клиент приехал не вовремя, то его заказ становиться приоритетным, но это не значит что все силы кидают на его выполнение т.к. потом можно получить принцип домино когда даже вовремя приехавший клиент стоит в очереди из-за того, что предыдущий клиент испортил все планы склада (как меня бесит такое в автосервисе — приезжаю во время по записи, а приходиться ждать т.к. кто-то приехал раньше, не по записи, и все кинулись чинить именно его машину…)
Если вернуться к теме, то можно рассмотреть процесс пополнения на примере Exceed. В системе есть хороший механизм отслеживания потребности в пополнении каждой ячейки отбора, но идиотский механизм выдачи задач на пополнение — задачи сортируются по приоритету (полноте пополнения и типу пополнения) и без учета текущего местоположения. В итоге с неоптимальными алгоритмами размещения, водитель ричтрака носится по всему складу выполняя пополнения с большими пробегами. И пока нет внешний проявлений (задержки отгрузок) никто на это не обращает внимание т.к. большое кол-во ричтраков вполне справляется с нагрузкой.
Единственное решение в таком случае — деление склада на зоны, закрепление за зонами определенной группы товаров и разграничение прав доступа к зонам для разных ричтраков. Это помогает сократить перемещение по всему складу, но не считаю, что на этом процесс оптимизации пополнения можно закрыть.
Скуп на сложные алгоритмы — если можно — киньте в личку пример нереализованного — интересно. Что касается возможностей — то есть и участки сбора с персональным приоритетом, и, соответственно пополнять можно каждый участок сбора, выполняя все задания внутри одного участка, и потом переходя к следующему, в не вперемешку весь склад. Складским участком мы локализуем хранение над участком сбора, оставляя запас плюс непривязанную зону. Таким образом минимизируя пробеги в рамках участков. Ну и немаловажная стретегия — количество и размер мест комплектации. От этого тоже зависит немало в оптимизации. Qguar также «умеет» пополнять как по вместимости, так и по потребности (от заказов).
А про технологические окна с учетом мощности склада и расписание я уже писал, и согласен с Вами. Нам это помогает. Плюс всегда есть набор внутренних работ с различной срочностью, которым мы нивелируем «пустоты».
Резюмирую нашу переписку по ЛС с Андреем — Qguar действительно не поддерживает многие сложные алгоритмы, но вопрос другой — стоит ли овчинка выделки?
Т.е. нужны эти алгоритмы в WMS или любую задачу можно решить административно или путем несложных манипуляций с размещением продукции по зонам и другой организацией процессов?
Эхх все сказки, сказочки … :-(
Судя по Вашей фразе получается что Qguar вообще ничего не умеет… Хотя заданные Вами вопросы охватывают функционал, встречающийся далеко не на 100% складов и совсем не ежедневных операций… Я не планировал с Вами спорить — просто считаю что говорить «удобную» правду не совсем верно.. или совсем неверно :)
Андрей, фраза поставлена правильно — «многие сложные алгоритмы»
В ней нет «вообще ничего не умеет» — это уже Ваши слова.
Мы в переписке обсуждали именно сложные алгоритмы, чем отличаются продвинутые системы от хороших, но все же не полностью функциональных.
Вот список того, что было обсуждено:
— Автоматическая блокировка товара при приемки.
— Маршрутизация перемещений.
— Размещение товара в хранение по возможности ближе всего к ячейке отбора.
— Разбитие задач на отбор между разными типами техники и свой порядок обхода для каждого типа техники.
— и т.п.
Вроде Вы сами согласились, что с таким функционалом не сталкивались и он Вам не нужен — именно это я и написал резюмируя переписку, и ничего более.
Из продвинутых систем мне больше всего нравиться из западных PSI, а из отечественных Solvo.
И в проектах, что я видел, этот функционал используется.
То Рубанов Сергей.
С одной стороны хочу остановиться обсуждать данный вопрос с Вами, с другой — начавшееся обсуждение затрагивает и сторонние компании. Повторюсь, я являюсь активным пользователем Qguar, но не продавцом/разработчиком. Что касается Вашего резюмирования….
Ну например «- Размещение товара в хранение по возможности ближе всего к ячейке отбора. » — я же писал Вам, что у нас сейчас в системе есть 33 алгоритма размещения товара из поставки (с учетом привязок, весогабаритных характеристик, etc). Очередность их использования определяется приоритетом. Одна из стратегий — Размещение товара в непосредственной близости от места сбора — (при этом система «шагает» вверх-вниз-вправо-влево по ряду/секции/уровню).
Для Вас же эта функциональность включена в раздел «не поддерживает»…
Да и вообще — отклонились от топика, хотя Вы — ТС, и сами курируете данный вопрос…
Постараюсь больше не засорять топик…
Андрей, либо вы умело играете фразами, либо так получилось.
Но в нашей переписке было лишь упоминание только о 33 алгоритмов и то, что их названия не переведены и неизвестно есть ли среди них нужный.
Сейчас, вдруг, вкрывается, что есть стратегия «Размещение товара в непосредственной близости от места сбора» и меня обвиняют, что я включил в «не поддерживает». Наверное, сейчас, вдруг, окажется что весь функционал поддерживается и я вообще не прав во всем.
Такой ход разговора, когда в личной переписке вы указываете одно, а в форуме другое меня не устраивает.
Или вы обиделись, что я резюмировал наш разговор публично? Тогда прошу прощения.
Я не согласен с такими обвинениями (в доказательство могу привести выдержки из переписки, но принципиально не буду).
Андрей, я солидарен — хочу остановиться обсуждать данный вопрос с Вами (тем более разговор изначально не заладился с Вашей попыткой доказать, что с одной стороны всякие умные алгоритмы в WMS не нужны, с другой стороны что все они у Вас есть).
Сергей, Вы взрослый человек, кто Вас в чем обвиняет? ;D
Все что я написал — что не согласен с «крайностями». Я не говорил, что все алгоритмы, которые Вы называете умными или сложными есть в Qguar. Обратное утверждение что многие сложные алгоритмы не поддерживаются в системе — тоже неверно.
Если мнение отличное от Вашего — это признак того, что разговор не заладился, то зачем открывать топик для обсуждения? :)
Например, для меня непринципиально отсутствие «умного» алгоритма, который позволяет (Ваш пример) при поступлении от поставщика Х блокировать только для продукции Y и не чаще раз в два месяца? Если у меня такое будет часто — я найду программное решение. Если редко — то есть административное решение.
Совсем не хочется, чтобы данный форум становился «обычным», где любой топик заканчивается переходом на личности….
Давайте обмениваться конструктивной информации по логистике :) и жить при этом дружно ;)
Мне видится следующее:
На складе мало штабелеров и достаточно рохлей. Пополнение необходимо.
Склад узкопроходный и штабелеры работают на рельсах только внутри прохода. Пополнение необходимо.
Штабелерная машина -весьма дорогостоящий механизм и гонять его в зону отгрузки директор склада запрещает. Пополнение необходимо.
И оно совсем не нужно, если отгрузка ведется полными паллетами. В этом случае схватил паллет сверху на вилы и в отгрузку… (если не учитывать первое второе и третье).
Пожалуйста, войдите или зарегистрируйтесь, чтобы комментировать.