How do I buy an ERP system? Part One
by Mark Hennessy on
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 organisational 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.
Forget RFP's
Controversial I know, but in my experience, they simply don’t work and here is why:
- Useless content
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.
- Not detailed enough
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?".
- Too rigid
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 organisations. 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.
- Lack of responses
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. They are a lot of work for the partner and usually the reason you are looking for a partner is to take advantage of their experience or industry knlowedge. Strictly controlled RFP processes restricts this by enforcing how the sales runs. Often the partner is best placed to define the process.
- The new system will change your requirements
It is common that an organisation’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 realise 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.
