How to conduct an ERP RFP in 10 Steps

If your company has decided that you need a new ERP system but would benefit from a little guidance on how to conduct the evaluation, let us help you with the steps to follow to improve the chances of a successful end product:

1. Understand and document the intended outcomes
2. Select the Evaluation Team(s) and Team structure
3. Document your workflows and assign weightings
4. Define how you will evaluate vendor responses
5. Select a first-round group of potential vendors (5-6)
6. Construct the RFP document and distribute
7. Evaluate the responses and cut the list to about three vendors
8. Vendor demonstrations and budgeted plan
9. Evaluate the revised proposals and cut list to two vendors
10. Negotiate with two vendors and make final selection

1. Understand and Document the Intended Outcomes

You need to define the business issues you are planning to resolve. This is a “pain/gain” analysis. Define and prioritize the “pains” in your current situation, and the “gains” that you wish to accomplish, including known future business models, if possible. Most of these will be clearly understood except for future business practices, and there, you just need to make sure you do nothing to impede them. Some of your requirements will be demanded to satisfy industry changes and some will be your own company’s needs. Get input from all your business leaders and study the metrics that you have. Once the leadership group understands and commits to these issues then you can begin to identify the teams and the people that will be responsible for selecting and implementing the chosen solution.

2. Select the Evaluation Team and Teams Structure

You will need a Steering Committee, usually comprising senior leadership (to set overall goals, scope, and budgets) and an Evaluation Team that will also serve as the Implementation Team. The Evaluation Team is the critical piece.  It includes the people in all the key workflows that understand the current system best, i.e. the people that you can least afford to assign to this project because they are so essential to how things function today. Nevertheless, get them on the team, and if necessary, backfill with internal promotions or new hires at the lowest level possible. Combine these people with others that can see what may be needed in the future. Select a Project Leader who has some management skills, is not from IT, and represents a group of people or workflows that stands to gain the most from a new system. When the group starts to meet, monitor the group, and make sure that the strong characters don’t dominate the discussion to the exclusion of good input from other sources. You may need to co-opt others from time to time to provide input, but who are not permanent members of the Evaluation Team – you don’t want it to get too big. The Steering Committee also rules on sticky areas of disagreement in the Evaluation Team.  There will be disagreements, and you don’t want to get sidetracked.

3. Document your workflows and assign weightings

In this step, you document the critical workflows in the business, including future workflows where possible. Where there are clear weaknesses in current processes, you need to understand and optimize so you don’t simply automate a poor current process. Documenting key workflows is necessary not just for the RFP, but also for controlled software demonstrations with qualified vendors. It’s also important so the whole Team has a common understanding. You should identify those processes that are part of your company’s core competencies, and differentiate them from those that are less important, and even those that will not be needed in the future system. This stage helps the group understand the benefits of a new system and is a follow-up to the Return on Investment (ROI) document that should be first created to complement the RFP process.  The ROI document quantifies the benefits of the new system and provides the metrics to review project success (or failure) at a later time. Finally, get agreement from the team that these workflow documents accurately reflect the company’s priorities and targets.

4. Define how you will evaluate vendor responses

The output from the previous stage includes details of essential workflows in the new system, and another list of workflows that would be “nice-to-have.” From there, you can develop a scoring system to evaluate vendor responses to your RFP. Not all “must-haves” are created equal.  We recommend that you divide the “must-have” workflows into three categories: those where there is no room for divergence, and which get the highest weighting; those that are important but that may be accomplished in different ways; and finally those workflows where you have a good deal of discretion about how you achieve the objective, and which may get the lowest ranking of “must-haves” in your evaluation. This forms one part of the multiplier to rank each vendor’s response. The other part of the multiplier is the vendor’s score for each detailed requirement in your RFP document. For example, you would assign a high score to a requirement that is fully met by a vendor’s current software, a lower score where the vendor can basically meet it, a lower score again for where a vendor can meet the requirement with customization, and no score where the vendor cannot meet the requirement with their current software. The product of the two will give you a score for each requirement for each vendor, which, when totaled, will properly represent how well they can meet your weighted needs.

5. Select a first-round group of potential vendors (5-6)

