Как и для чего задавать штрихкод ячейки адресного склада #768488

Здравствуйте. Пользуемся УТ 11.2.3 и у нас настроено адресное хранение товаров. Решили автоматизировать склад, купили терминалы и запустили на них это: Но эта обработка вместо того чтобы сканировать штрихкоды товара, просит отсканировать штрихкод ячейки. Кстати, на скриншоте в статье по ссылке отображена такая же ситуация. Но у ячейки нет реквизита штрихкод! Я не знаю как его задать и вообще зачем его задавать. Подскажите, пожалуйста, в чём тут дело?

ШК складской ячейки нужен чтобы пикая по нему (он прилеплен под/над/сбоку от ячейки на стеллаже/стене) быстро указать в ТСД данную ячейку. Т.е. выбрали положить, пик товар, пик ячейка - товар лежит в ячейке. И т.д.

Когда я делаю отбор, система и так знает, в какой ячейке товар лежит. Указывать ячейку незачем. Но программа всё равно требует. Если делать размещение, программа говорит: клади в ячейку Х. То есть она уже решила за кладовщика куда класть. И всё же, если это нужно, как штрихкод-то в программе задать? В справочнике СкладскиеЯчейки нет такого реквизита.

Склад и доставка - Сервис - Генерация топологии склада

И где же там штрихкод?

Или под штрихкодом подразумевается наименование ячейки?

скорее ее код в спец виде

Ок, попробую, это ли хочет сканировать обработка. Только вот интересно, код может задаваться не только цифровыми символами, но и буквенными, а также разными дефисами и пробелами. Как, интересно, сканер это будет считывать?

доп контроль. При отборе система знает в том числе и сколько товара нужно отобрать. Однако требует подтвердить товар и количество.

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

"Когда я делаю отбор, система и так знает, в какой ячейке товар лежит. Указывать ячейку незачем." - Неверный вывод. Перенос частной ситуации на общее правило. В общем случае один и тот же товар (!!даже полностью идентичный!!) может находиться в нескольких ячейках. И из какой ячейки брать товар система определять может по достаточно "длительным" правилам/стратегиям, которые "оптимизируют" работу склада. Например, вообразим себе ситуацию (упрощенно): Товар1, вместимость ячеек = 50 шт. - я1 (активное хранение) = 30шт - я2 (активное хранение) = 20шт куча заказов на разные товары, с разным иприоритетами/ сроками/итд, среди них - заказ1 = 15шт (срочный) - заказ25 = 40 шт. Система спланирует (упрощенно): - заказ1, отбор из я2 15шт (остаток после отбора 5шт) - подпитка, из я3 в я2 45шт (остаток после отбора 50шт) - заказ25, отбор из я2 40шт (остаток после отбора 10шт) Теперь представим себе суперумного кладовщика, который на задание "взять из я2 15шт" - умно думает а хрен ли мне идти в я2, я возьму тот же товар из я1 - товар тот же и его хватит. Берет и подтверждает только ОТБОР товара. далее подпитка - снимается 45шт и нормальный бегунок - задача которого быстро делать что скажут и не умничать и который зарабатывает именно на этом - эти 45 штук не может впихнуть в я2 потому что не лезет... Поэтому требуем от сбощика подтверждение того, что он подошел к ПРАВИЛЬНОЙ ЯЧЕЙКЕ. а потому уже - что взял правильный товар. Второе соображение: на складе все должно быть однообразно, воспроизводимо и прогнозируемо, то есть привычно - и для системы и для сборщиков. Поэтому даже тогда когда товар лежит всего в одной ячейке - проще требовать подтверждение ячейки даже в этом случае - это ОДНОБРАЗНО И ПРИВЫЧНО для сбощика и не отвлекает его на приняти лишних несущественных решений. Подошел к ячейке - жмак ячейку - НОРМА(не норма -красный аларм) - жмак товар - норма. Упрощение регламентов - как например у автора хотелка - можно сделать когда стратегия хранения товаров "для товара всегда существует только одна ячейка отбора" - да, возможно не стоит требовать подтверждения ячейки, а сразу спрашивать товар. Но если "ты" не лох чилийский - тупой кодер - а внимаешь в складские технологии и психологию людей - то ты должен понимать, что не требуя подтверждения ячейки на отборе ты скоро столкнешься с желанием складских не требовать подтверждения ячейки на размещении/или другими "косяками" которые размазывают "дисциплину" учета и выполнения операций, потом складские начнут упрощать жизнь уже себе - если не надо подтвержадть ячейки - а давайте складывать все в одну кучу чтобы потом не бегать за товаром и т.д. Поэтому надо продумывать очень тщательно последствия того, что ты внедряешь/программируешь. Где-то это может быть оправдано (упрощение), где-то нет. Запросто может быть, что упрощениена одном этапе приводит к непропорциональному величению издержек/рисков на других этапах.

