3 главные физические проблемы склада, которые разработчики должны решить с помощью WMS
18 мая 2023 г.Последние два года я работал в сфере электронной коммерции, уделяя особое внимание разработке систем управления складом (WMS). Те, кто принимал участие в разработке WMS, наверняка понимают проблемы, возникающие при возникновении проблем со складским или операционным персоналом. Я хотел бы обсудить три проблемы, которые могут повлиять на команду разработчиков. Если тема найдет отклик, я могу продолжить рассказывать о других проблемах, с которыми я столкнулся и которые я решил.
Справочная информация
WMS построена с использованием Java/Spring Framework. Он принимает только уникальные комбинации SKU (единица хранения) + штрих-код и работает с одним складом.
Несколько штрих-кодов
Довольно распространенная проблема на складах. Он звучит примерно так: «Ребята, сегодня к нам приходят айфоны из Китая и Индии, и нам нужно придумать, как их обрабатывать под единым артикулом. Ключевая проблема в том, что в России для складов используется EAN, В айфонах используется UPC.Штрих-код продукта меняется в зависимости от производителя, но продавец хочет рассматривать его как единый товар.Конечный покупатель получает опыт, похожий на лутбокс — все зависит от того, какой продукт выберет работник склада. , будь то из Китая или Индии.
Каковы возможные решения?
- Уникальный идентификатор. Самое простое решение — прикрепить уникальный штрих-код к каждому продукту в процессе получения. Этим занимаются такие компании, как Amazon. Однако важно понимать, что такой подход увеличивает время и ресурсы, необходимые для получения продукта.
- Ведение массива штрих-кодов. Этот подход подходит для быстрой реализации. Однако при этом игнорируются различные атрибуты, связанные с разными штрих-кодами. Например, один штрих-код может обозначать подарочный набор, а другой — отдельный предмет.
- Развязка SKU и штрих-кодов. Мы можем изолировать SKU от штрих-кодов. Этот подход движется к детализации, когда SKU предоставляет общую информацию о продукте, такую как размеры или SPU (номер детали поставщика), а штрих-код подчеркивает уникальные атрибуты, такие как цена, цвет или описание. Основными проблемами здесь являются реструктуризация потока информации для пользовательского интерфейса и, если конфигурация топологии недостаточно гибкая, изменение метода хранения в ячейках для оптимизации использования пространства и предотвращения перепутывания товаров с одинаковыми штрих-кодами.
Неидентифицированные продукты
Вернемся к iPhone. Большинство продавцов даже не знают, что они продают, поскольку закупают продукты в одном месте и стремятся быстро получить прибыль через торговые площадки. Карточки товаров создаются в системе фулфилмента, куда заносится информация о штрих-кодах. Не критично, если продавец ошибается в атрибутах товара для склада, но становится критичным, когда физически это один и тот же товар с разными штрих-кодами. В результате у сотрудников склада в руках может быть iPhone, но штрих-код не регистрируется.
Возможные решения:
- Обратная совместимость с выполнением: разумным решением может быть сканирование штрих-кодов и уведомление продавца о неопознанных товарах. Проблема заключается во времени, необходимом для решения таких проблем, особенно при работе с разными часовыми поясами или ограниченным временем для решения инцидента, в то время как продукт занимает место на складе.
- Использование искусственного интеллекта. Отличными решениями могут стать системы визуального распознавания, камеры типа "рыбий глаз" или поиск в Интернете для идентификации продукта. Единственным недостатком является стоимость внедрения таких технологий. Однако, глядя на более широкую картину, он также может решать проблемы с оптимизацией размещения запасов во время получения продуктов, что увеличивает скорость получения сотрудниками.
- Прямой звонок продавцу. Связаться с продавцом напрямую можно всегда. Этот подход быстрее, но не каждый склад оборудован для этого варианта.
- Доверие персоналу склада и обновление карточки товара. Не рекомендуется полагаться исключительно на действия сотрудников склада. Часто на складские должности нанимают людей, которые могут только следовать инструкциям. Идентификация продукта является важной задачей, потому что в конечном итоге человек, заказавший Steam Deck на 512 ГБ и получивший версию на 64 ГБ, столкнется с крайне неприятной ситуацией.
Несколько складов
В какой-то момент по мере роста бизнеса возникает необходимость в открытии дополнительного склада. Что можно сделать в этом случае?
- Создание дополнительного экземпляра. Это простое решение, но не всегда выполнимое из-за требований к ресурсам для развертывания. Кроме того, второй экземпляр может быть недоступен из-за проблем с сетью. Например, Kafka MirrorMaker можно использовать для дублирования только тех сообщений, которые соответствуют определенным условиям. Управление несколькими экземплярами с помощью одной команды является спорным вопросом. С одной стороны, это требует отдельных баз данных, а с другой стороны, требует постоянного обмена данными во время операций.
- Создание объекта хранилища. Это может быть простым и гибким решением. Однако все API должны иметь механизм для идентификации склада, с которым в данный момент работает сотрудник. Токены JWT и хранение информации о сотрудниках могут помочь изолировать сотрудников на разных складах.
Что вы думаете? Как бы вы решили такие проблемы? Спасибо, что поделились своими идеями в комментариях.
Оригинал