Beware of Web-based ERP System Selection Processes
The internet is replete with web sites offering pre-configured sets of business requirements for use in ERP selection projects. The claim is that much time and effort can be saved by using such resources – in fact pre-configured requirements specifications tend to focus effort in the wrong areas.
One of the most important tasks to do prior to selecting a new ERP system is to clearly document the business requirements. The requirements specification helps to clarify the project scope and provides a point of reference against which candidate systems can be compared. Unfortunately, developing a good specification takes time and effort and not surprisingly many organisations look for a shortcut.
At first glance, the internet appears to provide one. The web is replete with sites offering pre-configured sets of business requirements for use in ERP selection projects. Some sites go even further and provide an automated match of selected requirements against data held from various ERP systems. On the face of it, this seems attractive - after all why re-invent the wheel by documenting requirements from scratch when someone else has already done the job?
In fact, while in most cases pre-configured requirements listings and the matching tools provided by web sites can appear to save time, they focus the effort that is spent in the wrong areas. To appreciate why, consider the diagram below, which reflects how customer and ERP vendor effort is typically distributed when pre-configured requirements specifications are used in a selection process.
Effort vs Requirements when using Pre-configured Checklists
There are a small number of functional differentiators in most ERP selection projects. Typically these are complex requirements that may be specific to the organisation looking for a new system and usually will comprise 10% or less of the total number of requirements. The remaining 90%+ are also important but will be standard to many organisations, and as a result most ERP systems will provide functionality to meet them.
Unfortunately, pre-configured requirements documents are comprised almost entirely of standard requirements. While these have been pre-documented, the customer will still need to review each one and decide whether it should be kept or not and possibly make minor changes to the wording. Because of weight of numbers, this process inevitably takes more time than is spent on documenting the new differentiator requirements. From experience less than 20% of the time will be spent on the differentiators.
Web-based requirements listings are generally formatted so that the vendor responding to them indicates a level of fit against each by ticking a box. Because all boxes need to be ticked, the vendors will also spend most their effort responding to standard requirements, typically in a similar proportion to the customer. So in summary, at least 80% of the effort expended by the customer and the vendor will be focused on standard requirements for which almost every ERP vendor will have close to a perfect fit. Clearly this doesn’t help the selection process very much!
The alternative is to spend nearly all of the effort in addressing the differentiator requirements, taking it as a given that most of the standard requirements will be met. This is shown graphically below.
Effort vs Requirements when Focused on Differentiator Requirements
By taking this approach, the differentiator requirements can be documented in detail, providing a context, including where appropriate, flow charts or sample data. The result is a requirements document that is much more focused and richer in the areas that are most important.
From a vendor perspective, nearly all of the effort will be spent on understanding the key requirements and considering how best to meet them. Rather than simply ticking a box, the vendor will be asked to describe in detail, often using screen shots or case studies, how they would address each requirement. This allows vendor responses to be compared at a much greater level of granularity than is possible when using pre-configured requirements specifications.
Unfortunately, there are no shortcuts in the process just described – because the focus is on the differentiator requirements, pre-configured documents available from websites are of no use. However, the time that is spent will be used productively and will help to ensure a much better selection process.