"А еще возможна ситуация что система знает где лежит товар. туда приходит кладовщик и товар не находит, он берет из другой ячейки и параллельно отмечает откуда взял" - скорее правильная система (а не !сборщик!) сработает так: сборщик на ячейке отмечает "проблему" - допустим недобор товара - система учтет его и или сразу направит к другой ячейке с этим товаром или поставит задание на добор в очередь (в зависимости от ситуации/статегий/правил) - и сгенерит еще добавочное задание на блокировку и срочную инвентаризацию проблемной чейки. В итоге - система сдлала умнее сборщика - обеспечила добор товра и не забыла поставить на инвентаризацию, от сборщика здесь практически ничего не зависит. Вообще. то есть совсем. Сборщик даже не сможет "пропустить" недобранный товар - система его просто дальше не пустит  - или добери товар или обозначь проблему - или может и даст собирать дальше - но все равно будет по кругу снова гнать к этой же ячейке для добора товра.

Вполне убедительно. Спасибо вам за длинный текст. Вопрос «зачем» отпадает. Остался лишь вопрос — почему адрес ячейки задается набором алфавитно-цифровых символов. Ведь сканер штрихкода не сможет в общем случае его прочитать.

только чтобы заставить сборщика(ов) "старой закалки" так работать к каждому нужно по первости надсмотрщика приставлять с блокнотом и табелем

Вывод неверный. перенос частности на общую ситуацию. В общем случае сканеру пофиг что читать - буквы или цифры сканер читает полоски/кубики - в ШК могут быть зашиты даже нечитаемые визуально символы. Типов штрихкодов много всяких, например еан13, code39, code128 (пояндекси) - и если какие-то типы разрешают только цифры (ена13), то другие - набор символов гораздо богаче. "почему адрес ячейки задается набором алфавитно-цифровых символов." - потому что так удобнее. Вообщем-то для однозначной идентификации места хранения достаточно 3-х осей-значений. Но склады зачастую состоят из обосбленых "зон" - ими могут быть и отдельные помещения и отдельные зоны внутри большого помещения-склада. Конечно, (система нумерации ряд-стойка-ярус) в помещении1 стоят ряды с 1 по 15, во второй комнате с 16 по 18, в третьей - с 19 по 43. При частой ротации персонала на складах - будут проблемы с быстрым позиционированием сборщиков на нужную зону (упрощенно!) поэтому вводят дополнительную ось и получается 4-х осевая адресация - зона-ряд-стойка-ярус и получится 1-1-.... 2-16-.. (или 2-1...) 3-19-...(или 3-1...) от обилия ЦИФЕРОК - начинает клинить, облегчаем жизнь мозгам и глазкам А-1-... Б-1-... В-1-... также в штрихкодах могут кодироваться номера серий/партий - а они частенько нецировые могут быть...

НСИ и Администрирование — Настройка параметров системы — Шаблоны этикеток и ценников Вот спасибо! То, что нужно! Премного благодарен! Получается любой текст можно «загнать» в штрихкод

Не, не надо... надо просто делать такую систему, которая просто не пускает "дальше" , если не сделаешь КАК НАДО/КАК ТРЕБУЕТСЯ. Ну и при внедрении новых процессов, а штрихкодирование - это не поклейка шк и терминал в руки старому персонал, это - изменение принципов работы. поэтому ТРЕЗВО оцениваем, соглашаемся не на то что МЫ ХОТИМ УВИДЕТЬ (дали старому персоналу тсд и они радостно с энтузиазмом увеличили выработку на 30% за теже зарплаты), а трезво прикидываем что РЕАЛЬНО БУДЕТ (пессимистичный сценарий). А реально будет плохо - я когд авижу "наждор будет надсмотрщиков..." - сразу советую паралельно с внедрением новых технологий готовить почву для смены - быстрого и разового по возможности - около 80% старого персонала. Чем меньше старого персонала - тем все проще быстрее и спокойнее. Это у меня когда WMS внедряли проблем с персоналом не было. До этого уже выдрессированы были с ТСД и привычны и хорошо восприняли улучшение процессов (ибо ИЗМЕНЕНИЙ практически не было)

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