At this point you are ready to select the vendors to whom you will send the RFP document. The ideal candidates are established international companies that can provide a full complement of software, implementation services and ongoing support, and who are engaged in the publishing industry with existing customers in your sector. It is important to focus on your business requirements at this point and less so on the technology that any vendor espouses, however you must check that the technology used by any vendor is mainstream and does not pose any undue obsolescence risk.  Your list of vendors can be gathered from internet searches and other industry sources and should include only vendors for which a rudimentary search of public information on financial stability provides no red flags.

6. Construct the RFP document and distribute to vendors

The RFP provides details on your contact person for the evaluation, deadlines for submittals, and schedules for questions, consultations, and software demonstrations. Include your company background, a requirements summary, critical success factors, scope, and pain points, and any future business needs. You should ask for references (although you should expect that some vendors will not want to provide contact details until later in the process). Provide data volumes and growth estimates.

The RFP should request sample license agreements, website information, financial information, support capabilities and locations.  Notify vendors that you plan to interview support and consulting staff at the appropriate time. State your implementation time-frame requirements, any technical constraints, deadlines, and any penalties for late delivery.

Then you provide a formatted list of detail requirements (workflows and data), requesting specific answers that are limited to, for example:

• whether the vendor can satisfy the requirement “out of the box”,
• can satisfy the requirement with some limitations,
• can satisfy the requirement with minor modification,
• can satisfy the requirement with modifications, and
• cannot satisfy the requirement

You will have devised a scoring scheme for each of these possible responses and must follow up on responses that cannot be fully met “out-of-the-box,” to validate what vendors have claimed so you can assess the risks and costs in each case.  Lastly, ask the vendor to describe separately, in their own words, why they think they are a good candidate and what their differentiating qualities may be for this project.

7. Evaluate the responses and cut the list to about 3 vendors

Remember that the purpose of the RFP is to cut the options to the best three vendors to move to the important stages, which are detailed software demonstrations and subsequent consultations. The most crucial single characteristic of the best vendors at this point is whether and how they meet your detailed requirements list –  you can get a good idea of support and implementation capabilities later. Do the math, consult with your team, and select the short list of three final vendors.

8. Vendor demonstrations and budgeted plan

Now the real work begins. Judge the vendor demonstrations based on how well they perform your key workflows, and that means preparing detailed scripts that each vendor must follow. You may also allow vendors to additionally discuss and demonstrate issues that they consider important, but remember, they are going to present their best features here, so limit their time and reserve ranking points only for your scripts. With some vendors, you may need to demo more than once to eliminate any issues unresolved from the first round. Attendees should be the Project Team, plus occasionally additional SMEs for specific functions. Create a timed agenda for the demo and appoint a senior person to be the timekeeper. Vendors will want to follow up after the demo, and you will need to remind them of the allowable points of contact within your company or the “back-and-forth” may become overwhelming. You will also need to hold meetings with each vendor on implementation methodologies, consulting, and support, during which you should interview the consultants that the vendor has identified for your company’s implementation and support programs.

At this point, you will have begun to discuss detailed implementation schedules and a total project budget. This will entail several events and discussions with each vendor. Remind yourselves and each vendor of the original scope and objectives (assuming you have not modified them during the process), because each vendor will have a different solution and you must keep focused. It will begin to become clearer now which vendors offer the best, least risky solution.

9. Evaluate the revised proposals and cut list to two vendors

Now, reduce the list to two vendors as it will become too time-consuming to continue with more. You will have all the information you need on product fit, and each vendor’s implementation and support plan and budget. You should visit vendor references with members of your project team (the same members should make each visit) and dig more deeply into the financial stability of each vendor. Remind your company representatives now to limit communications with vendors so as not to divulge too much information prior to negotiations.  This will be challenging, as by now, there may be strong and diverse opinions amongst your team for each vendor. Final consensus in the team is the goal now.

10. Negotiate with two vendors and make final selection

Having made your final decision and obtained agreement from the Steering Committee, it is time to negotiate a final schedule, scope, and budget with both vendors. If you must do it consecutively, start with the weaker vendor. Although this is basically a quantitative decision, the (estimated) costs that you are working with at this point are not everything, and it is still important to reflect on which vendor your team is more comfortable with, and which solution offers the least risk, based on the quality of the staff, the credibility of the vendor, and the solution fit. Some of these issues may be resolved in reference visits but remember that a vendor is not going to recommend a visit to a customer that is not an advocate. Gather as much impartial information as you can and go with the people who have demonstrated sincerity and authenticity, with people that you all feel you can work with. You are ready to go!

knkPublishingSoftware.com

 Image by jcomp on freepik