Q.Does a Small Manufacturer Actually Need an ERP?
Usually not in the way the word implies. "We need an ERP" almost always means four or five specific things are broken — you cannot see what is in stock, production status lives in someone's head, purchasing is reactive, and nobody can tell what a job actually cost. Those are four problems, and buying one large system to solve all of them at once is the most expensive and slowest of the available routes.
The word ERP describes a category built for companies far larger than most of the manufacturers who end up shopping for one. At $5M–$50M in revenue, with twenty to a hundred and fifty people, you are being sold a solution to a coordination problem you do not have yet, and paying for it with an implementation that will consume your operations manager for a year.
That is not an argument for doing nothing. It is an argument for naming the actual problems first.
Name the Problems Before You Name the System
Write down what is actually wrong, in the language of your own floor. It usually reads something like this:
- We do not know what we have. Stock on the system does not match stock on the rack.
- We cannot tell a customer when their order will ship without asking three people.
- We buy raw materials reactively, so we are either short or sitting on too much.
- We do not know what a job cost until the month closes, if then.
- Quality records and lot traceability live in binders and a shared drive.
- Every report anyone actually uses is a spreadsheet someone maintains by hand.
Now rank them by what they cost you this year — in expedite fees, in overtime, in write-offs, in orders you could not promise. That ranking, not a vendor's module list, is your project plan. In almost every operation, one or two of these dominate and the rest are irritations.
The Four Routes
Route 1: Fix the data and the process, buy nothing
Worth taking seriously before anything else, because a surprising share of "we need an ERP" turns out to be "our item file is wrong and nobody owns the cycle count."
If stock on the system does not match stock on the rack, no new system fixes that — it inherits it. If your bills of material are out of date, an MRP run will produce confident nonsense. The test: could an accurate count, a cleaned item file and one person owning receiving fix the top problem on your list? If yes, do that first. It is cheaper, faster, and it is a prerequisite for every other route anyway.
Route 2: Buy a small-business ERP or MRP product
The right answer for a large share of manufacturers, and the one to beat.
There is a real category of products aimed at small manufacturers — inventory, bills of material, work orders, purchasing, basic costing — priced per user per month and live in weeks rather than quarters. If your process is reasonably conventional, these are genuinely good and nothing custom will beat them on price or time.
The test: sit two of your people down with a trial and run last week's actual orders through it. Not a demo — your orders, your items, your units. You will know within a day whether the assumptions fit.
Route 3: Buy a large ERP
Sometimes correct, usually premature at this size.
A full ERP earns its cost when you have multiple entities or plants, genuine regulatory complexity, or a customer base that contractually requires capabilities you cannot otherwise provide. It is the right call less often than it is sold, and the cost that sinks these projects is rarely the license — it is the implementation, the consultant, and the year of your operations manager's attention.
The test: name the specific capability that only a full ERP provides and that you need within twelve months. If you cannot, you are buying for a company you might become.
Route 4: Build the specific pieces, keep the accounting you have
The route people forget exists, and often the pragmatic one.
Most small manufacturers already have working accounting. What they do not have is the operational layer above it: production status by job, real inventory with lots and expiry, a purchasing view that looks ahead, an approvals trail. Building exactly that — and writing to the accounting system you already run rather than replacing it — is usually a weeks-long project instead of a year-long one.
The test: is what makes your operation different concentrated in one or two processes? Catch weight. A regulated approval gate. A conversion nobody else does. Routings that change per customer. If your difference is concentrated, build there and buy or keep everything else.
Want this looked at for your operation?
Twenty minutes on a call, and you'll know whether this is worth building, buying, or leaving alone. No deck, no pitch.
Book twenty minutesWhat the Research Says About How These Projects Go
Panorama Consulting Group publishes an annual ERP report. The 2026 edition, published in March 2026, surveyed 170 organizations with a median annual revenue of $200.5 million — larger than most of the companies reading this, which matters, because these are the outcomes of firms with more resources than you.
- On budget: 50.6% were on budget and 19.4% under, while 22.9% went slightly over and 7.1% significantly over. Panorama's own summary: "More than a quarter of organizations reported that their project was over budget."
- On schedule: 58.8% on time, 18.8% early, 18.2% slightly late and 4.1% significantly late.
- Why it goes over, verbatim: "Of those who were over budget, the most common reason was the unexpected need for additional technology." And, from the same report: "Organizations discover fatal misfits late in the project, so they turn to additional technology, scope expansion, and custom builds."
- Hardest benefit to actually realize: new operating models, at 40.7% — the lowest of every benefit measured. Productivity and efficiency gains, by contrast, landed for 87.3%.
That last pair is the useful finding. ERP projects reliably make existing work more efficient. They reliably fail to deliver the new way of working that was in the business case.
One more thing worth knowing: Panorama publishes no ERP "failure rate." If you see one attributed to them, it was invented. The same caution applies to the widely quoted McKinsey figure that large IT projects "run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted" — that is real, but it comes from a 2012 study with Oxford's BT Centre for Major Programme Management, covering projects with price tags above $15 million. It is fourteen years old and about a different class of project than yours.
What the Four Routes Actually Cost
Nobody can quote you a number without seeing your operation, but the published anchors are worth having in your head.
- Small-business ERP and inventory products publish real prices. Cin7 lists Standard at $349/month, Pro at $599 and Advanced at $1,199. Unleashed lists Core at $399/month and Pro at $729. Those are list prices from the vendors' own pages, checked September 2026, with user and order-volume limits attached.
- The two large ERPs you are most likely to evaluate publish nothing. Acumatica's pricing page says only that "Acumatica pricing is tailored using three factors"; NetSuite's old pricing page no longer resolves.
- Development firms that publish ranges put custom ERP high. ScienceSoft: "Average costs for building a standalone ERP module… vary from $200,000 to $500,000," and "Companies looking to develop an all-in-one ERP system should expect to invest $1,500,000+." Itransition (May 2026): platform-based implementation for a midsized company "may range from $50,000 to $1,000,000," and a full-scale custom ERP "may cost from $1mln."
- Timelines on those same pages are long. ScienceSoft: "Implementing an ERP system for a midsize company may require 1–3 years." Panorama's 2024 report gave a median project cost of $450,000 and a median timeline of 15.5 months.
Read the fourth route against those numbers. Building the operational layer above accounting you already run is a different order of project from any of them — which is the point of separating it out rather than calling the whole thing "an ERP."
| Route | Best when | Real cost | Time to useful |
|---|---|---|---|
| Fix data and process | Stock and the item file are wrong | Mostly internal time | Weeks |
| Small-business ERP/MRP | Your process is conventional | Per-user subscription | Weeks |
| Large ERP | Multiple entities, real regulatory need | License plus a much larger implementation | Quarters to a year |
| Build the operational layer | Your difference is in one or two processes | Fixed project fee plus support | Weeks |
Why "One System for Everything" Keeps Failing at This Size
Three reasons, all of them structural rather than bad luck.
The implementation is the product. The software works; configuring it to your operation is the project, and that project is staffed by the same people who are also running the operation. When a quarter gets busy, the project stops. Long enough projects get cancelled during a busy quarter, and most quarters are busy.
Everything is coupled. In one big system, you cannot fix inventory without touching purchasing, and you cannot go live on production without going live on costing. Go-live becomes a single enormous event with no way back, which is why it keeps slipping — nobody wants to be the one who says go.
The mismatch surfaces late. The way your operation actually works — the conversion, the exception, the thing your best customer requires — is discovered during configuration, months in, when the options are an expensive customization or changing how you work.
The alternative is boring and it works: solve the top problem on the ranked list, in production, in weeks. Then the next. Each one is small enough to finish, and each one earns the right to do the next.
What "Custom" Should Not Mean
It should not mean rebuilding accounting. It should not mean writing your own general ledger, payroll or tax handling. Those are solved, cheap, and regulated, and building them is how a sensible project becomes a decade-long liability.
Custom should mean the operational layer that is specific to you, reading from and writing to the accounting you already have. And it should come with the same conditions as any other build: a fixed scope and a fixed price agreed in writing before work starts, something live within weeks, and you owning the code and the accounts.
The One-Sentence Test
If you can finish this sentence, you have a project: "Right now, __ takes hours a week and goes wrong about times a month, and it costs us roughly __."
If you cannot, you do not have an ERP requirement — you have a feeling that things should be tidier. That feeling is real and usually justified, but it is not yet a thing to buy. Spend two weeks measuring, then come back. The measurement almost always changes which problem you thought was first.
FAQ
Q: Does a $10M manufacturer need an ERP? A: Usually it needs three or four specific problems fixed — inventory accuracy, production visibility, forward-looking purchasing, job costing — not one system that claims all of them. Rank the problems by what they cost this year and solve the top one in production before deciding on a platform.
Q: Is it cheaper to build a custom ERP or buy one? A: Buying is almost always cheaper if your process is conventional, and the honest test is to run last week's real orders through a trial of a small-business ERP. Building is justified when your difference is concentrated in one or two processes — catch weight, a regulated approval gate, per-customer routings — in which case build only that and keep the accounting you already run.
Q: How often do ERP projects go over budget or over schedule? A: In Panorama Consulting Group's 2026 ERP Report — 170 organizations, median revenue $200.5 million — 22.9% went slightly over budget and 7.1% significantly over, while 18.2% ran slightly late and 4.1% significantly late. The most common reason given for going over budget was "the unexpected need for additional technology." Note that Panorama publishes no ERP failure rate; any figure attributed to them is invented.
Q: Why do small-manufacturer ERP implementations fail so often? A: Because the implementation, not the software, is the project, and it is staffed by the people also running the operation, so it stops whenever a quarter gets busy. Everything in one system is coupled, so go-live is a single enormous event, and the mismatch with how you actually work surfaces months in, when the only options are expensive.
Q: Can we keep QuickBooks and still fix inventory and production? A: Yes, and for many manufacturers that is the pragmatic route. The operational layer — production status by job, real inventory with lots and expiry, forward-looking purchasing, an approvals trail — can sit above the accounting you already run and write to it, which turns a year-long replacement into a weeks-long project.
Read us often? You can add Futurise as a preferred source in your own Google account.