Согласен. Вообще у меня проблема была с пониманием, что штрихкод ? EAN13, вернее только одним этим стандартом он не ограничивается.

движок форума не пускает юникодные символы. Знак неравенства не прошёл.

Существует мнение что если в ячейки ложить товар то на складе будет бардак А если класть товар то будет все нормально

Проверим это утверждение

Проверяйте, только осторожнее -  то рванет... наблюдал несколько раз последствия... и ячейки есть, и штрихкода.. а товар "всё ложат и ложат, ложат и ложат"

У нас была обратная проблема - товар не ложили, а списывали и списывали, списывали и списывали, и говорили, что ничего не делали, всё само собой происходит

На том складе где система не взлетела... После ремонта обнаружилось аж кладбище бутыльков от "настоек пустырника"

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

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

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

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

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

бяка тотальная - "В случае, если система "оффлайновая" (или не дай бог вообще "бумажная") - то все отрабатывает как написал я (в случае с бумагой - сборщик записывает штрихкод/адрес на бумажке и его потом вносят операторы). " - бумажная технология вообщем ничем от ТСДшнйо не отличается. Можно считать что это - ООООЧЕНЬ медленный ТСД. ПЛАНИРУЕТ СИСТЕМА. Задание (ЗАДАНИЕ!!! а не личное решения сборщика что и куда) выдается системой путем распечатки. Сборщик идет и ДЕЛАЕТ ТО ЧТО НАПИСАНО НА БУМАЖКЕ (а не пишет на бумажку то, что сделал). Сделанное и отмеченное на бумаге - сдается оператору - который в ПОДАВЛЯЮЩЕМ количесве случаев просто ставит что все ОК (ибо по нормальной бумажной технологии отклонения так же редки). " (в случае с бумагой - сборщик записывает штрихкод/адрес на бумажке и его потом вносят операторы). " - это вообще не WMS, это простая учетная система - принесли бумажки, с них что-то забили в систему. Система отражает СОСТОЯНИЕ БУМАЖЕК, а не реальные процессы на складе. и совсем другое дело когда бумажка является ЗАДАНИЕМ точно таким же !!обязательным к исполнению!!! как и задание на ТСД. В условиях работы на ТСД задание на ячейку (например) может быть выдано другому сотруднику непосредственно сразу после отработки ячейки предыдущим сотрудником - так как сразу известен результат отработки ячейки предыдущим сотрудником. При работе на бумаге интервал подтверждения становится равным кванту времени от начала листа бумаги до конца. то есть следующее задание на ячейк выдаем после того как отразим результат с листа - только после окончания листа - через 30-40 минут. На складе с нормальной дисциплиной можно запросто выдавать на одну ячейку сразу нескольо бумажных заданий - они все равно будут выполняться разными людьми - проблема возникнет только тогда, когда какой-то сборщик зафиксирует проблему на ячйке/товаре и теперь эту "проблем" надо "распространить" по всем сборщикам, у которых на руках есть листы с этой ячейкой/товаром - инчае сначала прибежит один сборщик, потом второй. Или все проблемы по ячейке соберутся по итогам сдачи всех листов и хрен поймешь - то ли это одна проблема, то ли надо суммировать. Поэтому навскидку (упрощенно) бумажную технологию я бы делал "короткой" - временной квант обслуживания сборщиком бумажного задания должен быть как можно короче и на бумажное задание надо выдавать товар не по объему, а условно по маршруту движения - если сборщик идет змейкой по линейным рядам - то на каждый проход ряда - отдельное бумажное задание - взял лист НА РЯД (3 коробки, примерно треть паллеты) - а не на 1 паллету (4 ряда). прошел ряд - лист сдал оператору, паллету кинул в буфер, взял второй короткий лист, пошел во второй ряд. Оперативность отражения ЖИВОГО СОСТОЯНИЯ СКЛАДА - гораздо выше, приближается к ТСД. немного сумбурно получилось (упрощенно, утрировано)? но думаю смысл ясен. Могу согласится что выдвигаю спорные утверждения в вышеизложенном. Но очень похожая технология была у меня на складе, на этапе наведения порядка, когда на сборке ТСД еще не было. будет интерес - пишите, расскажу поподробнее (ничего особого нет).

