По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
скопировано от rsergio
Основные причины почему люди начинают смотреть в сторону WMS:
Основные причины почему люди начинают смотреть в сторону WMS:
- Большое количество пересорта, недогрузы, ежедневные претензии от клиентов
- Низкая эффективность работы сотрудников, долгое время поиска товара
- Невозможность контролировать склад как бизнес единицу, который постоянно жалуется на нехватку персонала и высокую нагрузку, желание внедрить мотивацию
- Необходимость увеличить оборот склада, когда наем дополнительного персонала уже не помогает
- Уйти от привязки к знания кладовщика, возможность эффективной работы новичка после пары часов обучения
- Переезд на высотный склад и невозможность работы без адресного хранения
- Оптимизация хранения товара, более эффективное использование складских площадей
копипаст из топика (360) на ветке
от 07.08.14, от rsergio
Скучно. Выложу немного текста из аналитического отчета по 4.0 ;)
Стратегии размещение, отбора, подпитки и прочие параметрические настройки.
В версии 4.0 заявлена возможность адаптации к условиям работы практически любого складского комплекса с помощью параметрических настроек. Действительно, количество настроек существенно было расширено по сравнению с версией 3.0. Основная гибкость в настройках должна приходится в область алгоритмов размещение, отбора и подпитки т.к. именно в этих момента больше всего различий между складами. Тут на помощь приходят стратегии, где можно настроить логику работы алгоритмов для различных товаров.
Но возможности этих алгоритмов сильно ограничено жесткостью их настроек. В самой стратегии можно указать условие и список шагов алгоритмов.
Если к настройке условий претензий немного, то настройка алгоритма сводится к выбору одного из списка жестко зашитого (всего 5 типов алгоритмов) и дополнительной тонкой настройкой установкой флажков. В качестве гибкой подстройки есть возможность только ограничить список зон для данного алгоритма.
Нет возможности дополнительно указать какие ячейки из зоны стоит рассматривать и какую ячейку лучше всего предпочесть из массива подходящих из зоны. Нам лишь можно настроить поиск ячейки ближе к ячейке отбора, а среди прочих ячеек выберется первая по фиксированному маршруту (об этом чуть ниже).
Остальные стратегии (отбора и подпитки) построены по тому же принципу - условие, список алгоритмов, где в каждом алгоритме выбор одного из зашитого (перечисление), пару флажков и список ограничений по зонам.
Кроме того, что сами стратегии не являются особо гибкими, мы также имеем жесткую привязку номенклатуры к стратегиям через модели учета. Каждый элемент справочника номенклатуры ссылается на Модель учета, где перечислены основные стратегии для работы с данной моделью.
Т.е. тем самым мы привязываем жестко товар к стратегии, а всю вариативность различных способов обработки товаров должны реализовать в самой стратегии.
При такой схеме реализации определения списка алгоритмов на проверку каждого условия будет затрачиваться ресурсы, т.е. если в стратегии 10 условий, а для данного случая должно сработать только 10-е условие по поряду, то вначале система отработает по отдельности 9 условий в холостую, и только на 10-м условии определит список алгоритмов, которые в дальнейшем будет дальше обрабатывать по очереди.
Детальный анализ кода конфигурации показал, что в алгоритмы заложен механизм гибкой произвольной настройки с помощью схемы компоновки данных. И в коде обработки алгоритмов есть блок, отвечающий за выдачу результата по произвольным алгоритмам. Но штатными средствами создать произвольный алгоритм пока нет возможности, и нет возможности его изменения - в типовой форме нет даже упоминания об этих реквизитах справочника.
Судя по коду (считывание несуществующего реквизита ТипАлгоритмаРазмещения в алгоритме отбора) данный функционал пока не рабочий и его появление следует ожидать в следующих релизах системы.
... продолжение следует ...
от 07.08.14, от rsergio
Скучно. Выложу немного текста из аналитического отчета по 4.0 ;)
Стратегии размещение, отбора, подпитки и прочие параметрические настройки.
В версии 4.0 заявлена возможность адаптации к условиям работы практически любого складского комплекса с помощью параметрических настроек. Действительно, количество настроек существенно было расширено по сравнению с версией 3.0. Основная гибкость в настройках должна приходится в область алгоритмов размещение, отбора и подпитки т.к. именно в этих момента больше всего различий между складами. Тут на помощь приходят стратегии, где можно настроить логику работы алгоритмов для различных товаров.
Но возможности этих алгоритмов сильно ограничено жесткостью их настроек. В самой стратегии можно указать условие и список шагов алгоритмов.
Если к настройке условий претензий немного, то настройка алгоритма сводится к выбору одного из списка жестко зашитого (всего 5 типов алгоритмов) и дополнительной тонкой настройкой установкой флажков. В качестве гибкой подстройки есть возможность только ограничить список зон для данного алгоритма.
Нет возможности дополнительно указать какие ячейки из зоны стоит рассматривать и какую ячейку лучше всего предпочесть из массива подходящих из зоны. Нам лишь можно настроить поиск ячейки ближе к ячейке отбора, а среди прочих ячеек выберется первая по фиксированному маршруту (об этом чуть ниже).
Остальные стратегии (отбора и подпитки) построены по тому же принципу - условие, список алгоритмов, где в каждом алгоритме выбор одного из зашитого (перечисление), пару флажков и список ограничений по зонам.
Кроме того, что сами стратегии не являются особо гибкими, мы также имеем жесткую привязку номенклатуры к стратегиям через модели учета. Каждый элемент справочника номенклатуры ссылается на Модель учета, где перечислены основные стратегии для работы с данной моделью.
Т.е. тем самым мы привязываем жестко товар к стратегии, а всю вариативность различных способов обработки товаров должны реализовать в самой стратегии.
При такой схеме реализации определения списка алгоритмов на проверку каждого условия будет затрачиваться ресурсы, т.е. если в стратегии 10 условий, а для данного случая должно сработать только 10-е условие по поряду, то вначале система отработает по отдельности 9 условий в холостую, и только на 10-м условии определит список алгоритмов, которые в дальнейшем будет дальше обрабатывать по очереди.
Детальный анализ кода конфигурации показал, что в алгоритмы заложен механизм гибкой произвольной настройки с помощью схемы компоновки данных. И в коде обработки алгоритмов есть блок, отвечающий за выдачу результата по произвольным алгоритмам. Но штатными средствами создать произвольный алгоритм пока нет возможности, и нет возможности его изменения - в типовой форме нет даже упоминания об этих реквизитах справочника.
Судя по коду (считывание несуществующего реквизита ТипАлгоритмаРазмещения в алгоритме отбора) данный функционал пока не рабочий и его появление следует ожидать в следующих релизах системы.
... продолжение следует ...
продолжение оттуда же
Расшифровка текста запроса из функции ПолучитьТекстЗапроса_РазмещениеСоставаКонтейнера_ВЗонуОтбора()
Запрос представляет собой пакет из 14 подзапросов. Краткое описание каждого шага:
1. Получаем штатные (закрепленные) зоны и ячейки отбора по номенклатуре.
2. Получаем полный список доступных ячеек (все ячейки указанных зон, если была указана только зона отбора, плюс фиксированные ячейки отбора) с учетом данных шага 1.
3. Получаем список допустимых зон из алгоритма размещения или все найденные зоны, если ограничений нет.
4. Получаем окончательный массив доступных ячеек из шага 2 с учетом ограничений из шага 3.
5. Получаем положение всех контейнеров в ячейках из шага 4.
6. Получаем список ячеек из шага 4 и доступных контейнеров в них из шага 5.
7. Получаем остатки всех товаров всех контейнеров из шага 5.
8. Подсчитываем количество контейнеров в каждой зоне по остаткам из 7 шага где товар равен исходному и остатков в ячейке не меньше минимального для контейнера.
9. Находим подходящие контейнеры из шага 6, где максимальное количество контейнеров по настройке не меньше текущего количества из шага 8
10. Объединяем данные с шага 9 и остатки с шага 7
11. К данным из шага 10 добавляются данные по вместимости контейнера по каждому товару для определения процента занятости для каждого контейнера
12. Определение свободных контейнеров совмещая данные из шага 9 и шага 11
13. Получения данных по классам ABC
14. Получение окончательных данных по контейнерам из шага 12 с подходящим ABC классом (если используется), где доступное количество для размещение не меньше кратности упаковки.
Расшифровка каждого шага запроса:
1. Для каждого товара может быть назначена или просто целиковые зоны отбора (плавающие ячейки), или конкретные ячейки отбора (фиксированные ячейки). Для зоны отбора настраивается минимальное и максимальное количество контейнеров в ней под номенклатура, а также минимальный остаток в контейнере (минимальные параметры нужны для подсистемы подпитки).
2. Для указанных зон получаем список всех входящих в нее ячеек отбора плюс фиксированные ячейки отбора по номенклатуре (если имеются).
3. В алгоритмах размещения могут быть наложены ограничения на используемые зоны. На этом шаге получаем список зон из алгоритма и объединяем с полученной таблицей зон, если таких ограничений нет. Т.е. на выходе имеем список допустимых зон.
4. Накладываем ограничения на зоны и получаем окончательный список всех ячеек для возможного размещения товара по данному шагу алгоритма стратегии.
5. Из регистра усПоложениеКонтейнеров получаем остатки по всем контейнерам, которые находятся в списке рассматриваемых ячеек.
6. Объединяем список ячеек и находящиеся в них контейнера и получаем таблицу связки Ячейка-Контейнер.
7. Получаем остатки всех товаров во всех контейнерах где есть остатков товара или ожидается его приход. В случае если у нас в зоне находится тысяча ячеек, а в каждой ячейке лежит ни один товар, то мы получим таблицу с несколько тысячами записями об остатков всех товаров в зоне.
8. Для каждой зоны подсчитываем количество занятых контейнеров, где количество остатка товара в контейнере больше или равно минимальному остатку в контейнере. Странно, но если в контейнере есть 5 штук, а по настройке минимум должно быть 10 штук, то данный контейнер мы не учитываем и можем завести еще один, если позволяют настройки.
9. Фильтруем список подходящих контейнеров с остатками с учетом максимального допустимого количества контейнеров в каждой зоне. Отбираются только те ячейки, в зонах которых допустимое максимальное количество не превышено. Т.е. если в зоне уже находится 5 контейнеров, а по настройкам разрешено максимум 5 контейнеров в зоне, то в список попадут все ячейки данной
зоны. И при определенных обстоятельствах товар может быть размещен в новую ячейку, т.е. будет заполнен 6 контейнер в зоне.
10. Получаем список доступных контейнеров и остатки номенклатуры в каждом контейнере. Только на этом этапе мы получили информацию о том в какой ячейке какой товар находится и в каком контейнере с его типом (контейнером может быть как паллета, так и сама ячейка, если в ней не ведется учет контейнеров).
11. В регистре сведений усВместимостьКонтейнеров содержится информация о вместимости номенклатуры в каждый тип контейнера. Зная остаток товара в контейнере, максимальную вместимость в контейнер, его объем, рассчитываем наполненность контейнера в процентах. Если вместимость в контейнер не задана, то умножаем объем одного товара на остаток товара и делим на объем контейнера. Если объем контейнера не задан, тогда считаем занятость равно 0. Если нет полных данных о слоях на паллете, то вместимость считаем как деление остатка товара на максимальную вместимость товара в контейнер. Если есть все данные, то рассчитываем высоту товара в контейнере по слоям и делим на высоту ячейки. В итоге получаем таблицу вместимости в процентах каждого контейнера, а также порядок сортировки по номенклатуре (вначале контейнера содержащие ту же номенклатуру, потом все остальные).
12. Зная процент занятости контейнера, а также вместимость искомого товара в каждый контейнер получаем таблицу с расчетом количества товара, который теоретически может быть размещен в каждый из предполагаемых контейнеров. Свободное количество определяем или просто разделив оставшийся объем контейнера на объем товара, или используя данные по слоям номенклатуры. В принципе зная вместимость товара в контейнер и остатков этого товара мы всегда можем узнать сколько в него еще влезет, но только если в ячейке находится только тот же товар или ячейка пустая. Сложная формула нужна для расчета вместимости, с учетом того, что в ячейке может находится несколько товаров. Но она далека от совершенства т.к. в случае смешанного хранения товар не хранится слоями как пирожок, где нужно учитывать высоту, а хранится кучками, где рассчитать реальную вместительность довольно сложно и хватило бы простого анализа объема.
13. Рассчитываем данные сортировки по ABС из регистров усКлассификцияABCXYZНоменклатуры и правил из справочника усПоследовательностьРазмещенияПоABC.
14. Собираем все полученные ранее данные в итоговую таблицу ячеек, потенциально доступных для размещения искомого товара с учетом, что в контейнер помещается как минимум одна целая упаковка. Настраиваются параметры сортировки по "к той же номенклатуре", ABC классу, свободному количеству для размещения, порядку размещения из настроек ячеек, коду ячеек.
В дальнейшем данные из этого запроса обрабатываются через правила совместимости, где с помощью компоновки данных проверяются настроенные условия правил совместимости товаров в ячейках. Для этого используется пакет из 7 подзапросов. Если в ходе проверки правил совместимости ни одна ячейка не удовлетворяет условию, то стратегия размещение продолжит искать ячейки по следующему по списку алгоритму.
Расшифровка текста запроса из функции ПолучитьТекстЗапроса_РазмещениеСоставаКонтейнера_ВЗонуОтбора
Запрос представляет собой пакет из 14 подзапросов. Краткое описание каждого шага:
1. Получаем штатные (закрепленные) зоны и ячейки отбора по номенклатуре.
2. Получаем полный список доступных ячеек (все ячейки указанных зон, если была указана только зона отбора, плюс фиксированные ячейки отбора) с учетом данных шага 1.
3. Получаем список допустимых зон из алгоритма размещения или все найденные зоны, если ограничений нет.
4. Получаем окончательный массив доступных ячеек из шага 2 с учетом ограничений из шага 3.
5. Получаем положение всех контейнеров в ячейках из шага 4.
6. Получаем список ячеек из шага 4 и доступных контейнеров в них из шага 5.
7. Получаем остатки всех товаров всех контейнеров из шага 5.
8. Подсчитываем количество контейнеров в каждой зоне по остаткам из 7 шага где товар равен исходному и остатков в ячейке не меньше минимального для контейнера.
9. Находим подходящие контейнеры из шага 6, где максимальное количество контейнеров по настройке не меньше текущего количества из шага 8
10. Объединяем данные с шага 9 и остатки с шага 7
11. К данным из шага 10 добавляются данные по вместимости контейнера по каждому товару для определения процента занятости для каждого контейнера
12. Определение свободных контейнеров совмещая данные из шага 9 и шага 11
13. Получения данных по классам ABC
14. Получение окончательных данных по контейнерам из шага 12 с подходящим ABC классом (если используется), где доступное количество для размещение не меньше кратности упаковки.
Расшифровка каждого шага запроса:
1. Для каждого товара может быть назначена или просто целиковые зоны отбора (плавающие ячейки), или конкретные ячейки отбора (фиксированные ячейки). Для зоны отбора настраивается минимальное и максимальное количество контейнеров в ней под номенклатура, а также минимальный остаток в контейнере (минимальные параметры нужны для подсистемы подпитки).
2. Для указанных зон получаем список всех входящих в нее ячеек отбора плюс фиксированные ячейки отбора по номенклатуре (если имеются).
3. В алгоритмах размещения могут быть наложены ограничения на используемые зоны. На этом шаге получаем список зон из алгоритма и объединяем с полученной таблицей зон, если таких ограничений нет. Т.е. на выходе имеем список допустимых зон.
4. Накладываем ограничения на зоны и получаем окончательный список всех ячеек для возможного размещения товара по данному шагу алгоритма стратегии.
5. Из регистра усПоложениеКонтейнеров получаем остатки по всем контейнерам, которые находятся в списке рассматриваемых ячеек.
6. Объединяем список ячеек и находящиеся в них контейнера и получаем таблицу связки Ячейка-Контейнер.
7. Получаем остатки всех товаров во всех контейнерах где есть остатков товара или ожидается его приход. В случае если у нас в зоне находится тысяча ячеек, а в каждой ячейке лежит ни один товар, то мы получим таблицу с несколько тысячами записями об остатков всех товаров в зоне.
8. Для каждой зоны подсчитываем количество занятых контейнеров, где количество остатка товара в контейнере больше или равно минимальному остатку в контейнере. Странно, но если в контейнере есть 5 штук, а по настройке минимум должно быть 10 штук, то данный контейнер мы не учитываем и можем завести еще один, если позволяют настройки.
9. Фильтруем список подходящих контейнеров с остатками с учетом максимального допустимого количества контейнеров в каждой зоне. Отбираются только те ячейки, в зонах которых допустимое максимальное количество не превышено. Т.е. если в зоне уже находится 5 контейнеров, а по настройкам разрешено максимум 5 контейнеров в зоне, то в список попадут все ячейки данной
зоны. И при определенных обстоятельствах товар может быть размещен в новую ячейку, т.е. будет заполнен 6 контейнер в зоне.
10. Получаем список доступных контейнеров и остатки номенклатуры в каждом контейнере. Только на этом этапе мы получили информацию о том в какой ячейке какой товар находится и в каком контейнере с его типом (контейнером может быть как паллета, так и сама ячейка, если в ней не ведется учет контейнеров).
11. В регистре сведений усВместимостьКонтейнеров содержится информация о вместимости номенклатуры в каждый тип контейнера. Зная остаток товара в контейнере, максимальную вместимость в контейнер, его объем, рассчитываем наполненность контейнера в процентах. Если вместимость в контейнер не задана, то умножаем объем одного товара на остаток товара и делим на объем контейнера. Если объем контейнера не задан, тогда считаем занятость равно 0. Если нет полных данных о слоях на паллете, то вместимость считаем как деление остатка товара на максимальную вместимость товара в контейнер. Если есть все данные, то рассчитываем высоту товара в контейнере по слоям и делим на высоту ячейки. В итоге получаем таблицу вместимости в процентах каждого контейнера, а также порядок сортировки по номенклатуре (вначале контейнера содержащие ту же номенклатуру, потом все остальные).
12. Зная процент занятости контейнера, а также вместимость искомого товара в каждый контейнер получаем таблицу с расчетом количества товара, который теоретически может быть размещен в каждый из предполагаемых контейнеров. Свободное количество определяем или просто разделив оставшийся объем контейнера на объем товара, или используя данные по слоям номенклатуры. В принципе зная вместимость товара в контейнер и остатков этого товара мы всегда можем узнать сколько в него еще влезет, но только если в ячейке находится только тот же товар или ячейка пустая. Сложная формула нужна для расчета вместимости, с учетом того, что в ячейке может находится несколько товаров. Но она далека от совершенства т.к. в случае смешанного хранения товар не хранится слоями как пирожок, где нужно учитывать высоту, а хранится кучками, где рассчитать реальную вместительность довольно сложно и хватило бы простого анализа объема.
13. Рассчитываем данные сортировки по ABС из регистров усКлассификцияABCXYZНоменклатуры и правил из справочника усПоследовательностьРазмещенияПоABC.
14. Собираем все полученные ранее данные в итоговую таблицу ячеек, потенциально доступных для размещения искомого товара с учетом, что в контейнер помещается как минимум одна целая упаковка. Настраиваются параметры сортировки по "к той же номенклатуре", ABC классу, свободному количеству для размещения, порядку размещения из настроек ячеек, коду ячеек.
В дальнейшем данные из этого запроса обрабатываются через правила совместимости, где с помощью компоновки данных проверяются настроенные условия правил совместимости товаров в ячейках. Для этого используется пакет из 7 подзапросов. Если в ходе проверки правил совместимости ни одна ячейка не удовлетворяет условию, то стратегия размещение продолжит искать ячейки по следующему по списку алгоритму.
из упоминавшеся ранее ветки, от rsergio, по Манхеттену
Ковыряюсь в архивной папочке WMS, нашел интересный отзыв об одной WMS. Источника (блога) уже нет, поэтому копирую просто текст:
Комментарий от: Serge [Посетитель]
прочитал всю страницу, много про WMS сказано хорошего, нам бы так жить :)
хочу поделиться своим опытом участия в работе WMS на достаточно крупном складе (10 тыс.кв.м.). если говорить кратко, то лучше, конечно, стало, но далеко не намного лучше - не так, как нам распевали внедренцы. от них мы слышали практически все рекламные фразу, выделенные курсовим топикстартером. мол, скорость работы увеличится, точность подбора увеличится (у нас до внедрения была точность чуть больше 93%, хотели добиться естественно 99% - и внедренцы говорили, что это реально). мы проходили курс обучения, с улыбкой предвкушали рай на складах и с нетерпением ждали запуска "боевого" сервера системы :)
и вот сейчас, спустя довольно продолжительное время, стало видно, что и система оказалась неидеальной на самом деле (если интересно, это манхеттен), и внедренцы местами профилонили, а местами и по ушам проехали, и на базе не стало идеально хорошо, и даже напротив - всё осталось так же, только теперь мы удивлённо узнаём, что и симболовские девятитысячники тоже легко можно разломать пополам - особенно если у тебя имеется опыт выпаса овец в горах))))
если по фактам, то:
-- адресное хранение на самом деле больше проблем создало, чем решило. было принято решение вести партионный учет, это повлекло за собой необходимость разделять партии по разным местам хранения. образно говоря, то, что раньше лежало на одной паллете, теперь разлетелось по трем. а если партионный учет не реализовывать, то неосвоенным остался бы один из самых больших плюсов WMS - за что тогда платить деньги - за возможность комплектовщикам играться с терминалами? :)
-- скорость подбора возросла, но не вполовину и даже не на четверть. наши комплектовщики и так знали места хранения групп товара и прекрасно ориентировались что где.
-- что реально принесло пользу, так это возможность оперативно изменять срочность сборки нужных заказов. более эффективным стало управление доставкой клиентам.
-- зато с одной из особенностей манхеттена мы здорово накололись. когда товар резервируется под отбор из одной ячейки и комплектовщик по какой-то причине не смог оттуда взять товар, то wms тупо генерирует т.н. "недобор" (корректировку количеств в заказе в минус), вместо того, чтобы перенаправить комплектовщика к другому месту хранения этого товара. как вы понимаете, в конечном итоге это здорово сказалось на качестве сборки заказов, ведь без wms комплектовщик запросто мог взять товар из соседней ячейки, никто ему не запрещал.
-- про то, что с внедрением wms появляется возможность немного сократить персонал базы, мы читали. на деле всё оказалось ровно наоборот. во-первых, доп.нагрузку (и какую нагрузку!) получил IT-отдел. глюков у Манха оказалось хватает, некоторые до сих пор не можем понять (а техподдержка внедренцев за каждое слово высылает счёт). во-вторых, появилась необходимость содержать специалистов по wms, разруливающих вопросы, возникающие у персонала, работающего с радиотерминалами (хорошо предложение построил! :) . в-третьих, появилась необходимость содержать людей, поддерживающих порядок в адресной системе, как пример - проведение ревизий, генерящихся wmsкой. в-четвертых, комплектовщиков тоже не стало меньше. работы хватило всем.
теперь по конкретной системе, то есть по манхеттену.
-- что ещё добило, так это невозможность конкретно в этой wmsке ручной генерации заданий - тем же водителям погрузчиков. чтобы просто переместить паллету с места на место, нужно сначала сделать это с консоли (или терминала, неважно) самому и переписать ячейки на бумажку, а потом бежать до водителя погрузчика и по бумажке объяснять ему, откуда и куда он должен перевезти паллету. или например ещё один громадный головняк - это "витрина" в торговом зале. перемещать туда по 1шт товара, если его там ещё нет - чисто ручной труд, иначе никак. при номенклатуре в 5 - 6 тыс наименований этот труд становится ежедневным, идиотским, - но необходимым для подержания актуальности данных в wms.
при этом наши программисты наотрез отказываются дописывать нужный функционал самотоятельно - т.к. в договоре (на обслуживание или как-то так, точной формулировки не помню) четко написано "изменяете код -- лишаетесь поддержки". а она иногда таки бывает нужна.
-- о мелочах типа отсутствия группировки доступов к отчетам по ролям я уже молчу. мало того, что не всем нужны все подряд отчеты (которых накопилось уже море), так ещё и нельзя скрыть доступ к отчетам, которые не всем видеть и положено. или всем, или никому.
-- ну и глюки. манхеттен почему-то позволяет создавать, например, отрицательные остатки. делать сверхотбор, генеря какие-то отрицательные цифры в количестве зарезервированного товара. при этом дальнейшая работа с этой ячейкой блокируется. комплектовщик лоханулся раз - всё, проси айтишников обнулить отриц.резерв. с таких кривых ячеек ни резервирование в отбор уже не работает, никакие другие операции с остатками. а если произвести попытку резервирования под отбор (т.н. запуск волны с завазами) и волна "откажется" системой с ошибками, то причину возникновения ошибок придется раскапывать из кучи англоязычного мусора, сгенеренного дотнетом в логах системы. то есть, даже ни один оператор на обработке накладных никогда не сможет разобраться в логах, чтобы понять, что же случилось с волной?.
-- ещё порядочный такой, большой минус - это указание на терминалах комплектовщикам собираемых количеств только и исключительно в базовых ЕИ. то есть, если товар весовой и нужно отобрать 500КГ какой-нибудь соли поваренной, то комплектовщик получит инструкцию на отбор 500000ГР и обязательно ошибется в нулях и чего-нибудь напортачит. не на первый, так на пятидесятый раз. это правда жизни. то же самое со штуками. коробочная вместимость побоку.
то есть, для "штучных" товаров (не весовых) количество коробов тоже на терминале выходит, но где-то сбоку и мелким шрифтом. а подтверждать отбор нужно именно в штуках.
вот такие реалии. складской персонал искренне не понимает, зачем их заставляют работать с "этой программой", ведь без неё было не хуже ни на процент. а ответ простой: программа стоит денег, и они уже затрачены на приобретение wms. и если сейчас сказать о том, что они были потрачены зря, то кое-на кого ляжет тень :) поэтому тужимся, но тянем.
2008-11-21 @ 09:55
Ковыряюсь в архивной папочке WMS, нашел интересный отзыв об одной WMS. Источника (блога) уже нет, поэтому копирую просто текст:
Комментарий от: Serge [Посетитель]
прочитал всю страницу, много про WMS сказано хорошего, нам бы так жить :)
хочу поделиться своим опытом участия в работе WMS на достаточно крупном складе (10 тыс.кв.м.). если говорить кратко, то лучше, конечно, стало, но далеко не намного лучше - не так, как нам распевали внедренцы. от них мы слышали практически все рекламные фразу, выделенные курсовим топикстартером. мол, скорость работы увеличится, точность подбора увеличится (у нас до внедрения была точность чуть больше 93%, хотели добиться естественно 99% - и внедренцы говорили, что это реально). мы проходили курс обучения, с улыбкой предвкушали рай на складах и с нетерпением ждали запуска "боевого" сервера системы :)
и вот сейчас, спустя довольно продолжительное время, стало видно, что и система оказалась неидеальной на самом деле (если интересно, это манхеттен), и внедренцы местами профилонили, а местами и по ушам проехали, и на базе не стало идеально хорошо, и даже напротив - всё осталось так же, только теперь мы удивлённо узнаём, что и симболовские девятитысячники тоже легко можно разломать пополам - особенно если у тебя имеется опыт выпаса овец в горах))))
если по фактам, то:
-- адресное хранение на самом деле больше проблем создало, чем решило. было принято решение вести партионный учет, это повлекло за собой необходимость разделять партии по разным местам хранения. образно говоря, то, что раньше лежало на одной паллете, теперь разлетелось по трем. а если партионный учет не реализовывать, то неосвоенным остался бы один из самых больших плюсов WMS - за что тогда платить деньги - за возможность комплектовщикам играться с терминалами? :)
-- скорость подбора возросла, но не вполовину и даже не на четверть. наши комплектовщики и так знали места хранения групп товара и прекрасно ориентировались что где.
-- что реально принесло пользу, так это возможность оперативно изменять срочность сборки нужных заказов. более эффективным стало управление доставкой клиентам.
-- зато с одной из особенностей манхеттена мы здорово накололись. когда товар резервируется под отбор из одной ячейки и комплектовщик по какой-то причине не смог оттуда взять товар, то wms тупо генерирует т.н. "недобор" (корректировку количеств в заказе в минус), вместо того, чтобы перенаправить комплектовщика к другому месту хранения этого товара. как вы понимаете, в конечном итоге это здорово сказалось на качестве сборки заказов, ведь без wms комплектовщик запросто мог взять товар из соседней ячейки, никто ему не запрещал.
-- про то, что с внедрением wms появляется возможность немного сократить персонал базы, мы читали. на деле всё оказалось ровно наоборот. во-первых, доп.нагрузку (и какую нагрузку!) получил IT-отдел. глюков у Манха оказалось хватает, некоторые до сих пор не можем понять (а техподдержка внедренцев за каждое слово высылает счёт). во-вторых, появилась необходимость содержать специалистов по wms, разруливающих вопросы, возникающие у персонала, работающего с радиотерминалами (хорошо предложение построил! :) . в-третьих, появилась необходимость содержать людей, поддерживающих порядок в адресной системе, как пример - проведение ревизий, генерящихся wmsкой. в-четвертых, комплектовщиков тоже не стало меньше. работы хватило всем.
теперь по конкретной системе, то есть по манхеттену.
-- что ещё добило, так это невозможность конкретно в этой wmsке ручной генерации заданий - тем же водителям погрузчиков. чтобы просто переместить паллету с места на место, нужно сначала сделать это с консоли (или терминала, неважно) самому и переписать ячейки на бумажку, а потом бежать до водителя погрузчика и по бумажке объяснять ему, откуда и куда он должен перевезти паллету. или например ещё один громадный головняк - это "витрина" в торговом зале. перемещать туда по 1шт товара, если его там ещё нет - чисто ручной труд, иначе никак. при номенклатуре в 5 - 6 тыс наименований этот труд становится ежедневным, идиотским, - но необходимым для подержания актуальности данных в wms.
при этом наши программисты наотрез отказываются дописывать нужный функционал самотоятельно - т.к. в договоре (на обслуживание или как-то так, точной формулировки не помню) четко написано "изменяете код -- лишаетесь поддержки". а она иногда таки бывает нужна.
-- о мелочах типа отсутствия группировки доступов к отчетам по ролям я уже молчу. мало того, что не всем нужны все подряд отчеты (которых накопилось уже море), так ещё и нельзя скрыть доступ к отчетам, которые не всем видеть и положено. или всем, или никому.
-- ну и глюки. манхеттен почему-то позволяет создавать, например, отрицательные остатки. делать сверхотбор, генеря какие-то отрицательные цифры в количестве зарезервированного товара. при этом дальнейшая работа с этой ячейкой блокируется. комплектовщик лоханулся раз - всё, проси айтишников обнулить отриц.резерв. с таких кривых ячеек ни резервирование в отбор уже не работает, никакие другие операции с остатками. а если произвести попытку резервирования под отбор (т.н. запуск волны с завазами) и волна "откажется" системой с ошибками, то причину возникновения ошибок придется раскапывать из кучи англоязычного мусора, сгенеренного дотнетом в логах системы. то есть, даже ни один оператор на обработке накладных никогда не сможет разобраться в логах, чтобы понять, что же случилось с волной?.
-- ещё порядочный такой, большой минус - это указание на терминалах комплектовщикам собираемых количеств только и исключительно в базовых ЕИ. то есть, если товар весовой и нужно отобрать 500КГ какой-нибудь соли поваренной, то комплектовщик получит инструкцию на отбор 500000ГР и обязательно ошибется в нулях и чего-нибудь напортачит. не на первый, так на пятидесятый раз. это правда жизни. то же самое со штуками. коробочная вместимость побоку.
то есть, для "штучных" товаров (не весовых) количество коробов тоже на терминале выходит, но где-то сбоку и мелким шрифтом. а подтверждать отбор нужно именно в штуках.
вот такие реалии. складской персонал искренне не понимает, зачем их заставляют работать с "этой программой", ведь без неё было не хуже ни на процент. а ответ простой: программа стоит денег, и они уже затрачены на приобретение wms. и если сейчас сказать о том, что они были потрачены зря, то кое-на кого ляжет тень :) поэтому тужимся, но тянем.
2008-11-21 @ 09:55
оттуда же, по Exceed
Для справки - FBR003 должна была закрыть возможность упаковки (контроля) еще недособранного заказа. Т.е. комплектовщик уши развесил, а контролер уже пытается проверить товар и у него это получается с кучей проблем в дальнейшем. Стоимость исправления ошибки - 85 502 руб.
FBR004 - простая "хотелка" чтобы при приемке определенных документов все входящие паллеты блокировались. Стоимость хотелки - 238 330 руб.
Ну и так далее. Не удивительно, что система умерла на нашем рынке.
Для справки - FBR003 должна была закрыть возможность упаковки (контроля) еще недособранного заказа. Т.е. комплектовщик уши развесил, а контролер уже пытается проверить товар и у него это получается с кучей проблем в дальнейшем. Стоимость исправления ошибки - 85 502 руб.
FBR004 - простая "хотелка" чтобы при приемке определенных документов все входящие паллеты блокировались. Стоимость хотелки - 238 330 руб.
Ну и так далее. Не удивительно, что система умерла на нашем рынке.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот