One thing I find amusing about the ERP industry is the focus on things that have little to do with project success. An example is ERP software. Sure, software is required to implement ERP, but many organizations and consultants treat software selection as some mysterious science project.
Regardless of how many consultants a client uses to select software, many would have been far better off selecting out of a hat. In fact, for those looking at Tier 1 & 2 vendors, once the short list is down to two packages, does it really matter which one you pick? The truth is either will work fine, and for the additional time and money spent, the organization is simply trading off one set of software issues for another. The point is…history has shown 90% of project failures have nothing to do with ERP software. The other 10% (where software is the culprit) could be avoided with some common sense.
While no one advocates prematurely jumping into a software decision, too much valuable time and money is wasted searching for that “perfect package” (that does not exist) or attempting to mitigate all risk (which is impossible). For example, it is common for organizations to spend twelve months and $350,000 evaluating software, and then insist it is installed in six months or less. Maybe we should spend less time beating software packages to death, and more time redesigning our business processes, managing change and knowledge transfer.
The reality is about 80% of the key inputs that ultimately drive the software decision are known after completion of the RFI process, analysis of independent research (readily available on the Internet), and the “must have” software requirements are demonstrated by the final two vendors. Of course, there are other items to evaluate to close the risk gap, but the law of diminishing returns should not be ignored.
The RFI (read between the lines)
When developed properly, an RFI (with a written vendor response) can provide extremely valuable information about a vendor, package, and help expedite the evaluation process (if one reads between the lines). Any two or three packages making the RFI cut (for further evaluation) should have the following attributes. When two vendors satisfy all items below, the risk associated with the final choice is greatly reduced.
1) The software is installed in many organizations within your industry segment.
For example, if your organization is a “process” manufacturer, but the software is installed mainly in discrete, engineering-to-order, or repetitive manufacturing companies, what does this say about the software “fit” for your organization? Furthermore, if there are very few installs of any type, this is a great big red flag. In fact, I would not buy a package with less than one-hundred client installs in production (not just thinking about installing) no matter what the vendors says the software can do.
2) The software is utilized by at least some organizations with more users (total and concurrent).
For example, if your organization has 250 total users and about 100 concurrent users, but the largest client install is 100 total users and 40 concurrent users, is this the pony you want to ride?
3) The software is not full of “bugs” or on the “bleeding edge” of technology.
Beware if the latest release is a major shift to “new technology” and/or is version 2.0 for example. New technology is great, but also it may have plenty of bugs to iron out. One thing is for sure, I do not want to be a guinea pig. The version 2.0 example highlights the fact if the software has not been around for a while, it probably falls short in terms of software functionality and more than the average amount of bugs. In the end, you want stable software and technology on which to run the business. During an ERP implementation there are plenty of other things to worry about.
4) The software is fully support by the supplier
This includes access to knowledgeable support personnel, documentation, software fixes, support for commonly used system infrastructures (operating systems, databases, hardware, etc), new releases occur at least every 18 months and there is an acceptable future date for the end of product life (or end of enhancements and new fixes).
5) The vendor direction and focus for future functionality is consistent with the organization.
For example, for a distribution company it is not a good sign when most of the future software functionality planned in the vendor’s development pipeline is for homebuilders.
6) Consulting services and formal training is readily available (through the vendor and third-parties)
The more options available the better.
7) A financially viable supplier provides the software.
Get a Dun & Bradstreet, latest financial statements, listen to the grapevine, and read the research from all the “think tanks”. Hopefully, the vendor is not going out of business anytime soon or a takeover is not right around the corner.
8) The software meets key business requirements (Must Have’s)
Require the vendor to respond to each item in writing, have them discuss their responses in detail, and then make them prove it in the first software demonstrations.
#1 Authority for ERP software & Business Systems