Вас, сударь, похоже несёт.... Все делится на два решения: Ваше и неправильное. Заметьте, я Вас не опровергаю. Да, Вы абсолютно всё правильно пишете в Вашем конкретном случае. Да, действительно алгоритмы и подходы, как у Вас, могут работать на многих предприятиях. Причем логично, что СИСТЕМА должна автоматически сформировать ЗАДАНИЕ, а сборщик берет лист/задание и поехал собирать - это вообще аксиома. Но я повторюсь, что кроме Вашей ситуации/видения/технологии есть еще и другие ситуации/видения/технологии, которые так же успешно работают на других предприятиях. И Вы можете сколько угодно кричать "ЗАДАНИЯ!!! СИСТЕМА!!! НИ КАКИХ ЛИЧНЫХ РЕШЕНИЙ!!!", но есть организации где нормально работает НЕ так, как Вы описываете. Не хочу углубляться в детали, но сборщиков на бумажной модели(тут тогда сразу дописывайте, что это медленный ОФФЛАЙНОВЫЙ ТСД, а не фига ни онлайновый, про который вы так в красках все описываете в ) можно развести по разным непересекающимся группам SCU и тогда любой сборщик столкнувшийся с проблемной ячейкой не бежит получать новое задание(и тупо тратит время, особенно будет "ржака" если он прошел полсклада и на последней ячейке обламался и нужно мчаться через весь склад и получать новое задание). Да, он у себя пометит эту ячейку как проблемную, возьмет из аналогичной поблизости(лист подбора сразу может быть с альтернативными адресами, где лежит нужный товар), закончит подбор и спокойно сдаст лист операторам. А операторы в свою очередь спокойно занесут эту инфу. Как отреагирует на это система? так как ее запрограммируют: и заблокирует, и отчет начальнику склада отправит на почту, и автоматом назначит инвентаризацию, да все что угодно. Зависит от фантазии/бюджета/времени и ресурсов. Конечно, это крайний случай, с полным бардаком на складе, но и с таким складом система будет работать. Наведут ли порядок в головах, трах..накажут "героев"-виновных, захотят ли вкладываться в оборудование и тд и тп - это все организационные вопросы. И хорошо если Вам позволят поучаствовать в их решении. Читаю еще раз все Ваши посты и на ум приходит аналогия "Вот типовая торговля/бухгалтерия/упп/зуп и т. д. и 200% что мы без всяких изменений автоматизируем все предприятия РФ/мира/вселенной. Если что то не получается - то они(предприятия) неправильно работают/ведут учет". Смотрите "ширее"(с)

Сударь, это вас несет. У меня подход простой. Решения - не мои. Они работают. Ибо практически стандарт. Есть другие способы организации работы склада. Они используются там где не доросли до продвинутых стандартов/схем (по разным причинам). Это тоже можно считать стандартом. Главное что их объединяет - это наличие СИСТЕМЫ РАБОТЫ. Хорошая или плохая - не суть важно. Главное - есть система правил, по которым надо работать. Это - ГАРАНТИРУЕТ ПРЕДСКАЗУЕМЫЙ результат. Следующая задача - от "низких" стандартов переходить к "высоким". Кто-то застрянет на низких стандартах (сам сидел), кто-то перейдет на высокие. Вот и вся разница - если она есть в подходах.

"Читаю еще раз все Ваши посты и на ум приходит аналогия "Вот типовая торговля/бухгалтерия/упп/зуп и т. д. и 200% что мы без всяких изменений автоматизируем все предприятия РФ/мира/вселенной. " - вот как раз тут у вас обломс.. из типовой у мну - только БП3 КОРП (которую еще не успели испоганить под хотелки бухов ибо только процесс перехода идет неторопливо - и уже обвешено кучей приблуд восьмерочником-бухгалтером). а все остальное - нетипове - ТИС, Бух 77, WMS - и мне ничуть не страшно внутрях тех прог которые я знаю подправить что надо или напиать частную конфигу для отдельного участка. Моя задача - не чтобы юзвери гемороиллись с типовым решением, а чтобы работали быстро и удобно - а каким образом я этого добьюсь - зачморю всех своими правильными решениями или поставлю абсолютно типовую/нетиповую конфигу - решать вообщем мне. и слава богу - к моему мнению пока прислушиваются.

..но надоело все вусмерть... ;-) в том числе и работа по бумажным технологиям... ;-)

