Many companies falsely believe that an ERP request for proposal (RFP) is the only or best way to begin their journey to finding a new ERP system. As an independent ERP consultancy, we can tell you that we consistently find that there's is a low correlation of using an RFP to ensure ERP success. With an RFP, ideally, you’re trying to outline (via a series of questions) what new system capabilities you will get when selecting new technology.
Here’s why this approach doesn’t usually work:
An RFP should be built on solid requirements. Your company probably has a good idea of business processes (as they’re done today) and some ideas about what you would like to see new software do. However, most companies don’t have the time or expertise to get the very important “requirements gathering” piece right.
Additionally, your procurement department (where RFPs first originated)has probably never purchased anything as complex as ERP software and services. They may have had success with RFPs to secure and service office equipment (think copiers, telephones, computers, etc.) which is about vendor performance on dissimilar office equipment. The complexity and moving parts of an ERP initiative are not comparable (or negotiated in the same way) and companies should not expect a procurement department or project team to have the needed expertise. The ERP software landscape is a constantly changing environment.
Will you get real value from the time and expense involved to execute the RFP process? Will the RFP be focused on the key requirements vendors will need to meet? In most cases, the answer is no. It could even lead to the selection of the wrong software. One of the primary goals of the RFP is to try to measure the degree of understanding vendors have of your initiative, and if their software solutions match priority needs while keeping customization in check.
Keep in mind there are many steps that should precede any talk of software. A company strategy and a defined phase are a couple of crucial topics that need to come first. A best practice looks something like this: Strategy, Define Phase then RFP (if you must). A qualified independent ERP consultant will be worth their weight in gold to help ensure and build the steps that will make an RFP effective. ERP consultants are experts at building palatable RFP tools that reflect your company’s unique needs because every company is different. In addition to designing an effective RFP, a company like Third Stage Consulting will walk you through how to evaluate the output in an unbiased way.
There’s a common misconception companies have that goes like this: If your company builds an RFP the right software vendors will come. This is not true in today’s competitive environment. There is more need than there are highly qualified resources, so software vendors are picking and choosing companies and demos they feel fit their wheelhouse best. Like your company – software companies also have limited resources. Look at it this way – if Oracle (or pick any reputable software brand) has 40 companies in the Denver area looking for completion of a time-consuming RFP, followed by detailed demos, they probably won’t accept the invitation to participate in all cases. Exhaustively constructed over kill-type RFPspoint to decreased participation. Or possibly worse yet, what if a company agrees to participate but your initiative is assigned to their “C-Team” which may not be readily apparent to you?
We prefer the interactive request for information (RFI) process to the traditional RFP process. It allows us (on behalf of our clients) to evaluate many software vendors while promoting open communication during the process. The RFP is more like a “structured test” whereas the RFI allows for listening and clarifying collaborative conversation that could lead to partnering.
Our proprietary database introduces an element of science into targeting vendors and software that play in your industry space – and will most likely suggest some software brands your company might not be familiar with. If your company does injection molding, we have a good idea of which software companies perform well in that space. It’s a far more interactive process that really gets to the heart of determining what software will be most beneficial for your company. We talk about possible solutions and roadblocks with the most viable vendors – in contrast to the question-and-answer format and dampened communication of an ill-constructed RFP.
Think of how inefficient this process can be. You are encouraging different software companies to tell you what you want to hear. What if you haven’t asked the question right or in enough detail? What if the answers to your questions aren’t truly how the software is configured to work? This process is better suited to buying a photocopier than a complex ERP system that theoretically will touch all aspects and departments of your company. Today’s software offerings can meet a host of challenges, but some can do it far more efficiently than others and deciphering fit is not easy.
I like to use this analogy when talking about an RFP: Is the real estate broker that got the best score on their real estate licensing exam the best person to sell your house? Maybe not … because you’ll want a resource that intricately understands the market, has proven experience, asks the right questions, identifies risks, negotiates hard for you, etc.
One of the most critical deliverables RFP needs to validate is the fit/gap analysis that identifies areas in which the standard version of the software does not meet the defined business requirements and recommends an approach for addressing those gaps via configuration and customization. Most RFPs don’t handle this well. You also have less obvious non-functional requirements or specifications that relate to elements of architecture, speed or performance of the system, integration to other systems, support of the system, maintenance agreements, and organizational partnerships required to get and keep the system live.
Point made – an RFP often falls short of the guidance you’ll need and is often inefficient at best.
At the Third Stage, we are seeing a trend of software vendors declining to participate in the RFP process – a point touched upon earlier in this blog. They too do not see this as good use of their time or may perceive the customer as not focused on the right things or difficult to work with. Do vendors recognize that there’s a low correlation between the RFP and the actual work that needs to be done (what haven’t you told them)? This is especially true if the vendor feels or hears that the RFP is being distributed to multiple software firms. In addition to the time and money, you’ll spend creating an RFP, the tone, length, and format may dissuade some of the more successful software vendors from participating.
The path to “getting it right” is having the right independent and experienced partner in your corner. We’d be glad to have the RFP conversation with you as well as discuss the other creative ways we can help point your company toward success.
