ABSTRACT

In order to be credible in chasing high-volume piece and case pick accounts, most public warehousing companies need to consider a new warehouse management system (WMS). Firms tend to over simplify what they need in a new system by stating only that they "need RF". There is a lot more to it than that to operate this type of account. This article describes a real-life example in which "having RF" would not be enough.

Inaddition to helping people find and install new warehousing systems, the Progress Group occasionally gets involved with clients who retain us to help them find a third party logistics (3PL) company to do their warehousing and fulfillment. It is my job on these projects to perform the systems assessment of the candidate firms. When I do this work, it often turns out that several of the candidates get eliminated from consideration NOT because of their facility's condition, management team, references, or even price but rather because of inadequate information systems. This is especially true for clients demanding high-volume piece pick or case pick services from their 3PL provider (i.e., the high-margin accounts that many of you would like to win!)

Most warehousing firms misunderstand why they lose on this issue. Many will restate our clients' reason for not selecting them as:

"We needed to have RF. We didn't have it, so we lost."

But using radio frequency terminals (RF) to scan product into and out of locations for the purpose of real-time inventory visibility or better inventory accuracy is only part of the story.

These firms lose because they don't have a warehouse management system (WMS)-one that provides features such as zone picking, dynamic forward pick areas, system-directed checking/packing, real time cycle counting without freezing inventory and so forth. RF often times is an important enabler of these features, but on its own it is not enough. Without these other capabilities you will struggle just to get the product out the door and that is why you can lose these types of opportunities.

A Real World Example

This point is best illustrated by a warehousing disaster story I recently encountered. As the story was told to me, a public warehousing company managed to win a contract account they really didn't have the system functionality to support. This account required a high-volume, pallet-in/pallet-case out fulfillment model. Other characteristics of the account included:

Type of Product:	Apparel
# of SKUs:	700+
Orders / Day:	30+ Orders Per Day
Lines / Order:	20+ Lines Per Order
Cases Per Order:	Typical orders ranged from 10 to 500 cases in size, with some as high as 2,000 to 3,000 cases
Number of Pickers:	18

Reserve product was putaway in standard single-deep pallet rack locations and a few floor locations on pallets. The reserve product took up over 200,000 square feet. Pallet picking from these locations was done using counter-balanced lift trucks.

Case Picking (which was the majority of the picking activity) was done using pallet jacks from a forward pick area consisting of slots located on the floor level of the reserve pallet rack. Like many companies attempting to support high-volume case pick accounts, our study company had both space and time problems. The forward picks slots could not hold a day's supply of inventory, and even if they could have, there was not enough time to "top them up" between the time orders were received and picking needed to start. As a result, the facility was forced to perform multiple, on-shift replenishments. This situation, combined with the company's inadequate WMS, was key to most of the warehouse's subsequent problems.

Note: It is fair to say that the older systems in use in many public warehouses today don't deal well with this kind of environment, and it is something you should understand about an account whenever you are considering taking on this kind of business.

Welcome to The Death March

At the time, the warehousing company used one of the common, paper-based, inexpensive packages that work well for the pallet-in/pallet out world, but struggle when placed in high- volume case- or piece-pick environments. Consequently, the startup and the continued operation of this warehouse account were what we in the software business call a "death march" constant overtime lead to fatigue, morale problems, inventory accuracy issues, over/short shipments, unrealized expectations, "concerned" customer phone calls, loss of customer satisfaction, and ultimately loss of the customer.

The main source of many of the problems leading to the "death march" was the system features that were NOT available in the company's WMS. It's important to explore these missing features because:

1) They are commonly missing in most of the less-expensive WMS packages
2) The list is much longer than simply "not having RF"

Experience has taught me that presenting a simple list is not enough. To truly appreciate the headaches these missing features will cause, warehousing companies need to understand the variety and complexity of inter-related problems that will surely arise in their operations as a result of attempting to serve a complex business model with a "feature-poor" system.

Problem #1: No Zone Picking Support