.. хотя например, мой склад вполне себе на этапе сборки может работать по бумажной технологии. Вполне прокатит. Пока ненапряжный сезон. дальше тупо начинаются просто непроизводительные потери времени. 1 минута сборщика стоит примерно 5 рублей. Если посчитать сколько сборщик тратит времени на работу с бумагой - стоимость сопоставима со стоимостью ТСД. Я уже приводил неоднократно выкладки по своему складу. По бумаге и по работе с ТСД (качество практически мало изменилось) - скорость по бумаге - максимум (максимум!) 60 строк в час - это были КОРОЛИ - которые ни мне, ни начальству на складе нафиг не нужны. Переход на ТСД - стабильный средний показатель ~105 строк/час (отклонения несущественные). А схема работы осталась практически такая же...

я читал и выкладки, и знаю, что Вы принимали участие в разработке/внедрении адресно-ячеистых складов. Меня всего лишь удивило "только так! и никак иначе!". Естественно, если работать по бумаге - все равно будут проседания по времени сбора и вообще работы на складе. Но если сравнивать совсем с ничем - то будут совсем неплохие результаты, а супер цифры мы действительно получим онлайн-терминалами. Ну и естественно система должна быть предусмотрена так, что "даже если за комп сядет тупая, слепая мартышка, у которой вчера накануне был бурный сабантуй с возлияниями и она всю ночь не спала - у нее не должно быть никаких ошибок. шаг влево шаг вправо - низя!" (с)

ну да, разные схемы, разные варианты. не было бы у меня бюджета на ТСД - выпилил бы не на сильно хуже на бумажной технологии - и работало бы тоже нормально. Вообщем мы говорим об одном и том же. я, только, сильно насел ;-)  А насел потому что - не важно что делать - на ТСД или на бумаге. или ваще подругому. Важное понимать - что надо делать. и зачем.и уметь это ОРГАНИЗОВАТЬ (если не умеешь делать сам). Был на складах - и автоматизированных и нет. Странно то - что либо автоматизировано либо ваще ноль. Какие-то средние варианты практически не встречались. Хотя кажется - что мешает на бардачном складе хотя бы ПРОСТО УПОРЯДОЧИТЬ работу склада СВОИМИ СИЛАМИ? пусть даже с тривиальной бумажной невмсной технологией? Но хотя бы .просто.навести.порядок.? - видимо у меня какие-то "неправильные" взгляды на порядок на складе и режимы его работы..?

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

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

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

О чем нахрен говорить когда я вменяемых данных не могу получить от клиента? Лезу сам на сайт чтобы выцепить логистические данные. Коробочная упаковка 6 кг, паллетизация - 84 короба на паллете, почему при этом вес паллеты соответствует 56 коробам? Ответ - потому что всем все похрен. Особенно хреново когда похрен становится отделу автоматизации... Хотя может это и правильно... Если отдел автоматизации - исполнительное подразделение и ему не ставили задачу обеспе чения корректности вводимых юзаерями данных - следует ли отделу автоматизации самому себе придумывать и усложнять задачи?

Вообще я считаю что у нас в складской логистике ситуация хреновая. Я не эксперт, но мнение имею... Смайл...

склады это отстойники ресурсов - материальных и человеческих :)

Это ты мощно выступил!

Просто потому что заплатив деньги не факт что получишь результат. А если нет разницы, то зачем платить больше?

А вот тут интересный вопрос! Как оценить продукт и вообще проект внедрения? единой системы оценки качества WMS-решения/проекта - не видел.

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

хорошее сравнение

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

Угу, это как одной конторе внедренцы напели - увеличение производительности в 2 раза при уменьшении ФОТ в 2 раза... И ведь верят...

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

Я бы сказал что вообще не стал бы подписываться под внедрение, хуэмэс это или еэрпэс. У директоров заказчика всегда куча головняков, которые он хочет подвесить на внедренца и таким образом перевести стрелки...

