I have spent the last 10 years of my career working with small and medium-sized businesses to select and implement new ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management) systems. One of the things I experience time and time again is that it is actually incredibly difficult to run a successful ERP selection process and make an informed decision between systems. How can you avoid mistakes when selecting a new ERP, finance or CRM system? What is the best way to replace systems that are no longer meeting your organizational goals?
It usually takes an experienced hand who has been through this process a few times to manage it successfully, and they usually end up buying a system they have used before because they trust it and already know how it works. The problem with this approach is the system chosen may not actually be the best fit for the business and decisions may be influenced by personal comfort with a system that is known.
If you do not have an experienced hand in the organisation where do you begin? Do you simply Google or ask Alexa ‘How do I buy an ERP system?’, or do you go for the relatively comfortable, but expensive approach of employing a consultant to write an RFP (Request for Proposal) document to aid the selection?
After all, when you recommend a system and implementation partner to your business, you are exposing yourself to some personal professional risk, to some extent. If the project fails who will be questioned and asked to justify their decision? Who will the users look to in the coming months and years when they are actually using the system on a daily basis?
This blog article examines what I have seen work well and not so well over the years and recommends a new way forward.
Controversial I know, but in my experience, they simply don’t work and here is why:
They are full of useless statements like: "system must be intuitive and user-friendly"; "must have comprehensive reporting capabilities"; "must be easy to upgrade". No respondent in his/her right mind is going to say that their system is not intuitive and easy to use. These types of statements are not quantifiable and pointless to ask.
They can never contain enough detail to accurately define an entire business’ requirements. It is not possible to accurately document every single system requirement; it would take far too long, cost far too much and would still be lacking in some areas. It is not until an implementation project has begun and the users start to see the capabilities of the new system that they start to understand what is possible. They should be asking questions like; "could we operate in a different and better way?"; "why was a particular element an important requirement?".
RFP’s are too rigid. They do not leave any room for knowledgeable partners to give the benefit of their experience and to suggest ideas for change based on best practice and what has been seen to work incredibly well on other implementations in similar organizations. A successful ERP implementation is a two-way process. The client has to be flexible and take advantage of the system’s native capabilities to get the best from it, and the implementation partner has to adapt the system to meet any important requirements. The mantra must be to keep it simple and do as little development as possible.
The tough truth is that most salespeople responding to RFP’s will be somewhat flexible with the truth when answering them. It is unlikely that a salesperson is going to say their system can’t meet an item marked as an ‘essential requirement’ when they know that the element is not actually that important based on their experience. It is easy to say you can meet a requirement when you have such limited information to go on. There are too many grey areas which make any promise easy to wriggle out of. Most ERP sales people groan inwardly when an RFP lands in their inbox. I know some partners who simply refuse to reply to them unless the client has agreed to engage in some kind of discovery meeting and I have regularly seen consultants struggle to get replies to RFP’s.
It is common that an organization’s requirements will change once they understand what a new modern business management system is capable of. For example, a selection team sets out with a brief to replace their legacy finance system for a cloud-based system which must handle multicurrency and multi-company consolidated reporting. It must integrate with an incumbent CRM system. Then once they start to understand the breadth of functionality contained in a modern system they realize that it is pointless to integrate with the CRM, it is better to replace it and have a single system across both Sales and Finance functions. The RFP doesn’t reflect this so is rendered useless in respect of the CRM system. The requirements are always ever changing as the team learns about new systems.