Предлагаю обменяться впечатлениями и информацией пока идет выставка (СТЛ-2007).
Я был на ней 2 октября. Буду еще 4 и 5, но уже сейчас понятно, что многого не успею.
Подозреваю, что и у других такая же проблема, давайте объединим ресурсы.
Пишите, что спросить, я тоже свои вопросы выложу.
#Практика #Информационные_технологии_в_логистике
:-?
Много очень уместных фишек работающих по технологии «drag&drog» — пересорт сделать, другие ошибки приемщиков исправить, перемещение, заказ на отгрузку/приемку сформировать по факту.
Хитрое понятие типа «ячейка-контейнер» и как его использовать если нужно по-быстрому отгрузиться и отпустить машину.
Фишка — как быстро приинять совершенно новый товар у которого ни штрих-кода, ни названия толкового нет по факту.
Еще есть — так сразу не вспомню.
Первое о чем я подумал — это то что потом очень сложно будет найти концы через какое-то время работы системы, но меня переубедили.
Часть подробностей (фотки и презентации) уже тут:
http://www.newgensy.ru/conference/conlog.2008.1.html
Остальное тоже выкладываю
Дмитрий, с удовольствием посмотрел выложенные материалы.
По Вашей презентации — жалко что нет хоть какого-то сравнения систем между собой, особенно интересны новые российские системы, хотя понимаю, что это стоит отдельных денег ;)
Расстроила презентация Солво — сплошная реклама, из всех 14 мегабайт нашел только один новый склайд по теме, все остальное есть в обычной презентации системы (надеюсь на словах рассказали больше, чем в презентации)
По PSI — очень порадовало. По PSIwms у меня достаточно материалов, но в этом очень много нового, т.е. Казачков Андрей хорошо подготовился.
Особо интересно решение задачи определения расстояния между ячейками.
Сам задавался этим вопросом: http://old.logist.ru/archive/YaBB.cgi?board=it;num=1222689588
Посмотрев на решение от PSI было радостно и грустно.
Радостно то, что в итоге я пришел ТОЧНО К ТАКОМУ ЖЕ результату (ей богу никуда не подглядывал, а просто в течении нескольких часов штурмовал мозг с листочком бумаги). Тоже понял, что нужно выделить простые области, рассчитать наилучшую точку входа и выхода для каждой пары областей, а внутри области считать прямые пути. При этом чем меньше области, тем точнее рассчеты, но больше база о данных пар областей.
Грустно, что убил несколько часов на изобретение велосипеда.
Правда в итоге задача то решилась, но на практике вопрос встал — между ячейками то теперь можно найти оптимальный маршрут на основе ближайшей, а вот как теперь это соединить с требованием обхода ячеек при комплектации то по змейке (паллете посередине прохода, берем товар то слева, то справа), то последовательно по ряду (для подбора со второго уровня спецтехникой), но при этом при переходе в другую область склада чтобы учитывалась всегда только физическое расстояние до ячейки.
Но PSIwms все же зачет, в моих глазах система еще подросла. Осталось узнать как реализованы принципы SOA (в HighJump не очень понравилось слишком большой сложностью настройки и скудности базового настроенного функционала).
Единственное не совсем согласен с графиком цены проекта с увеличением сложности. По моему мнению график «Собственная разработка» имеет несколько другой вид, ну да ладно. А по поводу коробочных решений так и есть — с ростом потребностей ценник на доработки резко идет вверх, хотя, с точки зрения пользователя, доработки простейшие, но текущие настройки не позволяют этого добиться. Правда не совсем правильно утрирование настройки «галками» — в коробочных решениях есть целые настроечные таблицы с кучей параметров. Этого тоже может не хватать, но все же это не набор флажков.
Жду следующих материалов.
Надеюсь никого не обидел, просто моя точка зрения ;)
Сравнения нет даже в исследовании, на основе которого я делал доклад. Пока нет четких критериев для сравнения, это вызовет больше претензий, чем принесет пользы.
То что донесли на словах я тоже постараюсь донести.
Все снято на камеру, но — это много весит.
Презентации вот на сайт заливаю по два часа…
Я уже сказал народу, что в следующий раз введем ограничение по объему.
Я в этом ничего не увидел очень уж нового. Я тоже занимался этой проблемой.
Тоже при(о)думывал сам. Тоже смотрел как у других.
У наших это тоже есть. У Адалиуса и у Логистикса. Причем сделано по-разному.
В общем виде все приходят к одному и тому же:
1. Ближняя зона — теорема пифагора.
2. Отдаленная зона — на графах.
Интересно дальнейшее развитие. Например параллельные ряды с несколькими переходами между ними,
когда кусок маршрута переносится в другой ряд. Там не все просто, есть над чем поломать голову.
Требования змейки и прохода вдоль ряда — несколько надуманы. То есть не совсем чтобы да, но и не совсем чтобы нет.
Я решил это выносом материальной точки, которая относится к ячейке из ее геометрического центра внутрь прохода на 0,5-1 м от фронта стеллажа.
Тогда змейка получается сама собой…
В PSI (а кстати на конференции прозвучала мысль, что все таки SOA в WMS в строгом смысле нет и никогда не было) реализован объектно ориентированный подход. В тонкостях я пока тоже не разобраля, собираюсь подъехать понажимать кнопки, но насколько я понял,
что здесь немцы подошли без фанатизма. Это авансом ободряет.
Я тоже не очень согласен. И Андрея на конференции по этому вопросу били. Но он все равно молодец, удар держит и не побоялся спорные моменты вытащить на суд коллег. Респект.
По поводу задачки про расстояние — это отдельная тема (надо будет поднять ее), все же не так там все гладко, хотя разработчики молчат, а остальные головы не ломали.
По PSI — видется серьезный игрок на нашем рынке, при правильном маркетинге ребята должны оттяпать увесистый кусок проектов в России. Вот, например, увидел в презентации в разделе «Клиенты» нашего конкурента :) Хотя все же можно назвать партнером в рамках одного рынка деятельности, но на склад вряд ли пригласят :)
По поводу кризиса — кто-то высказывался, что он подкосит крупных игроков с большими бюджетами, а вот по моей инфе есть у них проекты.
Например, одна компания по производству электронных микроэлементов собирается внедрять Manhattan, а сеть магазинов детских товаров Exceed. Хотя если раньше даже среднии компании могли себе позволить дорогие системы, то сейчас это себе позволяют только крупняки или операторы ответственного хранения.
В PSI (а кстати на конференции прозвучала мысль, что все таки SOA в WMS в строгом смысле нет и никогда не было) реализован объектно ориентированный подход. В тонкостях я пока тоже не разобраля, собираюсь подъехать понажимать кнопки, но насколько я понял,
что здесь немцы подошли без фанатизма. Это авансом ободряет.
Коллеги!
Насколько я понял в WMS вопросы транспортной задачи не решаються? Раз Вы спрашиваетсяо определении расстояний между ячейками. А как же считать сколько проехал погрузчик, сколько пробежал сборщик и все это потом в деньги?
:)
А все равно точных данных не получите.
Не встречал такого чтобы комплектовщикам еще и за километраж доплачивали.
Не согласен.
посчитать можно все, было бы желание…
А как же планировать ресурс, не зная элементарных данных на выполнение операций.
Есть же ограничения физического плана, типа скрость пешехода 5 км/ч , а с гидравлической тележкой еще меньше. кроме того, за смену человек может пройти с груженной тачкой например 10 км, а дальше падет как лошадь…
Потом можно посчитать сколько стоит копеек/рублей операция перемещения товара с одного угла в другой, на рампу и если клиенту вздумалось по какой-то необоснованной причине отказаться от товара, то можно выкать счет за уже сделанную работу (отборка, комплктация, преемещение в обратном порядке). ТИпа ничего личного, заплати за то, что сделали…
:)
Обычно замеряют среднее время которое уходит на каждую операцию и определяют сколько будет её себестоимость исходя из зарплаты сотрудника.
А вживление чипов под кожу, определение калорий которые были сожжены в процессе перетаскивания груженой тачки и сверхточная система определения местоположения типа GPS, но для людей — это уже из области фантастики.
Идея такая. счиитать точнее.
Посчитать стоимость каждой операции.
Сумма стоимостей операций = стоимости (себестоимость) например подготовки заказа
Но в этой себестоимости должны участвовать (например если в расчет брать только склад) диспечер, кладовщик, отборщик, штабелерщик, оператор, контролер + если участвовала техника эксплутационные затраты механизмов.
Посчтитать можно, если в инф.системе есть возможность фиксации времени в точке начала и конца операции при каждом переходе ответственности и изменении статуса, а также параметров расстояния между точками, включая высоту.
Вживление — уже возможно — RFID
Калории — согласен пока мерять не будем :)
Сверхточная система определения местоположения типа GPS, но для людей — можно решить админ.способом и радиосканерами. Система опрашивает свободных людей, если он готов принять задание, предлагает ему отсканировать ближайший штрихкод ячейки и вперед
:-?
Обычно, если производители WMS официально заявляют о том что в системе есть биллинг, то подразумевается что и все операции там должны фиксироваться. Иначе как биллингу то работать.
С высотой думаю что проблем не будет. А вот за геморой с расстояниями денег с вас при внедрении снимут по полной. Замучаетесь доказывать начальству что все это окупится.
Тем более, не факт что и стеллажи потом не будете переставлять, а это опять доработки.
А потом ваши клиенты будут удивляться — почему вчера отгрузка стоила 50руб, а сегодня уже 55руб.
А вы будете доказывать что это все потому что вчера паллета стояла на первом ярусе а сегодня на втором. ;)
:)
Мне как-то ставили задачу — рассмотреть возможность внедрения RFID (не вживление конечно, а так — на коробку наклеить, на паллет и т.п.).
В теории все красиво, а на практике оказалось столько тонкостей, что в попытках избавиться от человеческого фактора можно столько гемороя получить в итоге………..одни пищалки в магазинах чего стоят.
Да и ценник заряженный.
Реальное применение этого под вопросом. У нас вот есть рассчет расстояний при каждом перемещении, но пока еще не было потребностей использовать этот функционал для биллинга или другой аналитике вне самого процесса.
Т.к. у всех бизнес разный, то и применение может быть или не быть, или будет необходимо через некоторое время…
Например, есть в компании бюджетирование подразделений. Коммерческий отдел дает заявку на выполнение подготовки груза и выдачу.
Выполнение данной заявки стоит денег (если все считать — это реальная себестоимость) и можно сказать, что это покупка услуги.
Например
1. если все прошло хорошо (клиент доволен)
— затраты склада = стоимости услуги.
относят на склад и коммерческий отдел
Итог баланс равный
2. если все прошло хорошо (клиент заказал лишнее, ошибся или ошибся менеджер или передумал) — появляются дополнительные операции по возврату.
— затраты склада = стоимости услуги, относят на склад и коммерческий отдел, баланс равный
— доп. затраты склада — относят на коммерческий отдел
Итого баланс не равный — по внутр. процедуре затраты могут компенсироваться клиентом + доп. штраф (менеджером отдела) или остаються затратами этого отдела.
3. если все плохо (клиент не доволен) не нашли на складе или выдали не то
— затраты склада = стоимости услуги относят на склад и коммерческий отдел баланс равный
— доп. затраты склада — относят на склад
Итого баланс не равный — по внутр. процедуре затраты могут компенсироваться Сотрудниками склада + возможно штрафные санкции со стороны клиента или коммерческого отдела…
или остаються затратами склада, а по итогам месяца — нет премии.
Деньги — хороший и понятный показатель для измерений, а также инструмент для дисциплины взаимоотношений.
Другой пример
клиент покупает большую партию товара, требует скидку + спец. условия по маркировке и упаковке, а также доставка в офис с разгрузкой и т.д.
ПРи имеющемся инструменте подсчета себестоимости операций менеджер может увидеть реальные операционные затраты в деньгах (+ другие коммерческие данные) и порог рентабельности всей сделки. Что в свою очередь, станет предметом торга и позволит принять правильное решение.
К сожалению, в большенстве случаях, во многих компаниях (сам был когда-то в этом отряде) коммерсанты не утруждают себя такими «мелочами» и работают по принципу — Я ПРОДАЛ, медаль на грудь и на КАНАРЫ….
А очень хотелось бы другого подхода…
Да никто не говорит что не нужен биллинг для внутренних расчетов. Просто или перемещения вообще не считают (считаются процессы отбора из разных мест, контроля, загрузки в машину и т.п.), или считают усредненно, но не видел еще примеров, чтобы считалось каждое перемещение с учетом реального пробега техники (из ячейки L1 в ячейку L2 — 4 рубля, из ячейки L1 в L5 — 6 рублей)…
Мы вот себе заложили «на будущее», но не более
Я тоже про будущее говорю…
Когда каждую долю копейки считать будет надо…
Так вот и вопрос
— эта работа WMS или нет?
— если нет в функционале возможности определения пройденного расстояния, то значит в будущем будет проблема с решением данной задачи?
Это можно решить практически в любой WMS. Если система изначально умеет правильно считать физическое расстояние между ячейками — замечательно, если нет — не беда. Создаем внешнюю систему определения расстояния, а данные о перемещениях берем из журнала транзакций. Немного посложней, но результат то же будет. Проблема усугубляется только там, где поставщики не хотят привязывать координаты ячеек к физическим (XYZ) объясняя, что не поймут зачем это нужно …
Сергей!
Если я правильно понял, технически приивязать к ячейке физические координаты (XYZ), не очень сложно решаемая задача.
ТОесть в свойствах ячейки (высота, глубина , ширина, вес — грузоподъемность, тип поддона и т.д.) необходимо добавить поле с координатами и будет счастье….
Почему тогда?
— »… поставщики не хотят привязывать координаты ячеек к физическим (XYZ) объясняя, что не поймут зачем это нужно …»
— или не могут…
Просто добавить координаты — не сложно, но заносить информацию нужно удобным способом, а то есть примеры, где нужные реквизиты есть, но занести их можно только загрузив из Excell, а там нужно попариться чтобы все это привести к реальному виду. Лучший способ — «рисовать» ячейки изначально на визуальной схеме, а это уже требует создать такую форму и наделить ее определенным функционалом.
Некоторые поставщики до сих пор не знают зачем это нужно, другие делают, но по требованию пользователей или в качестве модной штучки, а не из-за того что понимают зачем. Почему? Да просто не все проходят практику работы на складах и подходят к системе как к программному продукту с определенной функциональностью, которую они хотели бы предложить, но если бы они после внедрения месяц другой поработали и посмотрели как с их системой работают другие пользователи (а не собирать статистику с обращений на службу поддержки), то некоторые вопросы просто бы не стояли.
Проблема еще в том, что сама по себе визуализация склада мало что дает, она должна предоставлять определенный сервис для того чтобы быть реально полезной и востребовательной. Поэтому без такого сервиса смотриться как красивая игрушка для презентации…
Дмитрий! Добрый день! Не могли бы Вы дать несколько комментариев к своим, безусловно, интересным материалам? Всего два вопроса:
1. Для меня было откровением количество проектов на Exceed в 2006. 22 проекта. Как вы посчитали?
2. Исходя из каких соображений Вы сделали вывод о том, что ни один из игроков не привысит порог выручки в 1 миллион долларов?
Небольшое пояснение к 2 вопросу. Я, к своему счастью, обладаю возможностью получать на регулярной основе аналитические отчеты Gartner и еже с ним. Так вот, Gartner в специализированном отчете «Market Share: Supply Chain Management Software, EMEA, 2007», выпущенном в середине 2008 года, зафиксировал для игроков российского рынка SCM следующие показатели по итогам 2007 года (в миллионах долларов): SAP — 2,6; Oracle — 1,9; Другие вендоры (т.е. все те которых Gartner за людей не считает) — 1,9, Manhattan Associates — 1,4; Accellos — 0,5; Red Prarie — 0,5; Infor (он же Exceed) — 0,1 и так далее… Понятно, что в выручку SAP, Oracle и др. попали, в первую очередь, решения именно для управления цепочками поставок. Но, на сколько мне известо, Manhattan Associates пока в России ничего кроме WMS не продает. Кому верить?
Пожалуйста, войдите или зарегистрируйтесь, чтобы комментировать.