ERP Selection & Evaluation Guide for Growing Indian Businesses

The pattern is familiar. There is an ERP in place, or Tally plus a set of spreadsheets that grew into a system. On paper it does the job. In practice the monthly numbers get rebuilt in Excel, physical stock and system stock have not agreed for years, each plant keeps its own register, and every small change needs someone who understands the customisations. Nobody planned it that way. It accumulated.

So the question at the start of a replacement is not which product has more modules. It is whether a new system can carry the way this business actually runs, without recreating the same workarounds in something newer. Feature lists do not tell you enough, because many systems will appear to meet the same requirements on paper.

Start with the problems, not the feature list

Write down the three or four things that actually hurt. Not "we need better reporting" but "the sales team commits stock we do not have, twice a month". Specific problems can be tested in a demo. Generic requirements cannot, which is why they end up satisfied on paper and unresolved in practice.

Once you have that list, most of the evaluation follows from it. The things that separate systems are how well they handle the way your business works, whether stock and finance stay honest across locations and periods, how much of the answer is configuration versus code, whether GST and e-invoicing sit inside the transaction flow or beside it, what happens to the systems you are keeping, and where your reports come from. Everything else is detail.

Is the platform really the problem?

This is the step most companies skip, and skipping it is expensive. The symptoms of a badly implemented ERP and an unsuitable one look identical from the outside.

Take the signals seriously: management reports rebuilt outside the system, stock that never matches the count, locations running parallel records, work that happens over email and reaches the ERP afterwards, changes that always need development, finance and operations reconciling two versions of the same number, and nobody able to answer "where do we stand today" without a manual reconciliation exercise.

Then, for each one, ask which of three things is true:

1. People are working around the system. It can do this; nobody does it that way. Replacing the software moves the habit into a new product.
2. It was never set up properly. The capability exists but the master data, configuration or workflow was left half-finished. This is usually repairable, and much cheaper than a replacement.
3. The product cannot represent your business. No amount of configuration closes the gap. This is the case that justifies starting again.

A useful test: take your worst two problems and ask what would specifically have to change for the current system to fix them. If the answer is configuration you never completed, you have an implementation project. If the answer is that the software has no concept of the thing you are describing, you have a selection project. Where it turns out to be the former, ERP implementation strategy and the risks behind ERP failure are the more useful reading.

Decide what you need before the demos begin

Vendors are good at demonstrations. If you arrive without your own definition of the problem, you will be shown a coherent story and asked to compare it with another coherent story. Put the following on paper first.

• Headcount and volumes now, and where you expect to be in three years.
• Locations, plants and warehouses, and which of them hold stock, produce, or invoice.
• What you make or move, and the operating model: to order, to stock, distribution, processing, or a mix.
• What lives in Tally today, what lives in the current ERP, and which spreadsheets the business genuinely depends on.
• Which masters and how much transaction history really have to migrate, and what condition that data is in.
• The GST, e-invoicing and e-way bill work you must produce, and where it sits in your flow.
• Systems that will not be replaced, and therefore have to connect.
• Cloud or on-premise, and the constraint behind that preference.
• The reports your management team actually uses to run the business.

On shortlist size: there is no correct number. A wider paper screen against this list, then a small group taken through the same scenarios in depth, works better than eight shallow demos. What matters is that everyone who reaches the demo stage gets identical scenarios, because otherwise you are comparing presentations.

Ten things worth evaluating properly

1. Does it fit your kind of work?

Some systems are built around a way of operating; others are general and adapted afterwards. Both can end well, but they ask different things of you. Have someone from the vendor walk your primary flow using your words, and notice whether the person doing it understands your industry or is reading a script. If every gap is answered with "we can build that", treat that as a warning that the implementation may be turning into a custom-development project.

2. Stock, locations and whether the numbers stay honest

Stock and multi-location handling are good places to test how the system behaves under real operating conditions. Multi-location is not a reporting filter; it is stock held in more than one place, moving between them, and reconciling afterwards. Ask them to move stock between two of your locations and then show you the audit trail. Ask what the system does when the physical count disagrees with the book.

3. GST and statutory work

Ask whether compliance is part of the transaction or a separate exercise afterwards. Then ask them to take one transaction all the way through to its statutory output, in the system, in front of you. Compliance handled by exporting to a spreadsheet, or by an add-on nobody in the room can open, is a problem you will inherit.

4. Standard, configuration, or code?

This distinction matters because configuration and custom code create very different maintenance obligations. Configuration uses supported settings and survives upgrades. Custom code has to be maintained by somebody, and it is usually the reason a company cannot upgrade three years later. Ask for your requirement list split three ways in writing: standard, configuration, development.

5. The systems you are keeping

Whatever survives has to connect. Get the method named for each one, and get someone to say who owns it when either side changes. A scheduled file drop described as "integration" is worth knowing about now rather than in month four.

