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.
