Для поддержания жизни форума хочу немного обсудить разные подходы к организации пополнения (где-то называют подпиткой).
Пополнение — это бизнес-процесс перемещения товаров из зоны хранения в зону отбора (где-то называют активной зоной) для возможности отбора продукции комплектовщиками под заказы от покупателей.
Само пополнение обычно делят на:
— Регламентное — пополнение освободившихся ячеек отбора или где осталось товара немного. При этом ячейки отбора зафиксированы за определенной номенклатурой.
— Под заказ (срочное) — пополнение ячеек отбора, где не хватает товара под запущенные заказы от покупателей. Более приоритетное, чем первое.
— В динамические ячейки — пополнение в динамические ячейки отбора под заказы. Ячейки не зафиксированы под определенные товары, а используются для осуществления процесса отбора для товаров, которым не назначены ячейки отбора.
В зависимости от склада, этот процесс может быть как второстепенный, так и очень важным.
Там, где ячеек отбора хватает и объем ячеек позволяет пополняться раз в неделю (например, по выходным) этот процесс не так актуален.
Ну а там, где ячеек отбора гораздо меньше чем номенклатурных позиций и оборот склада большой, приходиться пополнением заниматься на протяжении всего дня — процесс оптимального пополнения очень важен.
Теперь к реализации механизма — существуют два основных подхода в организации процесса в WMS (комбинированный пока не рассматриваем):
1. WMS периодически создает задачи для перемещения продукции из хранения в отбор. С заданным интервалом (или в определенный день) система анализирует минимальный и максимальный остаток в ячейке, находит для этого товара подходящую ячейку хранения и создает задачу на перемещение из ячейки А в ячейку Б (при этом товар заблокирован до окончания перемещения или его отмены).
Также задачи формируются при запуске заказов от покупателей.
+ Достоинства: есть возможность автоматической диспетчеризации задач по приоритетам
— Недостатки: возможны увеличения пробегов техники, блокировка ячеек процесса (например, не дает возможность вместо пополнения разместить в эту ячейку только что принятый товар), не всегда удобно создание задач по расписанию
2. WMS не создает задачи, а отслеживает потребность в каждой ячейке отбора, рассчитывает статус и необходимое количество (кто-то называет это «каналами»), а сами задачи формируются в момент запроса задания водителем ричтрака.
+ Достоинства: оптимальный пробег транспорта т.к. рассчитывается самое оптимальное перемещение в текущий момент времени в зависимости от места нахождения исполнителя и доступности товара не только в хранении, но и в других зонах где разрешено изъятие товара
— Недостатки: автоматическая диспетчеризация по разным типам задач затруднена т.к. сами задачи не создаются заранее.
Какой вариант более правильный, или есть другие решения?
Считаете ли вы процесс пополнения важным для обсуждения?
С какими способами оптимизации перемещений с помощью WMS вы сталкивались?
PS: свою практику буду раскрывать постепенно в ходе обсуждения ;)
Подключайтесь!
#Практика #Информационные_технологии_в_логистике
для продолжения дискуссии
вопрос -
что значит слово БИЗНЕС в данном предложении?
можно ли словосочетание БИЗНЕС-ПРОЦЕСС просто опустить в этом предложении?
измениться ли от этого смысл?
Можно опустить, смысл особо не измениться :)
Изменится ли «измениться», если опустить «ь» в данном предложении? ;)
По тексту можно найти еще несколько ошибок, только повод ли для обсуждения каждого слова в отдельности?
Или по теме высказаться некому?
тема проста как диффузия
тут и добавить нечего… не то, что обсуждать….
ИМХО
просто меня насторожило, что перевозка грузов внутри склада из обычной, рядовой операции вдруг стала БИЗНЕС-процессом
захотелось встать и нацепить парадный галстук….
Лично я за генерацию заданий. Тем более, что минусы относительно легко оптимизируются.
1. Оut-of-order execution. В момент, когда трак запрашивает следующее задание — система просматривает tasklist на заданную глубину, и выбирает такое задание, которое требует минимального холостого пробега трака от последнего зафиксированного местоположения. Плюс некий механизм дедлайна, чтобы задание из «неудобной» ячейки не могло обходиться траком бесконечно.
2. Alternative tasks. Если необходимый товар лежит на нескольких подходящих местах, то создается не одна задача на переноску, а несколько связанных альтернативных задач: «Взять с места А; Взять с места B; Взять с места C». При запросе траком следующей задачи, система выбирает из нескольких альтернатив ту, которую можно исполнить с минимальным пробегом, назначает ее траку, а остальные альтернативы уничтожает.
Сергей, спасибо за поддержание темы ;)
Оut-of-order execution не дает альтернативы в случае когда на одну ячейку отбора существуют десятки ячеек хранения (длинная позиция, активно и объемно продаваемая, причем размещенная не в одном месте) и товар также находиться еще на полу. При таком подходе следующая пара ячеек выбирается из принципа «меньшее зло», но при этом можно попытаться найти задачу «по пути» до ячейки хранения (например, снять паллету для отбора).
Alternative tasks чуть ближе к гибкости, но
1. Альтернативы создаются на момент формирования задачи(-ач), а к моменту ее выполнения ситуация на кладе может немного измениться и могут появиться более оптимальные источники.
2. Все альтернативные источники блокируются от изъятия (например, для отбора целой паллеты по следующему по порядку заказу) или требуется механизм убивания одной из «альтернативы» когда ни одна задача еще не взята, а есть потребность в продукции.
3. Возрастает нагрузка на систему т.к. на каждую ячейку отбора создается несколько задач по перемещению.
я за пока нерассматриваемый вариант - комбинированный:)
для операции пополнения полагаю лучшим генерацию заданий, при этом залежалые задачи можно периодически удалять — пусть планировщик создает новые по свежим данным.
а вот если операция пополнения в несколько этапов — то первое задание создавать, а последующие задания цепочки выдавать динамически по запросу исполнителя
Валерий, проблематика в том, что какой товар и куда пополнить — этот известно и можно зафиксировать.
Главный вопрос — откуда и когда. Т.е. можно создавать задачи с указанием конечной ячейки, а вот ячейку-источник и промежуточные уже искать интерактивно.
Если выделить ричтрак только для пополнения, то самым лучшим будет подход рассчитывать пару ячеек на текущий момент времени в зависимости от срочности заказов, ожидающих товар, и от текущего его местоположения.
Если же ричтрак должен выполнить ряд задач (размещение, отбор и пополнение), то тут заранее нужно формировать задачи, которые далее выдавать в нужном порядке.
Как у нас….
Есть ячейки комплектации, к которой привязан артикул. Отгрузка (оборот) артикула осуществляется через эту ячейку. У привязки есть параметр «Максимальное количество», «Порог пополнения».
Есть ячейки комплектации, привязанные к конкретному складскому участку, а участок привязан к складской группе.
Есть свободные ячейки комплектации, непривязанные ни к одной складской группе (общие)
Есть три типа пополнения
- автоматическое – когда запаса товара в ячейке не хватает для выполнения активированных заказов.
- предварительное – когда пополняются ячейки с привязкой до максимальной вместимости. Пополнение кратно ящикам. Если в ячейке есть неполный ящик – то система забирает россыпь. При этом есть возможность выбора % занятости ячейки – пополнять, если остаток ниже указанного %. Также ставится предельное количество формируемых заданий.
- пороговое – когда остаток в «привязанной» ячейке меньше указанного порога, но стараемся этим вариантом не пользоваться.
Итого. Днем выполняем пополнение по второму варианту, заполняя «привязанные» ячейки до максимума варьируя % заполненности. Ночью (дистрибуция) система сама генерирует необходимые пополнения по первому варианту, если дневного пополнения не хватило. Плюс для второго варианта используем административный расчет ячеек – количество товара в комплектации должно быть на 10-15% больше средне-пиковой суточной отгрузки.
Паллета-донор выбирается по FIFO, при равных датах прихода – с минимальным остатком.
Кроме этого днем используем компрессирование мест – маленькие остатки добавляем к остатку в комплектации, либо «склеиваем» маленькие остатки в хранении.
При обработке возвратов и малочисленных приходов используем «Дополнение» — когда товар размещается к остатку в зоне комплектации.
Работа с товаром, по которому ведется партионный учет и учет сроков годности, вносит свои коррективы, и требует строго соблюдения совместимости дат и партий.
Чтобы не переписывать сюда, размещаю ссылку.
Валерий, спасибо за статью, прочел с удовольствием.
Не совсем согласен, что там описано, но это не столь важно.
Статья более о процессе пополнения в общем, не касаемо особенности реализации в WMS.
Меня больше мучает вопрос оптимизации, рациональности процесса пополнения и выдачи задач в WMS.
Основная мысль статьи в том, что оптимальный способ пополнения для разных ситуаций будет разным. ;) Кстати, сейчас, вроде, модным течением стала адаптивность WMS — если уйти от рекламных брошюр, где новым словом называют старую возможность расставлять галочки, — то это как раз и будет возможность WMS самой оценить различные методы пополнения (причём динамически, в зависимости от происходящих изменений в товаропотоке) и выбрать из них оптимальный. Ведь все данные у WMS-ки для моделирования и оценки есть (или могут быть дополнительно заданы). А человек задаёт только приоритеты: скорость, равномерность, затраты…
Валерий, если углубиться в WMS с головой то становиться понятно, что процесс пополнения в текущих системах не оптимален т.к. это процесс для управления очень сложный.
Если с размещением и резервированием продукции все достаточно понятно, то процесс пополнения пока реализован в большинстве систем очень топорно — периодически создаются задания на пополнение ячеек. Проблема в том, что такой подход хорош на роботизированных складах. Когда же задачи выполняют люди, то свойственны задержки, а это значит, что к моменту выполнения задачи ситуация на складе может уже поменяться.
Если же попытаться рассчитывать наилучшее пополнение в момент, когда пользователь запрашивает задачу, то тогда возникают проблемы с приоритетом остальных задач или временем ожидания реакции от системы.
Вот и хочу понять где золотая середина, когда с одной стороны водитель ричтрака постоянно выполняет различные насущные операции (размещение, пополнение, отбор, перемещение) и не дает складу встать, и с другой стороны, в частности, задачи на пополнения выдаются именно оптимальным образом — приоритетно для наиболее востребованных товаров, из лучших мест хранения и с учетом его текущего местоположения.
Задачи на пополнение не должны формироваться жестко, а обладать некой свободой. Т.е. задача должна отражать потребность в пополнении ячейки отбора, но вот когда и откуда нужно рассчитывать уже по месту, в процессе поиска очередной задачи для водителя ричтрака учитывая параметры работы склада и нахождение товара в текущий момент времени.
Верю! :)
По уму, пополнение должно быть: либо периодическим и фиксированным по времени, либо производиться по потребности. В обоих случаях задача пополнения должна быть приоритетной, так как в первом случае это зашито в логику системы, а во втором мы, просто, испытываем неутолимую потребность в этой операции. Есть ещё смешанный тип, когда мы действуем по расписанию, но в случае, если к очередному моменту пополнения потребности в нём пока нет, мы его не совершаем — но в таком случае, операции и не возникает. То есть в любом из этих трёх случаев, когда возникает операция пополнения — она имеет наивысший приоритет, и остальные задачи честно ждут в очереди. А WMS может выбирать какая модель и с какими параметрами будет наиболее выгодной с точки зрения скорости и нагрузки на ресурсы — но это тоже сложная задача, и для её решения советую метнуться в соседние ветки по запасам и закупкам. ;)
Ну здорово! А что мешает реализовать этот алгоритм? Уже серверные ресурсы системы? Тогда надо загрублять и оптимизировать алгоритм уже с точки зрения этих ресурсов — но это больше работа для программиста.
Задачи пополнения не всегда являются приоритетными — все зависит от работы склада.
Например, задачи пополнения выполняются в течении смены для поддержания комплектации из ячеек отбора, но при определенных событиях водитель ричтрака должен выполнять другие задачи:
— Если в зоне приемки скопились неразмещенные паллеты, то нужно переключиться на размещение и хотя бы частично освободить зону.
— Если на воротах стоит машина под загрузку и осталось снять паллеты из ячеек второго яруса для загрузки, то водитель ричтрака опять же должен переключиться на эту задачу.
— Если все задачи на комплектацию продукции под заказ уже выполнены и остались задачи на отбор целых паллет, то тут опять же водитель должен оторваться от пополнения и отобрать требуемые паллеты.
Вернее правильнее не отрываться, а переключаться и оптимизировать пустые пробеги — отобрал паллету из зоны хранения и вывез к воротам для контроля, на обратном пути захватил паллету из зоны приемки и разместил в хранение, пополнил близлежайшую ячейку и снова отобрал паллету (в некоторых системах это называют «мультицикл»).
Технических проблем реализации того или другого алгоритма работы особых нет. WMS — это математический инструмент, построенный на принципе работы конечных автоматов. Главное разработать такой механизм, где было бы возможно моментально получать необходимый результат не нагружая сервер громоздкими рассчетами.
Получается, если появляется не приоритетная задача пополнения, значит никаких других задач уже нет? И никаких проблем, перечисленных в топике выше, кроме пустопорожнего пробега, тоже, значит, не возникает? Остаётся получается посчитать, что важнее временные затраты по ожиданию выполнения операций или, чтобы не было этого самого пустопорожнего пробега, и в зависимости от результата выбирать свою модель. Про смешанную написал ниже.
Реальную умную систему, которая сможет генерировать и корректировать в реальном времени такие «мультициклы», да ещё без серьёзной нагрузки на сервер — реализовать будет очень сложно, и в первую очередь потому, что такая система будет требовать от оператора задания весов для всех операций, с которыми система могла бы оценивать выгодность того или иного «мультицикла» — по сути получаются алгоритм по сложности как шахматы, причём на поле не в 64 клетки… Есть ещё третий путь — это задать всю экономику и поставить ограничители на систему (среднее и максмальное время на все виды операции с учётом времени ожидания), но такая система тоже получится не из простых.
Так дело-то как раз в том, чтобы найти баланс между нагрузкой на систему и загрублённостью алгоритма, заведомо не всегда чётко считающего. И тут очень много зависит не только от алгоритма, но и от его оптимизации, то есть программиста — можно до бесконечности перебирать все «мультициклы» по порядку, а можно только часть по какому-нибудь умному перебору!..
Если, реально, хочется получить такой алгоритм, то я бы советовал попробовать поговорить на эту тему с теми, кто рассчитывает автоматическую укладку грузов в автомобиль или на палету (им такие задачи знакомы). Или с теми, кто решает такие вот задачи от Яндекса: http://imat2010.yandex.ru/rules. ;) Можно покумекать над таким алгоритмом совместно, но для этого нужна чёткая формализация задачи — как говорится, правильный вопрос — уже половина ответа. ;)
Извините что вмешиваюсь в диалог профессионалов….
На мой взгляд все задачи про «мультициклы» и интерактивный подбор носителя для пополнения -«от лукавого»… из серии задач «а можно ли на ричтраки поставить gps?» :)
Всегда есть два способа решения складских задач — административный и программный…. И более продуманное административное решение позволяет не ломать копья над программными алгоритами с привлечением матмоделей….
Если исходить из допуска что склад настолько мал, что длина любого «вектора» перемещения незначительна — то даже склад с бесконечным фасадом можно разбить на «маленькие» склады, где не думать над оптимизацией перемещений.
По сути склад (читай водитель ричтрака) работает в «пакетных» заданиях — расставить паллеты с конкретной поставки, пополнить места комплектации для конкретной отправки, освободить места комплектации в конкретной зоне для пополнения под отправку, вывезти паллеты для конкретной отправки. И у каждой группы таких заданий есть приоритет, который можно менять через оператора. Допустим есть 1 ричтрак, поставка на 33 паллеты, отправка на 33 паллеты. Скорость обработки 2мин/палл. Важна свободная зона приема,отправка ждет — через час расставили поставку, через два — вывезли отправку. Надо отпустить машину — наоборот. Теперь включаем «мультицикл» — через час не имеем НИ ОДНОЙ законченной задачи. Смысл? Теперь про шахматные клетки. Если товар с прихода может попадать в ограниченную зону (товар одного поставщика/одной группы), то товар в отправку — ассорти. То есть ричтрак выполняя размещение с прихода все время оказывается в одном и том же секторе склада, и на 3-4-5 шаге «по пути» уже не будет паллет на вывоз к отправке. А значит он будет перемещаться вдоль фасада (просчитываем количество и пропускную способность коридоров в стеллажах, выезд в генеральный проезд сводит «мультицикл» на ноль). И уже получаем «треугольник» движения. Плюс техника имитирует броуновское движение на складе. А если сюда еще добавить пополнение «по дороге», то паллеты в зоне приема начнут думать — как им скрасить время ожидания :) Это мы еще не говорим о грустной вероятности возникновения на «побочных» этапах «мультицикла» ситуаций «А там нет паллеты, а место занято другим товаром, не влезает» ;D
Если есть два ричтрака — разделяем их по пакетным заданиям, что-то одно «горит» — совмещаем их на одном задании. Если нужно увеличение скорости — давайте вывозить паллеты поставки с ворот к началу принимающего ряда или «в лапы» ричтраку :)
Относительно интерактивного выбора ячейки для пополнения «по пути»… Для чего эта мнимая свобода? Есть заданный алгоритм отправки — FEFO, FIFO, LIFO плюс возможное ограничения по срокам на приему у Клиента. Работать такое решение, в основном, будет только на фронтальных стеллажах — уже область применения меньше… К тому же — данная оптимизация будет работать, если на складе товар находится на идентичных по количеству носителях, иначе количество оставшихся малочисленных количеств когда-то парализует пополнение…. Данная ситуация может привести к замедлению выборки данного наименования с «камчатки», ведь подхватывать будет те паллеты, которые по пути ричтрака + ближе к выходу — снова прощай ротация (например, смена дизайна упаковки, а у нас старый образец еще жив, хотя новый отгружаем)…
В итоге получаем набор ограничений, и легкой данная алгоритмизация уже не получится… опять же в помощь «кустовое» хранение над местом отбора, работа с «инвалидными» (неполными) паллетами — формирование одной неполной по артикулу при приеме, дополнение в комплектацию, компрессирование… ну и допуск что склад не настолько велик.. и длиной перемещения можно пренебречь… Опять же — доля перемещения к месту назначения в общем объеме операций (подъезд-разворот-подъем вил/паллета-снятие/постановка паллета-опускание паллета/вил-разворот) — опять боремся не за 100% оптимизации…
Поэтому для себя решил — не заморачиваться…. Правильное планирование + «всему свое время» (читай технологические окна) — и о такой оптимизации думать и нет смысла…
P.S. Повторюсь, это лишь мое мнение… ;)
по понятным причинам много писать не хочется :)
но в защиту «мультициклов» выскажусь
можно рассматривать два критерия оптимизации заданий для ричтрака:
— минимальное время выполнения пакета заданий, реализуется режимом «пакет заданий»
— максимальное количество выполненных заданий на каждый момент времени, реализуется «мультициклами».
для меня более предпочтительным является критерий, предполагающий «мультициклы». его достоинствами являются:
— минимизация пустых пробегов техники за счет зонирования маршрутов движения: ричтраки перемещают паллеты между буферами проходов и ячейками хранения. электротележки перемещают паллеты между буферами и воротами (экспедицией);
— обеспечение максимальной заполненности ячеек хранения: если для одного прохода стеллажей имеются 30 паллет для размещения и 30 паллет для вывоза, то нет необходимости резервирования 30 пустых ячеек для размещения — цикл работы включает вывоз-размещение. при этом после размещения паллеты задание на вывоз может подбираться из ячейки, ближайшей к текущему местонахождению.
т.е. два пакета заданий противоположной направленности выполняются за время превышающее продолжительность выполнения одного пакета размещения поставки не более чем на 10%.
а насчет Терминалов с GPS — такие наработки тоже имеются, причем с точностью до десятков см :)
Андрей, мнения конечно же могут быть разные — на то и форум, что бы их обсуждать ;)
Встречал начальников складов, которые говорили: «WMS — это все игрушки и никакая железка не заменит командный голос и дисциплину!».
Возможно, они тоже правы, но моя практика показывает обратное — с внедрением хорошей WMS процессы оптимизируются, и такие вот противники WMS или увольняются, или проникаются работой под управлением этой чертовой железкой :) .
Коли форум все же про IT, а не про склад в целом, то рассмотрим работу склада под управлением WMS и стоит ли оптимизировать перемещения.
Когда ходил в гости к 3PL оператору, то наблюдал картину как-раз «пакетной» работы.
Площадь склада более 20 т. кв.м., сидят сотрудники на столах, болтают. Вдруг приезжает машина, все вскочили, быстро разгрузили, ричтраки разместили и все, опять все сидят и болтают. При таких «наплывах» реально лучше работать «от задачи» даже если поток гораздо интенсивней.
Если рассмотреть дистрибьюторский склад средней фирмы с большим товарооборотом, то ситуация куда интереснее.
На ограниченной площади (2 — 5 т. кв.м.) в день нужно отгрузить порядка 20-50 заказов, собранных вчера, и собрать такое же количество заказов на завтра, нужно принять и разместить в хранение две фуры поступления, а зона приемки ели-ели вмещает половину фуры, ну и отпополнятся чтобы комплектация не встала т.к. ячеек отбора мало, а отгружают много. И на все это всего два ричтрака.
Если при такой работе начать работу от «пакета», то через какое-то время склад просто встанет, наступет патовая ситуация.
Реально управление берет на себя начальник склада — он в нужные моменты время отправляет сотрудников то на одну точку, то на другую. При этом не обязательно чтобы каждый пакет был доделан до конца — т.к. все делается с запасом времени, заранее, то к назначенному сроку обычно все успевают.
Но при наличии автоматизации не дело распределять задания командным голосом — система должна самостоятельно анализировать заполненность зон, отставание от графика по каждой отгрузке и перераспределять задания.
Реально на практике все это работает, есть конкретные примеры.
Ну а как в обществе, наука развивается на будущее, а в реалии пользуются текущими достижениями,
я заинтересован в оптимизации этого процесса, что и вылилось в эту тему.
Пожалуйста, войдите или зарегистрируйтесь, чтобы комментировать.