Архив форума

Для поддержания жизни форума хочу немного обсудить разные подходы к организации пополнения (где-то называют подпиткой).
 
Пополнение - это бизнес-процесс перемещения товаров из зоны хранения в зону отбора (где-то называют активной зоной) для возможности отбора продукции комплектовщиками под заказы от покупателей.
 
Само пополнение обычно делят на:
- Регламентное - пополнение освободившихся ячеек отбора или где осталось товара немного. При этом ячейки отбора зафиксированы за определенной номенклатурой.
- Под заказ (срочное) - пополнение ячеек отбора, где не хватает товара под запущенные заказы от покупателей. Более приоритетное, чем первое.
- В динамические ячейки - пополнение в динамические ячейки отбора под заказы. Ячейки не зафиксированы под определенные товары, а используются для осуществления процесса отбора для товаров, которым не назначены ячейки отбора.
 
В зависимости от склада, этот процесс может быть как второстепенный, так и очень важным.
Там, где ячеек отбора хватает и объем ячеек позволяет пополняться раз в неделю (например, по выходным) этот процесс не так актуален.
Ну а там, где ячеек отбора гораздо меньше чем номенклатурных позиций и оборот склада большой, приходиться пополнением заниматься на протяжении всего дня - процесс оптимального пополнения очень важен.
 
Теперь к реализации механизма - существуют два основных подхода в организации процесса в WMS (комбинированный пока не рассматриваем):
 
1.  WMS периодически создает задачи для перемещения продукции из хранения в отбор. С заданным интервалом (или в определенный день) система анализирует минимальный и максимальный остаток в ячейке, находит для этого товара подходящую ячейку хранения и создает задачу на перемещение из ячейки А в ячейку Б (при этом товар заблокирован до окончания перемещения или его отмены).
Также задачи формируются при запуске заказов от покупателей.
 
+ Достоинства: есть возможность автоматической диспетчеризации задач по приоритетам
- Недостатки: возможны увеличения пробегов техники, блокировка ячеек процесса (например, не дает возможность вместо пополнения разместить в эту ячейку только что принятый товар), не всегда удобно создание задач по расписанию
 
2.  WMS не создает задачи, а отслеживает потребность в каждой ячейке отбора, рассчитывает статус и необходимое количество (кто-то называет это "каналами"), а сами задачи формируются в момент запроса задания водителем ричтрака.
 
+ Достоинства: оптимальный пробег транспорта т.к. рассчитывается самое оптимальное перемещение в текущий момент времени в зависимости от места нахождения исполнителя и доступности товара не только в хранении, но и в других зонах где разрешено изъятие товара
- Недостатки: автоматическая диспетчеризация по разным типам задач затруднена т.к. сами задачи не создаются заранее.
 
Какой вариант более правильный, или есть другие решения?
Считаете ли вы процесс пополнения важным для обсуждения?
С какими способами оптимизации перемещений с помощью WMS вы сталкивались?
 
PS: свою практику буду раскрывать постепенно в ходе обсуждения
Подключайтесь!

Процитировано сообщение: Емеличев Алексей от 01.04.2010 :: 12:54:20:

 
Можно опустить, смысл особо не измениться

Процитировано сообщение: Каприелов Михаил от 01.04.2010 :: 13:47:59:

 
По тексту можно найти еще несколько ошибок, только повод ли для обсуждения каждого слова в отдельности?
Или по теме высказаться некому?

Лично я за генерацию заданий. Тем более, что минусы относительно легко оптимизируются.
 
1. Оut-of-order execution. В момент, когда трак запрашивает следующее задание - система просматривает tasklist на заданную глубину, и выбирает такое задание, которое требует минимального холостого пробега трака от последнего зафиксированного местоположения. Плюс некий механизм дедлайна, чтобы задание из "неудобной" ячейки не могло обходиться траком бесконечно.
 
2. Alternative tasks. Если необходимый товар лежит на нескольких подходящих местах, то создается не одна задача на переноску, а несколько связанных альтернативных задач: "Взять с места А; Взять с места B; Взять с места C". При запросе траком следующей задачи, система выбирает из нескольких альтернатив ту, которую можно исполнить с минимальным пробегом, назначает ее траку, а остальные альтернативы уничтожает.

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

Как у нас….  
 
Есть ячейки комплектации, к которой привязан артикул. Отгрузка (оборот) артикула осуществляется через эту ячейку. У привязки есть параметр «Максимальное количество», «Порог пополнения».  
 
