Skip to content
Custom Software

Manufacturing ERP for Indian MSMEs: what works and what fails

Nearly three-quarters of discrete manufacturing ERP projects miss their objectives, and it is almost never the software's fault. Here is what separates the ones that work.

Author
Astera Infotech
Published
Reading time
6 min read

Coimbatore runs on manufacturing. Pumps, motors, textiles, castings, auto components — mostly companies between twenty and three hundred people, most of them running on a combination of Tally, several spreadsheets, a WhatsApp group, and one person who knows where everything actually is.

At some point somebody suggests an ERP. Usually after a stock count goes badly wrong, or a customer asks for traceability nobody can produce.

The instinct is right. The execution is where it goes wrong, and the numbers on that are worth seeing before you sign anything.

Most of these projects do not go well

Discrete manufacturing ERP projects
Fail to meet their objectives73%
Average cost overrun215%
Of build cost spent again each year on upkeep20–35%
Discrete manufacturing has the worst record of any segment measured. Worth knowing before you start, because almost none of it is caused by the software being bad.Source: Panorama Consulting Group, 2026 ERP Report

Discrete manufacturing — which is most of what this district makes — has the worst record of any segment measured. Seventy-three per cent miss their objectives, and the average cost overrun is more than triple the original estimate.

Read the failure reasons and almost none of them are technical. Research on Indian MSME implementations lands on the same list every time: weak sponsorship from the top, poor project management, testing skipped, knowledge never transferred, and staff who quietly carry on using the old spreadsheet. The blunt version is that adoption is the risk, not the software.

Which is good news, because adoption is something you control and vendor selection largely is not.

Start by being honest about what is actually broken

The businesses that get value from this can name the problem in one sentence before anyone demos anything:

  • We do not know what is in stock without walking the floor.
  • We cannot tell which jobs made money.
  • Dispatch and invoicing disagree, so payments get delayed.
  • A customer wants batch traceability and we cannot produce it.
  • Month-end takes nine days and two people.

If you cannot finish that sentence, an ERP will not help yet, and you will spend fifteen lakh finding out. That is not a reason to do nothing — it is a reason to spend two weeks writing down how work actually flows first. Half the businesses that do this discover the real problem was one broken handoff, not the absence of a system.

The order to implement it in

This is the single biggest predictor of whether it survives contact with your shop floor.

The order that works
  1. One source of truth for items and parties

    Item master, customers, suppliers, units, tax rates. Dull, and every later phase is wrong without it.

  2. Purchase, stock and dispatch

    What came in, what is on the floor, what went out. This is where the first real saving shows up.

  3. Production and costing

    Work orders, consumption, job costing. Only meaningful once stock numbers are trusted.

  4. Accounts, payroll, analytics

    Last, not first — despite being the part most vendors demo on day one.

Each phase depends on the one above it being trustworthy. The projects that stall are almost always the ones that started at phase three or four because that is what the demo showed.

Vendors demo the dashboard because dashboards sell. But a production dashboard built on stock numbers nobody trusts produces confident, wrong graphs — which is worse than no graph, because people act on it.

Get the item master right first. It is the dullest fortnight of the project and everything downstream is wrong without it. Duplicate part codes, three units of measure for the same item, supplier names spelled four ways: fix that before it is baked into a system.

What matters in an Indian manufacturing context

Generic ERP advice skips the things that decide this here:

GST is not a feature, it is the plumbing. Invoices, e-way bills, HSN codes, input credit reconciliation. If GST handling is a bolt-on, you will be exporting to Excel every month — which is the exact work you bought the system to remove. This connects to how e-invoicing thresholds have moved, and any system you pick should already handle it.

Job work and subcontracting. Enormous amounts of Coimbatore manufacturing move material out to a job worker and back. Many ERPs model this badly or not at all. Test it with your own flow during the demo — send material out, get part of it back, account for the rest.

Multiple units of measure. Buy in kilograms, issue in metres, sell in pieces. Ask the vendor to configure your actual conversions, not a tidy example.

Shop floor reality. People on the floor will not use a system that needs a laptop and a clean login. It has to work on a shared tablet with dusty hands, or it will be filled in at the end of the day from memory — which puts you back where you started with extra steps.

Payroll and attendance. Shift patterns, overtime, contract labour. Usually the fastest visible win and the easiest to underestimate, for the reasons we set out in attendance and payroll.

Buy, configure, or build

Three honest options.

Buy a standard product. Cheapest, fastest, best-supported. Right for most businesses. The catch is that you adapt to it, and for genuinely standard manufacturing that is fine and often an improvement.

Buy and configure heavily. Where most MSMEs land. Works, but every customisation is a thing to re-test at every upgrade. Keep a written list of what was changed and why — the reason nobody can upgrade a five-year-old system is that nobody remembers.

Build the parts no product fits. Rarely the whole ERP, and anyone telling you to build one from scratch is selling hours. But a genuinely unusual process — an odd costing model, a customer portal, a machine integration — is often better built and connected to the standard system than forced into it. We have written about where that line sits.

A pattern worth noticing: the most successful projects we see are the smallest ones. One problem, solved properly, connected to what already exists.

The costs nobody puts in the quote

  • Data cleaning. Your item master, customer list and opening stock. This is your work, not the vendor's, and it takes longer than you think.
  • Your team's time. The people who know how the business works are the people who must specify it. That is real production capacity, spent for months.
  • Training, then training again. After three months, when people have hit the cases training did not cover.
  • Annual upkeep. Budget between a fifth and a third of the build cost every year. Not optional, and rarely mentioned upfront.
  • The parallel-running period. Old system and new, together, for at least a month.

Questions worth asking any ERP vendor

  1. Can you configure my actual job-work flow during the demo, with my part numbers?
  2. Who does the data migration, and what does it cost if my data is messy?
  3. What happens to my customisations when you release an upgrade?
  4. Can I export all of my data, in full, without asking you?
  5. What is the annual cost after year one — all of it?
  6. Which three of your customers are my size, in my industry, and may I call them?

Question six is the one that tells you most. A vendor with genuinely comparable references gives them readily.

The honest summary

An ERP is not a purchase, it is a change programme with software attached. The projects that work start with one nameable problem, fix the master data first, implement in the order above, and keep the first phase small enough to finish.

If you are weighing this up, tell us what actually breaks in your week and we will tell you whether it needs an ERP, a smaller system, or a fixed handoff — including when the answer is that you are not ready to spend the money yet.

  • erp
  • manufacturing
  • msme
  • custom software
  • operations
Next step

Want this looked at for your business?

Every business is different enough that general advice only goes so far. Tell us your situation and we'll give you a specific answer.