How to select the right ERP software

A defensible ERP choice runs in a fixed order. Narrow the field by industry, manufacturing mode, company size, and legal structure before you look at a single feature. Set the tier. Write requirements that separate the vendors rather than list everything the system should do. Build your own shortlist of three. Run an RFP and demos on your scenarios, not the vendor's. Check references of your own shape. Decide deployment last. Selection fails when it runs the other way, led by a 900-row feature list or by a vendor's sales team. Gartner expects more than 70% of recently implemented ERP initiatives to fall short of their original business case by 2027. Most of that gap is set before the contract is signed, in the selection.

Why most selections fail before the contract

Two failure patterns account for most of the disappointment in the Gartner figure, and both start in the selection, not the implementation.

The first is feature-led selection. A team writes a long requirements list, sends it to five vendors, and scores the returns. Every vendor answers "yes, standard" to almost everything, because almost everything is standard in a modern suite. The score compresses, the real differences hide, and the decision defaults to price or to whichever salesperson ran the best demo. The requirements list did not discriminate, so it did not decide.

The second is vendor-led selection. The team lets a vendor or a systems integrator (SI) frame the shortlist, write the evaluation criteria, and run the demos. The SI is 40 to 60% of the eventual bill, per ERP Research, an independent research firm, so its proposal is written to win, not to inform. A shortlist a vendor hands you is a list of products where that vendor looks good.

Both patterns share a root cause: the selection asks "which product has the most features" instead of "which product fits a company shaped like ours, and who will install it." The method below asks the second question in the order that keeps a vendor from answering it for you. The decisions it covers set how much of the later design phase, which runs 10 to 20% of implementation hours (ERP Research), is spent configuring a product that fits versus fighting one that does not.

Narrow by shape before you look at a feature

The first cut has nothing to do with features and everything to do with the shape of your company. Four facts remove most vendors from contention before any demo, and a CFO can write all four on one page in an afternoon.

Industry and manufacturing mode

Industry fit decides how much the product does out of the box, which decides custom code, which is the single largest cost lever a buyer controls. Holding custom code under 10 to 15% of requirements saves 20 to 40% of implementation cost (ERP Research). A product built for your industry meets more requirements as standard, so the custom code stays low on its own.

For manufacturers, mode narrows the list faster than revenue does. Discrete make-to-order and engineer-to-order work points toward Epicor Kinetic, IFS Cloud, and Infor CloudSuite Industrial. Regulated process and batch work points toward QAD Adaptive ERP, Infor CloudSuite Industrial, Plex, or a tier 1 suite. Plant-first manufacturers who want the shop floor, quality, and traceability before the ledger start with Plex. DELMIAWorks fits small discrete shops already in the Dassault engineering world. The full mode-by-vendor breakdown sits in manufacturing ERP for executives.

Other industries cut the same way. Asset-heavy utilities point toward IFS Cloud, SAP S/4HANA, or Oracle, and the choice turns on who owns the billing engine, covered in ERP for utilities compared. Services firms where finance and HR share one data model point toward Workday Financials. Multi-entity companies where consolidation matters more than a plant floor point toward Oracle NetSuite, Acumatica, or Sage Intacct. Process manufacturers and distributors in the mid-market fit Sage X3.

Company size, entities, and countries

Size sets the band, but two structural facts inside it matter more than the revenue line: the number of legal entities on one ledger, and the number of countries with their own statutory reporting. Each additional legal entity adds an estimated 10 to 20% of implementation cost, per CRM Layers, an advisory blog. That is a weak source, so treat the figure as a direction, not a rate. The direction is firm: entities and countries multiply the work, and they do it fastest on a product that was not built to consolidate many books in many jurisdictions.

Write the four facts down before the first vendor call: your industry and mode, your revenue and user count, your legal entity count, and your country count with local statutory reporting. These four, not a feature list, build the shortlist.

Set the tier, then price the band

The tier decision moves the budget more than any other choice in the program. At the same company size, a tier 1 product costs roughly 3x to 10x as much to implement as a tier 2 product, because tier 1 carries more configuration surface, tier 1 SIs charge more per hour, and tier 1 programs run longer (ERP Research). Published tier 2 mid-market programs run $300,000 to $3M; single-region tier 1 programs run $500,000 to $5M or more; global tier 1 programs run $20M to $50M or more (SysGenPro, CRM Layers). All are confidence C ranges from research sites and SIs, not audited accounts.

Revenue does not pick the tier. Five conditions do, and a CFO can answer all five in an afternoon.

If none of the tier 1 triggers holds, tier 1 is a choice you have to justify, not a default. The full case, including the year-three failure modes for each wrong choice, is in when a tier 2 ERP is right for a $1B company, and the arithmetic to rebuild any quote is in what an ERP program costs.

