Top 10 mistakes when implementing a Warehouse Management System (WMS)

Are your customers complaining about orders being late and always wrong?

Do your sales representatives sell products you do not have or cannot find?

Is your inventory about as accurate as your checkbook?

Are vendors telling you how easy it is to enter the electronic age?

When are you planning on implementing your computerized warehouse management system?

In the ever changing and demanding marketplace, we must automate the movement of information both internally and externally to compete and ultimately to survive and prosper.

The jump from 1950s technology to 21st century requirements is unavoidable for everyone from Fortune 500 companies down to start-up operations.

Yet few of us have the skills and experience to successfully implement the required technology associated with a warehouse management system (WMS).

We have all read the articles and books, listened to the software providers, and attended the seminars but the reality of the situation is that if you have not been there you will make the same mistakes everyone makes the first time.

So to make your system installation run smoother let’s review the 10 most common mistakes made when implementing a WMS.

No matter how simple or complex the WMS you require may be, there is not an off-the- shelf package that doesn’t require some degree of customization. If the chosen software cannot be easily customized to your operation then your operation will have to be customized to work within the parameters of the software.

Solution:

Conduct a thorough screening of all possible vendors to match industry experience and system capabilities with your operational requirements. This will minimize customization.

Generally once a vendor is selected the time to hammer out a contract drags out as it passes through legal departments. The bigger your operation and more expensive the system the longer the process is.

If you are willing to invest capital to complete the preliminary design with a vendor you can minimize customization time. If an unrealistic schedule is set you should adjust the schedule and spread the bad news as soon as possible to the project team.

This action will eliminate the temptation to expedite the system development at a higher cost and sacrifice functionality.

When buying a WMS the simple truth is that you get what you pay for. Software bargains simply do not exist in the real world. Any system purchased will require modification to properly fit your operation’s individual requirements.

Solution:

Carefully identify your operational requirements and prioritize them both by the financial and qualitative benefits required to improve customer service and accuracy. Then determine the level of system you can afford before selecting the WMS for your operation.

Trust is a terrible thing to take advantage of, but the simple truth is that historically software providers have been able to sell more systems than they can develop during any reasonable time frame. Make sure that your system gets what it needs.

Solution:

Assign a project manager who understands both computer systems and the project goals to monitor the system developer and to establish milestones on the system’s progress.

This will generally draw potential delays and problems to the surface where they can be dealt with easily.

Assuming that the system will work as designed at start-up and ignoring all the possible negative outcomes is a common and costly error.

Solution:

Develop a contingency plan to account for not only the total failure of the system but also for specific critical functional areas. These must be identified and addressed before starting the WMS.

Simple contingency plans include creating backup electronic copies of all downloaded files, backing up the system before start-up, and creating a stable recovery point.

The natural tendency of the system design team is to promote the benefits a system will provide to the users and then proclaim to the organization the results a fully debugged system will provide.

The amount of work required to adapt to new procedures and to eliminate minor bugs that plague most systems is somehow lost in the sales pitch.

Solution:

Everyday users must be trained in the daily operating environment. Selling the benefits should include focusing on the changes what will take place and on the reality of system start-up problems.

The daily users will make or break a system installation. Spend as much time selling the daily users on the need for their input and cooperation during the debugging stage as on the benefits to their jobs.

Let them take ownership of the system and they will strive to make it successful.

Competency-based training for all system users is critical for system success. Employees should be given system exposure and training before system start-up to build both a comfort level and a functional understanding of the changes that await them.

Solution:

During system final testing and start-up, users must be tested on their WMS operational knowledge and given the appropriate re-training to improve their use of the WMS.

This training is generally best provided by other internal users, outside parties, or vendor training personnel who are not programmers.

The easiest way to condemn your WMS to a certain and glorious failure is to provide the software vendor with faulty or incomplete data or fail to update product characteristic data at all.

Producing clean and accurate data is the responsibility of the user, not the developer. A great WMS will produce lousy results by inputting poor data into the system.

Solution:

To avoid this problem, devote the proper attention to collecting and updating all product characteristic data, all product pack size dimensions, and having accurate inventory by location of all products.

There is a common misconception that installing a WMS to improve information flow, entry, and tracking will eliminate all the inefficiencies within the operation.

In reality, by only improving the information flow there is a high probability that the operation as a whole will lose efficiency or fail to even begin to approach the promised improvements.

Solution:

During the initial definition of the WMS functional requirements, rather than document what you do now, document what you should be doing. This sounds simple but to realize the potential power of change you must first know what is available.

To accomplish this goal there are two choices: Educate your organization through seminars, vendor- arranged site visits, and lots of reading, or utilize the expertise of a consultant to stimulate the process.

A WMS start-up is like a rocket launch: even when it goes right there are initial and critical adjustments that must be made to reach a stable orbit and when it goes wrong there are a lot of pieces to clean up.

So what does this have to do with pointing fingers? Simple.

During the initial start-up of a WMS there are lots of adjustment to make to achieve full functionality. This takes time, patience, faith, and skill.

The common reflex reaction, brought on by the fear that orders will be lost or delayed, that the company has just flushed a whole lot of money down the drain on your recommendation or that the WMS provider is incompetent, are normal.

Irrationally responding to these fears will only bring equally irrational and uncooperative responses from the WMS provider.

Solution:

Stay calm. Work with the software provider to identify the true problem and then to find the cause of the problem.

Once the problem has been defined the extent of the damage to data should be examined and corrected (if you have the appropriate contingency plan this will not be a problem).

Then correct the problem whether it be software related, data related, or hardware related. Do not assign blame, only assume responsibility for success.

Why spend the time in designing a system and justifying its benefits if you are not going to confirm the actual results?

One of the biggest failures associated with a WMS is in not verifying that the system is working as efficiently as designed.

The potential payback is enormous for recapturing as little as 10% of unrealized payback on the original design.

Even more beneficial is the payback associated with the improvement on the original design that can be identified only after a WMS has been in operation for several months.

Solution:

Schedule an audit of the WMS between three and six months after start-up by an outside consultant that may or may not have been involved in the system design and implementation.

Have the consultant review your operation, report back the results, and suggest changes to the system.

This audit should take less than a week.

These are just some of the most common mistakes that are made during WMS implementations.

However you must be aware that there are many other pitfalls, potholes, and monsters out there to derail your WMS implementation.

Learn from the mistakes of others and avoid these 10.

Originally published at Flexspace Blog.