ERP Software Evaluation

One of the primary goals of an RFP is to identify which features each proposed system will provide.  This may sound rather easy, but in reality it is not.  This is because a vendor can respond with "Yes" to a question regarding a specific feature or function, then actually deliver that feature in one of many ways, each of which has its own level of risk.  There is no link between the "Yes" answer and the method used to deliver the feature, and it is this disconnect that causes the evaluation of this type of RFP response to be extremely inaccurate.

Looking at this problem in more detail quickly reveals the cause of this disconnect.  A vendor may respond with "Yes" to a question about a system feature, then, solely at the vendor's option, choose to deliver that feature using any of the following delivery methods:

• as a Standard "Out-of-the-Box" Feature, Fully Tested, Documented, & Supported
• by Changing a Configuration Setting Default Value to Something Else
• by Using a Report Generator to Provide a Non-Standard Report, Form, or Inquiry Screen
• by Performing a No Charge Software Scripting or Source Code Modification
• by Performing a Billable Software Scripting or Source Code Modification

Obviously, less risk is incurred when a feature is provided as part of the standard "out-of-the-box" software product.  Much more risk is incurred when that same feature is being provided as a scripting or programming modification.  Just because a vendor states they are providing a feature as a no-charge modification does not mean they can deliver it on time or bug-free.  The issue of RISK becomes very real. The chances of on-going software problem and increased support charges are much larger.

Over the last twenty years or so there have been many attempts to rectify the inability of software RFP responses to capture and communicate adequate decision-making information.  Some have declared the RFP "dead" or "useless" and have tried to forge a new trail.  This has always ended up in disaster simply because of the need to address thousands of requirements at a very detailed day-to-day operational level.

Others have tried different RFP response formats that allow vendors to respond in a more focused fashion.  Examples are "Yes, on a Future Release Date", or "Yes, with Minor Modification", and similar, in an attempt to clarify the responses.  These have been met with total confusion, if not outright disaster, because there usually is no legal teeth regarding adherence to "Future Releases" in the RFP, and each vendor can interpret the phrase "Minor Modification" quite differently from others. Worse yet, some vendors try to deceptively cram huge customization efforts into the "Minor Modification" category.

Clearly, there is a need for an RFP criteria format that can accurately collect the full range of decision making information in a reliable, consistent, and uniform manner.  

At Infotivity we have examined the above problems for well over twenty years and have determined that the best RFP response format is one that "locks" the vendor into a very specific delivery method in a very well defined manner, one that has no "wiggle room" as they say.  The possible responses must address all the possible ways software features or functions can be delivered (provided) in a one-on-one relationship, i,e,. a given response value cannot be construed to mean more than one thing.  Responses that "lock" the vendor in to one method of delivering a feature, in a very specific way that cannot be misunderstood, is the only way to be certain of having an accurate ERP RFP response and evaluation.

Infotivity developed the following RFP response format to obtain information in a consistent manner that can also be used to assess both the SUITABILITY and the inherent RISK of a given software proposal.

The Ideal RFP Response Format

This RFP response format is a very good way of identifying BOTH system feature AVAILABILITY, and the DELIVERY METHOD a vendor must utilize to provide that feature, in a completely quantitative format.  This is ideal for collecting data used to determine the suitability (weighted grade point score) of a proposed software system to your needs, AND data needed to assess the RISK of it's implmentation.

This type of RFP format is an excellent choice for RFIs & RFPs used to acquire enterprise-wide systems such as ERP.  The risk assessment is very important here because of the complex nature of the target environment and the amount of custom scripting or programming that is involved.

The format below has built-in safeguards to prevent the cheating and fudging described above.  One of the most notable is that there is no distinction made between actual "source code modifications" and so-called "scripting". Lets face facts - there really is no logical difference between an established programming language such as C++, or VB, and a proprietary "scripting" language.  Both need to be learned, both are created using commands and statements of some type, and the functions created both are only as good as the skill level of the person using them.  Everybody has heard of GIGO - Garbage In Garbage Out!

The Infotivity RFP response format is comprised of the following possible response values:

• FS = FULLY SUPPORTED
• NS - NOT SUPPORTED
• CO = CONFIGURATION OPTION
• RT = REPORTING TOOL
• FE = FREE ENHANCEMENT
• PE = PAID ENHANCEMENT
• 3P = THIRD PARTY

All Infotivity ERP RFP Master Templates utilize the above response types to ensure the highest quality vendor RFP responses and ensure the most accurate ERP evaluation scores possible.