Есть ячейки комплектации, привязанные к конкретному складскому участку, а участок привязан к складской группе.
 
Есть свободные ячейки комплектации, непривязанные ни к одной складской группе (общие)
 
Есть три типа пополнения
 
- автоматическое – когда запаса товара в ячейке не хватает для выполнения активированных заказов.  
 
- предварительное – когда пополняются ячейки с привязкой до максимальной вместимости. Пополнение кратно ящикам. Если в ячейке есть неполный ящик – то система забирает россыпь. При этом есть возможность выбора % занятости ячейки – пополнять, если остаток ниже указанного %. Также ставится предельное количество формируемых заданий.
 
- пороговое – когда остаток в «привязанной» ячейке меньше указанного порога, но стараемся этим вариантом не пользоваться.
 
Итого. Днем выполняем пополнение по второму варианту, заполняя «привязанные» ячейки до максимума варьируя % заполненности. Ночью (дистрибуция) система сама генерирует необходимые пополнения по первому варианту, если дневного пополнения не хватило. Плюс для второго варианта используем административный расчет ячеек – количество товара в комплектации должно быть на 10-15% больше средне-пиковой суточной отгрузки.
Паллета-донор выбирается по FIFO, при равных датах прихода – с минимальным остатком.
 
Кроме этого днем используем компрессирование мест – маленькие остатки добавляем к остатку в комплектации, либо «склеиваем» маленькие остатки в хранении.
 
При обработке возвратов и малочисленных приходов используем «Дополнение» - когда товар размещается к остатку в зоне комплектации.
 
Работа с товаром, по которому ведется партионный учет и учет сроков годности, вносит свои коррективы, и требует строго соблюдения совместимости дат и партий.

Процитировано сообщение: Разгуляев Валерий от 08.04.2010 :: 17:53:27:

 
Валерий, спасибо за статью, прочел с удовольствием.
 
Не совсем согласен, что там описано, но это не столь важно.  
Статья более о процессе пополнения в общем, не касаемо особенности реализации в WMS.
 
Меня больше мучает вопрос оптимизации, рациональности процесса пополнения и выдачи задач в WMS.

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

Задачи пополнения не всегда являются приоритетными - все зависит от работы склада.
Например, задачи пополнения выполняются в течении смены для поддержания комплектации из ячеек отбора, но при определенных событиях водитель ричтрака должен выполнять другие задачи:  
- Если в зоне приемки скопились неразмещенные паллеты, то нужно переключиться на размещение и хотя бы частично освободить зону.
- Если на воротах стоит машина под загрузку и осталось снять паллеты из ячеек второго яруса для загрузки, то водитель ричтрака опять же должен переключиться на эту задачу.
- Если все задачи на комплектацию продукции под заказ уже выполнены и остались задачи на отбор целых паллет, то тут опять же водитель должен оторваться от пополнения и отобрать требуемые паллеты.
 
Вернее правильнее не отрываться, а переключаться и оптимизировать пустые пробеги - отобрал паллету из зоны хранения и вывез к воротам для контроля, на обратном пути захватил паллету из зоны приемки и разместил в хранение, пополнил близлежайшую ячейку и снова отобрал паллету (в некоторых системах это называют "мультицикл").
 
Технических проблем реализации того или другого алгоритма работы особых нет. WMS - это математический инструмент, построенный на принципе работы конечных автоматов. Главное разработать такой механизм, где было бы возможно моментально получать необходимый результат не нагружая сервер громоздкими рассчетами.

Извините что вмешиваюсь в диалог профессионалов....
На мой взгляд все задачи про "мультициклы" и интерактивный подбор носителя для пополнения -"от лукавого"... из серии задач "а можно ли на ричтраки поставить gps?"  
Всегда есть два способа решения складских задач - административный и программный.... И более продуманное административное решение позволяет не ломать копья над программными алгоритами с привлечением матмоделей....
 
Если исходить из допуска что склад настолько мал, что длина любого "вектора" перемещения незначительна - то даже склад с бесконечным фасадом можно разбить на "маленькие" склады, где не думать над оптимизацией перемещений.  
 
