Picker Assignment Method Experimentations
This report will discuss two different proposed methods to assign pickers equally across all slots
Created on August 1|Last edited on August 1
Comment
Current ImplementationProblem with Current AssignmentProposed Alternative ImplementationsMethod 1Method 2System Performance
Current Implementation
We can find our current implementation for PCA on the flowchart below.
Since now we adopt a new system where the pickers are also checkers, we would only need to consider the picker assignment method. When the PCA job is triggered, it will retrieve two data: orders & pickers from oss_db and orders_db. From here, we follow the algorithm:
- Filter both orders and pickers data for current hub
- If any of these data is empty, move on to the next hub
- Sort orders with the highest number of SKUs in ascending order (orders with higher number of SKUs are prioritized)
- Otherwise, for each order, find pickers with the smallest workload (initially all pickers have 0 workloads)
- Assign order to that picker
- If there are no orders left to be assigned, move on to the next hub
Problem with Current Assignment
The current assignment method seems to be working; however, it introduces assignment inequality. You can check it further through this analysis (credits to @Luo Ting for creating this).
From the distribution charts, we can see that the assignment result is too one-sided, meaning that some pickers have lower number of orders (num_orders) and items (num_skus) while some of them have the opposite. This is due to the nature of our algorithm which always picker with the lowest workload (num_skus). This method fails when the assigned order coincidentally has a high number of workload, that picker will have a significant number of workloads compared to other pickers. It has no control over how many orders/items have been assigned to pickers and limit them.
Proposed Alternative Implementations
We came up with two alternative solutions by modifying the current implementation's algorithm.
Method 1
Limit assignments for each picker by dividing total orders by the number of pickers in that slot
💡
For example, if we have 100 orders and 30 pickers in slot 0, then we will only need to assign 3 orders for each picker, leaving 10 orders unassigned. These unassigned orders will be assigned with the same algorithm as before. By doing this, hopefully, we end up with an equal number of orders across pickers with some of them having one or two orders more (because of the unassigned orders). We could also ran this method based on the number of items in each order. Thus, we just need to change the total orders to sum of items in each order.
The results seemed to be fine. We have most pickers assigned to approximately ~20-30 orders with ~200 items on both models. However, the orders and items disparity are still evident.
Method 2
Limit assignments for each picker by dividing total orders by the number of pickers in that slot-hub combination
💡
Method 2 still has the similar assignment logic, except that we now consider the pickers' hubs. For example, we have 100 orders and consider the following pickers:
- Picker A: Hub 1, Hub 3
- Picker B: Hub 1, Hub 2, Hub 3
- Picker C: Hub 2, Hub 3
- Picker D: Hub 1
In method 1, we simply divide the total orders with the total pickers. In this case, we have 4 pickers and we will assign approximately ~25 orders. The problem with this, most pickers are available in various hubs. Hence, if one picker is on 3 different hubs and the other picker is only on 1 hub, picker with 3 hubs will still have more orders assigned compared to pickers who are in fewer hubs (Picker B will be assigned ~75 orders while Picker D will be assigned ~25 orders). Method 2 overcomes this issue by considering the number of hubs on each picker. From the example above, Picker A and C will have ~12 orders, Picker B will have ~8 orders, and picker D will have ~25 orders in each hub.
Looking at the result from model method2_on_orders_slot0 (right), it seems like the new assignment method has improved. Now pickers only have 1 or 2 number of orders difference. On the other hand, using number of items in method 2 (left) is not as effective as using total orders. We still end up with a large number of orders and items disparity between pickers.
System Performance
We have seen how the new improved methods perform compared to the current methods in production. Now, does the new improved model perform in terms of time and cost? Do they take longer time to run and utilize more memory?
Unsurprisingly, all methods took ~14s to run and ~6.4MB memory on average. This behavior is kind of expected because we only modified a small portion of the model.
Add a comment