Once the tier is set, price the band from a quote, not from memory. Take the annual software figure, multiply by 1x to 3x for implementation, add five years of software, and add 15 to 25% of implementation for each of years two through five as run cost. That gives a five-year total you can defend before any vendor shows you theirs.

Write requirements that discriminate, not a 900-row list

The 900-row requirements spreadsheet is the most common mistake in the whole method. Most of its rows describe things every modern ERP does. "The system shall post a journal entry" scores every vendor the same, so it adds length and removes signal. A list where every vendor scores 95% has told you nothing about which to pick.

The requirements that decide a selection are the ones where vendors actually differ, and there are rarely more than 50 to 100 of them. They cluster in four places: your industry and mode specifics, your multi-entity and multi-country needs, your integrations to systems you are keeping, and the two or three processes that are genuinely unusual in your business. A batch manufacturer's recipe-and-potency handling, a utility's FERC chart of accounts, a distributor's three-way match across ten warehouses: these separate vendors. A general ledger does not.

The test for keeping a requirement on the list is simple. If you cannot name at least one credible vendor that would answer it with anything other than "standard," cut it. It is scoring noise. A short list of discriminating requirements also forces each vendor to show the gaps, which is where custom code and partner products hide.

Make each surviving requirement demand a four-way answer rather than yes or no:

• Standard, works out of the box with no configuration.
• Configured, met through setup with no custom code.
• Custom code, requires development you will own and maintain.
• Partner or roadmap, delivered by a third-party product or promised in a future release.

A vendor that answers "standard" to a requirement that is really custom code or a partner product is the vendor whose program lands at the top of the range. The four-way classification is what turns a requirements list into a tool that discriminates.

Build your own shortlist of three

The shortlist should be yours, not a vendor's. A vendor asked for "alternatives" returns the products it beats, arranged to make itself the obvious answer. An SI asked to recommend returns the products its consultants are certified in and staffed for. Neither is a neutral list.

Build the shortlist from the shape facts and the tier decision. Three finalists is the right number: enough to create genuine competition on price and terms, few enough that each gets a real evaluation. Two leaves you without a fallback if one drops out. Five means none gets a deep look, and the extra two are usually there to make a preferred vendor look strong.

A worked illustration. A $600M single-country process manufacturer with three legal entities finishes the shape and tier work and lands in tier 2 with a deep industry-fit requirement. Its own shortlist is QAD Adaptive ERP, Infor CloudSuite Industrial, and Plex, each strong in regulated process work. It does not include the tier 1 suites, because no tier 1 trigger fired, and it does not include a general distribution product a reseller pushed, because the industry fit is too thin. That is a defensible list: three products that fit the company's shape, chosen before any vendor framed the question.

Keep one rule. The shortlist is set by the buyer's criteria and recorded before the vendors present. A finalist that enters the list after a good lunch or a board member's preference is the start of a vendor-led selection.

Run an RFP that forces honest answers

The RFP is where most of the honesty in a selection is won or lost. A loose RFP invites marketing prose; a tight one forces facts you can check. Six sections do most of the work.

The first is the discriminating requirements, each demanding the four-way classification above. The second is a fixed-format price: annual subscription or license and maintenance, the SI's implementation estimate with the SI named, and a five-year total built on the vendor's own assumptions. The third is the deployment model and the upgrade cadence, in writing, because that decision has cost and control consequences covered below. The fourth is the product roadmap with dates, so a "coming soon" answer carries a release and a year rather than a promise. The fifth is a reference customer of your shape, named in the response, not produced later. The sixth is a response to your own scenarios, written out, so the vendor commits on paper before the demo.

Two devices raise the honesty further. Where a requirement is met by a partner product, require the product name, its publisher, and its support contract on the response. A utility scoring a vendor for billing or asset management, for example, needs to know whether the capability ships from the ERP vendor or from a separate company whose contract it will sign. And require the SI to be named in the proposal, with the specific consultants' certifications, because the SI is 40 to 60% of the bill and a strong product installed by a weak team is a weak program. What to look for in that response is set out in how to read an SI proposal.

Score demos on your scenarios, not the vendor's

A vendor-run demo is a sales presentation with a product behind it. The canned demo is rehearsed, uses clean sample data, and skips every process the product handles badly. Scored as presented, it tells you which vendor demos best, not which product fits.

Take control of the demo in three ways. Script the scenarios from the two or three processes that are unusual in your business, and send them to each vendor in advance so all three run the same ones. Supply a sample of your own data, including the messy records, so the product is shown on your reality rather than the vendor's. And score against a rubric written before the first demo, so the team is not swayed by delivery.

A worked illustration. A multi-entity distributor scripts three scenarios: an intercompany sale that has to eliminate on consolidation, a return that crosses two warehouses, and a month-end close across five entities in two currencies. Each vendor runs the same three on the distributor's own chart of accounts. The scenarios expose exactly the differences the shape facts predicted, and the rubric, scored 1 to 5 on each scenario by each evaluator, produces a number the steering committee can defend. A process manufacturer would script a batch with a mid-run recipe change and a quality hold instead; the principle is the same.

