David Ogilvie’s Lucky 13 Tips for a Successful ERP Selection

Article by , August 5, 2020

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 the main driver of the ERP implementation failure rate.

It is my contention one of the key reasons for this is the selection methodology used by everyone is broken. To avoid Einstein’s definition of insanity and with the seriousness of the impact of a poor selection in mind, I have devised my “Sure Select” methodology. It consists of 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 selecting off-the-shelf ERP software:

Executives Rarely Do This.

Company executives are hired to run the business. They have a particular skillset and industry experience that helps them to run a particular business. Selecting and implementing ERP systems is not their core skill set. It is rare a senior executive has been involved in more than two in their whole career. As such, they are often working outside of their sweet spot for skill, experience, industry knowledge and network. Therefore, the result is often less than successful. Independent guidance is very helpful here.

No Lessons Learnt from Past Failures.

Looking in from the outside, it seems that companies and executives continue to make the same old mistakes over and over again. A potential cause is executives don’t do this frequently and therefore resort to using the same old methodology, even though past results are poor. They don’t know what they don’t know. It was Einstein who said the definition of insanity is doing the same thing over and over again and expecting a different result. However, if you don’t know something has been tried many times and failed, then it is almost impossible to avoid this behaviour. Having someone who has the experience and know-how to do things differently, is extraordinarily valuable.

An Executive’s First Step Is Generally to Reach Out to Software Vendors.

When confronted with the need to replace an existing business system, executives instinctively reach out to the industry and seek proposals for what they feel they want. Just as they do when looking to buy any new part or piece of equipment. Unfortunately, an ERP system is not simply another piece of equipment, it is a much more complex situation than that. It requires a different approach. Reaching out to software vendors in the first instance is exactly what the vendors want you to do so they can control the sales process. However, it is far from being in your best interest. A key mistake an executive can make is looking for what they want but not for what they need.

The Traditional Request for Proposal/Information (RFP/RFI) is Ineffectual.

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 a contract). This is a situation where often lengthy lists of requirements are provided to the software market, and the vendors/partners are required to respond to each individually. Many of these lists are simply downloaded from different websites and have no specific relevance to your situation whatsoever. Vendors will generally simply 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 shortlist of vendors. These vendors are then required to run a demonstration of the software. Some low-level reference checking is performed and, if everything checks out, the customer is required to make some determination as to who wins.

Sales Commissions Can Be Enormous.

There are a lot of extraordinary people in the ERP industry. However, it would be naïve in the extreme to think the big sales commissions were not VERY motivating to some, especially if they have a questionable moral compass.

The sale of an ERP system can run into many thousands of dollars at the lower end and from many hundreds of thousands to 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 this level of sales commission is on offer, it tends to encourage some salespeople to be less ethical than they should or could be, meaning you need to be cautious about whom you deal with. Initially, you don’t know where their compass is pointing.

The Historical Method of Selection Simply Isn’t Working Anymore.

If it ever 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 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 were required to make an ERP implementation go well. These additional costs have helped form 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 salespeople 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 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.

To demonstrate a point, I make the following metaphor. Could your 17-year-old daughter make a wise and informed decision when buying a used car without anyone’s guidance or help? Left to her own devices a devious salesperson could tell her anything and she would most likely believe them. If you or she does not understand cars, then this is fraught with danger. There are few executives experienced enough to do this without guidance and ERP is no different. I often associate the ERP industry as being like the used car industry. There are so many different landmines that exist – unless you have seen them, experienced them or run into them before it is difficult to avoid them.

While there is no absolute guaranteed way of selecting a perfect fit when looking for a new business application, like card counting, one can turn the odds definitely in your favour. There is a myriad of variables that can contribute to picking the wrong application. As I cover in my book “The 14 Deadly Sins of ERP Implementation” picking the wrong application is the number one of my “14 deadly sins”. There are, however, many measures you can take to dramatically lower the risk of selecting the wrong application.

Here are the 13 components of my “Sure Select” methodology to help you select the right ERP system:

  1. Understand exactly Why are you changing your system? I have lost count of the number of projects where I get called in to help replace a system, only to find there is no burning reason why the system should be changed. Often, the old system will do what is required and more. Moreover, it’s the untapped functionality that will often provide major improvements to the business. More recently many of the software vendors are pushing customers to upgrade to their new cloud offerings with the threat of withdrawing support for non-cloud versions. This is not a reason to change. You need a far more burning reason to change than that.

