Selecting the Right ERP Software:
David Ogilvie’s Lucky 13 Tips for a Successful ERP Selection
The ERP landscape is littered with horror stories of bad implementations costing companies many millions of dollars for absolutely no benefit (in some cases). Many of these failed implementations have ended up in court, or at least have involved an acrimonious split between customer and software vendor/partner. Studies have shown that selecting the wrong product in the first place is a main driver of the ERP implementation failure rate.
With the seriousness of the impact of a poor selection in mind, I have devised 13 key tips to a successful ERP selection.
Before I cover the keys to success in detail, let me quickly examine the historical landscape as it relates to off-the-shelf software selection:
· Executives rarely run this type of project. Executives are hired to run the business. They have a particular skill set and experience that helps them to run a particular business in a particular industry. Selecting and implementing ERP systems is not their core skill set. As such, they are often working outside of their skill sweet spot, experience, industry knowledge and network. Therefore, the result is often less than successful.
· The lessons from past failures don’t seem to be learnt. Looking in from the outside, it seems that companies and executives continue to make the same old mistakes over and over again. This is potentially due to the fact that executives don’t do this ERP selection frequently, and therefore resort to using the same ole methodology, even though past results are poor. Was it Einstein who said the definition of insanity is “doing the same thing over and over again and expecting different results”?
· RF(X) represents the historical method of selection where customers go to the market with different requests: RFP (request for proposal), RFI (request for information) and RFC (request for contract). This is a situation where often-lengthy requests are made of the software market, and the vendors/partners are required to respond. At this point, vendors will generally respond favourably to all or most of the requirements listed in the request because they don’t wish to be cut out early. This can lead to vendors’ responses being misleading in one way or another, such as providing lowball offers. The customer then develops a short list of vendors. These vendors are then required to run a demonstration of the software. Some low-level reference checking is performed and, if all checks out, the customer is required to make some determination as to who wins.
· An ERP sale can run into many hundreds of thousands of dollars at the lower end, and many millions of dollars at the upper end. The value of commissions payable on these sales is substantial, and therefore the competition is fierce. When these levels of commissions are on offer, it tends to encourage some sales people to be less ethical than they should or could be, meaning you need to be cautious about whom you deal with.
The historical method of selection simply isn’t working anymore, if it ever really did. There are many reasons for this:
· The majority of the systems being reviewed can in most cases meet the list of required functions given in any RF(X). In many ways, the functionality war is over and has been for more than 15 years.
· Budgets are usually required as part of the RF(X) submission. Again, vendors often lowball their submissions because they don’t wish to miss out so early in the process. It is ironic that past customers in many ways contributed to or caused this behaviour. Software companies lost deals during the budget step of the process, often unfairly, when they were being truthful and indicating what implementation costs really were. Unfortunately, customers didn’t want to hear so high a cost at the beginning of the process and eventually went for a cheaper option, only to find out later that additional costs really were required to make an implementation go well. These additional costs have helped formed the ERP legend that budgets are almost always exceeded. But could it be that the original budgets were not realistic in the first place?
· Differences in submissions are difficult to discern. Each vendor will calculate costs and present their submission in a different format from the other submissions, no matter how structured the customer tries to make the response forms. It’s a fact of life in these selections: comparisons can be difficult to make, and the differences can be very difficult to discern.
· Demonstration presenters and sales people are not implementers. They rarely have worked on a real implementation and are prone to make promises the implementing team cannot fulfil. Those charged with making the presentations are knowledgeable and smart people. They can generally think quickly on their feet and have the ability to show the product in its best light, thereby avoiding often-embarrassing gaps in capability. ERP implementation history is littered with stories of promises made in demonstrations that are unable to be fulfilled by functional consultants when the rubber hits the road: in the implementation.
· Software vendors/partners will often conduct the demonstrations using their scripts, which don’t actually reflect your business process. They follow, for example, a generic process, such as procure to pay, to demonstrate that the system will comply with requirements.
This flawed process has contributed to fostering certain behaviours from software vendors/partners. Here are the behaviours you are likely to see if you continue to follow this process:
· Some will lie, while others will spin the facts to best suit their product. Their behaviour is about ensuring the product is shown in its best light and safeguarding their position so that they aren’t cut out too early in the process.
· They will attempt to bypass procurement structures, if you have them in place. They will want to speak to the people who sign the cheque, and not the selection committee charged with the role of selecting the product.
· They will attempt to make the selection process as easy for themselves as possible and will resist any attempt at providing detailed work to respond to your demands.
· They will be investing in your sales process, so they will expect some value for their investment.
· They will create doubt anywhere they can, especially with the opposition and potentially with your team.
· They will try to say your way isn’t the right way—and in many cases they are right.
So essentially, I am saying there is no surefire way to guarantee a perfect fit when looking for a new business application. There are a myriad of variables that can contribute to picking the wrong application. And picking the wrong application is number one of my “14 deadly sins” to ERP implementation failure, as I mentioned in my article “David Ogilvie's 14 Deadly Sins.” There are, however, a number of measures you can take to dramatically lower the risk of selecting the wrong application. In my next post I will go through my 13 lucky tips to selecting the right ERP system.