The demo is also where the four-way requirement answers get tested. A requirement the vendor marked "standard" in the RFP should be shown live, on your data, with no "we can configure that after the session."

Check references of your own shape

A reference call is worth the hour only if the reference is shaped like you. A glowing call from a company half your size in another industry on a different deployment model tells you nothing about your program. Set the shape before you accept the reference.

The reference should be within about 50% of your revenue, in your industry and mode, with at least your legal entity count and country count, live for at least a year so the first full budget cycle has run, and willing to take your call directly rather than through a vendor-arranged session. A vendor that cannot produce a reference of your shape is telling you where its product runs out of road, and that is useful information in itself.

Ask the questions a vendor would not script. What went over budget, and by how much. Which custom code they built and now regret. How long the implementation actually took against the plan, given that a survey reported by ERP Today found 31% of implementations ran longer than expected and 12% had significant delays. Whether the SI's A-team stayed or rolled off after the sale. And the one question that compresses all the others: knowing what they know now, would they pick the same product and the same SI again.

Decide deployment last, by vendor

Deployment model is a decision, not a default, and it belongs late in the method because it narrows differently for each vendor. The three models trade standardization against control. Public cloud (multi-tenant SaaS) gives continuous updates and the lowest run burden, at the price of less control over when changes land and how far you can customize. Private cloud (single-tenant, vendor-hosted or on a hyperscaler) gives more control over timing and configuration at a higher cost. On-premise gives the most control and the most work, and it is a shrinking option.

The models available depend on the vendor, so deployment cannot be decided before the shortlist is set.

Each model has a company it fits. A company that wants the lowest run burden and can standardize its processes fits SAP S/4HANA Public Cloud, Oracle Fusion, or NetSuite, all of which push toward standard processes and away from the custom code that inflates cost. A company that needs more configuration control, or carries data-residency constraints, fits RISE with SAP, Infor CloudSuite on a private tenant, or IFS Cloud. A company with a genuine reason to keep the system in its own data center, such as a plant with no reliable connectivity or a sovereignty rule, still has Epicor Kinetic, IFS Cloud, Acumatica, and QAD Adaptive ERP as on-premise options.

One cost note sits inside this decision. On-premise software has usually been capitalized, while a cloud subscription has usually been booked as operating expense. For a regulated utility, that difference decides whether the spend can enter rate base and earn a return, which is why a utility settles the deployment model with its regulatory counsel, not with the SI. The detail is in ERP for utilities compared.

In-product AI: a tie-breaker, not the basis

Every vendor now sells an AI story, and the claims are large. Oracle announced its AI Success Navigator, with six implementation agents, and a Fusion Setup and Configuration Registry on October 26, 2026, citing one customer's claim of 80% on design and configuration. NetSuite announced SuiteExpress, an agentic implementation toolset, the same day, claiming go-lives in "weeks, or even days." SAP reported a 77% efficiency gain for Joule for Consultants across 19 use cases at partner ABeam in August 2026. Opkey claims up to 50% lower management cost and up to 85% less testing time. Sage and PwC put agentic delivery on Sage Intacct rollouts in April 2026 with no formal metrics disclosed. Every one of those is a confidence C vendor or partner claim, and none cites a completed independent program.

The analyst projections are more measured and still conditional. McKinsey, in May 2026, said AI-enabled work "could" cut implementation effort by at least 50%, with 80% on testing and 90% on training preparation, all projections rather than results. BCG estimated a 20 to 40% reduction in April 2025. Gartner expects about 40% of agentic AI projects to be canceled by 2027.

The site's judgment is that in-product AI is a tie-breaker between two products that are already close on fit, never a reason to pick a product that fits worse. Treat an AI claim the way you treat any other requirement: ask the vendor to show it live on your data, and ask for a reference customer who used it on a program of your shape. A capability no reference has used in anger is a roadmap item, not a feature. The fuller treatment of what AI does and does not change in an implementation is in AI-assisted ERP implementation.

The common selection mistakes

Most failed selections repeat a short list of errors, all of them avoidable with the sequence above. Leading with a feature list every vendor meets, so price decides by default. Letting a vendor or SI set the shortlist, which guarantees a list where that party wins. Picking the tier on revenue instead of on entities, countries, volume, growth, and industry fit. Scoring a demo the vendor scripted on the vendor's clean data. Accepting references the vendor arranged instead of references of your own shape. Deciding deployment by habit rather than by the control and cost trade-off. Buying the AI story as the basis for the choice rather than as a tie-breaker. And the quietest one: scoring the product and ignoring the SI, when the SI is 40 to 60% of the bill and decides whether a good product becomes a good program.