How to choose an ERP for an Indian manufacturing MSME

Start with the diagnosis, not the shortlist

The most common way this goes wrong is starting from "we need an ERP" rather than from a specific, expensive problem. An ERP is not a thing you need; it is a thing you buy to stop something particular from happening.

Before you contact anyone, write down the three most expensive recurring problems in your plant. Not categories — incidents. For example:

• "We quoted a job in March at a price based on a BOM that had changed in January, and lost about two lakh."
• "Material was at a plating vendor for eight months and nobody noticed until the audit."
• "Physical stock and book stock differ by roughly 12 per cent and we write off the gap each year."
• "Every quotation takes our senior engineer two days because he rebuilds the cost from scratch."

This list does two things. It gives you a way to evaluate demos — you ask each vendor to show you their handling of your three problems, not their favourite features. And it gives you a rough value for the project, which tells you what you can sensibly spend.

If you cannot write three specific, costly incidents, that is worth knowing too. It may mean the honest answer is a better spreadsheet discipline and a Tally upgrade, not an ERP.

The three categories you are choosing between

Whatever the marketing says, there are broadly three options available to an Indian MSME, and they fail in different ways.

Tally plus spreadsheets

What most shops run today. Tally is genuinely excellent at what it does — statutory compliance, your CA already knows it, and there is no learning curve. The spreadsheets fill the gap for BOMs, costing and job work.

The failure mode is not that spreadsheets are bad. It is that they are single-owner. The BOM file is understood by one engineer. The job-work register is maintained by one person. When that person is unavailable, the information is functionally gone, and nobody else can confidently answer a question from it. It is also invisible to everyone who needs it in real time.

Tier-one global ERPs

Very capable, genuinely proven at scale, and built by companies that will still exist in twenty years. If you are multi-plant, multi-currency, or consolidating internationally, this is the correct category and the rest of this article matters less to you.

The failure mode for an MSME is a mismatch of assumptions. These systems assume an internal IT function, a change-management budget, a rollout measured in quarters, and labour paid by time. Localisation for Indian requirements is frequently an add-on module with its own licence. The implementation partner, not the software vendor, determines your outcome — and partner quality varies enormously.

Focused manufacturing ERPs

Systems built for a narrower band of manufacturer. Faster to implement, priced for an MSME, and usually opinionated about how you should work.

The failure mode is fit. Because they are narrow, the gap between "almost fits" and "fits" matters enormously — and a vendor in this category has every incentive to describe the former as the latter. Which brings us to the questions section.

What is specific to Indian manufacturing

Four things routinely break imported software, and they are worth checking explicitly because a generic feature list will not reveal them.

Labour paid by output

If operators are paid per piece, per hole or per kilogram, an ERP that only models hourly rates will mis-cost every one of those operations. This is not a rounding error; we have walked through a worked example where it runs to 22 per cent. Ask specifically whether the costing basis can be set per operation.

Job work as a core process, not an exception

In a lot of Indian shops, a third to a half of the process happens somewhere else. That means delivery challans under Rule 45, statutory return windows under Section 143, ITC-04 filing, and reconciling partial returns and vendor scrap against the original challan. Software that treats subcontracting as an occasional purchase order will not carry this.

GST as a live constraint

GSTR-1, GSTR-3B, period locking once a return is filed, TDS at the payment point, e-way bills. These change periodically. Ask how statutory updates are delivered and whether they carry a separate charge.

Mid-year onboarding

Nobody is ready to go live on 1 April. If a system cannot load opening balances at an arbitrary date, your project either waits nine months or runs two systems in parallel — and parallel running is where implementations quietly die.

Twelve questions to ask every vendor

Ask all twelve of everyone, including us. The pattern of answers tells you more than any individual answer.

What it really costs, and how long it really takes

Software licensing is rarely the largest number, which is why comparing monthly fees is a poor way to compare options. Budget for four things.

1. Licence. Watch the pricing basis carefully. Per-user pricing looks cheap at five users and reshapes your rollout at twenty — and per-seat costs tend to mean the storekeeper never gets a login, which quietly wrecks your data quality.
2. Implementation and configuration. Usually a one-time fee, sometimes comparable to a year of licence.
3. Data migration. The variable that dominates. Cleaning an item master with inconsistent part numbering is genuine work, and it is your people who must resolve the ambiguities because only they know the answers.
4. Your own team's time. Almost never budgeted, and frequently the largest real cost. Someone senior will spend meaningful time on this for the duration.

On timelines, be sceptical of any number quoted before the vendor has seen your data. As a rough guide for an MSME with a single plant:

• Clean data — maintained item master, BOMs already documented: 4 to 8 weeks.
• Typical data — partial documentation, some tribal knowledge: 2 to 4 months.
• Difficult data — BOMs as drawings and memory, inconsistent part numbers: 4 to 6 months, mostly data work.

Notice that the variable is your data, not the software. Any vendor quoting a fixed timeline without examining it is guessing.

How these projects actually fail

Failed implementations are rarely a technology problem. Four patterns account for most of them.

The system nobody enters data into

The commonest failure by a distance. The software is fine; the floor does not use it. Material gets issued physically and recorded two days later from memory, so stock is permanently wrong and confidence collapses. Causes are usually screens that take too long for high-frequency tasks, or per-seat licensing that denied a login to the person who actually handles material.

The parallel run that never ends

Running old and new together "until we are confident" sounds prudent and is usually fatal. Double entry is exhausting, so one system gets updated properly and the other decays — and it is normally the new one that decays, because the old one is where the invoices go out from. Pick a date and cut over, with a pilot line beforehand to de-risk it.

The customisation spiral

Each department requests changes to match existing habits. Six months later you have a heavily modified system that nobody can upgrade. Some customisation is legitimate; wanting a screen to look like the old spreadsheet generally is not.

The fit that was never there

The vendor said yes to everything during selection. Month three reveals the product cannot model something structural to your business. This is why question 1 matters more than the other eleven combined.

Making the decision

When you have two or three real candidates, three tie-breakers are worth more than a feature matrix.

Who did you speak to? On a demo, were you talking to someone who could explain how the costing engine works, or someone reading a datasheet? For a small vendor especially, the answer predicts what support will feel like in month seven.

What did they say no to? The vendor who declined something is giving you real information. The vendor who said yes to everything has told you nothing at all.

What does the pilot look like? Any vendor should be willing to run one product line end to end on real orders before you commit the whole plant. If that is resisted, ask why.

And it is entirely legitimate to conclude that none of them fit yet. Tally plus a genuinely well-maintained spreadsheet, with someone accountable for it, beats a half-implemented ERP comfortably. The failure mode of doing nothing is visible and slow. The failure mode of a stalled implementation is expensive and demoralising, and it makes the next attempt harder because the whole plant now believes these projects do not work.

---

Related reading

• Piece-rate costing: why your machine-hour rate is lying to you
• GST job work under Section 143: the return deadlines explained
• The industries NextGenManager is built for