RFI vs RFP: Why an ERP RFP is Not Always the Best Option for Your Business

The dreaded ERP RFP or Request for Proposal. Would-be purchasers spend way too much time and money, if employing outside consultants. Software resellers hate them with a passion. Unfortunately, the results are often less than optimal. So what are the options? Let’s look at a direct RFI vs RFP comparison to see how they each affect how you choose technology.

At its core, an RFP is a formal invitation extended by an organization to potential suppliers or service providers, soliciting detailed proposals for meeting a particular need. Whether it’s procuring goods, services, or initiating a partnership, an ERP RFP is the initial step in the procurement process. It typically includes details such as the project scope, objectives, desired outcomes, evaluation criteria, and timeline. While they might seem like the ideal way to make sure all information is clearly communicated and factored into a proposal, unfortunately things don’t always work out that way. We’ve seen many times where an RFP process led to an extremely challenging implementation or even the wrong software selection from the start. While we are certainly available for RFP rescues, we’d prefer to help people avoid the challenges altogether. So when looking at your options of RFI vs RFP let’s talk about why RFPs struggle to deliver strong outcomes and what can be a better alternative.

Here are the top five disadvantages of using an RFP to find a new business management solution:

1. The person or organization preparing the RFP often does not fully understand the business requirements.
   Many RFP’s are prepared by an outside consultant who is NOT an expert in your industry or, more specifically, your business. The key element for a successful selection starts with a foundation of meeting the requirements of your operations group, not finance, who are often leading the selection process. Because of the fundamental lack of understanding, the preparer must resort to other strategies, which are discussed below.
   
   
2. It is an extremely expensive process to create an ERP RFP from scratch.
   To create an RFP from scratch requires interviewing several people in each functional area of the business. This can be upwards of fifty people for a larger organization. To do this from scratch and document the necessary business processes is easily a six-figure cost and possibly more. Most organizations view this step as a necessary evil and are reluctant to invest an appropriate amount, which leads to sub-par results as the document will not adequately represent the organization’s key requirements.
   
   
3. The RFP relies on quantity versus quality.
   Due to the lack of detailed knowledge of the specific business processes needed for a new system and the constraint of a limited budget leads many RFP preparers to pull out previous or standardized versions of RFP’s to use for the new customer. Most RFP’s include hundreds and even thousands of detail lines that represent the sum total of requirements across ALL organizations, not just those required for the business in question. Editing can reduce the number of the lines but still results in many lines that are not priorities, which can confuse the results. The number of truly key requirements necessary for the selection of a new system is shocking small.
   
   
4. Lack of industry knowledge leads to involving unnecessary software vendors.
   It is not uncommon for an ERP RFP process to consider ten to fifteen different solutions or just those the current system users are most familiar with. With rapid changes in technology, newer solutions may have emerged in the industry that are then left out of the selection process. On the other hand, comparing a large number of systems leads to high costs and an excessive amount of time from company representatives as they try to grapple with the flood of information and possibly even software demonstrations from multiple vendors. The winner of the RFP process is often the organization with the best sales process, not necessarily the best product match.
   
   
5. The timeline to select a new system can extend significantly.
   The combination of all of these factors can lead to a much longer period of time to actually select a new system. In some cases, it can be more than three times what would be necessary if only the critical business processes were identified and the most appropriate software vendors contacted.
   

So, what is a better way? The answer can be called different things but is sometime known as a Request for Information, or RFI. It’s concentrated on quality over quantity. The following points will show a direct RFI vs RFP comparison and provide some illumination on how this could work:

1. The most critical business requirements are normally found in the operations group, not finance or IT.
   It is a fact of life that the people who lead the system selection process are most likely to be out of the finance or IT groups. While the choice of technology platform is important, it becomes less so when industries have standardized on some common technologies such as Windows SQL Azure and Microsoft 365 (Office). This becomes a standard requirement that should automatically disqualify companies not meeting this standard. With the rapid changes in technology, companies cannot afford to be reliant on old technology. It might work today but the business also might get left behind by more adaptive competitors. Finance capabilities in available systems have become so similar it is rare that a finance requirement will make a difference to the final choice. Identify the few key requirements from Finance and IT to make sure the considered solutions have the desired base platform.
   
   
2. Identify the current systems users who thoroughly understand the critical business processes.
   As noted in the previous point, the most important requirements will generally come from the operations group. Identify the current operations system users who demonstrate flexible thinking and aren’t just looking to re-implement the current features in the new system. Make them in charge of the process.
   
   
3. Identify who will prepare the Request for Information.
   The documentation should be focused more on processes than specific features. Chose someone with an aptitude for understanding and quickly documenting business processes. This can be an outside person but, if so, find someone with a reputation with either experience in your industry or with a reputation for rapidly understanding the in-depth processes of new businesses. If an internal person, make sure they have both the aptitude for this process and the necessary internal backing to direct the team.
   
   
4. Focus on quality over quantity and identify your key requirements.
   Instead of having hundreds of detail lines in an RFP, the final documentation should result in a few hundred lines supported by information on key business processes. An example of quality over quantity is shown in the following example.

• Quantity questions for Accounts Receivable
  • Does the new system produce an aged accounts receivable listing of outstanding customer invoices?
  • Does accounts receivable integrate with the general ledger?
• Quality questions for Accounts Receivable
  • Can the system produce invoices in an unlimited number of currencies?
  • Can the system generate invoices in multiple languages?
  • Can the system generate intercompany invoices and purchase documents between related company business units set up in different companies?
    
    

1. Thoroughly research available systems most appropriate for the organization.
   Find a selection of industry experts. They may not be part of the organization but it is worth seeking these out. Check out industry groups. Find software reviews. Speak to current users. All before identifying system vendors who represent the solutions. Look for current industry leads and search for the “up and comers”. Identify the technology platforms while you are at it. There is no use picking an old system running with COBOL programming code when all your competitors are moving to a Microsoft SQL Azure database running in the cloud. If you’re not sure about either of those, please feel free to reach out to us and our experts can answer some questions for you. We’re happy to help.
   
   
2. Define a logical selection process and insist that both internal and external people adhere to it.
   Software vendors are notorious for trying to twist the selection process to fit their sales methodology. You get to do this once. They live in this world and have worked with many organizations. Make sure you get what you need and don’t take shortcuts.
   
   

More than one RFP or RFI process has been scuttled by a pretty demo. If you are involving software demonstrations, make sure you are setting the agenda, going into enough detail, and looking at only those areas critical to your business requirements, whether existing or new. That will also make it easier for you to properly compare the solutions afterwards, since you’ll see what you need to instead of each vendor focusing on their shiny tools.

Enjoy the process as much as you can! Changing systems can be stressful but it is an excellent opportunity to improve the lives of the system users and improve business operations. As with any other project, the key to success and reduced stress is communication, both with internal and external stakeholders.

If you are looking to learn more about a centralized, all-in-one accounting, rental management, and operational software solution, contact our team at hi@opendoorerp.com