Where ERP selection usually goes wrong
An ERP decision commits a company for five to ten years, and the expensive mistakes are rarely made at signature. They are made in the first two weeks, when a company starts by watching demonstrations instead of writing down what it actually needs.
Every modern system demos well. Without your own requirements document you are comparing presentation quality, not fit. What follows is a sequence that removes that failure mode — it applies whether you are replacing spreadsheets, retiring a legacy ERP, or migrating off a system that is no longer supported in your jurisdiction.
The framing that matters. You are not choosing software. You are choosing a combination of system, implementation partner and your own willingness to change processes. Any one of the three failing sinks the project, regardless of licence cost.
Step 1. Map your processes before looking at systems
Write down how five to seven core processes work today — as they actually run, not as the procedure manual describes them. Sales from enquiry to payment. Purchasing from need to landed cost. Stock movement. Production or projects if you have them. Period close, including who does what and how many days it takes now.
This document does the work at every subsequent stage. It turns vendor conversations from presentations into specific discussions, and it is the only defence against buying a system that demos beautifully and fits nothing.
Step 2. Split requirements into critical and nice to have
A list of 200 requirements where everything is important stalls the decision or turns the project into bespoke development.
Critical means the business stops or breaks the law without it. There are usually 15 to 25 of those. Everything else is negotiable, and the less customisation it demands, the cheaper the project becomes.
| Category | Example | How to handle it |
|---|---|---|
| Critical | Statutory tax reporting for your jurisdiction | Must work in standard or in a supported localisation. Absence is grounds to reject the system |
| Important | Automatic landed cost on imports | Verify in a pilot. Customisation acceptable if quoted in hours and money |
| Nice to have | A specific document layout | Defer to phase two. Frequently turns out to be unnecessary after go-live |
The threshold that protects budgets: if the standard covers less than 70% of critical requirements, you are commissioning development rather than an implementation — with the timelines, risks and maintenance cost that implies.
Step 3. Evaluate the vendor, not just the product
- Platform longevity. Where will this product be in ten years? Companies that treated this as theoretical have had accounting systems switched off by sanctions, acquisition or end of support.
- Localisation ownership. Who maintains the country layer, and how fast does it respond to legislative change? "There is a localisation" is a weaker answer than "here is who ships it and how often".
- Partner ecosystem. How many firms implement this system in your market? If the answer is one, that is dependency rather than a saving. Count open job adverts naming the system — that is your future hiring pool.
- Update model. Cloud platforms update themselves; on-premises systems update at your cost. Business Central, for example, ships two feature waves a year.
- What happens to customisations on update. Modern platforms isolate them as extensions. Older ones modify base objects, which makes every upgrade a project.
Step 4. Count cost of ownership, not the licence
The licence is the most visible line and rarely the largest. Comparing two systems on subscription price alone regularly picks the more expensive one.
Total cost of ownership, line by line
| Line | Share of a three-year budget | What moves it |
|---|---|---|
| Licences or subscription | 15–30% | User count, and correct allocation of licence types |
| Implementation | 35–50% | Number of areas, data condition, process complexity |
| Customisation and integrations | 10–25% | How far processes deviate from standard |
| Training | 5–10% | User count and module depth |
| Support after go-live | 10–20% | Hours as consumed, or a fixed retainer |
| Your own team's time | Rarely counted | But it decides whether the project lands on schedule |
Two costs hide outside this table. Recurring verification of customisations against each platform release, and the productivity dip in the first weeks after go-live. Neither appears in a quote; both are real.
The practical conclusion: a cheap licence with heavy implementation regularly loses to a more expensive subscription running close to standard. Model the arithmetic for Business Central specifically in the cost calculator.
Step 5. A pilot instead of faith
Test the finalist on one end-to-end process using your own data. Order → reservation → shipment → invoice → payment → close, for example.
Two weeks of pilot reveals more than a month of presentations, because it exposes what demos hide: how many clicks a routine operation takes, how the system behaves with your item catalogue, and what happens when a user makes a mistake.
One condition: run identical scenarios across all finalists. Otherwise the comparison is not a comparison.
Demo checklist: what to insist on seeing
Vendors demonstrate what shows well. This list asks for what does not.
- Our data, not sample data. Even a small import of your item catalogue changes what the interface feels like.
- A full cycle, not features. Follow one order from enquiry to cash, in one sitting.
- An error and its correction. Post a document wrongly, then fix it. This is where systems differ most.
- Month-end close. Ask to see the actual sequence, not a slide describing it.
- A report you actually use. Bring the report management reads weekly and ask to see it built.
- The mobile or shop-floor view if people will work outside a desk.
- Permissions. Show a restricted user's screen, not the administrator's.
- What is missing. Ask directly which of your critical requirements the standard does not cover. A vendor who says "everything is possible" is describing development, not fit.
How to evaluate the implementation partner
The system is the same for everyone; the partner is not. Roughly half of ERP project outcomes trace back to this choice rather than to the software.
| What to ask | What a weak answer sounds like |
|---|---|
| How many projects like ours have you delivered, and in which industry? | A number with no examples anyone can verify |
| Which of our critical requirements works in standard, and which needs extending? | "Everything is configurable" |
| Who specifically will run our project, and what else are they on? | A named team on the proposal, different names on delivery |
| What does the estimate consist of, and what would push it up? | A single total with no breakdown |
| What happens to our extensions at the next platform release? | Hesitation, or "we will look at it then" |
| Who owns the source code of custom work? | Anything other than a clear contractual answer |
| Can we speak to a client you delivered for? | Refusal without a confidentiality reason |
Implementation risks and how they materialise
- Dirty data. The most underestimated risk. Duplicate counterparties and inconsistent item codes convert directly into billable hours and delayed go-live. Start cleaning before you have chosen a system — it is useful regardless of the outcome.
- No internal owner. A partner cannot make decisions about your processes. Projects without a named decision-maker on the client side stall in exactly the same place every time.
- Scope drift through customisation. Each individually reasonable request compounds into a system that cannot be updated cheaply.
- Training cut to save budget. The technical go-live is half the project. The other half is whether people use the system afterwards.
- Go-live mid-period. Launching in the middle of a reporting period guarantees a reconciliation problem. Start of a new year or quarter costs nothing extra and removes it.
- Migrating everything "just in case". A decade of history belongs in read-only access to the old system, not in the new one.
Classes of system on the market
| Class | Fits | Defining trait |
|---|---|---|
| Accounting packages | Up to 10–15 users | Cover bookkeeping but not management control |
| Mid-market ERP | 10–300 users | One system for finance, stock, purchasing, sales, production |
| Enterprise ERP | 500+ users | Complex architecture, long implementation, high budget |
| Vertical solutions | Narrow niches | Cover specifics out of the box, weaker on general processes |
| Custom build | Genuinely unique processes | Perfect fit and total dependency on specific developers |
Most companies between 10 and 300 users end up comparing mid-market platforms. If Business Central is among your finalists, who it fits and who it does not is a more useful read than a feature list, and the platform guide covers what implementation and migration actually involve.
Comparing the options
There are effectively four routes. Here is an honest comparison — each is right in some situation.
| Option | Best for | Strength | Weakness |
|---|---|---|---|
| Keep the legacy system | Small companies with no growth plans | Team already knows it, minimal spend | Regulatory risk, limited integration, dependence on one developer |
| Cloud ERP from a global vendor Business Central, NetSuite | 10–200 users | Vendor-managed updates, native Microsoft 365 integration, predictable cost | Some processes must adapt to the standard |
| Enterprise ERP SAP S/4HANA, Oracle | Large groups, multiple entities and countries | Handles any level of complexity | Budget and timeline several times higher, needs an in-house IT team |
| Custom build | Genuinely unique business models | Exact fit to your processes | You own development, security and support forever |
Requirements checklist: what to compare
The common mistake is comparing feature lists from sales decks. Compare what drives cost of ownership over years.
| Criterion | What to ask |
|---|---|
| Process fit | Demo my scenario, not a generic one. How much is covered by the standard? |
| Localisation | Local accounting, VAT and statutory reporting — standard or customisation? |
| Updates | How often they ship and what happens to our customisations |
| Integrations | Bank, webshop, marketplaces, warehouse hardware — ready connectors or development? |
| Data ownership | Can we export all our data at any time in a usable format? |
| Partner ecosystem | How many teams in the country know this system. One is a risk |
| Total cost | Licences + implementation + support + customisation over three years |
Red flags during selection
- "The system does everything." None does. Ask what it cannot do — an honest answer signals experience.
- Demo on abstract data. Insist on your process with your numbers, even simplified.
- A price before any analysis. An exact figure before studying processes means change requests later.
- No access to customisation code. You are locked to that partner permanently.
- "Live in a month." A realistic mid-market implementation takes eight weeks or more.
How long selection should take
A typical cycle is four to eight weeks: one week to document processes, two for the shortlist and demos, one to check references and the partner team, the rest for internal budget approval. Rushing here costs more than waiting — replacing an ERP a year later is far more expensive than spending an extra week choosing.
Frequently asked questions about ERP selection
How do you choose an ERP system for a mid-sized business?
Start by documenting processes as they are, split requirements into critical and nice-to-have, verify local statutory compliance and calculate three-year cost of ownership rather than the entry price. Always see a demo of your own scenario and check how many partners in your country support the system.
How much does an ERP system cost for a mid-sized company?
The budget combines licences, implementation, data migration and support. For cloud systems like Business Central, licences run $80–110 per user per month; implementation depends on process complexity. Compare the three-year total: systems that look cheap at the start often carry expensive support.
How long does ERP selection and implementation take?
Selection takes four to eight weeks, implementation eight to twenty depending on complexity. For a mid-sized company the typical full cycle from first meeting to live operation is about six months.
Can ERP be implemented in phases?
Yes, and for most companies it is the safest approach. Phase one covers finance and sales, then inventory, then manufacturing and analytics. Each phase delivers a working result and spreads the budget.
What are the most common ERP selection mistakes?
Choosing by feature list instead of your own scenario, comparing entry price instead of total cost of ownership, starting vendor talks without documented processes, and relying on a single partner who knows the system.
Should we switch from a legacy ERP or extend it?
Compare the three-year cost of both paths, including downtime risk and the cost of integrations you cannot build on the old platform. If the legacy system blocks reporting or integration you already need, extending it only delays the decision.