6. Where reports come from

Ask them to build one of your reports during the session, from data entered in that session. A prepared dashboard tells you the system can display numbers; it does not tell you the report you need can be produced, or that you will be able to change it later without raising a ticket.

7. Deployment

If both cloud and on-premise are offered, ask what actually differs between them. Ask what your own team will have to manage in each deployment model; the difference is not only where the software is hosted.

8. Implementation and data migration

Any credible timeline depends on two things the vendor does not control: the state of your data and the availability of your people. If neither appears in the plan, the plan is a sales document. Ask how they handle masters that arrive incomplete, because yours will.

9. Training and what support looks like afterwards

Find out who answers an operational question six months after go-live, and how. Training treated as a one-week event before go-live can leave a good system only partly adopted.

10. Changing it in two years

Your process will change. Ask for a real example of a change made after go-live and who made it. If the honest answer is that every change comes back to the vendor, factor that into the cost of ownership.

Make the vendor demonstrate your real work

A prepared demo is designed to work. The data is clean, the flow is rehearsed, and the awkward cases are absent. That is not dishonest. It is simply what a demo is. But it will not tell you what you need to know.

The single most useful change you can make to an ERP evaluation is to supply the scenarios and some representative data yourself, and to give every shortlisted vendor the same ones. Not your whole database; a small extract that includes the cases you know are difficult.

Five scenarios cover most of it:

1. A sales order through dispatch, invoice and receivable, including a part dispatch and whatever tax or pricing wrinkle you actually deal with.
2. A purchase requirement through PO, goods receipt, stock update and vendor invoice, including a short receipt or a rejection.
3. A stock transfer between two of your locations, and the reconciliation afterwards.
4. One of your management reports, built in front of you from the transactions just entered.
5. For manufacturers: a BOM through material requirement, work order release, production recording, and the stock and cost that result.

Throughout, keep asking one question: is this standard, configuration, or custom development? Ask it every time something impressive appears. The answers are the most valuable notes you will take.

Manufacturing evaluations need more depth because important differences are often hidden behind the same high-level feature names. Two areas repay separate scrutiny: how the system holds material structure and multi-level BOM, and how it sets and analyses work-order costing and variance. Both are written for exactly this stage.

Keep a simple record of what you were shown

Scoring is worth the effort mainly because it forces you to write down what actually happened, while you still remember it. A worksheet like this, filled in during or straight after each demo, is enough.

Two rules make it useful. Score only what was demonstrated, not what was described. And if you want weighted scoring, set the weights before the demos start — deciding them afterwards is how a preferred vendor wins a process that was supposed to test it.

Large ERP or mid-market ERP: what actually changes?

This comes up in many serious evaluations, usually framed as a question about capability when it is really a question about what the system will ask of your organisation. The points below are tendencies worth testing, not rules.

Both ends have a characteristic failure. A mid-market system bought by a business that genuinely needed enterprise breadth can get stretched past its design, and that is where customisation-led trouble starts. A large platform bought by a company without the capacity to govern it can end up under-configured and only partly adopted, producing exactly the spreadsheets it was meant to remove. Both look like software problems afterwards. Both were decisions about scope.

When exactllyERP is worth evaluating

Plainly, so you can rule it in or out early. exactllyERP suits a growing mid-sized or enterprise business — the typical profile is roughly 100 to 5,000 people — running real operations across one or several locations, that wants a connected ERP rather than accounting software with additions around it. It is built for eight industries: Manufacturing, Seeds, Steel, Edible Oil, Chemicals, Cement, FMCG, and Transport & Logistics. Both cloud and on-premise deployment are supported, and APIs are available for approved third-party integrations. Implementation is typically 6–8 weeks, depending on scope, data and complexity.

For manufacturers, the areas worth putting under pressure are multi-level BOM and work orders, material planning from production demand, routing and operation sequences, multi-location inventory, job work and subcontracting, rejection and rework, and actual work-order costing with variance. The manufacturing overview shows how they connect, and the features page covers the wider functional scope.

Two honest caveats. If what you need is accounting, a full ERP is more system than the problem requires. And if you have a genuinely unusual requirement, whether a specialised process or an industry practice particular to your operation, do not assume it is covered because the surrounding area is. Ask for it to be demonstrated. That advice applies to every vendor on your list, including us.

Before you decide

Whatever ends up on the shortlist, the last stretch is the same. Write down the workflows that actually matter. Give every vendor the same scenarios and your own data. Record what was demonstrated rather than what was promised. Get the standard, configuration and development split in writing. Then decide.

If exactllyERP is on that list, bring us your workflows rather than asking for a standard demonstration — a walkthrough built around your operation is more useful to you and more revealing for both of us.

Common questions