Make sure you have built a well-documented business case clearly articulating why you should be looking for a replacement and understand the value that will be gained by changing. Topics your business case should include are the following:

  • What are the specific business problems you expect to be solved by the new system? What pain points do you expect to be resolved, and quantify what that benefit will be? Be specific as in how many dollars will be saved by changing.
  • What makes you think a new system will fix these issues? Especially if the change is to the new cloud version. As many vendors have a decrement in the product’s capability in the cloud versions and it is common for customers to lose functionality by changing.
  • What other options to changing have you looked at? What internal changes have you examined and excluded before deciding a new system is the answer?
  • What have you included in the costs: interfaces, licenses, internal resource costs, backfilling costs, etc.? Do you have the total cost of this change calculated?
  • How have you estimated the value of the benefits? Have you been conservative with your estimates? There is a human tendency to overvalue the benefits gained by such an initiative.
  • What criteria do you have for assessing a business case and for your decision-making process?
  • How do an ERP selection and the resulting implementation project fit with your strategic plan? How does the change support or enhance your strategic direction? How recently have you conducted a strategic review?
  • Are your different divisions operating well at the moment; that is, are they operating in an effective cross-functional manner? If not, the new system may make them collaborate, where they haven’t had to before. Has this increased level of change management been included in your business case?
  1. Have matching corporate cultures. A key component to a successful implementation hinges on having a sound, workable relationship between you and the software vendor/partner. It’s not until the implementation project gets underway, key details of the business are delved into, and the pressure of the project builds that key corporate behaviours from either side come to light. All too often the cultures of the two organisations are such that they don’t match or work well together.

Conflicting corporate cultures can be a major factor contributing to why implementations get off track and customers begin to blame the vendor/partner for outcomes, or lack of them. If more time were taken upfront to fully understand the cultures of both companies, much of this heartache could be avoided. Place more emphasis on the relationship than you have done previously. Focus on the relationship, not on the software functions.

Also, ask how the vendor’s consultants are remunerated and more importantly what incentives they are receiving if any. Establish what incentives and motivations to deliver on time or early and on/under budget are used. If there are no incentives in place, negotiate with your software vendor/partner to have some put in place for both teams, otherwise, there is no incentive for them to deliver quickly. It is in their best interest that the project takes longer than expected.

  1. Have a proven ability to get things done. Similarly related to culture, and actually, a subset of culture is each organisation’s ability to accomplish things. Project work is different than business as usual: it requires people who can work to a deadline under high-pressure situations. Both organisations must work in sync. The selection process gives both an early insight into how the other operates. Use this time wisely and be observant.
  2. Strategy before software. Not enough executives undertake a strategic review of the business before they start thinking about software. Much of the focus is on solving today’s problems rather than fully understanding what the business will look like in three, five or ten years. What functional requirements will the business need then? Executives frequently make the mistake of looking for what they want – rather than looking for what they need. It is important to understand the difference between what you want and what you need. In my experience, it is common for a customer not to know what they need. They think they do, but they often have difficulty articulating their functional requirements, to the depth or detail required to be sure the software functionality is a fit. It is often that the language used is different, in that, the parties often use the same or similar words, but they often have completely different meanings. Having an independent expert often helps act as a translator to ensure each party understands what the other is saying. Here are some actions that will help you prepare for this:
  • Have a detailed understanding of what processes you want the system to perform. If you have detailed work instructions, process scripts or maps available they can be helpful. For example, it may be useful to utilise APQC or SCOR as the basis for discussions around your processes with the software vendor. This reference will help both you and the software vendor understand what you need and stay on the same page.
  • Make sure all deviations by the software from your processes are documented. This will help with future change management tasks.
  • Make sure your business rules are documented and understood. Many organisations believe this is well understood however it has been my experience when this is the case, the detailed design stage of the implementation can often go off the rails because clear process decisions cannot be made.
  • Make sure all your process exceptions are documented – this is where the devil hides. ERP implementations always suffer from issues created by the devil in the details. Try to flush out as many of these as soon as you can.
  1. Have a no customisation mantra. There is a common theme in project reviews that emphasises the importance of this point. After 12 months of actually using a system, approximately 80% of executives indicate they wished they had not been so quick to modify the new system.

A common message is that the company should initially learn to use the new system in its vanilla form and only look at modifying the system for core, critical point-of-difference functions. Be prepared to push back on your company’s wants. Modifications come with high actual, and the hidden costs have generally proven to be even more expensive.

  1. Those who demonstrate, implement. In my book, “The 14 deadly sins of ERP implementation” I highlight the importance of having high-quality consultants from the software vendor working on your implementation. This is a critical success factor.