По сути склад (читай водитель ричтрака) работает в "пакетных" заданиях - расставить паллеты с конкретной поставки, пополнить места комплектации для конкретной отправки, освободить места комплектации в конкретной зоне для пополнения под отправку, вывезти паллеты для конкретной отправки. И у каждой группы таких заданий есть приоритет, который можно менять через оператора. Допустим есть 1 ричтрак, поставка на 33 паллеты, отправка на 33 паллеты. Скорость обработки 2мин/палл. Важна свободная зона приема,отправка ждет - через час расставили поставку, через два - вывезли отправку. Надо отпустить машину - наоборот. Теперь включаем "мультицикл" - через час не имеем НИ ОДНОЙ законченной задачи. Смысл? Теперь про шахматные клетки. Если товар с прихода может попадать в ограниченную зону (товар одного поставщика/одной группы), то товар в отправку - ассорти. То есть ричтрак выполняя размещение с прихода все время оказывается в одном и том же секторе склада, и на 3-4-5 шаге "по пути" уже не будет паллет на вывоз к отправке. А значит он будет перемещаться вдоль фасада (просчитываем количество и пропускную способность коридоров в стеллажах, выезд в генеральный проезд сводит "мультицикл" на ноль). И уже получаем "треугольник" движения. Плюс техника имитирует броуновское движение на складе. А если сюда еще добавить пополнение "по дороге", то паллеты в зоне приема начнут думать - как им скрасить время ожидания Это мы еще не говорим о грустной вероятности возникновения на "побочных" этапах "мультицикла" ситуаций "А там нет паллеты, а место занято другим товаром, не влезает"  
Если есть два ричтрака - разделяем их по пакетным заданиям, что-то одно "горит" - совмещаем их на одном задании. Если нужно увеличение скорости - давайте вывозить паллеты поставки с ворот к началу принимающего ряда или "в лапы" ричтраку  
 
Относительно интерактивного выбора ячейки для пополнения "по пути"... Для чего эта мнимая свобода? Есть заданный алгоритм отправки - FEFO, FIFO, LIFO плюс возможное ограничения по срокам на приему у Клиента. Работать такое решение, в основном, будет только на фронтальных стеллажах - уже область применения меньше...  К тому же - данная оптимизация будет работать, если на складе товар находится на идентичных по количеству носителях, иначе количество оставшихся малочисленных количеств когда-то парализует пополнение.... Данная ситуация может привести к замедлению выборки данного наименования с "камчатки", ведь подхватывать будет те паллеты, которые по пути ричтрака + ближе к выходу - снова прощай ротация (например, смена дизайна упаковки, а у нас старый образец еще жив, хотя новый отгружаем)...
В итоге получаем набор ограничений, и легкой данная алгоритмизация уже не получится... опять же в помощь "кустовое" хранение над местом отбора, работа с "инвалидными" (неполными) паллетами - формирование одной неполной по артикулу при приеме, дополнение в комплектацию, компрессирование... ну и допуск что склад не настолько велик.. и длиной перемещения можно пренебречь... Опять же - доля перемещения к месту назначения в общем объеме операций (подъезд-разворот-подъем вил/паллета-снятие/постановка паллета-опускание паллета/вил-разворот) - опять боремся не за 100% оптимизации...
Поэтому для себя решил - не заморачиваться.... Правильное планирование + "всему свое время" (читай технологические окна) - и о такой оптимизации думать и нет смысла...
 
P.S. Повторюсь, это лишь мое мнение...  

Андрей, мнения конечно же могут быть разные - на то и форум, что бы их обсуждать
 
Встречал начальников складов, которые говорили: "WMS - это все игрушки и никакая железка не заменит командный голос и дисциплину!".
Возможно, они тоже правы, но моя практика показывает обратное - с внедрением хорошей WMS процессы оптимизируются, и такие вот противники WMS или увольняются, или проникаются работой под управлением этой чертовой железкой .
 
Коли форум все же про IT, а не про склад в целом, то рассмотрим работу склада под управлением WMS и стоит ли оптимизировать перемещения.
 
Когда ходил в гости к 3PL оператору, то наблюдал картину как-раз "пакетной" работы.  
Площадь склада более 20 т. кв.м., сидят сотрудники на столах, болтают. Вдруг приезжает машина, все вскочили, быстро разгрузили, ричтраки разместили и все, опять все сидят и болтают. При таких "наплывах" реально лучше работать "от задачи" даже если поток гораздо интенсивней.
 
Если рассмотреть дистрибьюторский склад средней фирмы с большим товарооборотом, то ситуация куда интереснее.
На ограниченной площади (2 - 5 т. кв.м.) в день нужно отгрузить порядка 20-50 заказов, собранных вчера, и собрать такое же количество заказов на завтра, нужно принять и разместить в хранение две фуры поступления, а зона приемки ели-ели вмещает половину фуры, ну и отпополнятся чтобы комплектация не встала т.к. ячеек отбора мало, а отгружают много. И на все это всего два ричтрака.
 
