Are you one of the companies still running the warehouse on the host system inventory module or on an outdated locator system - or even tracking materials on a spreadsheet? There's no need to raise your hand here in public, but you know who you are - and you know it is well past time to enter the 21st century and move up to what it requires to remain competitive in the marketplace. Your customers and supply chain partners probably know you need to do it, too.
To help you get there, let's review the most common mistakes made in WMS implementations.
Whether you choose to upgrade an existing system, add or activate a new module in your ERP system, or go with a best-in-class, stand-alone warehouse management system (WMS), you stand to gain great benefits, and they are generally easy to justify and to realize if you do the project correctly. The key is full-time project management and support not only for selecting a system, but for implementing it and training your people, too. It is true regardless of whether you will be implementing a basic locator system, a mid-tier WMS, or a Tier One WMS with all the bells and whistles to help you get every last ounce of wasted labor out of your operation.
No matter how simple you think your demands on a WMS must be, there is no off-the-shelf package that does not require some degree of customization. If the software cannot be customized to your operation, then your operation will have to be customized to work within the parameters of the software.
Solution: Focus your vendor selection on providers who know the industry and with system capabilities that match your operational requirements. This can be done by leveraging outside expertise, and it will minimize customization. Also, if you are willing to invest the capital and time to do the preliminary design with the selected vendor, you can minimize lost time later in the process. It's important to remember, too, that even after you select a vendor, the time to hammer out a contract usually drags out as it passes through legal departments. The bigger your operation and the more expensive the system, the longer this takes.
If your schedule turns out to be unrealistic, adjust it as soon as possible and spread the news as soon as possible to the entire project team. The faster everyone can adjust, the lower the temptation to expedite the system development at a higher cost or to sacrifice functionality in order to get it done quicker
The simple truth is, if you buy low-end software, you get low-end functionality. Software bargains simply do not exist. Any system will require some level of modification to properly fit your operations' requirements, and this adds to the price. Although software today is more driven by user-configurable system parameters, those only affect standard operations. Deviations from the standard set-up still require modification.
Solution: Carefully identify your operational requirements and prioritize them both by the financial benefits and the by the qualitative benefits to customer service and accuracy. Then determine the level of system you can afford.
It is a terrible thing to take advantage of a customer's trust, but the simple truth is that software providers historically have been able to sell more systems than they can develop during any reasonable time frame. The old saying is that the squeaky wheel gets the grease. If you or your consultant are not monitoring your system developer closely, another system may be getting the grease.
Solution: Assign a full-time project manager who understands both the technology and the project goals to monitor the system developer and to establish milestone tests. This will generally draw delays and problems to the surface, where they can be dealt with easily and sooner rather than later.
Assuming that the system will work as designed the day you start it up and ignoring all the possible negative outcomes is a common and costly error.
Solution: Make sure you allow for the system to ramp up. Do not expect it to be 100 percent efficient on day one. Develop a contingency plan before start-up to account for not only a total system failure, but for specific, critical functional areas to go down. Simple contingency plans include creating back-up electronic copies of all downloaded files, backing up the system before start-up and creating a stable recovery start point. New systems actually tend to hurt productivity in the first month of operation and then begin the climb to meet promised efficiency over the next several months. Training and productivity measurement are a key to making this happen as quickly as possible.
The natural tendency of the system design team is to promote all the results that a fully de-bugged system will provide—eventually. The amount of work required to adapt to new procedures and to be directed by a computer and the number of irritating minor bugs that plague most system start-ups are somehow lost in the sales pitch.
Solution: Everyday users must be trained in the daily operating environment, about the changes that will take place, and on the reality of system start-up problems. Daily users will make or break a system installation. Spend as much time selling the daily users on their input and winning their cooperation during the debugging stage as you do convincing them how the system will improve their jobs. Let them take ownership of the system, and they will strive to make it succeed.
Too many companies believe the software vendors' pitch that anyone can learn the system in 15 minutes, and they fail to make training part of the implementation plan.
Solution: 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 their comfort level and their functional understanding of the changes that await them. During final testing and start-up, users must be tested on their WMS operational knowledge, and those who need it must get the appropriate re-training. Generally, the best people to provide this training are other internal users, outside parties, or vendor training personnel who are not programmers.
The easiest way to condemn your WMS to a certain and spectacular failure is to provide the software vendor with faulty or incomplete data or to fail to update product characteristic data at all.
Solution: Producing clean and accurate data is the responsibility of the user, not the developer. A great WMS will produce lousy results if poor data was put into the system. Devote the proper attention to collecting and updating all product characteristic data, all product pack-size dimensions and the starting inventory locations 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 an operation. In reality, improving only the information flow gives a high probability that the operation will not even approach the promised improvements—and it may even lose efficiency. Then whoever championed the WMS will be updating his or her resume.
Solution: During the initial definition of the WMS functional requirements, document what you should be doing rather than what you are doing now. You must keep in mind the best practices for your industry and strive to achieve them. To realize the awesome potential power of change, you must first be cognizant of what is available. There are two ways to go about it: 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 ongoing critical adjustments before the payload reaches a stable orbit. And when something goes wrong, it can go very wrong. What does that have to do with pointing fingers? Finger-pointing is a normal reaction if expectations are not met - regardless of whether the expectations were naïve. What governs is 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, and that the WMS provider is incompetent.
Solution: During a WMS start-up, there are lots of adjustment to make in order to achieve full functionality. They take time, patience, faith and skill. If it looks like things are going wrong, stay calm. Work with the software provider and consultants to identify the true problem, then to find its cause. Once the problem has been defined, examine the extent of the damage to data and correct it. (If you made the appropriate contingency plan (solution No. 4) this will not be a problem). Do not assign blame; assume responsibility for success.
Find out more about the right WMS by downloading the brochure here.