How to evaluate your ERP RFP responses
There’s a fair amount of confusion about the need to assess ERP RFPs prior to establishing a proper selection process. Each ERP vendor showcases different operational values. However, unless a comprehensive RFP evaluation is conducted, there is a possibility that an enterprise can choose the wrong product, for the wrong reasons, at the wrong price-point.
Consequently, highly-granular evaluation criteria must be applied to ensure that all business goals are most efficiently met. These typically include:
- Evaluation-based criteria which allows the enterprise to compare one provider’s solution in the context of its specific operational needs while mitigating undue sales pressure.
- The ERP evaluation approach allows the enterprise to extend its flexibility when considering how RFP proposals are to be assessed going forward. Some focus elements here involve; platform selection, third-party services, support responses, training rounds, and/or launch and implementation processes.
- Establishing an ERP evaluation round ensures even-handed measurement when weighing the merits of competing providers.
- The application of ERP evaluation aids processes related to product sales, and consequent contract negotiation.
- Focus on developing and applying comprehensive ERP evaluation tasking provides additional data-points throughout. Elements of this type ultimately accrue to final decisions that ultimately affect final pricing and performance validation.
What questions should I ask in an ERP RFP?
Once a proper evaluation process is complete, the best way to approach challenges relating to the development of a legitimate list of vendors is by means of an ERP vendor selection criteria. This exercise should not be viewed as a redundant process, but instead should be seen as the beginning of a thorough investigation into the differences between various providers.
There are a number of ways to format this kind of criteria, ranging from complex ERP selection matrices to various simple ERP selection templates. Regardless of the delivery format, however, the goal will be simple; to clearly define and articulate ‘how, how much, and what’ each product offers when weighed against the company’s specific operational goals.
To help you understand what will be required, here are some general measurement concepts that can be applied to the essential selection effort:
- Begin with the number of necessary query categories such as; the number of required platform modules, i.e. accounting, production, inventory, distribution etc; depth of customer support, i.e. direct, voice-only, online-only, all the above; depth of warranty, price model etc.
- Develop an internal measurement method. For example, a 1-5 metric with 5 being best can be applied, or the user can sub-measure individual tasks. Either way, this approach is entirely up to the user, but regardless, any value process will be better than none.
- Once you have a category metric structure established, rank the questions within each category. For example, this ranking process can apply from ‘most needed’ worth 5 points, versus ‘least needed’ worth 1 point.
- Based on the aforementioned question rankings, weigh all major categories accordingly. For example, most needed would, again, be worth 5 points, while least needed would be 1 point.
- Use the same processes and measurements relating to each individual module question.
- Re-weigh any categories/sub-categories and/or questions as necessary.
Once this measurement structure is complete, the user should have a pretty good idea of what they will need to know, based on empirical thought processes, not pure conjecture.
Who should evaluate the RFP?
Depending on the size of the enterprise, decision-making, or vetting, an ERP selection criteria can range from a multi-member evaluation committee to individual senior managers. However, in all cases, final judgments relating to the purchase of an ERP platform should be defined by business management, not representatives of the IT community. While this may appear to be counter-intuitive, there is a simple reason for this suggestion.
Regardless of how fair they may be, IT folks tend to love technology before they love the necessary needs of business. Consequently, if a CEO or CFO finds themselves in a position of being responsible for writing a significant check to greenlight an ERP purchase, the needs of the business must always come first; regardless of how clever a particular technology may, or may not be, ‘best of breed’ from a technical perspective.
This awareness is regularly proven by statistical metrics associated with proportional differences between successful ERP implementations, versus those that regularly fail. For example, according to a recent report, up to 75% of all ERP implementations fail.
However, these failures are not typically defined by technical weaknesses so much as the way that particular businesses fail to understand, vet, and make decisions associated with a particular ERP platform. For example, the researchers suggested that; 48% of businesses admitted that they found platform solutions confusing; 50% found sales offers confusing; and 33% felt unsure about honest and transparent sales advice, while only 26% felt confident once a purchase decision was reached.
Consequently, it is clear that administrative/financial managers must be equipped with time and education by employing a proper set of evaluation and selection criteria. If enterprises fail to heed this warning, any business that is considering an ERP purchase will operate on its back foot from the outset.
RFP evaluation matrix
While the discussion above primarily amounts to concepts and theoretical constructs associated with ERP RFPs, in order to really understand how the entire value proposition works you should consider the effort as a practical construct. Consequently, let’s take a snapshot of a typical ERP evaluation matrix. This image relates to a process manufacturing document oriented to just one page in an ERP inventory module evaluation analysis provided by Infotivity:
The validation legend for the aforementioned snapshot includes; fs – fully supported; pe – paid enhancement, and ns – not supported. Note that the questions suggest extended granularity leading to further investigations and even deeper requests for information throughout the extended RFP.
Now that you’ve experienced an example of what a real evaluation matrix looks like, here are several other tips to leverage:
- Key points to consider: write your questions as clearly as possible. If you find that a question requires a deeper investigation, add another question, but don’t utilize serial semicolons. When it comes to developing RFPs it is expected that detailed questions will be necessary, but in execution, simple will always be the better choice.
- Narrowing down your selection list: don’t go too afield of your intended business purpose. If your stated goal is to resolve a problem with accounting and inventory, focus on those needs. Don’t allow yourself to be distracted by two or three other ‘enhancements’ that your selected provider may offer along the way. Remember, you’re trying to solve a business problem, whereas the salesperson is trying to sell more software. These two elements are typically mutually exclusive, but you’re still going to have to drive the bus.
- Next, get into a habit of reviewing your RFP regularly, as in every week, just to ensure that you’re refining what you’ve already done. If you don’t pay attention, scope creep can become a real problem, and the mere involvement with an ERP platform will offer plenty of challenges as it is.
- How to choose between similar systems: as suggested earlier, using the weighted method allows an easy way to separate the wheat from the chaff. Accept that everyone in the sales community is going to be gunning for your money, so be disciplined, but most importantly adhere to your evaluation and selection plan without deviation. This step will save you time and money.
Things to avoid during the ERP RFP evaluation process
Now that we’ve discussed some of the major ways that you can get your ERP RFP evaluation off the ground, there are also some things you might want to avoid, including:
- Never make an evaluation decision without executing a direct ERP software comparison between competing provider’s systems. Spend the time to go through each evaluation question on a head-to-head basis. Otherwise, something can be missed in the clutter, and when it comes to resolving an ERP assessment the old saying ‘time is money’ applies on steroids.
- Never accept a confusing sales response to a written RFP question. With respect, sales people want to sell stuff – to you – not necessarily resolve your business problem. If you don’t understand a written response, ask the RFP candidate to clarify the response until you either gain intellectual satisfaction or check the candidate off the selection list. It’s just that simple.
- Don’t employ an overly-complicated weighing structure. In this case, use a common approach to defining metrics. If you start with a value scale ranging from 1-5, stay with the same scale, and don’t employ multiple mathematical structures. It’ll confuse the issue when the time comes to make a decision, and also run the chance of missing some salient value in the midst of any potential clutter.
As you might expect, there are numerous other tips and traps that you should apply when designing an ERP assessment, evaluation, and decision matrix, but as asserted earlier most are subjective. The bottom line is that any good ERP RFP is driven by patience and detail, that ultimately leads to a solid decision for the business at-large.
Featured white papers
ERP Software Pricing Guide
Get your comprehensive guide to the cost of ERP softwareDownload
60-Step ERP Selection Checklist
Get the comprehensive checklist for your ERP selection projectDownload
Mastering ERP demos in five easy steps
Your guide to using vendor demos to make an informed ERP selection decisionDownload
The invitation to tender process for ERP
What should be included in your ERP ITT
Finding your top ERP for higher education
The benefits and requirements of higher education ERP
Franken-system: the dangers of stringing together a bunch of apps
A guest blog from Jonar discussing a one-system solution versus multi-system operations