3 главные физические проблемы склада, которые разработчики должны решить с помощью WMS
business warehouse warehouse-management

3 главные физические проблемы склада, которые разработчики должны решить с помощью WMS

18 мая 2023 г.

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

Справочная информация

WMS построена с использованием Java/Spring Framework. Он принимает только уникальные комбинации SKU (единица хранения) + штрих-код и работает с одним складом.

Несколько штрих-кодов

Довольно распространенная проблема на складах. Он звучит примерно так: «Ребята, сегодня к нам приходят айфоны из Китая и Индии, и нам нужно придумать, как их обрабатывать под единым артикулом. Ключевая проблема в том, что в России для складов используется EAN, В айфонах используется UPC.Штрих-код продукта меняется в зависимости от производителя, но продавец хочет рассматривать его как единый товар.Конечный покупатель получает опыт, похожий на лутбокс — все зависит от того, какой продукт выберет работник склада. , будь то из Китая или Индии.

Каковы возможные решения?

  1. Уникальный идентификатор. Самое простое решение — прикрепить уникальный штрих-код к каждому продукту в процессе получения. Этим занимаются такие компании, как Amazon. Однако важно понимать, что такой подход увеличивает время и ресурсы, необходимые для получения продукта.
  2. Ведение массива штрих-кодов. Этот подход подходит для быстрой реализации. Однако при этом игнорируются различные атрибуты, связанные с разными штрих-кодами. Например, один штрих-код может обозначать подарочный набор, а другой — отдельный предмет.
  3. Развязка SKU и штрих-кодов. Мы можем изолировать SKU от штрих-кодов. Этот подход движется к детализации, когда SKU предоставляет общую информацию о продукте, такую ​​как размеры или SPU (номер детали поставщика), а штрих-код подчеркивает уникальные атрибуты, такие как цена, цвет или описание. Основными проблемами здесь являются реструктуризация потока информации для пользовательского интерфейса и, если конфигурация топологии недостаточно гибкая, изменение метода хранения в ячейках для оптимизации использования пространства и предотвращения перепутывания товаров с одинаковыми штрих-кодами.

Неидентифицированные продукты

Вернемся к iPhone. Большинство продавцов даже не знают, что они продают, поскольку закупают продукты в одном месте и стремятся быстро получить прибыль через торговые площадки. Карточки товаров создаются в системе фулфилмента, куда заносится информация о штрих-кодах. Не критично, если продавец ошибается в атрибутах товара для склада, но становится критичным, когда физически это один и тот же товар с разными штрих-кодами. В результате у сотрудников склада в руках может быть iPhone, но штрих-код не регистрируется.

Возможные решения:

  1. Обратная совместимость с выполнением: разумным решением может быть сканирование штрих-кодов и уведомление продавца о неопознанных товарах. Проблема заключается во времени, необходимом для решения таких проблем, особенно при работе с разными часовыми поясами или ограниченным временем для решения инцидента, в то время как продукт занимает место на складе.
  2. Использование искусственного интеллекта. Отличными решениями могут стать системы визуального распознавания, камеры типа "рыбий глаз" или поиск в Интернете для идентификации продукта. Единственным недостатком является стоимость внедрения таких технологий. Однако, глядя на более широкую картину, он также может решать проблемы с оптимизацией размещения запасов во время получения продуктов, что увеличивает скорость получения сотрудниками.
  3. Прямой звонок продавцу. Связаться с продавцом напрямую можно всегда. Этот подход быстрее, но не каждый склад оборудован для этого варианта.
  4. Доверие персоналу склада и обновление карточки товара. Не рекомендуется полагаться исключительно на действия сотрудников склада. Часто на складские должности нанимают людей, которые могут только следовать инструкциям. Идентификация продукта является важной задачей, потому что в конечном итоге человек, заказавший Steam Deck на 512 ГБ и получивший версию на 64 ГБ, столкнется с крайне неприятной ситуацией.

Несколько складов

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

  1. Создание дополнительного экземпляра. Это простое решение, но не всегда выполнимое из-за требований к ресурсам для развертывания. Кроме того, второй экземпляр может быть недоступен из-за проблем с сетью. Например, Kafka MirrorMaker можно использовать для дублирования только тех сообщений, которые соответствуют определенным условиям. Управление несколькими экземплярами с помощью одной команды является спорным вопросом. С одной стороны, это требует отдельных баз данных, а с другой стороны, требует постоянного обмена данными во время операций.
  2. Создание объекта хранилища. Это может быть простым и гибким решением. Однако все API должны иметь механизм для идентификации склада, с которым в данный момент работает сотрудник. Токены JWT и хранение информации о сотрудниках могут помочь изолировать сотрудников на разных складах.

Что вы думаете? Как бы вы решили такие проблемы? Спасибо, что поделились своими идеями в комментариях.

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE