Choosing a new ERP is one of the most expensive decisions a mid-market and enterprise company makes. You (hopefully) do it once a decade. So it understandably gets the treatment you would expect for a decision that size. A formal request for proposal. A scoring committee. A long list of requirements, weighted and tallied. Demos from the finalists. A spreadsheet that, at the end, helps crown a winner.
It feels like real diligence. It is, in a way. But most of the time, it is primarily designed to measure the one thing that doesn’t determine whether the project succeeds.
On the features a committee actually scores, the major platforms have mostly caught up to one another. Which means you’re grading the software vendors on capabilities that every serious contender shares.
Where platforms genuinely differ is in how well they fit your industry and your real workflows. Companies like Infor have gone hard into making sure they service industry micro-verticals for this reason.
But fit is only part of the story. The partner who implements the system and the way you run it after go-live decide success or failure at least as much as the software itself. We all have heard about ERP implementations that go off the rails. In nearly every case, the technology wasn’t the problem.
When your RFP process assesses the vendor’s list of features and not the outcome you’re trying to achieve, problems often are the result. In this article I want to propose three questions you can ask to avoid this issue.
The selection process is built to do a different job than you think
The RFP process is generally done by procurement. It’s a major part of what they’re hired to do. And I’m not knocking them – I’m simply acknowledging who owns the process. But it’s important to understand their incentives.
This isn’t a criticism of procurement. Procurement is doing exactly what it is supposed to do: reduce commercial risk, create a fair process, and protect the company from making a bad purchasing decision.
All of those are reasonable goals. But none of those goals relate to choosing the partner most likely to deliver tangible business value.
The result is that most RFPs become a feature checklist, scored by committee. A beauty pageant, basically. Each finalist parades its capabilities, the committee gives them points, the highest score wins. That number mostly reflects how well each vendor performs in a demo, not how the software will behave inside your actual operation two years from now.
Common RFP pitfalls, and what they have in common
There are a number of downstream issues that are (usually) consequences of this process:
- Everyone’s requirements get equal weight. When you collect input from every department and treat item as roughly equal, you get a compromise built to please everyone and serve no one in particular. But you’re selecting an ERP to accomplish a strategic objective. Good strategy typically requires trade-offs. It’s hard to equally be everything to everyone and to do all things well. You have to make decisions.
- Workflows, not tasks. RFP requirements often ask whether the system can perform certain tasks. Can it support lot traceability? Can it handle landed cost? Important questions. But businesses don’t create value through tasks. They create value through end-to-end processes. Generating an invoice is necessary but insufficient. What you really want is to move an order from quote to fulfillment with fewer errors, less inventory, and better customer service than competitors. You don’t just need to be evaluating functionality, you need to evaluate how it will impact your ability to operate.
- The person across the table is paid to close. Most account executives are compensated on a license quota. They are not bad actors, they again are creatures of their own incentives. And their incentive is to close the software deal as quickly as possible. If the recommendation turns out to be wrong, what happens to them? Usually nothing.
- The selection adviser is often just another software person. Plenty of companies bring in an outside adviser to run the process, which sounds like a safeguard. But selection consultants are not industry strategists. They usually run a transactional, feature-first process, and don’t understand specialized platforms or the edge integrations that unlock real value, like warehouse management, manufacturing execution, and EDI. There is a reason for that. It is simplest for them to define their role narrowly, around software features, and steer toward the path that carries the least risk for them. Sometimes that means skipping the services and implementation question altogether, which is the part that actually decides whether you succeed.
- The cloud is oversold. Software-as-a-service is often pitched as all-inclusive. Move off-premise, lower your operating costs, and let us manage and support the whole thing. But reality usually is more complicated than that. You’re likely to see a responsibility matrix with hundreds of tasks that are still yours.
- There is such a thing as RFP fatigue. By the time a procurement-driven selection reaches the finish line, the committee is tired. It’s a slog. They kinda don’t want to think about implementation and support, and tend to just trust whoever the winning brand recommends. Arguably the most consequential part of the decision gets made on fumes.
Notice that every one of these forces is about people and incentives. Not one of them is something the RFP scores. This is why two companies can select the exact same ERP platform and experience completely different outcomes.
Three questions to increase your odds of success
You don’t need a longer checklist. What you need are different types of questions, ones that focus on services partners in addition to product platforms.
The following are a few questions I suggest baking into your selection process:
1. Which six-to-eight value streams must this deliver?
If the goal is not simply selecting software but improving business performance, the evaluation process has to revolve around the handful of workflows that actually create value. I’ve found It’s typically around 6-8 items.
Define the handful of end-to-end workflows that actually carry your business value. For a manufacturer, that might be forecast-to-production, make-to-order fulfillment, inventory replenishment, quality management, and customer-specific shipping requirements. For a distributor, it might be procurement, warehouse execution, EDI-driven order processing, inventory allocation, and order-to-cash.
The exact workflows vary by industry. That’s the point.
This question creates focus. It forces your own team to agree on what matters most. It’s hard to do, which is probably why teams avoid it. But the pain of a botched implementation is way worse.
Once you have those questions, make each vendor prove they can help with those workflows. Ideally with your data and your scenario, not a generic demo dataset that was built to make the software look good.
Some ERP vendors (like Infor) have increasingly moved toward industry-specific value-stream selling for exactly this reason. They recognize buyers are purchasing the ability to execute a small number of critical workflows better than they do today. The more the discussion centers on those workflows, the more likely the selection process is to surface meaningful differences between platforms.
Doing this requires that everyone is on the same page though, including procurement. You have to make sure that they know you’d prefer a system that runs your real value streams beautifully and handles the rest adequately vs. a system that scores well on everything but is great at nothing.
2. Who is contractually accountable for making them happen?
Build strategic partner due diligence into the procurement process from the very start, and do so with the same seriousness you bring to the software scoring. Some useful questions:
- How long have you operated under your current brand? Companies that have rebranded recently are often hiding a history worth asking about.
- What is your resource tenure and attrition? High turnover means the experience you are buying might leave midway through your project.
- Will the people in this room be contractually named to our project? This is the single best defense against the A-team-then-B-team switch. If they’re not willing to name names in the contract, you have your answer.
- Do you have a demonstrable body of work in our micro-vertical, and references we can actually call?
- Are you positioned, geographically and across time zones, to support our team when we need you?
3. Who is responsible for keeping it running?
This one is about making sure you have a plan for how the system will be supported and staffed once it’s live. You can’t treat support as a problem for the future. Figure out, from the beginning, who can run the warehouse management, manufacturing execution, and EDI connections that hold your operation together. Who is going to continue to support you once the implementation team moves to its next project.
The answer might be your internal team. It might be a partner. It might be a mix that shifts over the first year. Any of those can work. What does not work is punting on the decision until things are on fire. Your ERP is not a fixed asset – you can’t treat it as such.
What you are really choosing
Choosing an ERP is not really a technology project. It is a strategic decision about how your business will run for the next decade. The software is certainly an input. But so are the consulting partners who stand it up, and the operating model you build around it.
If you are going to run a selection in the next year and you would value an experienced second set of eyes on your requirements, your charter, and your staffing model, we’d be happy to chat.
