Page 1 of 9

•

........................................................................................................................................................ 3

...................................................................................................................................................................... 4

................................................................................................................................................. 4

..................................................................................................................................... 5

.............................................................................................................................................................. 5

...................................................................................................................... 6

.............................................................................................................................................. 6

..................................................................................................................................................... 6

......................................................................................................................................................................... 7

.............................................................................................................................. 7

........................................................................................................................................................................................ 7

..................................................................................................................................... 8

..................................................................................................................................................................... 8

.................................................................................................................... 8

................................................................................................................................................................................ 9

•

Numerous companies have enjoyed the benefits of using a real-time Warehouse Management Software (WMS) system. When

properly deployed, this technology can enable companies to reduce labor costs, improve accuracy, and greatly increase visibility of

inventory and workflow.

While there are significant benefits to using WMS systems, there are numerous accounts of troubled, even failed implementations.

Many companies have gone into a WMS implementation highly confident – perhaps because they have already successfully deployed

ERP and other major software systems in the past. Even these companies at times have fought mightily to get their WMS systems up

and running.

This begs the question: Why is WMS so challenging to deploy compared to other business software systems?

Commonwealth has identified several key reasons for these challenges:

Lack of true “standardization”: In the front office, processes in widely different businesses can often be executed in

remarkably similar fashion (HR, Accounts Payable, Accounts Receivable, etc.) However, the business commonality often

ends in the distribution center. Even amongst relatively similar businesses, different SKUs, different handling characteristics,

different retail compliance requirements, and different sales channels can create a wide disparity of processes in the

distribution center. As a result, WMS systems are able to use fewer “off-the-shelf” features than other systems, and often

require customization. Custom modifications can be “buggy” and prone to failure during go-live.

Exceptions to the rule: This same process complexity often leads to numerous exceptions and workarounds to the normal

rules in the warehouse. These work-arounds often go undocumented and are not discussed at the time the software is

configured. Sometimes, the work-arounds only come to light during go-live, and require rapid code-writing on the fly to

accommodate.

Fewer business-savvy users: Warehouse workers often have less familiarity with business process transformation, and less

experience with new technology than do their counterparts in the front office. This generally contributes to a “culture shock”

once a new software system is put in place.

Material handling equipment: WMS systems often interface with conveyors, printers, scales, and other devices. These

interfaces are usually custom-written, and can be problematic if not tested properly.

Simultaneous active transaction volume: This is perhaps the single biggest factor which can be overlooked when

comparing WMS to ERP implementations. Many times a company has far more distribution center workers than front office

workers. Each warehouse worker may be processing multiple transactions per minute on mobile devices. Workers are also

spread out across a large area rather than being clustered together in cubicles. As a result, during go-live, the sheer volume of

activity can be problematic. If multiple workers encounter even minor problems at the same time, it is difficult to rapidly

resolve them without falling behind in the day’s work.

•

All of these factors can contribute to a higher risk of sub-optimal implementations with WMS than with other systems. These

problematic go-lives can create numerous business issues including:

Cost overruns

Implementation delays

Configuration or interface errors

Training problems

Inability to ship product at go-live

Gross inventory inaccuracies at go-live

Difficult and expensive future system upgrades

Commonwealth has defined six key areas which companies must give attention to in order to properly mitigate the risk of a

troublesome – or failed – WMS implementation:

Proper alignment in expectations between the purchasing company and the software vendor is vital for a successful implementation.

This alignment really begins in the vendor selection phase. Commonwealth recommends that companies document their business

process requirements at a very granular level before even signing a contract with a software provider. This Business Process Review is

best done using a spreadsheet matrix which allows for line-by-line, step-by-step auditing. All desired processes should be listed, along

with all exceptions to the rule.

Next, each operation process “owner” should audit the Business Process Review and approve or reject it on a line-by-line, process-by-

process level. This is often the best way to ensure that manual work-arounds that currently exist get identified and accounted for in the

new system.

Once the company’s operations staff have fully reviewed and approved the Business Process Review, then the same spreadsheet

matrix should be sent to each WMS vendor who is bidding on the project. These vendors then review each process description on a

line-by-line, process-by-process level. Vendors indicate whether or not their software can accommodate the required functionality, and