Если при такой работе начать работу от "пакета", то через какое-то время склад просто встанет, наступет патовая ситуация.
 
Реально управление берет на себя начальник склада - он в нужные моменты время отправляет сотрудников то на одну точку, то на другую. При этом не обязательно чтобы каждый пакет был доделан до конца - т.к. все делается с запасом времени, заранее, то к назначенному сроку обычно все успевают.
Но при наличии автоматизации не дело распределять задания командным голосом - система должна самостоятельно анализировать заполненность зон, отставание от графика по каждой отгрузке и перераспределять задания.
 
Реально на практике все это работает, есть конкретные примеры.
 
Ну а как в обществе, наука развивается на будущее, а в реалии пользуются текущими достижениями,  
я заинтересован в оптимизации этого процесса, что и вылилось в эту тему.

Андрей, Вы правы, когда речь идет о большой площади склада и нужном количестве техники.
 
Мы с Валерием, видимо, сталкиваемся с другими клиентами - те, кто пытается снять как можно меньшую площадь склада (рассчитывают впритык под текущий оборот + небольшой прогноз роста), заставить под завязку стеллажами (жалко же что площадь будет "простаивать" - нужно везде напихать стеллажи) и скупыми на дорогую технику.
 
Иногда доходит до абсурда - в целях экономии и попытки обойтись всего одним ричтраком, заказчики предлагают даже трехходовки - паллету с приемки вначале размещает сотрудник с тележкой - если можно вниз, то размещает вниз, если наверх, то перемещает в зону перехвата другой техники, а там, если возможно, паллету забирает водимый штабелер (который может поставить до 3-го яруса), ну и под конец только ричтрак.
Также на моей практике были предложения пополнения в два захода (при неполном пополнении, когда нужно доложить товар на паллету) - вначале ричтрак снимает в проход все нужные паллеты, далее сотрудники перекладывают товар в ячейки отбора, после чего ричтрак возвращает паллеты обратно. При этом никто не задумывается как будет проезжать другая техника и ходить комплектовщики...
 
Если провести аналогию, то можно сравнить с автомобилями - если у вас стоит двигатель в 500 лошадей, то вам все-равно какой у него КПД, а вот когда по закону страны вы не можете выпустить автомобиль более 280 л.с., то вы начинаете выжимать из того что есть максимум.
 
То же и с логистикой - при наличии площадей и техники многие 3PL-щики не задумываются над оптимизацией и после внедрение WMS занимаются только интеграцией с разными клиентами, порой даже отказывая некоторым клиентам из-за особенности складирования. А потом в кризис начинают заваливать спамом и предлагать демпинговые цены т.к. вся эта техника просто простаивает.
 
Когда же нужно получить максимум из имеющихся возможностей, то тут умные алгоритмы реально помогают справиться меньшим количеством персонала и техники.
 
Как раз в этой теме и идет попытка найти алгоритмы оптимизации перемещений (конкретно пополнения) когда минимальное количество техники и персонала делает максимально полезный объем работ.
 
PS: У вас стоит Qguar WMS?

Qguar, к сожалению, скуп на сложные алгоритмы и вынуждает применять другие механизмы оптимизации. Хотя это отдельный разговор - никакая WMS не способна "вытянуть" склад, если сам склад (процессы, сотрудники и оборудование) не оптимально использует доступные ресурсы.  
 
По статистике, которую мне передал один из крупных вендоров, очень мало складов занимаются оптимизацией процессов в самой WMS после внедрения. На тот момент из пару десятков внедрений на складах, вендор выделил только две компании, которые интенсивно работали над совершением работы WMS - это одни из фармацептов, и компания, где я тогда еще работал
 
А в текущей своей практике часто сталкиваюсь с тем, что уже даже на этапе согласования будущих складских процессов чувствую отсутствие представителей заказчика желания вникать в процессы и оптимизировать их. Часто заказчик делает незначительные замечания и соглашается с предложенными процессами не пытаясь полностью в них разобраться. Приходиться брать эти обязанности на себя и пытаться расшевелить заказчика активней участвовать в проекте.  
 
Также нужно понимать, что те технологии, которые мы хотим тут обсудить, не являются основополагающими - при нештатной ситуации (например, внеплановый приезд крупного клиента) всегда можно поднять срочность определенному заказу и кинуть дополнительные силы на его выполнение.
 
