Creating the Perfect RFP for an ERP Software Evaluation

Years ago, selection and advisory firms would push the importance of documenting an ERP Request for Proposal (RFP) when completing a software selection. In recent years, however, many organizations have moved away from formalizing this process. The reasons for this are many, specifically that software vendors have nearly perfected the art of manipulating these documents.

With that said, there are still times when a formal RFP/RFQ is needed as part of your evaluation of SAP S/4HANA vs. Oracle Cloud vs. Microsoft Dynamics 365 vs. other systems you might be considering. Whether you are part of a Government organization, NGO or commercial company that has procurement standards in place that need to be followed, there are still plenty of opportunities to create a Request for Proposal or Quote.

As you proceed down this path, keep in mind that the software landscape is changing quickly (as outlined in our 2019 Digital Transformation and ERP Report), and your RFP process needs to keep up. Following are some tips to perfecting your software vendor RFP:

Requirements specificity is key: If you have limited or high-level functional requirements in your RFP, you will most likely find that all vendor responses approach 100% out-of-box functional fit. For example, if you request something like “invoicing capability”, the top ERP systems – and pretty much every ERP system on the planet – will be able to do this. If you want A/P to be able to run an invoice for a non-inventoried item, however, be sure to state that. If you leave any possible variation open in your requirements, vendors will fill it with their own assumptions.

Request definition surrounding software modification: This has become an area of significant confusion. Common phrases such as “customization” and “configuration” are still helpful, but are no longer enough. Keep in mind the following:

• A majority of software platforms can be configured as flexibility is increasing rapidly. There is also great variance in what “configuration” takes across different platforms. Just because a requirement is checked “configurable” does not mean it is easy to implement.
• Many software platforms have pre-built integrations to other systems. If not specified in the RFP document, vendors may consider these pre-built integrations as out-of-box functionality.
• Request definition surrounding “available through third-party” applications. Confirm if these applications are integrated into the core software, if they have been implemented together successfully in the past and if they will require separate license agreements. Vendors will often state that a functional requirement is available through third-party applications simply to avoid checking “not available”, even if there is no proven integration to the core ERP platform being proposed.
• If you are dealing with one of the large SAP or Oracle system integrators such as Deloitte, Accenture, or Capgemini, be sure to fully understand the details of their cost estimates. You will also want to rationalize their staffing levels to ensure that you are overpaying for their large team of consultants.

Specify that you are looking for operational and implemented functionality: For some reason we are seeing vendors check “out-of-box” for functionality that is still in development phase if it is intended that the code will become part of the core package. They will state that it has “been tested” and is ready for deployment, but there is grave danger in being the guinea pig.

Don’t take pricing too seriously:
While it is important to accurately estimate the costs of your SAP, Oracle, Microsoft or other ERP implementation, it is also important to recognize that much of these costs can be negotiated at a later time:

• request pricing to include these modules if the requirements suggest the need.
• Likewise, request the cost estimate to include third-party and integrated modules if available.
• If there is notation of needed customization, request if the estimate provided contains any room for customization. As it is very difficult to accurately quote level of effort for a true customization, most vendors will leave this out of the initial cost estimate.
• Keep in mind, no matter how good your RFP document is, that vendors will be low-balling the cost estimate. The assumptions will be that everything goes smooth, that the configurations run without a hitch and that the implementing organization will adopt new processes and begin using the software as it was intended. This is never the case, and estimates provided should be used as a ballpark figure, at best. The actual cost of implementation will come during the planning phase where business, organizational and operational readiness is measured, where integrations and infrastructure impacts are mapped and where timelines are set.

Allow for a free form notes section: This will allow vendors the opportunity to add any relevant information surrounding their responses and will give a more complete answer to questions surrounding software fit.

Creating a complete RFP document takes time and effort. If you are going to do it, do it right. Otherwise you will spend the same amount, if not more time and effort validating vendor responses. If your purchasing department has a “template” RFP that is commonly used for equipment or services purchase, it will need significant modification to meet the needs for a software platform. This is an area where independent ERP consultants can provide valuable guidance, so don’t hesitate to reach out for help.