On this page
- What problem are you solving?
- Define the outcome
- Who should decide
- Turn work into requirements
- How it will be delivered
- Evaluate the whole ERP
- Shortlist first
- Make vendors prove it
- Record what was shown
- Functional sign-off
- When systems look equal
- Customer proof
- How exactllyERP fits
- Selection checklist
- Go deeper
The right ERP is not automatically the product with the most modules, the biggest brand or the lowest quotation. It is the system that fits the way your business needs to operate, can be implemented realistically, connects with the systems you intend to keep, gives the organisation the controls and information it needs, and remains manageable after go-live.
This guide explains how to make that decision.
Start by deciding what problem you are actually solving
Some companies begin an ERP search when what they really have is an accounting-software problem.
Others already own an ERP, but much of the business has gradually moved outside it.
Sales keeps one spreadsheet. Production keeps another. Accounts maintains reconciliations of its own. Branches or plants have local records. Management reporting is assembled after the event. Employees know that the official system exists, but they also know which Excel file contains the number they actually trust.
Those are important warning signs.
But they do not automatically mean that the ERP needs replacing.
Before starting a selection process, separate three different situations.
You have outgrown accounting software and disconnected applications
Accounting software is primarily concerned with financial transactions and books of account. An ERP should go further: connecting the operational events that eventually create those financial transactions.
An order affects stock. Stock can affect procurement or production. Production consumes material and creates finished goods. Dispatch creates billing. Billing creates receivables. Collections affect cash.
When each of those activities lives in a different application or spreadsheet, the organisation spends increasing effort reconciling the same business between systems.
That is a genuine ERP problem.
Your existing ERP can do the job, but the implementation never landed properly
This is different.
The functionality may exist, but master data is poor, workflows were never completed, users were insufficiently trained, controls were bypassed or people returned to old processes after go-live.
Replacing the software without understanding this can simply move the same behaviour into a new ERP.
Your ERP can no longer represent the business
This is the clearest replacement case.
Perhaps the business has added locations, plants or companies. The operating model has become more sophisticated. Traceability, planning, costing or distribution requirements have changed. Every significant process now needs custom code. Critical reports are built outside the ERP because the necessary operational information never reaches it correctly.
In that situation, the limitation may genuinely be the platform.
Before asking “Which ERP should we buy?”, therefore ask: “What exactly has stopped working, and why?”
A useful starting exercise is to write down the five problems management most wants a new ERP to eliminate and identify whether each is caused by people, implementation, process design or software capability.
That one exercise can prevent a very expensive selection process from solving the wrong problem.
Define the outcome before defining the software
ERP requirements often begin as lists of modules:
Finance. Purchase. Sales. Inventory. Manufacturing. CRM. Reporting.
That is necessary information, but it does not explain what success looks like.
A stronger ERP selection starts with business outcomes. For example:
- management should be able to see the current stock position without asking three locations to reconcile it first;
- production planning should use actual material availability and pending demand;
- credit limits should be enforced at the point where an order is entered;
- finance and operations should arrive at the same inventory value;
- one business transaction should not have to be entered repeatedly into separate applications;
- month-end reporting should come from controlled system data rather than manually rebuilt spreadsheets.
These statements can eventually be tested. “We need better visibility” cannot.
Define the scope as well
Before talking seriously to vendors, document what the new ERP is expected to cover. Include:
- Business entities
- Which companies, divisions or legal entities are included?
- Locations
- Which plants, warehouses, depots, branches and offices are in scope?
- Processes
- What happens from procurement through production or service delivery, sales, dispatch, finance and reporting?
- Users
- Who will use the system, and for what?
- Systems being replaced
- Which applications and spreadsheets should disappear?
- Systems being retained
- Which applications must continue and therefore integrate with the ERP?
- Data
- What masters, open transactions, balances and history may need migration?
- Growth
- What additional locations, users, products, transactions or business models might the system have to accommodate?
An ERP that fits today’s organisation but not the organisation you are reasonably building towards may only postpone the next systems problem.
Put the right people around the ERP decision
ERP should not be selected by IT alone.
It should not be selected by Finance alone either.
And it should certainly not be selected because one senior executive liked one particular demonstration.
An ERP sits between departments. That means the selection process needs people who collectively understand the business the system is expected to run.
CEO / MD / Owner
The CEO should be clear about:
- why the organisation is making the change;
- which business outcomes matter;
- what level of organisational change is acceptable;
- whether the selected system supports the company’s direction and scale;
- whether the vendor feels credible enough for a long-term relationship.
The CEO does not need to evaluate every transaction screen.
The CEO does need to ensure the organisation is solving the right problem.
CFO / Finance Director
The CFO should test:
- financial control;
- stock and cost integrity;
- receivables and credit;
- auditability;
- reporting;
- cash and reconciliation;
- implementation risk;
- total cost over several years.
The lowest quotation is not necessarily the lowest-cost decision.
COO / Operations Head
The COO needs to answer the question many ERP selections avoid: Can we actually run the business this way every day?
Planning, production, purchasing, stock movement, quality, distribution and exceptions need to work inside the operating flow rather than being reconstructed afterwards.
CIO / IT Head
IT should examine:
- deployment architecture;
- infrastructure responsibility;
- integration;
- APIs;
- security;
- performance;
- migration;
- backup and recovery;
- extensibility;
- future maintenance.
A system can fit the business functionally and still create an architecture that IT cannot support sensibly.
Accounts / Controllers
The people responsible for daily financial accuracy should test the detail:
- transaction flow;
- ledgers and subledgers;
- GST and statutory processes where applicable;
- opening balances;
- ageing;
- stock valuation;
- approvals;
- reconciliation;
- audit trail;
- period-end processes.
Functional heads and power users
The employees who know where the current process breaks are essential.
They know the exceptions.
They know that a normal sales order is easy but a part dispatch with a credit issue is difficult. They know that standard production is simple but rework is not. They know which report looks straightforward until somebody has to reconcile it.
Those difficult situations are often where the real differences between ERP systems appear.
ERP project champion
One person should coordinate the buyer side of the process.
That does not mean making every decision.
It means making sure requirements are documented, questions get answered, decisions are recorded, vendors receive comparable information and unresolved risks do not disappear between meetings.
Turn the way your business works into requirements
A strong ERP requirement describes what the business needs to accomplish. A weak one simply names a feature. Compare:
The second version can be demonstrated. That makes it useful.
Capture normal workflows and exceptions
For every important process, ask:
- What normally happens?
- What occasionally goes wrong?
- Who is allowed to override it?
- What should the ERP prevent?
- What should it record?
- What should Finance see afterwards?
- What should management be able to report?
A requirements document containing only the normal case will select an ERP for the easiest day your business ever has. Your difficult days matter more.
Separate requirements into priorities
Not every requested feature should carry equal weight. Use three practical categories:
This matters because ERP projects can become overloaded with accumulated wishes from every department.
A request is not automatically a requirement simply because somebody would like it.
Ask how each requirement will be delivered
For each important requirement, ask the vendor to classify the answer.
Standard
The capability is part of the normal product.
Configuration
The product supports it through settings, masters, workflows or other supported configuration.
Custom development
Code or a separately developed component is required specifically for your requirement.
None of these categories is automatically bad. Some genuinely differentiating business processes justify custom development.
The problem begins when nobody knows which category a requirement belongs to.
- why configuration cannot meet the requirement;
- who will build it;
- who will test it;
- who will maintain it;
- what happens during an upgrade;
- what further cost or dependency it creates.
Customisation should be a conscious business decision, not a surprise discovered during implementation.
Evaluate the whole ERP, not only its feature list
Feature fit is essential. It is not sufficient.
A serious ERP evaluation should consider at least seven dimensions.
Operational and industry fit
Can the ERP represent the way the organisation actually works?
Does the vendor understand the language, transactions, exceptions and controls of your operating environment?
Industry-specific depth matters most when the industry’s operating concepts genuinely differ from general business processes.
At the same time, a generic platform can be the right choice for an organisation whose processes are relatively standard or whose broader technology strategy outweighs specialist workflow depth.
This is a trade-off to evaluate, not a slogan.
Go deeperIndustry-Specific ERP vs Generic ERP — How to Decide
Finance, control and management visibility
Can operational activity flow into finance without repeated manual reconstruction?
Can users see:
- stock and valuation;
- receivables and payables;
- cost and variance where relevant;
- audit trails;
- reconciliations;
- management reporting?
The objective is not simply to automate transaction entry. It is to make operational and financial information agree.
Architecture and deployment
Do you need cloud, on-premise or another hosting arrangement?
Who manages the infrastructure?
What do security policies require?
What happens at remote locations with unreliable connectivity?
How are upgrades, backups and disaster recovery handled?
These questions deserve their own decision rather than being reduced to “cloud is modern” or “on-premise gives control.”
Integration and data
List every system that will remain after ERP implementation.
For each one, determine:
- what information must move;
- in which direction;
- how often;
- how it will connect;
- who owns the interface;
- what happens when an integration fails.
An available API is useful.
It is not, by itself, an integration strategy.
Also understand your ability to access and export your own ERP data if requirements change later.
Go deeperERP Integrations, Data Portability & Post-Go-Live Support
Implementation and organisational readiness
A good ERP can still become a poor implementation.
Before choosing the product, understand what implementing it will require from your own organisation.
Who will provide process decisions? Who will clean data? Who will validate migrated balances and stock? Who will test workflows? Who will train users? Who has authority to prevent uncontrolled scope growth?
The vendor can implement software.
The buyer still has to implement change inside the business.
Vendor and support model
ERP is not a one-time software purchase.
Understand:
- who will actually implement the system;
- whether implementation is direct or partner-led;
- who supports you after go-live;
- how issues are escalated;
- how future changes are handled;
- whether relevant customer evidence exists;
- what happens when the product itself changes.
A persuasive sales team is not the same thing as a dependable delivery and support organisation.
Total cost of ownership
Do not compare licence prices alone.
Depending on the system and implementation, the economic picture may also include:
- implementation;
- data migration;
- customisation;
- integrations;
- training;
- infrastructure or cloud hosting;
- annual support or maintenance;
- upgrades;
- additional users/modules;
- internal project resources.
Compare vendors on the same scope over an agreed period rather than comparing quotations constructed around different assumptions.
Go deeperERP Pricing, Licensing & 3–5 Year TCO — How to Compare Quotes
Shortlist before the demonstrations begin
Do not use demonstrations to discover what you need. Use requirements to decide who deserves a demonstration.
An initial vendor screen can eliminate systems that clearly fail non-negotiable criteria such as:
- fundamental functional fit;
- deployment constraints;
- statutory requirements;
- critical integrations;
- industry requirements;
- organisational scale;
- commercial feasibility.
There is no universally correct number of ERP vendors to evaluate. The objective is simply to avoid spending management and functional-team time on a large number of shallow presentations.
A smaller number of credible candidates examined deeply will usually teach you more than a large number of generic demonstrations.
Make vendors prove the difficult parts
Once the shortlist exists, the selection process should change from “Tell us what your ERP can do” to “Show us what happens in our situation.”
Give shortlisted vendors the same scenarios. Include ordinary workflows, but deliberately include difficult ones. For example:
And whenever something important appears, ask:
Is this standard functionality, configuration or custom development?
The purpose of an ERP demonstration is not to be impressed. It is to reduce uncertainty.
For the detailed scenario methodology, evaluation scorecard, reference questions and red flags, use the ERP Demo & Vendor Evaluation Checklist and Exactlly’s existing ERP Selection & Evaluation Guide.
Record what was demonstrated
ERP decisions become surprisingly subjective after several vendor meetings.
One team remembers the reporting. Another remembers the salesperson. A senior executive remembers one particularly attractive dashboard. A functional user remembers the one exception the system could not handle.
Do not leave the final decision to memory.
Establish the evaluation criteria before the demonstrations and record:
Weighting should also be agreed before vendors are demonstrated. Otherwise the selection criteria can unconsciously change to favour the product somebody already prefers.
What should each function approve before the final ERP decision?
A final ERP recommendation should be more than a combined score. Different stakeholders should explicitly be comfortable with different risks.
| Stakeholder | Should be satisfied that… |
|---|---|
| CEO / Owner | The system addresses the business problem, supports the direction of the company and represents an acceptable organisational risk. |
| CFO | Financial controls, reporting, commercial assumptions and multi-year cost are acceptable. |
| COO / Operations | The business can genuinely operate through the proposed workflows, including important exceptions. |
| IT | Architecture, deployment, integrations, security, data, performance and maintainability are acceptable. |
| Accounts / Controller | Transaction integrity, statutory processes, reconciliation, auditability and opening-state migration can be controlled. |
| Functional heads | Critical day-to-day workflows have been demonstrated rather than promised. |
| Project Champion | Scope, unresolved gaps, implementation responsibilities and decision records are complete. |
This does not mean every stakeholder chooses a different ERP.
It means nobody discovers after signing that the selection process never evaluated the risk they were expected to manage.
When several ERP systems appear equally capable
This is common. Most serious ERP systems will satisfy a large proportion of a conventional feature list.
When that happens, go deeper rather than adding more features to the spreadsheet. Compare:
- How naturally does each system handle your signature workflows?
- How much configuration or code is required?
- What will your organisation need to manage?
- How difficult is integration with the systems you are keeping?
- How realistic is the implementation approach?
- Which system will users actually work in rather than work around?
- What will the solution cost over several years?
- What relevant customers can confirm the vendor’s ability to deliver and support it?
The right answer may differ from one business to another.
That is why “best ERP” lists can only take a buyer so far.
What customer proof should you ask for?
A customer logo proves that a commercial relationship existed. It does not automatically prove that the ERP runs the process you care about.
Ask for evidence relevant to your own decision. Ideally, a reference should share some combination of:
- industry;
- operating model;
- scale;
- number of locations;
- implementation complexity;
- workflows;
- integrations;
- business challenge.
Then ask what happened after the sale. What was difficult? What had to be customised? What took more effort than expected? How did users adopt the system? How does the vendor respond now that implementation is over?
A useful reference does not need to say that everything was perfect. It needs to help you understand what owning and operating the ERP is actually like.
One ERP replacement story worth thinking about
SKICORP provides a useful example because the lesson is not simply about software features.
The diversified manufacturing group came to Exactlly after an earlier ERP initiative had run for around two years without delivering the required result. exactllyERP was subsequently implemented to the customer’s full satisfaction in less than a year and now runs across all verticals of the business. The Exactlly relationship has continued for more than seven years.
The important point for an ERP buyer is not that every implementation should take the same amount of time. They will not.
It is that product selection, organisational fit and implementation delivery have to be judged together.
A technically capable ERP that never becomes the way the business operates has not solved the ERP problem.
How exactllyERP fits into this evaluation
Exactlly has developed business software since 1997 and today supports more than 40,000 users.
exactllyERP covers eight industry verticals:
Seeds · Iron & Steel · Transport & Logistics · Manufacturing · Chemical · FMCG · Edible Oil · Cement
It supports both cloud and on-premise deployment. For on-premise environments, Windows and Linux server environments are supported, and customers may choose their own cloud infrastructure where that deployment approach is appropriate.
exactllyERP can also support APIs and integrations according to implementation requirements, and mobile applications are available for relevant workflows.
Commercially, Exactlly supports a perpetual-licence model with annual support/subscription, with pricing provided according to the buyer’s scope.
Those are reasons to consider Exactlly where they match your requirements.
They are not reasons to lower the standard of evaluation.
If you evaluate exactllyERP, give us the same difficult workflows, exceptions, reports and integration questions you give every other shortlisted ERP vendor. Ask us to show them.
ERP selection checklist
Before approving an ERP, confirm that your organisation can answer yes to the following.
Business
Requirements
Evaluation
Technology
Implementation
Commercial
Proof
The buying process probably needs more work before the contract does.
Go deeper
Different ERP decisions deserve deeper examination.