rsergio (Все сообщения пользователя)

Приветствую.

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

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

Нет. Инсток я вообще в глаза никогда не видел, да и не слышал как-то до этой вот темы...

Как я понял не взлетело с ТСД, поэтому перешли на бумагу, но постараюсь завтра уточнить подробности.

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

C этим как-раз проблем нет - любой склад на выбор. Только клиенты всегда любят смотреть на склад, чтобы максимум на их похож был, а такой не всегда удается найти.
И что интересно - два одинаковых склада по факту всегда имеют отличия в работе, так что одинаковых складов не бывает.

Но по ответам мне кажется, что Дмитрий для себя уже систему выбрал и пытается совместными усилиями убедится в правильности выбора

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

Другой вопрос в том, что они не хотят называть конечную стоимость проекта без первоначального обследования.
И полную стоимость проекта готовы озвучить после подписания договоров, что не всех устраивает.

Я изучил продукт изнутри и не вижу проблем в его доработке. Конечно, ядро систему уже не переписать, но вот дописать нужный функционал можно без проблем. По крайней мере в части функционала, не затрагивающегося экраны ТСД.

Добрый день, Дмитрий.

Боюсь в этом бюджете вместе с ТСД ни Axelot ни Manhattan не пролезут. К сожалению про IsWMS вообще ничего не знаю, поэтому не подскажу.

Да и выбор Manhattan для такого склада видится не очень рациональным.
На нашем рынке много отечественных систем, которые закроют ваши потребности полностью.

Не согласен с тем, что 4-я версия у Axelot есть "коробочный продукт". Система получилась функциональной и множество настроек делается интерактивно, а для всего остального есть возможность изменить полностью открытый код силами внедренца или своими. Другое дело, что не все любят много дорабатывать под проект, пытаясь остудить пыл заказчика начиная "это неверно" и заканчивая "это невозможно".

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

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

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

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

Например, стоит 5 весов для сортировки 5 заказов.
Пользователь на ТСД сканирует очередной короб и WMS говорит сколько товара и на какие весы переложить.
Он перекладывает, система сравнивает вес и продолжает операцию (или сигнализирует об ошибке).
При этом мы в теории убиваем двух зайцев - и контроль проводим по весу и уменьшаем количество хождений по складу т.к. комплектовщик за раз собирает несколько заказов.

Это как один из вариантов. Я не говорю что он 100% верный.
Надо больше считать, но у меня пока нет времени, уже надо лететь в другой город на следующий проект...

Посмотрел пересечение заказов.
Всего 586 контрагентов и 180 позиций номенклатуры.

При этом у  569 контрагентов (97%) существует как минимум один заказ другого контрагента, который совпадает на 100% (один из заказов содержит в себе целиком номенклатуру другого заказа).
Если планку опустить до 80% пересечения, то уже 582 контрагента пересекаются (99%)

Есть позиции товаров, которые встречаются у 50% заказов.
Распределение товаров по контрагентам/заказам выглядит следующим образом:


Предварительно видится, что есть смысл объединять несколько заказов в единую волну и собирать вместе.
Волна должна состоять от 3 до 10 заказов, которые максимально пересекаются между собой.

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

Например, можно вместе запустить следующих контрагентов:

Контр_1835 + Контр_1844 + Контр_1841 + Контр_1864 + Контр_1865 - они имеют около 15 повторяющихся артикулов во всех заказах и все меньше ящика (только в Контр_1865 ящики есть)

Или можно брать мелкие заказы с одной позицией и собирать за раз:

Контр_1181 + Контр_1182 + Контр_1454 - Номенклатура 774_ШТ
Контр_1619 + Контр_1637 + Контр_603 - Номенклатура 38_КГ

Или к крупным заказам приплюсовывать мелкие, который 100% повторяют номенклатуру крупных:

Контр_1796 (88 позиций) + Контр_1584 (8 позиций) + Контр_1058 (5 позиций) + Контр_1388 (5 позиций) + Контр_1028 (4 позиции)

Добрый день.

Было бы здорово если бы были данные о весе полного ящика каждого артикула

Николай, все правильно пишите.

Но за неимением подробных данных мы предполагаем, что автор поставил вопрос на обсуждение не из праздного любопытства, а просчитав потери от пересорта/недостач и придя к выводу, что проблему нужно решать.
Чтобы сравнить уровень издержек на пересорта со стоимостью возможного решения задачи, нужно примерно понимать стоимость решения (как в денежном варианте, так и в затрате времени персонала).
Найдя несколько вариантов и просчитав затраты на них уже можно сравнить с затратами на пересорт, и уже принять решение о целесообразности одного из них.

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

Заказов 500, но артикулов всего 100.
Значит предположительно пересечение в заказах есть и можно рассмотреть такой вариант.

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

Задача то не выдать сразу 100% решение, а с помощью мозгового штурма выработать подход.
Пока не хватает полной статистики, чтобы сразу отмести нереальные варианты. Есть у меня система, в которую я загружаю статистику за определенный период и уже множество готовых отчетов. Обычно хватает даже "слепых" данных в виде "Контрагент 1", "Контрагент 2" и "Товар 1", "Товар 2", главное чтобы данные по количеству/весу/объему были реальные.  

Насколько артикула пересекаются в заказах?
Возможно ли запустить волновой отбор не под заказ, а по артикулам с последующей сортировкой?

Идея в том, что данным с производства можно доверять, значит нужно обеспечить, чтобы заводской ящик был распределен полностью, в короткий период и на стационарном месте.
Т.е. берем некоторый пул заказов и отбираем целыми ящиками из хранения. При этом сам отбор ускоряется и количество "ходок" уменьшается т.к. уже не собираем по 2-3 ящика (мелкие заказы), а сразу по 16.
Далее вывозим ящики в зону сортировки где товар раскидывается под заказы под управлением системы. Если в один заказ переложили, то сразу же другому не хватит и ошибку можно отловить.
При необходимости подключаем стационарный весовой контроль, причем можно рассмотреть вариант под каждый заказ свое место с весами.

Или какая-то модификация алгоритма.
Тут конечно нужно смотреть статистику по заказам, времени их добавления, пересечению артикулов, заказанному количеству и пр.

Нет возможности в каждый ящик собирать отдельный артикул? Не хватит тогда ящиков?
Тогда было бы проще контролировать вес по артикулам, а позже перекладывать товар между ящиками для минимизации их количества.

На колбасном складе в хранении сколько примерно ящиков стоит?
И сколько примерно батонов влезает в каждый ящик?

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

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

Вы взвешиваете всю тележку или каждый ящик в отдельности?
В каждом собранном ящике одна номенклатура или несколько?
Ящики нумеруются?

Первый раз слышу о проблеме двойного Enter'а. Какие терминалы?
Даже если это глюк оборудования, то можно и программную заплатку поставить пока выясняется причина такого поведения.

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

Это обычные будни 1С-ника
Я обычно успеваю вклинится между фоновыми заданиями т.к. они все короткие, а если есть какое-то длинное, то его отдельно можно выключить.

Копию можно еще делать через SQL.

У нас возможны различные варианты, но каждый имеет свои ограничения.

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

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

А вот пополнение обычно рассчитывается on-line в зависимости от текущего положения исполнителя, срочности заказов на текущий момент, расположения товара и т.д.

У вас под каждый проход отдельный поток? В чем смысл?

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