Most ERP selection projects do not fail because the team picked a bad piece of software. They fail because the criteria used to compare vendors were vague enough that any of the finalists could claim to satisfy them, and the decision came down to whichever salesperson presented best.
Selection criteria only earn their keep when they are specific enough to produce different scores for different vendors, and weighted so that the criteria that actually matter to your business carry more weight than the ones that are just nice to have.
This article covers the ten criteria worth evaluating, how to turn them into a weighted scoring matrix instead of a checklist, the real vendor selection process and how long it actually takes, and what industry research on ERP project failure says about which criteria matter most.
What is ERP?
ERP is an abbreviation for Enterprise Resource Planning. Different industries use ERP software to manage and automate core business processes such as accounting, finance, HR, and operations.
As a result, ERP software can help businesses streamline their operations and improve efficiency by integrating these various business functions into a single system.
To learn more about ERP, check our blog post “What is ERP“.
Selection criteria for ERP system
These ten criteria cover what actually differs between ERP vendors. The next section shows how to weight and score them instead of just checking each one off.
1. Objectives and requirements
Start from the business outcome, not the feature list: what specifically are you trying to fix? If the goal is faster order-to-cash, you need visibility into order status and customer history. If the goal is lower carrying costs, you need real inventory forecasting and reorder-point logic. A requirements list built from generic “must integrate everything” language cannot later be scored, because every vendor will claim to satisfy it.
2. Budget and total cost of ownership
The budget depends on company size, process complexity, and how much functionality you actually need, but the number to negotiate around is total cost of ownership (TCO), not license price. TCO includes the initial license or subscription, implementation and data migration, ongoing support, upgrades, and training, and the implementation and migration line items are usually where budgets actually break, not the software itself.
3. Technical fit and user adoption
Technical fit covers system architecture, platform, customization depth, and implementation complexity.
- Architecture: how the system is built, for example client-server versus web-based/cloud-native.
- Platform: the underlying infrastructure the system runs on.
- Customization depth: how far the system can be adapted to your processes versus how far your processes need to bend to the system.
- Implementation complexity: how long and involved the rollout is expected to be.
- User adoption: how quickly staff can realistically learn the system, which matters more than feature count if the workforce resists using it.
4. Integration
The ERP system needs to interface cleanly with what already exists internally (accounting, production, HR systems) and externally (supplier EDI, customer-facing order status). Poor integration is what turns an ERP rollout into a set of disconnected systems held together by spreadsheets, so ask vendors for named, working integrations with your specific existing systems, not a generic claim of “open API.”
5. Deployment options
On-premise systems run on your own servers. You get more control, at the cost of a larger upfront investment and ongoing infrastructure maintenance.
Cloud-based systems are hosted by the vendor and accessed through a browser. Typically cheaper upfront and faster to implement, with less infrastructure control in exchange.
6. Internal system requirements
An on-premise system is only realistic if you already have the IT infrastructure and staff to run it. Without that, a cloud-based system is usually the more honest choice, not because on-premise is worse, but because the internal capability to support it does not exist yet.
7. Future scalability
The system, and the vendor, need to grow with the company. Check the vendor’s release cadence and roadmap, not just current features, since a system that fits today but has no clear upgrade path is a two-to-three-year problem, not a permanent solution.
8. Support and training
Confirm what implementation and ongoing support actually looks like, not just that it exists: response time commitments, whether support is included or billed separately, and whether training is a one-time event or an ongoing resource as staff turn over.
9. Industry expertise of the vendor
A vendor with real experience in your industry brings pre-built workflows and fewer surprises during implementation. The tradeoff: a vendor that is too narrowly specialized in a different segment of your industry may force you into someone else’s process rather than yours, so weigh relevant experience against configurability rather than treating “industry experience” as an automatic plus.
10. Vendor stability and references
Once the criteria above are set, the remaining differentiator is the vendor itself: financial stability, how long they have supported the product, and reference customers of a similar size and industry you can actually call.
Turning criteria into a weighted scoring matrix
A checklist tells you whether a vendor meets a criterion. It does not tell you by how much, or whether that criterion should have mattered as much as another one. A weighted scoring matrix fixes both problems and is the standard tool procurement teams and ERP consultants use to turn a shortlist into a defensible decision.
- Assign a weight to each criterion so all weights sum to 100 percent, based on what actually matters for your business, not a generic default. A company migrating off a 20-year-old on-premise system might weight technical fit and data migration risk heavily; a fast-growing company might weight scalability and integration higher.
- Score each vendor 1 to 5 on each criterion (5 = fully satisfies the requirement with clear strength, 3 = adequate with gaps, 1 = significant deficiency), based on demos, RFP responses, and reference calls, not the vendor’s own marketing claims.
- Multiply each score by its criterion’s weight, then sum across all criteria to get one comparable total per vendor.
A simplified example, weighting four of the ten criteria above:
| Criterion | Weight | Vendor A score (1-5) | Vendor A weighted | Vendor B score (1-5) | Vendor B weighted |
| Technical fit and integration | 35% | 4 | 1.40 | 3 | 1.05 |
| Total cost of ownership | 25% | 3 | 0.75 | 4 | 1.00 |
| Industry expertise | 25% | 5 | 1.25 | 3 | 0.75 |
| Support and training | 15% | 3 | 0.45 | 4 | 0.60 |
| Total | 100% | 3.85 | 3.40 |
Vendor A wins here despite a lower cost score from Vendor B, because the criteria this business weighted most heavily (technical fit and industry expertise) favored Vendor A. That is the actual point of weighting: it stops the cheapest or best-presented vendor from automatically winning a comparison where cost was never the top priority.
A common, sensible sequence for the shortlist itself: start from 6 to 10 vendors based on market research, narrow to 3 or 4 for full RFP responses and scored demos, then take the top 2 to reference checks and final negotiation. The matrix should inform the decision, not replace judgment; a vendor that wins on paper but fails reference checks is not the right choice regardless of its score.
ERP vendor selection process
The selection process of an ERP vendor typically involves the following steps:
1. Requirements gathering
Document the business requirements and translate them into the weighted criteria above. This phase typically consumes 30 to 40 percent of the total selection timeline, and skipping or rushing it is the single most common reason selection projects pick a vendor that turns out not to fit.
2. Shortlisting
Narrow the market to 6 to 10 vendors based on reputation, relevant experience, and stated capability against your requirements, before investing time in formal RFPs.
3. Request for proposal (RFP)
Send a formal RFP to the shortlist, structured around your weighted criteria so responses can be scored consistently rather than compared as free-form marketing documents.
4. Scored evaluation and demos
Narrow to 3 or 4 finalists for scripted demos against your own use cases (not the vendor’s canned demo script), score them using the weighted matrix, then take the top 2 to reference calls before final negotiation.
5. Negotiation and selection
Final pricing and contract terms are negotiated with the winning vendor, and the process closes once both parties agree to terms.
How long this actually takes: a thorough selection process for a mid-sized business typically runs 3 to 6 months from requirements gathering to signed contract; larger organizations with more complex requirements often need 6 months to a year. Compressing the process into less than 8 to 12 weeks measurably raises the risk of a poor vendor fit, and letting it run past 9 months tends to stall momentum and produce decision fatigue rather than a better outcome. Neither extreme serves the decision.
Why selection criteria matter more than they look like they should
Industry research on ERP project outcomes, most consistently Panorama Consulting’s annual ERP report, has for years put the share of implementations that miss their original budget, timeline, or objectives at well over half, with commonly cited figures in the 55 to 75 percent range depending on the year and how “success” is defined. That number gets quoted often enough that it is worth being skeptical of any single precise figure, but the pattern behind it is consistent and specific enough to act on:
- Budget overruns are most often caused by additional technology needs that were not scoped during selection, not by the base software cost. That is a selection-criteria failure (criterion 2 above), not an implementation surprise.
- Underestimated staffing shows up in a large share of over-budget projects. If the selection process never asked how many internal hours the vendor’s implementation actually requires, the answer arrives as a mid-project surprise.
- Data migration problems are one of the most frequently cited causes of schedule overruns, and they are rarely caused by the new system: they surface because data cleanup gets treated as a cutover-weekend task instead of a phase-one priority during selection and planning.
- Change management and inexperienced project teams, alongside data migration, account for the large majority of project failures identified in this research, which is why criterion 3 (user adoption) and criterion 9 (vendor’s industry expertise, meaning they have actually managed this kind of rollout before) carry real weight rather than being a formality.
None of these are software defects. They are selection-process gaps: the criteria never asked the question that would have surfaced the risk before the contract was signed.
Worked example: scoring two ERP finalists
Company: a mid-sized distributor running a 15-year-old on-premise system, evaluating two cloud ERP finalists after a four-month selection process.
Weighted criteria set by the company: technical fit and integration with their existing warehouse system (35 percent, the highest weight, because their current integration is manual and error-prone), total cost of ownership (25 percent), distribution-industry expertise (25 percent), and support quality (15 percent). Notice that “features” is not a standalone line; specific requirements were folded into technical fit rather than scored as a generic wish list.
What the scoring surfaced: Vendor A scored highest on technical fit and industry expertise, having implemented for several similarly sized distributors, but scored lower on total cost of ownership because its implementation partner quoted a longer, more hands-on rollout. Vendor B was cheaper and demoed well, but its reference customers were in retail, not distribution, and could not speak to the warehouse integration the company weighted most heavily. The weighted total favored Vendor A, and reference calls confirmed the integration claim; the cheaper, better-demoed Vendor B would have been the wrong choice had cost been scored without its weight reflecting what actually mattered.
FAQs
What are ERP vendor selection criteria?
ERP vendor selection criteria include the vendor’s reputation and experience, financial stability, product and service quality, customer references, support and maintenance offerings, implementation and training services, and pricing. Score each against your own weighted priorities rather than treating them as a pass/fail checklist, and confirm claims with reference customers rather than the vendor’s own materials.
How long does the ERP selection process take?
A thorough selection process for a mid-sized business typically takes 3 to 6 months from requirements gathering to signed contract, with requirements gathering alone consuming 30 to 40 percent of that time. Larger, more complex organizations often need 6 months to a year. Compressing the process below 8 to 12 weeks raises the risk of a poor vendor fit.
Why do so many ERP selection and implementation projects fail?
Industry research, most consistently Panorama Consulting’s annual ERP report, has for years put the share of projects missing their original budget, timeline, or objectives at well over half. The most commonly cited causes are unplanned additional technology needs, underestimated internal staffing, data migration treated as a late-stage task instead of a phase-one priority, and inexperienced project teams, not defects in the software itself.
Conclusion
Selection criteria only do their job when they are specific enough to produce different scores for different vendors and weighted so the criteria that matter to your business outweigh the ones that are merely nice to have. A checklist cannot do that; a weighted scoring matrix, built from the ten criteria above and applied consistently across a shortlist, can.
Budget the real timeline for it, 3 to 6 months for most businesses, and treat requirements gathering as the highest-leverage phase rather than the box to check before the “real” evaluation starts. The research on why ERP projects struggle points back to exactly these gaps: criteria that never asked about staffing, data migration, or integration complexity in enough detail to catch the risk before the contract was signed.