highlight areas where customization is required.

Once a vendor has been selected, this Business Process Review matrix becomes a part of the contract with that vendor. The vendor

will typically create an additional “functional specification” document which is produced in their own unique format and describes

how their software will work at the keystroke-level. It is crucial that this Functional Specification be audited against the Business

Process Review to ensure conformity. Any deviations from the original plan must be highlighted and discussed.

By following this process, companies can help ensure that all of the desired functionality is built into the WMS software, and reduce

the instances of costly change-orders after a contract is signed.

•

Some best practices in WMS testing include:

Have enough scripts: It is common for companies to use over 1,000 distinct test scripts (a specific transaction which is to be

tested with specific data elements) in a WMS implementation.

Scripts must address (A) Normal functionality, (B) Exceptions, and (C) User Errors. Items B and C tend to be overlooked,

and can be the most problematic during an implementation.

Expect failure: It is common for the first WMS software “build” to have numerous errors and to “fail” at 30% or more of the

scripts.

Be thorough: It is vital that a company develop a large number of test scripts, and ensure that they are thorough and

complete. These test scripts must be based on actual, final functionality which is required.

Document and verify: Each script should be tested, and a representative from the Operations Group should participate to

ensure that the script “passes” the test.

Some tried-and-true suggestions for WMS training include the following:

Plan for cultural change: A company may be transitioning from a very manual environment to a very automated one. This

will require a completely different method of operating from what is done today.

Train enough people: EVERY warehouse worker who will be touching or moving product from one virtual location to

another must be trained in the proper use of the system.

Don’t bypass the system: EVERY time a product is moved, a transaction must be recorded in the WMS. In the current,

manual environment, when unexpected events occur, warehouse workers have developed various responses and “work-

around” procedures to ensure that product still ships as expected. In the new environment, with the WMS, any unexpected

events must be responded to WITHIN THE WMS. Manual “short-cuts” or “work-arounds” will not be possible, and will

have a negative impact on the operation. All of these manual work-arounds must be addressed in a functional specification

prior to go-live. They must be thoroughly tested. Staff must be trained on every work-around and must demonstrate

proficiency.

Companies should train three levels of workers:

1. Super Users: There will be 3 – 6 super-users typically. Each super-user must have the ability to access every area of

the WMS and perform any operation to correct errors and ensure that the WMS is up and running every day.

2. Troubleshooters: A company should have at least one (1) Troubleshooter for every ten-to-fifteen (10-15) users of the

system (and more if possible). Troubleshooters should be highly experienced workers who are very familiar with at

least one aspect of the system (receiving, put-away, picking, etc.). These Troubleshooters should be clearly identified

and should be the individuals who the General Users will consult with if they experience problems or have questions

during the go-live. No matter how thorough the training is, users will inevitably have a number of questions that will

arise during go-live. The Troubleshooters’ job is to address these questions quickly to keep the operation running.

3. General Users: These are the warehouse workers who will be using the system. As noted previously, any workers

who will be handling or moving product from one virtual location to another should be trained on the use of the

system. General users should be tested on their knowledge of the system on a pass/fail basis.

•

Prior to going live, a company must conduct a thorough readiness assessment. Companies should be prepared to delay the go-live if

for any reason it is believed that the company is not ready to begin using the software.

The readiness assessment should cover many points, including:

System readiness: Have all of the functionality points been tested and passed?

Interface readiness: Are the WMS and ERP systems exchanging data as required?

Visibility and Reporting: Does the company have FULL visibility, via reports, of the status of every order? Can the

company easily view demand and match it up to available supply? Can the company quickly view any orders which cannot

be filled due to lack of inventory availability and cross reference this with status of inventory in the DC?

Training: Do the super-users truly “own” and understand the software? Are they capable of performing complex operations

in the WMS? Are there enough Troubleshooters in place? Are they properly trained? Are the General users properly trained?

Does the staff know how to react when things don’t go according to plan?

Data Conversion: Has all of the required data been properly converted and tested for completeness?

Inventory Condition: Does the company believe that the current inventory record is highly accurate? Is there sufficient open

space in the DC for each SKU to reside in a designated bin location? Are there excessive amounts of product in non-bin/floor

locations?

During go-live, companies must give diligent attention to two types of issues which will arise:

These are problems which are caused by operator error, and not an inherent problem with the

software. Thorough training ahead of time can mitigate some of this risk, but not eliminate it.

Having a large number of well-trained trouble-shooters is one of the best ways to manage

operator errors at go-Live. A few key principles which will help this process are:

General Users must know who the Troubleshooters are, and must be encouraged to

seek their help when unexpected things occur - not try to work-around the problem.

Troubleshooters must be good communicators and able to quickly rectify problems.

Troubleshooters must know when a problem is NOT an operator error but is actually a

bug in the system, and must quickly escalate these to a Project Manager.

•

Software bugs can occur on even the most mature software systems with a large amount of testing. It is normal for at least SOME

bugs to occur during any WMS go-live. Companies implementing a WMS must be prepared to address them in the following ways:

Designate at least one “Project Manager” whose sole job is to track bugs and their resolution path. Project Managers should

NOT be floor-level Troubleshooters, and they should NOT be the individuals who are tasked with “fixing” the bugs. The

Project Manager’s time is spent in the office, reviewing reports of bugs from the Troubleshooters and keeping everyone

organized.

Troubleshooters should follow this basic path when bugs arise:

o Log each bug on the Tracking Tool and assign a number

o Document the nature of the bug

o Determine the operational impact of the bug

o Assign a priority level to fixing the bug

o Assign a resource to fix the bug

o Track the implications: track each sales orders which may be held-up due to this bug, track inventory which may be

due to this bug, etc.

During go-live, daily meetings should be held with the entire implementation team to review the status of bugs and ensure

that fixes are being implemented in a timely fashion.

Every WMS implementation initially results in short-term a loss of productivity – sometimes a serious one. Some reasons for this

include:

Workers must begin tracking all of their actions with bar-code scans. This initially takes longer than simply reading pieces of

paper.

Workers will have a general lack of familiarity with the system which will impact productivity negatively.

Operator errors and software bugs will slow down productivity

Companies should PLAN for this productivity drop by either scheduling the go-live at a slower time of the year or adding extra staff

for the initial implementation period.

There are many other steps which companies can take to ensure a successful go-live. For instance, if it is possible to operate in parallel

with the current system for a time, this is a good way to mitigate some of the risk of a failed implementation.

Additionally, the company’s executives should avoid imposing an absolute deadline on the operation to go-live with the new WMS. A

company should not bring unnecessary risk on themselves by rushing the WMS implementation process. If the Readiness Assessment

reveals that the company is not ready, then the implementation should not go forward.

These cautionary tips should not in any way discourage a company from implementing a WMS system. WMS, when implemented

properly, can help transform an operation and greatly improve profitability. Companies considering these changes should do so with a

solid plan in place, and not be over-confident because they have successfully executed other complex software projects in the past.

As in most areas of business, proper planning prevents poor performance!

•

Report: An Objective Guide to Selecting a WMS

Presentation: Improving Warehouse Productivity without Tier 1 Technology

Blog Article: Do I really Need a Tier 1 WMS?

Commonwealth Supply Chain Advisors does not sell Warehouse Management Software, and is not affiliated in any way with software

developers. Commonwealth’s role is to assist companies with selecting, and implementing WMS successfully. We provide companies

with the tools, templates and guidance to make the process of going live with WMS painless and well-organized.

The Commonwealth Seven Step WMS Implementation process is:

Please feel free to contact Commonwealth if this service would be of value to your company at this time! Contact Us.

•

Ian Hobkirk is the founder and Managing Director of Commonwealth Supply Chain Advisors. Over

his 18-year career, he has helped hundreds of companies reduce their distribution labor costs, improve

space utilization, and meet their customer service objectives. He has formed supply chain consulting

organizations for two different systems integration firms, and managed the supply chain execution

practice at The AberdeenGroup, a leading technology analyst firm. His career has provided him with

a broad perspective on how to solve supply chain problems without automatically resorting to

expensive technology. Mr. Hobkirk has authored dozens of white papers on supply chain topics, and

his opinions have been featured in publications such as DC Velocity, Modern Materials Handling,

and The Journal of Commerce.

His company, Commonwealth Supply Chain Advisors is a completely independent consulting firm that does not sell technology

solutions.