Top 3 Warehouse Physical Problems Developers Must Solve in WMS

Over the past two years, I have been working in the e-commerce field, specifically focusing on the development of Warehouse Management Systems (WMS). Those who have been involved in WMS development can surely understand the challenges that arise when warehouse or operational staff encounter issues. I would like to discuss three problems that can impact the development team. If the topic resonates, I can continue sharing about other challenges I have encountered and resolved.

Background Information

The WMS is built using Java/Spring Framework. It only accepts unique SKU (Stock Keeping Unit) + barcode combinations and operates with a single warehouse.

Multi-Barcode

Quite a common problem in warehouses. It goes something like this: "Hey guys, today we're receiving iPhones from China and India, and we need to figure out how to handle them under a single SKU. The key issue is that EAN is used in Russia for warehouses, while iPhones use UPC. The barcode of the product changes depending on the manufacturer, but the seller wants to treat it as a single item. The end customer ends up with a loot box-like experience—it all depends on which product the warehouse employee picks, whether it's from China or India.

What are the possible solutions?

1. Unique identifier: The simplest solution is to attach a unique barcode to each product during the receiving process. This is done by companies like Amazon. However, it's important to understand that this approach increases the time and resources required for product receiving.
2. Maintaining an array of barcodes: This approach can be suitable for quick implementation. However, it neglects the different attributes associated with different barcodes. For example, one barcode might represent a gift set while another represents an individual item.
3. Decoupling SKU and barcodes: We can isolate the SKU from the barcodes. This approach moves towards itemization, where the SKU provides general information about the product, such as dimensions or SPU (Supplier Part Number), while the barcode emphasizes unique attributes like price, color, or description. The main challenges here are restructuring the information flow for the user interface and, if the topology configuration is not flexible enough, changing the storage method in cells to optimize space utilization and prevent mix-ups of products with identical barcodes.

Unidentified Products

Let's get back to iPhones. Most sellers don't even know what they're selling since they source the products from one place and aim for quick profits through marketplaces. Product cards are created in the fulfillment system, where barcode information is entered. It's not critical if the seller makes mistakes in the product attributes for the warehouse, but it becomes critical when physically it's the same product with different barcodes. As a result, the warehouse staff may have an iPhone in their hands, but the barcode doesn't register.

Possible solutions:

1. Backward compatibility with fulfillment: Scanning the barcodes and notifying the seller about unidentified products can be a reasonable solution. The challenge lies in the time required to resolve such issues, especially when dealing with different time zones or limited time for incident resolution, while the product occupies storage space.
2. Using AI: Visual recognition systems, fish-eye cameras, or internet searches for product identification can be excellent solutions. The only downside is the cost of implementing such technologies. However, looking at the broader picture, it can also address issues with optimizing stock placement during product receiving, thus increasing the speed of receiving by employees.
3. Calling the seller directly: It's always possible to directly contact the seller. This approach is faster but not every warehouse is equipped for this option.
4. Trusting the warehouse staff and updating the product card: It's not advisable to rely solely on the actions of warehouse employees. Often, individuals who can only follow instructions are hired for warehouse positions. Identifying the product is a crucial task because in the end, a person who ordered a 512GB Steam Deck receiving a 64GB version would face a highly unpleasant situation.

Multi-Warehouse

At some point, when business grows, opening an additional warehouse becomes necessary. What can be done in this case?

1. Creating an additional instance: It's a straightforward solution but not always feasible due to resource requirements for deployment. Additionally, the second instance may be unavailable due to network-related issues. For example, Kafka MirrorMaker can be used to duplicate only the messages that meet certain conditions. Managing multiple instances with a single team is debatable. On one hand, it involves separate databases, but on the other hand, it requires constant back-and-forth during operations.
2. Creating a Warehouse entity: This can be a simple and flexible solution. However, all APIs need to have a mechanism to identify the warehouse the employee is currently working with. JWT tokens and storing employee information can assist in isolating employees across different warehouses.

What do you think? How would you solve these types of problems? Thank you for sharing your ideas in the comments.