Evaluating ERP software is a long and tedious process. The evaluation is carried out on multiple dimensions e.g. technology, functional fit, implementation & support capabilities, future readiness etc. Functional fit or the features of an ERP play a dominant role in the decision making process. Let us look at a few pieces of information and try to connect the dots.
In his book 'Complexity Avalanche' J.B.Wood states that product companies are generating features more than what the users can consume, leading to a “Consumption Gap.”
This consumption gap is also evident from a Standish Report which states that 19% of software features in production are rarely used and 45% are never used.
On the other hand, a typical RFP for an ERP on technologyevaluation.com boasts of not less than 1000 features. Obviously, the potential customers have a daunting task on their hand when it comes to evaluating ERP software based on features. A clear comparison strategy is needed which will simplify the task without compromising the objectives of going for an ERP.
ERP vendors want to showcase as many features as possible. Their marketing collaterals are flooded with these. Customers have their own list of features which originate from multiple sources.
Features of the legacy systems the users are in love with are included. Users give their own requirements based on the challenges faced due to limitations of the legacy systems. Management has its own list based on top line and bottom line improvement requirements. If external consultants are involved they earn their fees by bringing in the processes re-engineering requirements. At the end, the prospective customer is overloaded with a list of features often camouflaged as “business requirements” .An enormous amount of time is spent on evaluating these features and then we have Wood and Standish Group telling us that a large number of these are rarely or never used.
How do we fix this problem? The first step is to list down all feature requirements and segregate those into three groups. The First group is “Need” A clear definition helps here or the users have the tendency to push everything as “Needs”. The critical requirements without which the business comes to a standstill are Needs. The caveat is that not all features in the legacy system are critical requirements. Users may have to be pulled out of their comfort zone to drop a few of these e.g. some reports.
Next set of feature requirements is “Want” features. These features introduce best practices and improve process efficiency. These are the drivers behind going for an ERP system. Electronic fund transfer (EFT) is a “Want” feature and not a “Need” feature. All other features fall under Not Applicable or Not Relevant category.
Needs and Wants are based on the industry of the customer. This needs to be understood clearly. According to a survey, only 24% of the vendors have Fleet Management functionality. Now in Logistics industry, you can’t do without it and it is clearly a Need. However for any company without a fleet of vehicles, it is not even a “want”. Lot traceability is a Need in Food industry from a compliance point of view. In Industrial machinery industry, it may be a Want. Credit card payments and shopping cart are the Needs of online retailers and not even relevant for a B2B engineering company.
So we have classified all feature needs into Needs, wants and Not Relevant. What next? The first step is to compare various ERPs on this feature list. An RFP can be taken out where a vendor tags each feature as “Standard Feature”, “available through customization” and “Not available”. We need a framework in place to analyse vendor responses.
ALL Needs must be satisfied preferably through standard features. If not, these should be available through customizations. Each requirement satisfied through a standard feature has a higher weightage. The vendor may agree to make the customization available as a standard feature in future versions. This is a critical point which is often overlooked and these customizations make the upgrades very expensive. Thus having access to the senior management and product teams to get clarity and commitment on this aspect is necessary for a proper evaluation. Vendors not meeting any “Need” should be dropped at this stage.
Remaining vendors can be compared on the Wants in a slightly different way. An impact analysis is required for the Wants not satisfied and categorized as high, medium or low. High impact features need to be added as customizations and preferably included in the product as a future roadmap. Medium to low impact features can be parked aside and the evaluation can move to other dimensions like implementation capabilities, support, price and usability.
Usability needs special attention. A Large number of features are not used (as mentioned by Wood and Standish Group) because users have to navigate multiple screens to use a simple functionality e.g. finding material and capacity problems in a work order. Few market leaders have a reputation for being very complex to use and it is common to see users of these ERP software performing many functions outside the system at these installations. On the other hand few ERPs like Ramco have paid special attention to this aspect. A case in point is concepts like Hubs where a user gets all his functions on one screen which leads to high user adoption.
All features other than Needs and Wants are no more than eye-candies used by vendors to lure the customers. Customers will do well not to spend precious executive time on seeing and evaluating these. A demo script containing Needs and Wants can be given to the vendors to achieve this.
In a nutshell, customers should develop a framework of Need/Want/Not Relevant features vs. Standard/Customization/Not Available and then evaluate an ERP. Once an ERP satisfies all needs and high impact wants evaluators should quickly move on to other dimensions of evaluation rather than getting lost in the bells and whistles features.
We shall cover those dimensions in the forthcoming blogs here. Stay tuned to Ramco Systems for more on blogs on ERP.