Choosing Manufacturing ERP Software
How manufacturing ERP software works, who needs it, how to evaluate it, and when modernising the system you have beats replacing it.
Founder, Viithiisys
What manufacturing ERP software is
Manufacturing ERP software is a single system of record that links bills of materials, production orders, inventory, purchasing, costing and finance, so a change in one place updates the others.
Enterprise resource planning (ERP) started as material requirements planning on mainframes. The idea was simple: if you know what you will build, you can work out what to buy and when. Modern manufacturing ERP adds shop-floor reporting, quality records, costing and the general ledger on top of that.
The phrases manufacturing ERP and ERP for the manufacturing industry mean the same thing here. The difference from a general-purpose ERP is the production module: routings, work centres, lot tracking and cost roll-ups.
How manufacturing ERP software works
The system holds a bill of materials (the parts list for each product) and a routing (the steps and machines that make it). A demand signal runs against stock and open orders to produce purchase and production orders.
Each order then moves through states: planned, released, in progress, complete. When a shop-floor operator reports quantity made and quantity scrapped, the ERP consumes components, adds finished goods and posts the cost to finance.
Three pieces carry most of the weight:
- Item master data, where a wrong unit of measure quietly breaks every cost calculation.
- Planning logic, which decides what is ordered and when.
- Costing, which turns production events into money.
Most disappointments trace back to the first of these. Microsoft's documentation for production control in Dynamics 365 Supply Chain Management shows how many separate settings sit behind these steps in even one packaged product.
Who manufacturing ERP software is for
It suits plants where the same information is currently kept in several places and the copies disagree. If planners, buyers and accountants each keep their own spreadsheet of what is in stock, an ERP removes the argument.
It tends to pay off once you have multiple work centres, purchased components with lead times, or customers who ask for lot traceability. Regulated sectors such as food, medical and automotive supply feel this earliest.
The US National Institute of Standards and Technology runs the Manufacturing Extension Partnership, a federal programme that helps small manufacturers with technology adoption. It is a reasonable neutral place to look for local advice before talking to vendors.
Who should not buy one yet
A shop with one product line, a handful of machines and a stable customer base can often run on a good inventory tool and an accounting package. A full ERP adds data entry that someone has to do every day.
Be cautious if your processes change every quarter. An ERP rewards stable definitions: part numbers, routings, units. If those are still being invented, you will spend the project encoding guesses.
Also hold off if nobody on your side can own the project. ERP rollouts need someone with authority over both production and finance. Without that person, every disagreement between the two departments lands on the implementation team.
What manufacturing ERP software costs
Cost has three parts: licences or subscription, implementation and integration, and the internal time your own people spend. The third is the one that gets left out of the budget.
Packaged vendors publish different shapes: per-user subscriptions, tiers by module, or perpetual licences with annual support. Published vendor price lists are the right place to check current figures, and they change often.
For our own work, we do not quote a number in an article. We scope a fixed project after a discovery call, because a custom edge around a packaged ERP can be a small connector or a rewrite of quoting, and the range between those is too wide to guess.
When comparing quotes, ask each vendor what is out of scope. Data migration, integrations and user training are where scope quietly stays out of a quote.
Buy, configure or build
Buy a packaged system when your processes are close to standard. Build when a specific rule is your edge. Most plants do both: configure a packaged core and custom-build a few edges.
| Option | Good when | Failure mode |
|---|---|---|
| Packaged SaaS ERP | Processes are close to standard, small IT team | Workarounds pile up where your process differs |
| Open-source ERP (such as Apache OFBiz) | You have engineers and need control of the code | Customisations go undocumented when the builders leave |
| Packaged core plus custom edges | A few rules are a competitive edge | Integrations become the new place nobody understands |
| Fully custom build | Your process has no packaged equivalent | You own every bug, report and compliance change |
The Apache OFBiz project is a good example of the open-source row: a complete framework that rewards teams who document what they change. We cover enterprise-scale builds on our enterprise software page.
How to evaluate manufacturing ERP software
Evaluate with your own data and your own hardest cases. A demo shows the vendor's best scenario. Your sandbox test shows yours.
Pick five scenarios that have hurt you before. A multi-level bill of materials with a substitute part. A rework order that should not double-count cost. A quote that needs price, stock and lead time from three places. A partial shipment. A lot recall.
Then ask each vendor to run those on a copy of your data. Score each one on three things: did it work, how much configuration it took, and what a user has to do by hand afterwards.
Bring your production lead and your finance lead to the sessions. They will spot problems an IT evaluator misses, such as a cost roll-up that does not match how you value work in progress.
Whether one system or several is better
This is contested. One camp says a single ERP gives a single truth and fewer integrations to maintain. The other says best-of-breed tools for scheduling, quality and warehouse handling fit the shop floor better than the ERP's own modules.
Both are right in different plants. A single system wins when the process is standard and the team is small. Best-of-breed wins when one function, such as finite scheduling, is where you make or lose money.
The trade-off is plain. Several systems means integrations, and integrations fail quietly: a sync that stops on Friday is found on Monday when a planner notices stock is wrong. The industry reference for describing how plant and business systems should talk is the ISA-95 standard from ISA.
Where ERP projects go wrong
They go wrong on data and on ownership. Dirty item masters, undefined routings, and no single owner will sink a good product faster than any missing feature.
The most expensive ERP mistake is replacing a system because nobody can explain it, when explaining it would have cost far less.
Other common failures:
- Migrating years of messy data unchanged, then blaming the new system for the mess.
- Customising the new ERP to copy the old screens, which rebuilds the old problem.
- Skipping user training, so operators keep a spreadsheet on the side.
That last one is the warning sign to watch for. When people maintain a shadow spreadsheet, the ERP has already lost the trust of the people it was meant to serve. The next section is about a case where that happened.
A real example: an ERP nobody could explain
Our Apache OFBiz modernisation case study covers a wholesale distributor, so not a plant, but the ERP failure pattern is the same one manufacturers meet.
The company ran a nine-year-old Apache OFBiz 17.12 instance with 340 custom extensions. The two engineers who wrote them had left, and nothing was documented. Every new report became a developer ticket with a two-to-three week queue, so the business built a shadow ERP: 41 Excel exports kept by 11 people. Quote turnaround was 2.5 days because pricing lived half in OFBiz and half in a spreadsheet.
They were scoping a move to a tier-one ERP, mainly because nobody could say what the current one did.
What we changed, and what we left alone
We ran a five-day diagnostic first. It found the customisations were sound engineering that had simply become untouchable, and the PostgreSQL schema underneath was clean. The problem was access, not data.
So we did not migrate. Over eight weeks we documented all 340 extensions and put a read-only API over the existing schema, with 29 live endpoints. Quote assembly now pulls price, stock and lead time in one call. Quote turnaround fell from 2.5 days to 3 hours, and report tickets fell from roughly 14 a month to 2.
We left 12 of the 41 spreadsheets alone, because they were genuine ad-hoc analysis where Excel is the right tool. We also left the OFBiz version unchanged and kept the whole build read-only, so nothing could write to the general ledger.
When modernising beats replacing
If the data is sound and the pain is access and documentation, put an interface over the system you have. If the platform is unsupported or cannot model how you now make things, replace it.
Ask three questions before you sign a replacement contract:
- Can anyone explain what the current system does, customisation by customisation?
- Is the underlying data clean enough to query directly?
- Is the platform still maintained?
If the first answer is no and the other two are yes, you have a documentation problem, and a migration will carry it into the new system. Our system modernisation work starts with exactly this diagnostic. Years of manufacturing software development services have taught us that a replacement project run before the diagnosis tends to reproduce the old mess in newer software.
Choosing a partner for manufacturing software
A good partner will ask about your routings and your worst reports before they mention a platform. They should also say plainly when your problem does not need new software.
Viithiisys has shipped software since 2007, with more than 500 projects delivered across six countries. Our engineering team works from Mohali, with a Canadian office in Markham, Ontario. For leadership on a platform decision without hiring a full-time executive, our fractional CTO service provides senior engineering oversight on a fractional basis.
When you compare a manufacturing software development company with a packaged vendor, ask who owns the documentation at the end. If the answer is that only the vendor's staff can explain the system, you are about to recreate the situation in the case study above.
Where to start
Before any vendor call, write down which three or four reports your planners wait longest for, and where the data for each one actually lives. That list tells you more about your ERP than a feature matrix.
If you cannot say where a number comes from, that is the first thing to fix, whatever you decide about replacing the system. We can walk through the workflow with you and tell you whether you need new software, a documented version of what you have, or neither. Book a workflow audit and bring the two or three reports that cost you the most waiting.
FAQ
- What is manufacturing ERP software?
- Manufacturing ERP software is a system of record that links bills of materials, production orders, inventory, purchasing, costing and finance. A change on the shop floor, such as a scrapped batch, updates stock and cost in the same place, so planners and accountants work from one set of numbers.
- How do I choose an ERP for the manufacturing industry?
- Write down your five hardest real scenarios, such as a multi-level bill of materials with a substitute part or a rework order. Ask each shortlisted vendor to run them on your data in a sandbox. Score the results on how much customisation each one needed, not on the demo.
- Should I build custom ERP software or buy one?
- Buy when your processes are close to standard and you can accept the vendor's way of working. Build or extend when a specific routing, pricing or compliance rule is your competitive edge. Most plants end up configuring a packaged system and custom-building a few edges around it.
- Do I have to replace my old manufacturing ERP?
- Not always. If the data underneath is sound and the pain is access, reporting or missing documentation, you can often document the customisations and put an interface over the existing system. Replace when the platform itself is unsupported or cannot model how you now make things.