Также нельзя прогнозировать такие ситуации, а вот работать по факту приезда машины тоже не правильно - по любому нужно планировать работы заранее и выполнять работы на складе с учетом запланированных приездов.
Если же клиент не приехал - должна быть зона хранения собранных заказов в стеллажах.
Если клиент приехал не вовремя, то его заказ становиться приоритетным, но это не значит что все силы кидают на его выполнение т.к. потом можно получить принцип домино когда даже вовремя приехавший клиент стоит в очереди из-за того, что предыдущий клиент испортил все планы склада (как меня бесит такое в автосервисе - приезжаю во время по записи, а приходиться ждать т.к. кто-то приехал раньше, не по записи, и все кинулись чинить именно его машину...)
 
Если вернуться к теме, то можно рассмотреть процесс пополнения на примере Exceed. В системе есть хороший механизм отслеживания потребности в пополнении каждой ячейки отбора, но идиотский механизм выдачи задач на пополнение - задачи сортируются по приоритету (полноте пополнения и типу пополнения) и без учета текущего местоположения. В итоге с неоптимальными алгоритмами размещения, водитель ричтрака носится по всему складу выполняя пополнения с большими пробегами. И пока нет внешний проявлений (задержки отгрузок) никто на это не обращает внимание т.к. большое кол-во ричтраков вполне справляется с нагрузкой.
 
Единственное решение в таком случае - деление склада на зоны, закрепление за зонами определенной группы товаров и разграничение прав доступа к зонам для разных ричтраков. Это помогает сократить перемещение по всему складу, но не считаю, что на этом процесс оптимизации пополнения можно закрыть.

Резюмирую нашу переписку по ЛС с Андреем - Qguar действительно не поддерживает многие сложные алгоритмы, но вопрос другой - стоит ли овчинка выделки?
 
Т.е. нужны эти алгоритмы в WMS или любую задачу можно решить административно или путем несложных манипуляций с размещением продукции по зонам и другой организацией процессов?

Процитировано сообщение: Рубанов Сергей от 15.04.2010 :: 21:43:50:

 
Судя по Вашей фразе получается что Qguar вообще ничего не умеет... Хотя заданные Вами вопросы охватывают функционал, встречающийся далеко не на 100% складов и совсем не ежедневных операций... Я не планировал с Вами спорить - просто считаю что говорить "удобную" правду не совсем верно.. или совсем неверно  

То Рубанов Сергей.
 
С одной стороны хочу остановиться обсуждать данный вопрос с Вами, с другой - начавшееся обсуждение затрагивает и сторонние компании. Повторюсь, я являюсь активным пользователем Qguar, но не продавцом/разработчиком. Что касается Вашего резюмирования....
Ну например "- Размещение товара в хранение по возможности ближе всего к ячейке отбора. " - я же писал Вам, что у нас сейчас в системе есть 33 алгоритма размещения товара из поставки (с учетом привязок, весогабаритных характеристик, etc). Очередность их использования определяется приоритетом. Одна из стратегий - Размещение товара в непосредственной близости от места сбора - (при этом система "шагает" вверх-вниз-вправо-влево по ряду/секции/уровню).  
Для Вас же эта функциональность включена в раздел "не поддерживает"...
Да и вообще - отклонились от топика, хотя Вы - ТС, и сами курируете данный вопрос...
Постараюсь больше не засорять топик...

Процитировано сообщение: Рубанов Сергей от 16.04.2010 :: 19:28:49:

 
Сергей, Вы взрослый человек, кто Вас в чем обвиняет?    
Все что я написал - что не согласен с "крайностями". Я не говорил, что все алгоритмы, которые Вы называете умными или сложными есть в Qguar. Обратное утверждение что многие сложные алгоритмы не поддерживаются в системе - тоже неверно.
Если мнение отличное от Вашего - это признак того, что разговор не заладился, то зачем открывать топик для обсуждения?  
Например, для меня непринципиально отсутствие "умного" алгоритма, который позволяет (Ваш пример) при поступлении от поставщика Х блокировать только для продукции Y и не чаще раз в два месяца? Если у меня такое будет часто - я найду программное решение. Если редко - то есть административное решение.
 
Совсем не хочется, чтобы данный форум становился "обычным", где любой топик заканчивается переходом на личности....
Давайте обмениваться конструктивной информации по логистике и жить при этом дружно