Three Reference Materials for Selecting ERP Software
Last week, just I was leaving Australia, I saw the Australian version of CFO magazine on sale at the airport. At $19 (AUD) it was pricey but the entire issue was a selection guide for ERP solutions. Publications like this are helpful to those starting an initial selection process and can be useful in some short-listing efforts. If you can't find this issue (or don't want to spend the coin to buy it outright), much of the material can be found online at: http://www.cfoweb.com.au/softwareguide06/product.asp . This guide has data on several dozen vendors and can be perused online.
Software Magazine has in its current issue (May/June 2007) the article "Application Packages:
Taking the Plunge: Searching for the Perfect ERP System". Because this magazine comes in a digital format, you can read/store this on your PC. Please see www.softwaremag.com (however, the site did not have the latest issue up at the time of this blog posting).
Brown Smith Wallace Consulting Group has a number of resource sites (e.g., www.software4manufacturuers.com or www.software4distributors.com ) that software buyers might benefit from. My quick review of these suggests that they help one compare different solutions against one another.
I'm not endorsing or critiquing any of these. I will argue that the following issues plague any selection tools:
- comparisons of functions and features are tough to do as the base data is costly to accumulate and so hard to keep current
- function/feature comparisons of mature applications will rarely yield useful results as the products are being compared on points that rarely differentiate in a meaningful way. For example, who cares if a general ledger package has 5 methods of allocating balances and a competing package only has four. If both support the method you need, what's the incremental value of functionality you don't need or want (or want to incur the long-term cost of maintaining)?
- few selection methodologies use business case scenarios and fewer still are backed up with data that helps a buyer choose between two solutions that scenarios are applied against
- selection guides should also contain TCO and/or ROI calculator/comparative tools that rigorously evaluate total life-cycle costs
- few selection methods consider the end-of-life costs involved in de-installing a package and replacing it with another product at a later date
- there is an underlying bias in any reference data you get from a third party. Sometimes this is due to the source of the information. If a vendor provides it, it will rarely suggest anything unflattering about the vendor's product. Integrators could slant either the data or the questions used to shape a decision to favor product(s) that they implement. Some bias is the result of the analyst who prepares the consolidated data. Maybe that analyst has had prior experience with one product versus another and rates the one product higher. Subjective scores are okay as long as you know who and how they were prepared.
Assistance with complex selections is always appreciated. Prospective buyers should tap any and all resources to help with these decisions. Prospects though should remember that:
- selections are a technical, functional, human and political process. Selection efforts that only focus on the technical or functional aspects are doomed. If the selection doesn't address the human and political aspects, it is a waste of time and money.
- selections are quite costly. Don't underestimate the time and money to bring all of the organization into the buying process. There's a reason that large ERP deals often have 10-18 month sales cycles. Everyone, it seems, has a stake in these choices.
- selections are often determined by top executives without the use of tools like those above. They look at the quality management programs in use by the different vendors. They look at the quality of the senior management teams at the different vendors. And, far too often, they look at what their competitors are using and want to ensure they maintain competitive parity (not advantage).
- selections do not have to be logical. Lots of top executives have made irrational decisions (at least to many of us, these are irrational) re: ERP choices but their votes count more that others.
In my career, I've helped create a half-dozen software implementation methodologies. Each has its pluses and minuses but methodologies without current product intelligence (or vice versa) are useless. Call or write and we can compare notes. But, get all the unbiased data you can get (more on this in the next post).

Brian,
Great article on a important issue that often determines the ultimate success of a complex project.
I have blogged about it here: http://projectfailures.com/blog/2007/5/22/software-selection-blues.html.
Michael Krigsman
http://projectfailures.com
Posted by: Michael Krigsman | May 22, 2007 at 06:48 AM
Software selection is fraught with problems. I agree that it is very difficult to use any automated selection process for anything but limiting the number of choices. At www.software4distributors.com, our goal is to do just that. Make it easy for a company looking fro software to focus in on three or four viable options. Then it is imperative to do the necessary research to find the best of the finalists for any given company.
The comment that “comparisons of functions are costly to accumulate and keep current” is defiantly the truth. We spend over a man year annually just working to update our lists. We do not review each of the 2000 questions each year, but do select about 300 points each year to check. Also, we do not review hundreds of packages, only about 25 key packages in the vertical market we serve. It is very focused and unbiased.
Still, the most important action a company can take is to develop a short list of applications to review. Then identify the 10 or 20 or even 50 critical issues that give you a competitive advantage. Assume that any of the major packages will do all of the basics (general ledger, invoicing, A/R, and A/P). Ask each of the vendors to prove that they can provide solutions to the features that matter.
As you point out, it is also a political decision. Most of the packages will solve the processing issues. BUT, if the staff is not behind the selection, the software implementation can easily fail. Allow everyone to put their thumb print on the decision so that it is theirs. Then they will work hardest to make it work.
Posted by: Steve Epner | June 01, 2007 at 12:27 PM