Is an RFP Necessary for an ERP Project? What SMEs Need to Know
When large companies start an ERP project, they’ll typically send out an RFP (request for proposal) to get more information from potential vendors. Then they’ll review the responses and narrow down their options to a short list that they want to provide demos.
But what if you’re a small to mid-size company – does an RFP still make sense?
While most SMEs (small to mid-size enterprises) opt to evaluate ERP on their own, there are cases where an ERP request for proposal makes sense. My goal here is to help you understand the pros and cons of both approaches to ERP evaluation and guide you to the option that makes the most sense for your business.
A look at what's included here...
Option 1: Using an RFP to Evaluate ERP Software
Why do companies use an RFP process for ERP projects?
A request for proposal is a way to collect more information from potential vendors on how their ERP solutions will work for your business. Typically, this is done through an ERP consultant – a third-party that you hire to help you evaluate software options. Keep in mind that you could get responses from ERP vendors that publish the software or ERP partners that sell, implement and support the software.
In our experience, there are a few common scenarios that drive the decision to use an RFP process.
- You aren’t clear on the value of ERP. In this case you’ll rely on the ERP consultant to educate you and seek out information from vendors to prove the value.
- You aren’t sure how to find the right ERP solution. It’s one thing to review the features each software promotes, but it’s another to dig deep and determine whether the functionality truly meets your needs. An ERP consultant can help you define your requirements, so each vendor response speaks directly to them.
- Your business is large and has complex processes. This is less common in the SME space, but there are companies with enough complexity that an RFP is useful. Working with an ERP consultant can also be helpful if you need a third-party to guide conversations among larger teams (particularly if they’re not all on board with an ERP project).
- Individuals involved want to mitigate risk. Many people have heard horror stories about ERP projects gone wrong. So, it’s natural for individuals to be nervous about taking on the responsibility of owning the selection. Working with an ERP consultant can be seen as a way to mitigate that personal risk.
What’s the advantage of an RFP?
Leveraging the knowledge and expertise of an ERP consultant is one of the biggest advantages to an RFP process. They can provide guidance on the process and connect you with ERP partners they’ve had good experience with in the past.
While ERP consultants are thought to be objective, remember that they’re also human. They can have their own biases toward certain ERP solutions and partners. So, choose your ERP consultant carefully – you want one that you trust has your best interest at heart.
Here are a few of the other pros for an RFP:
Rather than spending hours reviewing ERP vendors’ websites, you tell the vendors what you need, and they’ll tell you if they can meet the need or not.
A request for proposal forces you to organize, articulate and document your requirements, so you know exactly what you’re looking for in an ERP system.
Having detailed requirements provides a solid basis for scoping and design when you get to implementation.
You’ll get a feel for the vendors and ERP partners based on how they respond to the RFP. Pay attention to items they didn’t respond to, the level of detail they use and how the response is presented. You can usually tell if they put some real effort into the response or simply made a few tweaks to a templated response.
What’s the downside of an RFP?
Earlier, I mentioned that some companies use a request for proposal to mitigate the risk of being responsible for a failed project. The interesting thing is that an RFP can also introduce risk in another way.
Sometimes the best partners won’t respond, and you lose out on the opportunity to evaluate a good candidate.
Why wouldn’t they respond?
Because preparing RFP responses is time-consuming. Most ERP partners will only respond to ones that they know are a good fit (which requires crystal clear requirements). And many partners won’t respond if they can’t talk to either you or your ERP consultant to clarify questions. It’s tough to put their best foot forward in the response if they don’t fully understand your business.
Here are a few other RFP downsides to consider:
An RFP process adds cost. You’ll pay for your ERP consultant’s time, plus there’s an indirect cost of your team’s time. Outlining requirements, preparing the request for proposal, reviewing responses…it all takes time. Some of this is unavoidable, even if you handle the evaluation yourself, but the cost is certainly higher with this approach.
Sometimes ERP consultants have a short list of their ‘favorite’ solutions. These may or may not be the best fit for your business. Make sure you understand why the consultant is putting each solution in front of you.
Even with a solid requirements list, there’s nuance to your processes that’s tough to communicate in a written document. Typically, an ERP partner would uncover this during discovery, which happens before the demo. In an RFP process, the demo is based purely on your RFP document. It’s likely that you’ll have to go back and do some form of discovery after the demo based on things that come up in conversation.
Evaluating ERP through an RFP process can take more time. The point above is just one of the reasons. You often end up doing multiple demos because the ERP partner doesn’t have an opportunity to do a proper discovery first.
What are the common RFP mistakes to avoid?
If you decide to go ahead with a request for proposal, how do you make that process go as smoothly as possible? Understanding what derails an RFP is the best place to start. Here are some common mistakes we see. Avoid these and you’ll be in good shape.
Lack of support at the executive level. If your senior team isn’t on board with an ERP project, you’re more likely to spend a lot of time evaluating solutions, only to not select one at all. Make sure the person signing the cheque is fully behind the ERP project before you get too far down the path.
Setting unrealistic expectations. Often, we see this come up in the timelines. Companies don’t allow enough time for the selection process, and then they continually delay key activities or the decision. Give yourself enough time (considering other projects and activities), then stick to your timelines – no exceptions.
Not outlining the must-have requirements. If ERP partners can’t tell from your RFP which requirements are essential to a successful project, they’ll have a harder time creating a demo that really speaks to your needs. Rank your requirements as must-have, nice to have and non-essential to help partners disqualify themselves. This works to your benefit so you can focus on responses that will be best fit for your needs.
Lack of clarity on your objectives for the ERP project. For an ERP partner to craft the best RFP response, they need to understand what’s going on in the business that makes you think you need ERP. Clearly outline the objectives – how you’ll know if the ERP project is successful. If you can quantify it, even better.
Providing lengthy Excel sheets with functional requirements. Outline your requirements in enough detail that ERP partners can understand what you need, without overdoing it. The information in your RFP should be useful and necessary – if it’s not, remove it.
Asking for a full proposal without a discovery. Even with the most detailed RFP, an ERP partner won’t get the full understanding of your business until they do a discovery session with you. Only then can they recommend the best solution and provide a proposal.
Option 2: Managing Your ERP Evaluation Internally
What’s the advantage of evaluating ERP on your own?
Most small to mid-size companies choose to evaluate ERP software on their own. They pull together a team internally, assign a project champion and start searching for solutions. Typically, this approach tends to be faster, more efficient and more cost-effective. You won’t have the added cost of an ERP consultant and you can make decisions faster with a tight internal group.
You also benefit from the expertise and best practices of the ERP partners or vendors that you evaluate. We’ve talked about the importance of discovery – this is perhaps one of the biggest advantages of engaging partners directly. They’ll use their experience to ask the right questions and dig deeper to uncover your requirements and understand your processes. Most importantly, they’ll get to know your people and your culture, which is equally important to software requirements (if not more so).
What’s the downside of evaluating ERP on your own?
If you don’t have a clear buying process, it can be easy to get off-course. Luckily, if you want to do the evaluation yourself, there are tons of resources available to help you through the process. Our SME Guide to Selecting ERP is a great place to start – it answers the most common questions and lays out a roadmap for choosing ERP software.
A few other things to consider:
You’ll spend more time researching solutions and ERP partners.
You’ll do a discovery with each provider, instead of just providing a list of your requirements for them to speak to. This can get repetitive for your team and has the risk of taking extra time. We recommend narrowing it down to two or three providers before you engage them for a demo. Any more than that can be overwhelming.
You could end up evaluating multiple ERP partners that sell the same solution. The downside here is time. But vetting your partner is an important step and it’s a choice you want to get right. So, the time is well spent.
To do an RFP or not to do an RFP?
In our experience, an RFP typically doesn’t make sense for smaller companies (think $5 million to $30 million in revenue). Even above that threshold, it’s dependent on the complexity of your business processes and how comfortable you are handling the process internally. Consider how much control you want over the process and what level of responsibility you want to take. That will help you decide.
The big takeaway here is that you can create a blend of both approaches that gives you some of the rigour of an RFP process, without the added time and cost. If you can articulate and document your requirements before you engage ERP partners, your conversations will be that much more productive. The same can be said of how you approach your demos – going in with a list of requirements and a scoring method will provide a framework for your team to evaluate fit of the solution and the partner.