The right ERP is the one that fits your company's shape, and the surest way to pick the wrong one is to start from a vendor's list of alternatives. Gartner expects more than 70% of recently implemented ERP initiatives to fall short of their original business case by 2027. A choice that holds up narrows the field by manufacturing mode, industry, company size, and legal-entity count before anyone demonstrates a feature. It settles the tier first, because the tier moves the budget 3x to 10x. And it carries no vendor past the shortlist without a named condition under which that vendor is the right answer. Score the demos on your scenarios, check references of your own shape, and the choice defends itself in the boardroom.
Fit rules out most vendors before a feature is demonstrated
How you make things, what industry you are in, how large you are, and how many legal entities you consolidate decide the shortlist more reliably than any feature list. Start there and the field of forty vendors becomes a list of three to five before the first demo. Start with features and you compare products that were never a fit, guided by the vendor whose list you are reading.
Manufacturing mode is the sharpest filter. A discrete assembler, a batch chemical plant, and a job shop need different planning logic and costing, and the independent lists agree on far fewer fits than the vendor pages claim. Of the eight systems compared in the manufacturing pillar, only four are a natural fit for engineer-to-order work and only four for regulated process or batch work. A food or pharmaceutical manufacturer that leads with mode has ruled out half the market before lunch.
Company size and entity count set the ceiling. Revenue near $1B puts a company in a band where both tiers quote real numbers, so revenue alone cannot pick the tier. The structural facts do: the number of legal entities on one ledger, the number of countries with their own statutory reporting, transaction volume, the five-year growth path, and industry fit. A CFO can answer all five in an afternoon, and the answers point to a tier the revenue line does not.
| Filter | What it rules out | What it leaves |
|---|---|---|
| Manufacturing mode or industry | Products not built for your mode (process, discrete, engineer-to-order, job shop) or vertical | The three to five vendors with real content for how you operate |
| Company size and user volume | Products that will outgrow you, or that you will outgrow inside five years | The tier whose ceiling you sit comfortably below |
| Legal entities and countries | Products built for one country and simple consolidation, when you have neither | Products that treat localization and multi-entity close as standard content |
| Deployment constraint | Models your data-residency or control rules forbid | The one or two deployment models you can actually run |
The tier decision sets the budget, so make it first
The single decision that moves the budget most is the tier, and it is the one buyers leave until last. At the same company size, a tier 1 product costs about 3x to 10x as much to implement as a tier 2 product. ERP Research puts SAP S/4HANA Private Cloud at $500,000 to $5M and Oracle Fusion Cloud ERP at $300,000 to $3M, against Infor CloudSuite at $100,000 to $1M and Epicor Kinetic at $75,000 to $500,000. Run cost, at 15 to 25% of implementation every year, widens the gap over five years.
This pillar does not re-argue the tier choice, because two articles already do. The case for how much the whole program costs and how to rebuild any SI number sits in the cost pillar, what an ERP program costs. The case for which tier a company in the overlap belongs to, condition by condition, sits in when a tier 2 ERP is right for a $1B company. Settle the tier using those two, then let this article govern how you choose the product inside it.
The reason tier comes before product is arithmetic. Pick the tier wrong and no amount of careful product selection recovers the 3x to 10x gap. A $1B single-country manufacturer with deep industry fit that buys tier 1 pays for configuration surface it will use perhaps 30% of, every year the system runs. A $1B company growing by acquisition that buys tier 2 scopes a replacement by year six. Both mistakes come from choosing on revenue alone, and both are settled before the product shortlist starts.
A vendor's alternatives list is a sales tool, not a shortlist
Search for any ERP product and the vendor's own site returns a page of alternatives. That page is marketing. It names the competitors that vendor is confident it beats, framed around the features where it wins, and it leaves off the products that would beat it on your requirements. A shortlist built from an alternatives list is a shortlist the vendor built for you.
A defensible shortlist is different in kind. It starts from the fit filters above, not from a product, and every name on it carries the condition under which that product is the right answer. The difference shows in what each list can survive. An alternatives list collapses the moment someone on the steering committee asks why a named competitor is absent. A conditions-based shortlist answers that question in one sentence for every vendor, present or absent.
| Vendor alternatives list | Shortlist you can defend | |
|---|---|---|
| Built by | The vendor, to win | You, to fit |
| Starting point | A product you already favor | Your mode, size, entities, and constraints |
| What it names | Competitors that vendor beats | Products that meet your stated conditions |
| Survives the question "why not X?" | No | Yes, with the condition X fails |
| Survives an audit | No | Yes |
The deeper mechanics of running the selection, from the long list to the demo scenarios to the scoring, sit in the companion guide to selecting ERP software. The rule for the board paper is the one above: a shortlist is something you authored against conditions, not a page you printed from a vendor.
Never carry a vendor past the shortlist without naming the condition it wins under
The discipline that keeps a selection honest is a single sentence per vendor: the condition under which this product is the right answer. Write it before the demos, and a vendor that no longer meets its condition drops off without an argument. Skip it, and the vendor with the best presenter stays on the list.
Every vendor named below has at least one situation where it is the right call. The criticism in the "runs out of road" column is specific, and where it comes from a vendor's own comparison or an interested source, that is marked. This is the vendor-neutral core of the method. No product is recommended without its condition, and no product is dismissed without a reason you could defend.
| Vendor | The condition under which it is the right answer | Where it runs out of road |
|---|---|---|
| SAP S/4HANA | Many legal entities and countries on one financial model; a parent group that needs one ledger and one planning run at global scale | A single-country operation under about $500M that cannot staff a 36-month program (the $500M line is IFS's, a competitor) |
| Oracle Fusion Cloud ERP | Multi-entity groups where finance, consolidation, and reporting lead the case; companies already on Oracle | Plant-floor and MES depth, and any need for on-premise deployment |
| Microsoft Dynamics 365 Finance and Supply Chain | Mid-market to enterprise discrete and mixed-mode operations already standardized on Microsoft; list price about $210 per user per month (microsoft.com) | Deep process manufacturing; total cost climbs as add-ons and partner MES are bolted on |
| Workday Financials | Services firms where finance and HR need one data model | Manufacturing and inventory-heavy operations |
| Infor CloudSuite | Discrete and process work inside Infor's named micro-verticals; multi-site in one to a few countries | A vertical outside its templates; a product portfolio (LN, M3, CSI) that takes work to tell apart |
| IFS Cloud | Asset-heavy, project-based, and engineer-to-order manufacturers who need ERP, asset management, and field service in one model | A simple repetitive plant that pays for depth it never uses |
| Epicor Kinetic | Discrete make-to-order, engineer-to-order, and mixed-mode plants that want scheduling and MES inside the ERP; cloud, on-premise, or hybrid | Process manufacturing (no independent list opened for the manufacturing pillar names it there) |
| QAD Adaptive ERP | Regulated discrete and process suppliers (automotive, life sciences, food) needing localizations across 100-plus countries on one instance | Shop-floor scheduling and mixed-mode job control, which ERP Research rates Epicor stronger on |
| Oracle NetSuite, Acumatica, Sage Intacct | Multi-entity companies under about 500 users where consolidation matters more than a plant floor | Deep manufacturing and large multi-country statutory reporting |
The test for the steering committee is blunt. Ask the SI proposing any product to name which row applies to your company. If the answer is "scalability" or "future-proofing" with no number attached, the product has no condition and should not be on the list.
Score demos on your scenarios, not the vendor's script
A scripted demo shows the product on its best day. The vendor picks the data, the process, and the path through the screens, and every product looks strong when it chooses its own ground. The only demo that tells you anything scores the product on your scenarios, run on your messiest real transactions.
Write five to eight scenarios from your actual operation before the first demo, and send them to every finalist with the same data. Pick the transactions that break things: the month-end close with an intercompany elimination, the engineer-to-order job that changes mid-build, the return that crosses two tax jurisdictions, the drug lot that needs a recall trace. Give each vendor the same scenarios and the same two hours, and score each scenario against the same scale.
The scoring belongs to a panel, not one person, and the weights are set before anyone sees a demo. A scenario the business runs a thousand times a day outweighs one it runs twice a year, and the weights should say so in advance so no single demo can move them. The guide linked above lays out a scenario template and a scoring scale written fresh for this site. The principle here is narrower: the vendor's script tests the vendor, and your scenarios test the fit.
Ask every finalist for a reference customer within 50% of your revenue and in your industry
A reference customer of your own shape is the hardest claim for a vendor to fake and the most useful one to collect. The rule we recommend is specific: a live customer in your industry, within 50% of your revenue, with at least your entity count and your country count, who will take a 30-minute call. A vendor that cannot produce one is not short on references. It is telling you where its product runs out of road.
The shape matters more than the logo. A $600M process manufacturer learns little from a $40B reference running a different mode, because the $40B company configured the product with a team the $600M company will never have. The questions worth the call are the ones the sales cycle buries: what the reference would scope differently, where custom code crept above the 10 to 15% of requirements that holds implementation cost down, how long the close actually takes now, and whether the newest entity or country went in cleanly. Those answers, from a company your size in your industry, outweigh any slide.
The deployment decision is a board matter, not an IT detail
Where the software runs, public cloud, private cloud, or on-premise, changes the run cost, the upgrade cadence, the data-residency position, and the exit, so it belongs in the board paper rather than buried in a technical annex. The three models trade control against cost and effort, and the right answer follows from a few facts the board already cares about.
| Model | Right when | What the board gets, and gives up | Example products |
|---|---|---|---|
| Public cloud (multi-tenant) | Processes can be standardized; lowest run cost and effort are the priority; no hard data-residency rule | Lowest run cost and no upgrade projects; gives up control of the upgrade calendar and some configuration surface | SAP S/4HANA Public Cloud ($200,000 to $2M), Oracle Fusion, NetSuite, Business Central, Acumatica |
| Private cloud (single-tenant) | More configuration surface is needed; the company wants to control when it takes upgrades | More control and configuration room; costs more than public cloud (S/4HANA Private Cloud runs $500,000 to $5M) and still needs an upgrade discipline | SAP S/4HANA Private Cloud, RISE with SAP, Oracle Fusion |
| On-premise or hybrid | Data residency, regulatory, or control rules forbid a shared platform; an existing data center is sunk cost | Full control and residency; carries the hardware, the patching, and the upgrade project the cloud models remove | Epicor Kinetic, IFS Cloud, Infor (selected editions) |
The board-level reading is short. Public cloud is the lowest-cost, lowest-effort default, and the published S/4HANA ranges show it running roughly half to a quarter of the private-cloud figure because process standardization is the price of entry. Private cloud buys back configuration and upgrade timing for companies that genuinely need them. On-premise is the right answer only when a residency or regulatory rule forbids the alternatives, because it hands back the hardware, the patching, and the upgrade project that the cloud models were bought to remove. Decide the model early, because it rules vendors in or out: a hard on-premise requirement ends the conversation with a public-cloud-only product before the first demo.