The startup receiving activity went smoothly at first. Problems didn't really materialize until orders started flowing in. Because of the size of the orders and the number of SKUs involved, this account should have been zone picked, but the company's WMS didn't support this picking method. Instead the warehouse associates attempted to manually "zone pick" by physically dividing the paper picklists (1 page per picker) across multiple pickers.

Unfortunately, this approach didn't work. Many of the orders didn't have enough lines to enable a multiple-picker split. For the orders that were big enough to split, the management team soon discovered this practice generated more problems downstream when picking was complete. The system's inability to direct staging and load checking created immense confusion for the pickers, quality control (QC) checkers, and for loaders.

Problem #2 - No RF Staging / Locating Capability

RF staging and locating capabilities are WMS features that direct pickers to stage picked loads in a specific location, direct QC checkers to those loads for auditing, and ultimately direct loaders to the product to enable them to load and ship. Because the company's WMS didn't have staging functionality, the pickers who had been given individual order pages had no idea where on the dock the other pickers had put the other loads for that order. With no direction, the pickers simply dropped their pallets randomly. The lack of locating capability hurt both QC checkers and the loaders, who were commonly forced to scramble around trying to find at least a few pallets associated with every order. This manual searching process wasted labor, tied up dock doors, and jeopardized shipping windows.

Problem #3: No System-Directed Checking

System-directed checking is a WMS feature that directs QC checkers' activity; tracks order detail lines relative to their "checked" status; and tracks where everything is located. As described above, lack of RF staging created a situation in which outbound pallets associated with different pages of an order would show up on the dock at different times and in different places. As a result, the QC Checkers didn't know what portion of the order a given pallet related to. Since the system didn't support system-directed checking, the checkers were forced to flip back and forth across the manifest trying to manually check things off. Naturally, items were missed, counted incorrectly, and frequently over- or under-shipped.

On a personal note, I find I have the same problem when the home delivery grocery service drops off my order which sometimes exceeds 150 items spread across 4 or 5 totes; it's really not easy to find everything, and it certainly isn't an efficient process. When pressed for time, I usually just check as many items as I can in five minutes and then let the delivery driver go.

Problem #4: No Automatic Skipping of Short Picks Waiting on Replenishment

Unable to beat these problems, the management team decided to switch from the manual zone picking approach and instead gave each picker an entire order to pick. This practice created its own suite of problems that caused the death march to continue.

For all its faults, the manual zone picking approach had the side benefit of distributing workload, staff, and inventory demand throughout the facility. In the "whole order" model, multiple orders were being picked at the same time, and most of these orders required the same popular items. This simultaneous demand didn't exist when they were trying to zone pick. As a result, there was a huge surge in demand for popular items at the start of each shift. The first few pickers to get to a popular pick face would typically clean out the inventory, so the next group of pickers would discover the location as being short.

When this happened a picker would have to make a decision: 1) should they stop picking the order and get inventory control to look for additional inventory to fill the order from some other location; or 2) should they just assume that someone else had gotten there earlier and that a replenishment had been already ordered and was coming, so they could pick the remaining lines on the order, and come back to that item once they finished picking the balance of the order.

Unfortunately, there was no way to know for sure, so pickers would usually stop picking and stage the pallet in a short order area for inventory control to research. This action resulted in a huge amount of inventory control work. This site had three times the number of inventory control staff that a comparable facility would typically require.

Of course none of this would have happened if the WMS supported two critical functions: 1) RF picking; and 2) a "skip" function, to direct pickers around a pick face if that pick face doesn't have enough inventory to satisfy the order. These are not common features, however, associated with the less expensive packages.

Problem #5 - No Real Time / Hot Replenishment Functionality

The situation above then raises a key question- why were the replens not completed before the picker got to the pick face? One reason is that in a paper-based, high-SKU environment, replenishers have no way to know what pick faces are empty and hence should get first priority. Second, replenishers are given no warning of what pick faces are about to be cleaned out, so they have no opportunity to expedite these as "high priority" replenishments, topping off those pick-faces before they actually run out.