By insisting during the selection process that you have the best consultants demonstrating the product to you and for them to then be allocated to your implementation, helps you ensure you have the best. It is common practice for software vendors to have well trained, and often very well paid, people who can perform a great show in demonstrations. They are adept at avoiding the clunky bits of the software and they know how to avoid the landmines in the software. The implementing consultants, not so much. These consultants are, of course, best utilised by the software company when they are on the client site’s billing. As such, they are not usually available for demonstrations. However, for you to understand who they are, how they operate, how your people relate to them and also ensure that any promises made in the demo can be implemented, you need them to perform the demonstration. This is not a popular position by the vendors and I can assure you they will do everything in their power and provide every excuse they can to avoid this. But I can also assure you, it is in your best interests to stand firm here and demand this happens. I have had situations where you, the customer, may have to incur some costs and pay for these consultants to perform the demonstration. This is a small cost to incur in the overall scheme of such a project. It has been possible to negotiate that any costs paid during selection are credited to the implementation project should they be successful.

  1. Hire consultants with a high level of experience in your industry. Many implementations have functional consultants who know their vertical (e.g., finance or supply chain), but their experience has been in different industries. There is a high chance your industry has key nuances. If the consultants haven’t been exposed to these differences, there is a strong chance you will be paying for their education. This places you in a situation where those consultants are not in a position to provide you with sound advice about how to best use the application in your circumstance. Both of you will be learning together … not an ideal situation. Sadly, however, this is not an uncommon one.
  2. Don’t select and implement the latest version. Unless that version has been in the marketplace and has been used by others for at least 12 months. New releases are notoriously full of bugs and if you’re not careful, you become the software company’s tester. If you are told that the functionality you need will be in the next version, either wait until it’s been in commission for 12 months or look elsewhere if it’s critical. Do not rely on this promise.
  3. Perform two rounds of due diligence and do it early in the process. Historically, reference checks are performed at the end of the selection process. I believe you should conduct an initial round of due diligence calls early in the process to help identify any major red flags before you invest a lot of time, money and effort in engaging with software vendors. The goal here is to flush out early anyone who has a bad reputation. This is achieved by asking vendors to provide a long list of clients that you can randomly choose to contact. Otherwise, you get a list of “friendly” people they have set up. It is not uncommon for this list to still be implementing and have not gone live with the product. This, of course, is a red flag if they do that. These early investigations can be carried out by phone in the first instance. Of course, engaging someone like me can help you flush this out as I am experienced with the different vendors and can provide an independent view and I can help with the questions to ask.

However, after you have selected a preferred vendor or shortlist of vendors, then a different level of due diligence is required. Often this due diligence process consists of either phone calls or a quick site visit. The site visits often consist of you being ushered into a boardroom for a chat with IT managers and/or senior executives from the company. Rarely do you get to chat at length with the end-users to find out how they feel about the product or the implementation process. This level of feedback is key.

There are several key considerations to keep in mind when conducting this detailed due diligence. It is best to talk to those end users whose businesses are similar to your own in some way. Those considerations are:

  • Try to speak to a business in your industry. Often those businesses given as references may be in different industries. While this is not necessarily a bad thing, those in your industry will be able to attest to the software consultant’s knowledge of the nuances of the industry.
  • Try to speak to a business of approximately your size. A business that is of a different size to you may have a completely different culture to yours and whether the culture will be a good fit. They will be able to attest how the software consultants understood a business of your size, the demands on your staff and how they related to them. They will also be able to explain how the new system contributed to their growth.
  • Try to speak to someone in your location. Those in your area will attest to the quality and speed of the support in your location.
  • Try and speak to clients who had problems. No project goes 100% smoothly, even the successful ones have challenges. Speaking to those customers who had problems will allow you to determine how the vendor handled these problems. All vendors have clients who have had difficulties. It’s how they handled these problems that matter, not the fact that the clients had trouble.
  • Make sure the all reference sites are using the exact version of the software you’re implementing.
  1. Appoint an internal solution architect. That is, someone responsible for the overall solution’s effectiveness. Have them involved from the beginning through the implementation. Someone in the business has to be responsible for the overall solution. This person should be responsible for how the solution is designed and how the different components (such as integrations) fit together, and for explaining to the various parts of the business any implications of design or modification changes.
  2. Make this a business project. This is not an IT project, and core executives from each workstream within the business should be actively involved. Whenever these projects are left to the IT department, they fail. This isn’t because IT managers are lousy project managers; it’s because, at the end of the day, an ERP system runs the business and business people need to be closely involved.
  3. Understand the licensing/subscription model. Rarely are you able to conduct an accurate apples-to-apples comparison on licensing costs because each vendor has a different method of calculating the cost. It is important to thoroughly understand what will impact your license costs. For example, one major vendor uses role-based licensing. This is a situation where the level of license used is determined by the functions a security role can perform. Some customers have received big shocks when they realised that the way they structured their security roles had a licensing impact. Be sure you understand what will affect the costs.
  4. Get sound legal advice early. Ensure you get an expert in this field, and not simply general counsel, specifically someone who has software contract experience. I mentioned earlier that promises are made in demonstrations that cannot be delivered in implementation. The most important area to cover is to make sure you have sufficient leverage when it comes to vendor performance. Your legal documents must ensure the software vendor is held to performance obligations throughout the implementation process. This is but one issue that can be minimised by having the right legal documentation in place at the beginning. By being proactive in this area, you can protect yourself against major heartache later.