Я, например, имел удовольствие видеть Мегапроект "Внедрение адресного хранение на Акселот:Управление складом 3.0" в одной компании. Проект "успешно" внедрялся и самим Акселотом(основные внедрятели) и компанией Белов и партнеры(писали обмены м/у УТ 10 и собственно самим акселотом, и чего то еще там дописывали - сильно не вникал чего). Акты с отметкой "сдано успешно", "благодарственные отзывы" подписал ИТ менеджер, выросший из админов и нибуя не разбирающийся в учетных системах, но с атестатом/дипломом MBA. Проект вылез в больше ляма рублей в далеком то ли 11 то ли 12 году и причем на всех углах шептали "что компания здорово сЫкономила", обучение пользюков никто не проводил. И что в результате получилось? В компании есть УТ и есть акселот, в каждой системе - свои остатки. Заказы выгружаемые из ут по 10-15(!!!) раз продажники вынуждены менять(причем каждый раз созваниваясь с клиентом), потому что товара тупо нет в наличии. Сыпятся какие-то непонятные ошибки в акселоте, изза закрытого кода -херотлавливаемые. Попытка подтянуть и абелова и акселота к исправлению - ни к чему не приводит, "это не наша ошибка, это вторая сторона". Наконец то удалось выяснить, что у акселота, при загрузке заказа, в котором товары с сериями(читай, с ГТД, ибо товар весь импортный) - происходят какие то непонятные превращения количества товара в сторону увеличения. Причем баг помню был плавающий, но закономерность просекли. Обращаемся в акселот, как обычно "скиньте нам базу на посмотреть", посмотрели и говорят "да, есть такая штука, но это не глюк. Поэтому исправлять будем за деньги" "И сколько?" "6 часов по 1,5 (или по 2 -2,5, непомню давно было) т р". "Вы обуели? Это явный глюк, исправляйте" "Нет, мы об этом на этапе внедрения говорили устно, в следующих версиях это будет исправлено". "Ладно, х.. с вами, заплатим, но 6 часов потратить на прописание в вашей загрузке .Свернуть без серий - это как то много, сокращайте время". Сторговались, сделали гораздо дешевле(причем закрывали часами, которые остались запланированными в проекте). С остатками никто ничего не делает, закупленные вафли и оборудование глючит. Все попытки обратиться к внедренцам имеют один посыл - на х. к производителю. Топ менеджеры ходят и дрюкают ИТ службу "Мы заплатили гору бабок, где результат?" ИТ менеджер докладывает "У нас все хорошо, я все сделал правильно завтра/послезавтра/послезавтра наступит счастье, поставщиков услуг я выстроил, все будет супер!!!" И тут спрашивают вновьприянтого 1сника на работу "что же все таки занах у нас тут творится?" Тот говорит, я тут неделю поработал, посмотрел что у вас тут есть (и в ут и в акселоте) - проект НЕЛЬЗЯ было запускать и НЕЛЬЗЯ было вести так. "Обоснуйте, пожалуйста" Обосновал. ИТ менеджера разжаловали в админы (и через 2 месяца выпилили), начальника склада поменяли через 4 месяца. Одинэснику в рамках проектов приняли на работу двух прогов + дали в  подчинении 3 бухов из 5(разгребать первичку) + на проект взяли грамотного логиста, с туевой хучей автоматизаций складов(правда на SAP). И начался адский проект по разгребанию Г...в учетных системах за 10 лет работы компании. Было написано свое адресное хранение(за 2 месяца) внутри УТ, проведена инвентаризация и запущено в эксплуатацию. Коллектив кладовщиков не меняли, просто сократили половину за ненадобностью. И если раньше сборка заказов держалась на "старичках", которые помнят где что хранится(хотя бы примерно, потому что склад был паллет на 1200, ассортиментный ряд - 4-5 тыс. SCU), то даже дятлу распечатай лист подбора - он все нормально и быстро соберет. Акселот в результате положили на полку. Благодарственное письмо с сайта сняли.

а сколько можно в нем заложить KPI для мотивации сотрудников склада - это просто жесть как много. Задача компании, которая обслуживается аутсорсерами, является перенос своих "рисков" по внедрениям/поддержки на плечи аутсорсеров.   у господина Злопчинского реально видел хорошие статистические данные, рекомендую. Где то он презентовал свое внедрение(или внедрения), то ли тут то ли на нимфостарте и вроде с показателями что было, что стало.

а это вполне реально, для большого склада, если будут грамотно прописаны с учетом топологии порядки обхода и маршруты отбора. ну и чучмеки на ричтраках грамотно обучены. а то бывает одни отбирают 100 строк в смену, а другие 500 (с перекурами) само собой напрашивается кого то сократить

Страшно представить, какой бардак на складе, на котором WMS поможет сократить ФОТ на 50%... Ну и есть маленький нюанс - отборщики как правило работают по сделке, и в этой части ФОТ просто физически не может измениться...

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

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

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

это точно.

...wms как предлог для наведения порядка на складе... ;-)