A company often comes to the realization that their existing systems are constraining growth. They may also be unreliable, dependent on manual input, etc. There is little debate that modern ERP software will help … but what’s the best way to get there?
Unfortunately, many companies believe that an ERP request for proposal (RFP) is the way to begin. 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:
Does your company have the technical ability to build and evaluate an RFP effectively?
An RFP should be built on solid requirements. Your company probably has a good idea of business processes (as it’s 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 import “requirements gathering” piece right.
I’m not knocking your employees or IT department – and God forbid you delegate it to your procurement department, which has probably never purchased anything as complex as ERP software and services. So, will you get real value from the time and expense involved to execute the RFP process? In most cases, the answer is no. It could even lead to the selection of the wrong software.
There are many steps that should precede any talk of software. A clear digital strategy and a define 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 RFP tools that reflect your company’s unique needs because every company is different. So, 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.
We prefer the interactive request for information (RFI) process to the traditional RFP process. It allow us (on behalf of our clients) to evaluate many software vendors. Our proprietary database puts an element of science into targeting vendors that play in your industry space.
For example, if your company does injection molding, we probably 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. Contrast that level of detail and communication with what you get in the question and answer format of a traditional RFP.
Does the RFP with the most “yes answers” win?
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 right questions 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 top ERP systems 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 an RFP needs to validate is the fit/gap analysis that identifies all areas in which the standard version of the software does not meet the defined business requirements and recommends an approach to addressing those gaps through configuration and customization. Most RFPs don’t handle this well. Then you 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.
Perhaps I’ve made my point – a report called an RFP often falls short of the guidance you’ll need and is often inefficient at best. There are much better ways to be investing in your ERP evaluation and selection process.
At Third Stage we are seeing a trend of software vendors declining to participate in the RFP process. They too do not see this as good use of their time or may perceive the customer as not focused on the right things.
Vendors recognize that there’s a low correlation between the RFP and a successful ERP implementation. This is especially true if the vendor feels or hears that the RFP is being distributed to many firms. In addition to the time and money you’ll spend creating an RFP, the mechanism itself may dissuade some of the more successful software vendors from participating.
I can’t emphasis enough the path to “getting it right” is having the right partner. We’d be glad to have the RFP conversation with you and contrast it with other creative ways that we can point you toward success.
Please feel free to contact us to brainstorm the best ways to structure your software evaluation process. We are happy to be a sounding board as you continue your transformation journey!