If you are evaluating warehouse software solutions and returns functionality is a key value driver for savings through the use of a new application, be prepared to be disappointed. Most warehouse software providers do not provide a dedicated returns module capable of supporting serious returns functionality capable of efficiently processing between 15-30% volume compared to outbound sales. Distributors to large retailers who contractually can return any product they purchase free of penalty OR retailers who face season product rotation know this all too well.

Attempting to sell a generic receiving module as a viable option to adapt to these high volume returns needs is not practical for many reasons as a detailed review of the differences between receiving and returns will show:

1. Terminology.
* Receiving is processed against a purchase order while returns are processed against return authorizations.
* Receipt processing generally involves unitizing items to a standard pallet ti and hi while returns are checked in and examined at the piece level.
* Receipts are generally brought in under an inventory status, while returns are processed by cost accounting disposition code.

2. Supporting Operational Process
* Receipts generally require the following process from the time the supplier trailer arrives: 1) Validate PO/SKU/Quantity 2) Unitize cases into standard pallet ti/hi 3) Sample cases are inspected for quality control/vendor scorecarding 4) Pallets are located into inventory using configured business rules 5) HOST application is updated with inventory/PO changes.
* Returns generally require the following process from the time the inbound carrier arrives: 1) Cartons are counted and validated against RMA/RA 2) Cartons are opened and each item identified 3) Items can be validated against a corresponding sales order or customer 4) Items are visually inspected for cost accounting disposition 5) Re-salable items are initially sorted into totes awaiting full case consolidation 6) Consolidated full cases are located into inventory 7) HOST system integration determines customer credit amount.

3. Supporting Warehouse Staff
* Receiving will require resources dedicated to unloading/unitizing, counting/verification, and locating per inbound trailer, with an option for a single resource to completely process an advanced shipping notice receipt.
* Returns will require a single resource dedicated to case-level check-in, and multiple resources, dedicated to a terminal processing station for piece level disposition processing.

The clear diversity of required data elements, supporting operational processes, and required resource staff between standard receiving and returns processing highlighted above cannot be realistically supported by the same series of software processing screens. If returns is a process that can be improved through value-driven processes, take the time required to ensure that you are not solving a returns issue with a receiving solution.

Are you in the middle of a software evaluation and thinking,

"What is the probability that the vendor(s) we are considering will be acquired?"

"If the software vendor is acquired, will the solution we select still exist?"

Three to five years ago, vendor consolidation in the supply chain execution space was rampant with most acquired solutions being phased out in place of the vendor's flagship solution.

Today, the supply chain execution space if very mature and established with recent acquisitions focused on adding complimentary solutions, not eliminating competitors. Manhattan has acquired Logistics.com and Avant while HighJump Software has acquired Pinnacle Transportation.

Rumors of vendor consolidation amongst the main solution providers (Manhattan, HighJump, and RedPrairie) are generally rampant around the end of the quarter, when companies are making key buying decisions, and losing vendors may be tempted to spread fear, uncertainty and doubt (FUD) about one of their competitors.

The reality that one of these main vendors would acquire one another doesn't make sense for several reasons:
1. Two of the three vendors are owned by venture capital/inventment firms that are most likely waiting for the appropriate time to issue an IPO. These entities could add a competing vendor into their portfolio of solutions, but most likely not consolidate the organizations together.
2. These vendors are not niche players by geography, industry segmentation, or technology platform. Customers will generally evaluate two of the three at a minimum during their evaluation and the idea of now having to work with a solution provider that you didn't originally select will be a tough pill to swallow, especially when the acquiring vendor will want you to either renew your maintenance or convert to their flagship solution.
3. Each of these vendors has a full suite of solutions in their portfolio, thus making the holistic acquisition that much more challenging and costly for the acquiring vendor.

What is still a likely scenario is the prospect of an enterprise software vendor adding one of these solutions to its suite of software solutions:
1. INFOR has many software solutions for ERP, WMS, and TMS modeling and while they have released a 2008 version of a consolidated WMS solution between recent acquisitions of EXE and Provia, adding one of the top three vendor soluitons could happen, especially to take advantage of missing solution components like labor management, slotting, or third party billing.
2. SAP and Oracle have a suite of WMS solutions in place, but in recent evaluations, they still lack the advanced functionality that these top three best of breed providers offer; an acquisition could help solve this.
3. What about Microsoft? Their Dynamics solution is actively competing with SAP and Oracle as a HOST and Manufacturing application, but they have no supply chain execution suite to speak of. An acquisition of one of the top best of breed providers developed in a Sequel Server database and Microsoft platform could be a nice compliment.

One of the approaches enVista helps customers review during any type of supply chain initiative is to review your current operation for increased efficiency. Supply chain projects are the ideal time to examine non-valued added steps as well as possibly address the cliché question, “Why does our organization do it this way?”. Studies have shown that companies who automate bad processes actually increase their cost of operating largely due to two factors: 1) automating a process with technology that enforces checks and balances will most likely add steps to your process in order to capture data points or perform validation checks within a process that already has more steps than it needs. 2) adapting a solution to meet a company’s inefficient process most likely leads to customization and modification of the technology, again leading to additional implementation and support costs.

Part of the reason operational process changes are not implemented as part of a supply chain initiative is that most software vendors identify these tasks as “client-side” services, left to the initiation and discretion of the customer to execute, not the software vendor. Accordingly, most vendors will help support the configuration and setup of any customer supply chain, even those that are sub-optimal, with the guarantee that the software will work as defined and configured. Unfortunately, the uneducated customer who has not implemented these systems before can be easily mislead that the software by itself will act as a panacea to current operational challenges.

Case in point, I visited an electronics manufacturer and distributor who was eight weeks into an implementation of a new tier-1 warehouse software application. The customer asked that enVista help review their current product slotting because they were consistently short shipping orders because the required items were not available in the designated primary location, in this case level one racks. The customer sited that they could not complete and execute replenishment tasks in time for picking to be executed, so clearly they did not have items located in close proximity to their associated level one primary location. I watched one of the company’s top workers execute a typical replenishment transaction, which averaged fifteen (15) minutes to complete (4 replenishments per hour compared to an industry best practice of 10 per hour). The replenishment worker was spending significant time letting down multiple partial pallets of the same item from a reserve location and manually consolidating this into a single replenishment pallet. I could understand during the first week of implementation where the warehouse system would try and flush out excessive “honeycombing” (i.e. storing multiple partial pallets of the same item in many reserve locations caused by pickers randomly allocating product from the “closest” location to them, not necessarily the oldest), but not after eight weeks. I went back to review the receiving process and the locating rules associated with new item receipts; almost every container shipment resulted in a single partial pallet remaining after unitizing the product on the receiving dock. Accordingly, in following the company’s original process, all pallets received, including both full and partial, were first located to an empty location rather than trying to consolidate like product together (NOTE: this product is not date sensitive) – the software system emulated exactly the original process the company had before, but the process was not efficient and was causing significant challenges downstream.

One solution for the customer is to focus on better processes up front during receiving and put-away to help create increased throughput and order fulfillment downstream. No question that slotting would also help the client, but a thorough examination of all their processes was immediate; then the software could be configured to support these efficient processes as opposed to “better sameness”.