Robust WMS' applications support system-directed RF task management. This functionality is used to tell replenishers what task to perform next. Under RF direction, replenishers do not work off of a paper pick list at their own discretion. Rather, the system communicates directly to the replenisher those pick faces that are about to run out of stock-he or she doesn't have to drive around looking for them. These systems will also generate a replenishment task before the inventory in a pick face runs out, thereby eliminating stockouts (or at least reducing their duration). To ensure the most important inventory is replenished first, the task manager will prioritize the replenishment tasks for empty pick faces before those that still have some stock. All of these features rolled together are known as "real-time" or "hot" replenishment.

These features can save significant amounts of picking and stocking labor. In addition, they help improve fill completion and, by extension, customer satisfaction.

Problem #6 - No Real-Time Lot Substitution During Picking

Even if this warehouse had all the features discussed previously, it would still have had one major problem remaining-adjusting orders to reflect what lot was actually picked. This account's product was lot tracked, and when orders were shipped, the bill of lading had to document what lot was being sent. However, consignees didn't demand a specific lot. They just wanted the bill to reflect the lot number that was actually picked.

The system used on this account, like many non-RF based systems, facilitated this need by allocating inventory to orders in a strict lot fashion. This meant that when the system allocated inventory to an order, it allocated a specific lot in a specific location. The picker was forced to pick that specific lot to satisfy the order despite the fact that the consignee didn't care what lot they got.

This allocation approach meant that, if a picker wanted to pick a different lot, they were forced to turn the order over to an inventory control clerk before the order could be shipped. The inventory control clerk had to subtract the original line from the order and add a line that reflected the lot that was actually picked.

This shuffling of lots from order to order is a lot of work, i.e. telling the system that a lot of inventory that was supposed to be picked for one order is actually being used to fill a different order. Unfortunately, in environments where a warehouse is forced to replenish a pick face to satisfy a given set of orders, the shuffle becomes necessary if the system doesn't support automatic lot substitution. Since this isn't really intuitive, an example is necessary:

Imagine 4 pickers in a warehouse using a paper-based system. All of these pickers need the same item out of a pick face. The first picker gets there and needs 20 cases of Lot 1, but there are only 10 cases, so the picker takes 10 and goes on to his next pick with the idea he will come back to pick up the 10 missing cases later. The next picker needs 30 cases of Lot 1. Since there is no inventory of this item in the pick face, the picker skips it and goes on to his next pick location-believing (as did the first picker) that he will just come back and get the merchandise once the pick face is replenished.

In between the 2nd and 3rd pickers, the replenishment of Lot 1 now arrives in the pick face. The third picker now shows up to pick 30 cases of Lot 2. Picker 3 needs Lot 2 because when the system did the allocation there was only 1 pallet worth of Lot 1. This picker picks the 30 cases of Lot 1 and turns his pallet over to inventory control to adjust his order accordingly. When this happens, he or she forces the other pickers to have their orders adjusted as well. This cascading inventory inaccuracy can flood an inventory control desk, as it did at this particular warehouse.

Conclusion

You need more than RF to work complex, high-volume accounts. You need functionality that is dependent upon RF, but not necessarily inherent in all RF based systems. This is an important point to recognize now that some of the lesser expensive packages have begun to offer RF. If you are going to chase pick/pack or high-volume case pick accounts you need to ensure that the system you purchase includes the sophisticated logic and feature suite that makes RF so valuable. Bolting RF onto the side of a less-sophisticated system saves key entry and at some level tracks the whereabouts of product in your facility, but is not sufficient to support a complex operation.
About the Author:

Steve Mulaik is a partner in TPG's Logistics Systems Practice. Steve's career has been spent designing and implementing Inventory management, Warehouse management, and Transportation planning systems in a variety of industries. Before joining The Progress Group in 1996, Steve was Vice President of Information Systems at RaceTrac Petroleum, a $1 billion convenience store chain, and prior to that he spent 6 years in the Big 6 as a consultant to retail and manufacturing firms. Recently Steve has begun to focus on the systems needed to support the growing third party logistics marketplace, and he has spoken at a variety of conferences on this subject and other topics related to warehousing systems.

Home • About Us • Services • Clients • Publications • Contact Us