In Part I on fulfillment KPIs, we took a look the customer facing metrics, from inventory to fulfillment. And that inventory being fulfilled, is coming from somewhere. So let’s take a look at the inbound side of an eCommerce fulfillment center now.
The Different Inbound Flows
Generally speaking, you can separate warehouse operations into three blocks: Outbound, Inventory and Inbound. For the purpose of this article, we look at the major different inbound flows into a warehouse, all the way to stowing the goods, which closes the loop to inventory. These flows are
- Parcel deliveries
- Inbound transfers (in case there are more than one warehouse in the network)
- Partial and Full Truck Loads
We will focus on the KPI aspects of this, the operations behind them, things like license plate receive, stow strategies and so on, are better covered separately.
Inbound Parcel Deliveries
This covers all deliveries coming with parcel carriers. In most cases, they make a small fraction of total inbound volumes. Quantities per delivery tend to be low, with a high degree of multi-article deliveries. So what does this mean for our set of fulfillment related KPIs, KPIs we plan to use on a weekly basis? It means that we have to leave certain details, like stow and inventory quality by inbound flow, to the warehouse ops team. What we want to know, is how good inbound operations are performing. From a customer perspective, this means to monitor to which degree inbound operations are negatively impacting availability.
First and foremost, this means to monitor backlogs, as everything that is not stowed cannot be picked and not sold. For parcel deliveries, we have to register how many purchase orders have been delivered, how many have been received and how many have been stowed. In practice terms, the latter is much easier than the latter. It can be made easier, but implementing the necessary interfaces and tools to allow scanning of individual parcels or use tracking data to monitor deliveries. As each tracking number, either scanned or imported from carriers, can be matched against an purchase order, it is possible to link these deliveries to receive and stow events.
Collecting his information once per day, for KPI purposes, is enough. One potential set-up is to import carrier tracking data after the last parcel delivery, and to combine his information with receive and stow events once inbound operations are closed for the day. Comparing these numbers no gives us the number parcel deliveries delivered on that day, how many have been received but not stowed and how many have been stowed. We see how big the backlog is, how old it is. Which is everything we need, and we put that into KPIs by showing the oldest inbound by date and the highest daily backlog of the previous week.
A lot of the general principals apply to all three different inbound flows. So we apply the same principals we use for parcel deliveries for transfers. We collect the number and quantities for each transfer, the received and stowed transfers. Operationally, I is a little bit tricky. It makes sense to allow partial receiving and stowing for transfers, because they usually are larger than parcel deliveries. The question is how these partially received transfers are treated in the backlogs. Are they open transfers? Received transfers? Or do we use a different KPI? Personally, I prefer to keep the number of metrics as low as possible and as much standardized as possible. So I would not create a different KPI for partially received and stowed transfers, I would treat them as open transfers until they are completely closed. Because, in addition to availability, we want to make sure backlog are not increasing or big enough to cause problems. And if it is not possible to receive a transfer completely on any given day, it is sign of trouble in the warehouse docks.
So for transfers, we have the same KPIs as for parcel deliveries: highest backlog of the previous week, oldest transfer of the previous week. As it is the same principal as for parcel deliveries, this metric can still easily be handled and understood.
Full and Partial Truck Loads
Now it gets a little bit more complicated. First, because these deliveries make up the majority of the inbound volumes. Secondly, because there are most likely things like license plate receive in place to speed things up. And we want to make sure that we have the necessary transparency in place to monitor all that. The important distinction here is between license plate and non-license plate, full or partial truck loads are not an overly important factor here.
Again, we apply the same principal as before, we collect delivered, received and stowed data on purchase order level. Once for license plate and once for non-license plate receive. We again track the oldest open purchase order and the highest backlog for the previous week. We can get the delivered purchase orders by collecting the information during unloading, receive and stow are again pulled directly from the WMS.
As license plate receive, where a complete delivery is received without individually receiving each unit and order line, is there decrease receive cycle times, there shouldn’t be any backlog at all of un-received deliveries. There can be a backlog of goods that are not yet stowed, so this has to be monitored very closely. What we also need to monitor, is the stow and receive quality of goods coming through license plate receive. As we totally depend on suppliers to properly label and advice on goods being delivered, any mistakes propagate through the system, potentially impacting customers.
So it makes sense to implement random inspections for license plate receives, where every unit is individually received and controlled. Based on these results, we calculate the defects in DPMO. Ideally the threshold is lower than any threshold we use for inventory quality, issues during receive compound inventory issues and we want to be on the safe side. If these random controls are not feasible, it is possible to link inventory quality data to the corresponding license plate receives. Breaking these numbers down by supplier on a KPI level isn’t really necessary, this can be done for deep dives and root cause analysis when needed.
On-Time Delivery – For Suppliers and Warehouses
One important aspect, and one directly linked to inbound operations, is the delivery performance from suppliers. A lot of discussion, especially when suppliers are not meeting SLAs, turns around who is a fault for late deliveries. Is the supplier for delivering late? The warehouse for receiving late? Or was the truck scheduled late by the warehouse?
One neat way of tacking this issue is to use yard management data. All that is needed is the required delivery date or delivery window, the initially requested date, the scheduled date and the actual arrival date. Using this data, we can build a graph that looks like this:
What this graph tells us, with one look, is which inbound deliveries are scheduled late by the warehouse, which ones are early and which ones are on-time. Every bubble above the ladder is late, bubble on the ladder are on-time an bubbles below the ladder are early. Bubble size and color can be defined in a lot of ways, I like using size based on units in the scheduled delivery and color based on urgency. Urgency is a moving target, so, and can lead to confusion, just sticking with number of units works just as well. Assuming there is a digital yard management in place, this can even be built in Excel.
That’s it for now with fulfillment KPIs. Part three will discuss how these metrics and KPIs can be used weekly and even daily. Which is of course what greenleaves.io was founded to do for you in the first place!