Thanks to IT Toolbox for this post:
There are over 1,000 manufacturing systems in North America and yet The Wall Street Journal has stated that “73 % of all manufacturers are dissatisfied with their current ERP systems.”
There are a number of theories why implementations have problems:
– Poor planning or no planning at all
– Top Management not involved or did not commit to the project
– Unreliable data
– Lack of training or implementation assistance
– Poor selection process
– Lost project momentum
– Business processes are not corrected
But the main reason that implementations fail is the legacy selection process commonly used is flawed.
The Budget Approval Dance
The first step in any selection process is expenditure approval. Middle managers spend days defining their selection process plan. The more detailed the budget approval request is, the more detailed the selection plan is, the more due diligence is assumed and therefore perceived risk is lessened. The legacy selection plan usually contains:
– A multiple page, detailed system requirements definition (sent to a short list of vendors for confirmation), and submitted as a Request for Proposal (RFP)
– Multiple, onerous “sales demos” with various systems
– Telephone reference calls on the selected vendor
The middle manager can get so obsessed with budget approval; and, the upper manager can get so consumed in confirming the selection process is sound, that the most important objective in selecting a new system can be overlooked. The most important goal should be to ensure your company is successful with the new system! Any other consideration should be secondary.
Systems Today Are Function-Rich
The more you evaluate systems, the more you recognize that all have an abundance of functionality. The reason they fail is not a lack of information, it is the exact opposite. They are too cumbersome and too difficult to learn.
Then why do we devote our entire search to evaluating which system has the best and/or most functionality? Is it because new systems are purchased only every ten years, therefore, no one individual has the experience to learn from their mistakes?
Let’s review the legacy selection approach described above.
1 – Issue a detailed multi-page novel called the “system requirements list” to all software vendors to fill out (honestly) thereby confirming which match. However software companies want to remain in consideration, and are motivated to answer each question with a carefully worded, “yes we do that!”
2 – The selection team then shoulders the arduous task of reviewing “sales demos” in an attempt to decipher the differences. “Sales demos” are designed to look good. If the “sales demo” did not look good, the software company would go out of business. Software companies hire professional presenters who know precisely which keystrokes will present their software in the best light.
Remember the first day you looked at the system you use now? How difficult did it seem then versus today? How many months did it take before the haze lifted and the system became second nature? Is it possible to recognize the pros and cons of a system you are reviewing for the first time in an 8 hour, “sales demo”?
3 – You now call references to confirm that companies are happy with their systems. Where did you get the references from? Did the software vendor carefully select “bullet-proof” customers that swear the software turns water into wine?
4 – And voila … you have selected the very best system for your company. Or have you?
A Fresh Approach To Selecting ERP Systems
If time is money, then speed is profit. How can we speed up the ERP selection process, yet not fall into the same traps as the majority do, which fail?
The most important factor in selecting a new system is: to make sure your company is successful with the new system. If 73% of manufacturers are not satisfied with their current ERP system and used the same selection process as you, why will yours be different? Maybe a different process should be investigated.
Not to mention that the step-by-step, due diligence process historically used, costs $10,000s of internal resource time.
This 3-Step Plan is only common sense. But best of all, it will take far less time to complete and your results will be guaranteed!
Step 1 – Define the critical requirements that are unique to your company and match to the vendors on your short list. Please note: Critical requirements only. You have to assume that all systems will have an “Aged Trial Balance”. This list should not be longer than two pages. Only continue to step 2 with those that sufficiently match.
Step 2 – Visit a company using the system, preferably one you can drive to, in a similar industry and size as your own. You may not get all criteria matched, but ask. With these demands, it is more difficult for the vendor to select who you visit.
I once heard of a manufacturer who was “paid” to be a positive reference for a software firm, yet they did not even use the software.
A visit is so much better than a phone call that in fact, it can take the place of the “sales demo” entirely.
Step 3 – After the first 2 steps, you should have a favorite system. If you are still not comfortable enough to take the plunge, this final step eliminates any further risk. Ask this vendor to bring in the consultant you will work with after the sale is complete, not the professional presenter. Trainers have to live with their promises after the sale, and will be quite forward about what the system can, or cannot do.
Have the consultant set up the software around your requirements and enter a sub-set of your data. The intention will be to present the system as if it were live at your facility. Offer to pay for this service. Consultants are not offered to prospective clients because existing customers are paying them to implement their projects. This “proof of concept pilot” may cost a few thousand dollars, but will be far less expensive than the time-consuming step-by-step method.
The most important factor in selecting a system is to make sure your company is successful with the new system. This 3-step process will guarantee results. Why would you use any other method?
Remember, if you fail to implement, why do you care what the software does?