ERP Blog | Videos | Podcasts

Writing an RFP for an ERP Project? Avoid These 5 Stumbling Blocks

Written by Shawn Windle | Jan 24, 2019 11:25:57 PM
Writing a request for proposal for an ERP project is not for the faint of heart. Even experienced IT and project managers struggle with the task. It may well be worth enlisting the expertise of an independent ERP consultant to guide you through this process or offer other options. In this blog we’ve outlined five stumbling blocks we have seen companies inadvertently create for themselves.

Writing a request for proposal for an ERP selection project is not for the faint of heart. Even experienced IT and project managers struggle with the task. It may well be worth enlisting the expertise of an independent ERP consultant to guide you through this process. In this article, we’ve outlined five stumbling blocks we have seen companies inadvertently create for themselves.

1. Not providing enough company background

For optimum results, help your vendors help you. They need to understand your business. You don’t want them to have to search your website to try to understand your company. Give them an insider’s perspective.

Begin an RFP with a detailed overview. This should include where you are and where you want to be in the future. Take time to describe your workforce, how your business is growing (or not), and your customer base. Be sure to include:

  • High level pain points:
    Example: Low inventory continues to plague the production floor as vendors continue to miss delivery dates for raw materials.
  • A sense of where you fit in your industry:
    Example: We are the second largest US based manufacturer of O-rings, and what sets us apart is our ability to make unique sizes and colors.
  • Who will be working on the initiative from your company:
    Will it be defined as an IT project or a company initiative? Who is the project sponsor and is there an oversight committee? Will internal resources be part-time or full-time? How will success be measured?

Poorly-crafted RFPs don’t do this well — instead, they tend to focus on elimination points or checklists. When writing a comprehensive company background, you don’t need to give away your “secret sauce,” but you certainly need to be open. Taking time to do it right will also challenge your internal project team to examine your company’s landscape. The more inclusive, the more likely you are to get quality responses from potential partners and vendors.

2. Neglecting to fully explain your current ERP system landscape

Effectively explain what systems and software you are currently running. Describe why you’re switching and what you hope to achieve. What are your assumptions about the risks vs. rewards of new software? Be sure to communicate your real goals to educate vendors about changes you are targeting. Document what you have today, why you’re switching and what your end goals are.

For example, be transparent if there’s an underlying cause, such as you’re looking to raise capital and need more robust internal controls and a developed financial reporting system. This documentation should help ensure your needs are articulated and help eliminate gray areas.

3. Thinking a detailed list of requirements is enough

While clear RFP technical requirements are important, creating an effective demonstration script is more important. The script should hone in on the functionality you are seeking. Modern ERP software can handle standard business processes (think finance, procurement, human resources, etc.), but it doesn’t know how you want your business to operate — and it can't anticipate unique workflows.

Vendors need to show you exactly what their applications can do via a defined script. A script also helps keep vendor responses consistent. It’s important to keep them on track.

You want the vendor to demonstrate if their software can or cannot perform defined functions. If it can’t, you may need to bring in another tool, customize or choose another software. You want vendors to show how requirements would be executed in real time. If you rely on just a list of requirements, you risk the vendor checking off a set of “yes” or “no” boxes, which in the end might not be terribly helpful.

4. Not understanding your total costs

One of the goals of an RFP is to get a high-level cost estimate early in the process. Less than one third of ERP software implementations come in on or under budget, and the reasons vary as to why. For example, your company may ask for unplanned customizations to meet various business needs. Or perhaps the variables related to software acquisition and deployment weren't fully understood.

Software contracts are complex. Expect a contract to contain a multitude of costs besides the software itself, such as ongoing maintenance costs, licenses, etc. Vendor agreements are not one-size-fits-all and are negotiable, but you need to know what and how to negotiate. You’re not only attempting to understand your current purchase, but how the decisions you make now will impact future updates or releases. You want to fully comprehend the incremental costs you will incur.

Also consider what happens to your ongoing costs if your company grows. What you negotiate today will have an impact well into the future. An independent ERP consultant can be invaluable in helping to understand, negotiate and modify a contract designed to work in your favor. This could include incorporating concessions and throw-ins you might not know were possible.

5. Not fully understanding the team you will be working with

The person who is attempting to sell you software or services is destined to disappear once the sale is finalized. You are then turned over to a service/implementation team. Since you will spend the duration of the project with this team, insist on meeting them and getting them involved early on — before you sign a contract. In a sense, you’re “interviewing” them for technical and cultural fit. This is a very important step that should not be skipped.

The service/implementation team should be able to discuss your pain points and provide technical insight into how their software will or will not accommodate your needs. Ask for examples of where they’ve implemented this software in your industry and ask for references. Determine the specific experience of each person in the group. Are you getting the “A” team or the “C” team? You want to end up with the right people who along with your own internal team will be accountable for success. If you don’t feel good about the team don’t be afraid to call a time out. The seller may be able to substitute other resources, or maybe it’s just not a good fit.

Summary

The cost, time and demands of the RFP process may or may not be the best path for your organization. If you think an RFP is your only good option, talk with us. We’ve introduced other streamlined methodologies with proven results. We didn’t get to be one of the world’s most trusted ERP advisors without learning a few efficiencies along the way.