Most ERP comparison guides evaluate manufacturing software the way they'd evaluate a CRM or an accounting package — modules, pricing tiers, a checklist of generic features. That approach misses almost everything that actually determines whether a manufacturer succeeds with ERP or quietly reverts to spreadsheets six months after go-live. The real differences live in specifics: how deep the bill of materials can go, whether a work order can carry a quality hold, whether the cost you see on a job is what it actually cost to make.
This guide walks through the evaluation criteria that matter for a manufacturing business specifically, in the order they tend to surface once you get past a sales demo and start testing a system against your own products, your own routings and your own shop floor. None of this is abstract — every section below is something you can and should ask a vendor to show you live, with a real product structure, before you sign anything.
Bill of Materials Depth: Single-Level, Multi-Level and EBOM vs MBOM
The bill of materials is the backbone of any manufacturing ERP, and it's also where the gap between vendors is widest. A single-level BOM lists the raw materials and bought-out parts that go directly into a finished item. That's sufficient if you assemble from stock components and nothing you build is itself used inside something else. Most real manufacturers don't fit that description for long — a fabricated bracket becomes part of a sub-assembly, which becomes part of a larger unit, and the BOM needs to represent that nesting accurately, not flatten it into a single shopping list.
Multi-level BOM support means the system understands that a parent item consumes sub-assemblies, and those sub-assemblies have their own BOMs that consume further components, and costs and stock consumption roll up correctly through every level without someone recalculating by hand. Ask a vendor to build a real four- or five-level structure from one of your own products during the demo. If the tool struggles, or if costing at the top level doesn't reflect a change you just made three levels down, that's a serious limitation you'll live with for years.
The second distinction that matters — and that generic ERP evaluations almost never mention — is engineering BOM versus manufacturing BOM. An EBOM reflects how a product was designed: components grouped by function, matching the engineering drawing. An MBOM reflects how it's actually built: sequenced by routing step, including sub-assemblies, consumables and shop-floor materials the drawing never lists, like welding gas or fasteners bought in bulk rather than tracked per unit. If your ERP only supports one flat list, engineering and production end up maintaining two separate versions of "the BOM" in different tools, and the two quietly drift apart. QTT-ERP's Manufacturing module keeps both views connected to the same underlying item master, so a change made on one side is visible on the other instead of requiring a manual reconciliation.
Work Order and Job Card Management
A work order is the instruction to build something; a job card is the record of what actually happened at each operation along the way. The distinction sounds academic until you're standing on a shop floor trying to answer a simple question — which operation is this job stuck at, and why — and the system can't tell you because it only tracks work orders as a single open/closed status.
Evaluate whether the system can break a work order into its individual operations — cutting, machining, assembly, painting, inspection — each with its own status, assigned operator or work center, and start/finish timestamps. That level of detail is what lets a production supervisor see, at a glance, that job 4021 has been sitting at the paint booth for six hours longer than it should have, instead of only knowing the order as a whole is "in progress" somewhere in the plant.
It's also worth checking how the system handles partial completions and split lots — a work order for 500 units rarely finishes all 500 at the same operation at the same time in practice. Some units move ahead for urgent dispatch while the rest continue through remaining operations. ERP that only supports all-or-nothing work order closure forces production staff to either wait unnecessarily or fudge the records to keep moving, and neither outcome is one you want baked into your system of record.
Quality Holds and Inspection Integration
Quality control that lives in a separate logbook or standalone tool is a liability, not a convenience. The value of quality data is almost entirely in what it stops from happening next — a failed incoming inspection should block that raw material lot from being consumed into a work order, and a failed in-process inspection should block that work order from advancing to the next operation, automatically, without relying on someone remembering to check a separate register before moving stock.
When evaluating this, look specifically for the concept of a quality hold as a first-class state on both inventory and work orders — not just an inspection record attached after the fact. A hold should be visible to whoever is picking stock or scheduling the next operation, and clearing it should require a role with the authority to do so, logged with who cleared it and when. That's the difference between quality control that actually prevents a bad batch from shipping and quality control that only documents a bad batch after a customer complains.
Also check how the system handles inspection sampling plans and non-conformance workflows — can you define AQL-based sampling for incoming material, route a non-conformance to a disposition decision (rework, scrap, use-as-is with concession), and tie the cost of rework or scrap back to the job it occurred on? Manufacturers that can't answer "how much did rework cost us last quarter, and on which products" usually can't answer it because that data never made it out of a paper inspection sheet.
See BOMs, work orders and quality holds working together
Book a free QTT-ERP demo and we'll build a multi-level BOM from one of your own products, live.
Book a Free DemoShop-Floor Data Capture
Every other section in this guide depends on one unglamorous prerequisite: data actually getting entered at the point it happens, by the person doing the work, without friction. An ERP with a brilliant work order and costing model is worthless on the shop floor if recording a completed operation requires walking to an office terminal and filling in a multi-field form from memory twenty minutes later.
Evaluate shop-floor capture the way an operator would use it, not the way an office user would. Can a job card be updated from a shared terminal or tablet at the work center with a barcode or QR scan rather than manual lookup? Does starting and stopping an operation take two taps, not two minutes? Does the interface work reasonably on a low-cost Android device in a noisy, gloved-hands environment, or does it assume the same screen real estate and precision as a desktop dashboard?
The honest test is to put the system in front of an actual machine operator during the evaluation, not just procurement or plant management, and watch how long it takes them to complete a routine transaction unaided. If it takes real training and a laminated cheat sheet taped to the machine, adoption on the floor will lag no matter how good the reporting looks from the manager's office — and reporting is only as good as the data operators actually bother to enter.
Costing Accuracy: Standard vs Actual
Most manufacturing ERP can produce a cost figure for a finished item. Far fewer can tell you, accurately, whether a specific job made or lost money — and that gap is where a lot of manufacturers quietly bleed margin without realizing it until year-end.
Standard costing prices a product against a predetermined material rate and labor allowance, set periodically and used for quoting and budgeting. It's useful and necessary, but it's a planning number, not a fact about what a particular job cost. Actual costing tracks what a specific work order really consumed: the true price of the material lot that was issued (which may differ from standard if it came from a different supplier batch), the labor hours genuinely logged against each operation, and any scrap or rework generated along the way.
The evaluation question worth asking directly: can the system show a variance between standard and actual cost on a completed work order, broken down by material versus labor versus overhead, without a manual export-and-reconcile step in a spreadsheet? If the answer is no, you'll find out a job lost money in a month-end variance report weeks after it happened — far too late to do anything about the cause. QTT-ERP ties work order costing directly to inventory valuation and the general ledger, so actual cost variance is visible job by job, not just as a lump aggregate at period close.
Scheduling and Capacity Planning
Scheduling and capacity planning solve related but different problems, and it's worth being clear about which one you actually need before evaluating a system on either. Basic scheduling sequences confirmed work orders on a calendar or work-center queue — useful, and usually sufficient, when order volume comfortably fits within available machine and labor hours.
Capacity planning goes a step further: it checks a new order against real, finite machine and shift availability before you promise a delivery date, and flags a conflict — say, two large jobs both needing the same CNC machine in the same week — before it becomes a missed delivery rather than after. This matters most for manufacturers running close to full utilization, where the difference between "we can commit to this date" and "we hope we can" has real financial consequences with customers.
When comparing systems, ask specifically how work-center capacity is modeled — is it a single shared number for the whole plant, or per machine and per shift, accounting for planned maintenance windows and existing committed load? A scheduling view that looks impressive in a demo but doesn't account for a machine being down for service that afternoon will give you a confident-looking plan that's wrong the moment you rely on it.
Maintenance Integration
Maintenance is easy to treat as a separate concern from production planning, and that's precisely the mistake that causes scheduling promises to fall apart in practice. A machine that's down — whether for planned preventive maintenance or an unplanned breakdown — is capacity that doesn't exist, and if the scheduling module doesn't know that, it will happily book work against it anyway.
A standalone CMMS can track maintenance history, spare parts and technician assignments perfectly well in isolation. What it can't do is automatically prevent the production scheduler from committing a machine to a job during its scheduled service window, or feed unplanned downtime straight into a revised delivery estimate without someone manually cross-checking two separate systems. Maintenance built into the same platform as manufacturing and inventory means machine availability — not just machine history — is live data the scheduler actually uses.
Concretely, look for preventive maintenance schedules tied to actual machine usage (running hours or units produced, not just a calendar date), breakdown logging that captures downtime duration and root cause, and a direct link between an asset's maintenance status and its availability in the production schedule. QTT-ERP's Maintenance module shares the same asset and work-center data as Manufacturing for exactly this reason — so a machine on hold for service shows up as unavailable capacity everywhere it matters, not just in a maintenance log nobody else looks at.
Reporting That Actually Reflects the Shop Floor
A manufacturing ERP's reporting is only as good as the data captured everywhere else in this guide — but even with good data flowing in, generic financial or inventory dashboards often miss the questions a plant manager actually asks day to day. Evaluate reporting against real operational questions, not a generic list of chart types.
- Which work orders are behind schedule right now, and at which specific operation are they stuck?
- What's our actual scrap and rework rate this month, broken down by product and by work center?
- Which jobs came in over standard cost, and was the variance material, labor or both?
- What's real machine utilization versus planned capacity over the last quarter, accounting for maintenance downtime?
- How many units are currently on quality hold, and how long has each been held?
If a vendor can't pull up a live version of most of these during a demo using data close to your own operation, their reporting is likely built around finance and inventory use cases with manufacturing as an afterthought — which tends to show up later as custom report requests that take weeks to build after go-live, once the gap becomes obvious in daily use.
A Practical Evaluation Checklist
Bringing the sections above together, here's what's worth insisting on seeing live, with your own product data, before committing to a manufacturing ERP:
-
Multi-level BOM, built live
A real four- or five-level structure from one of your products, with costs and stock consumption rolling up correctly through every level.
-
Operation-level work orders
Job cards broken into individual operations with their own status, not a single open/closed flag on the whole order.
-
Quality holds as a first-class state
A failed inspection blocking stock or a work order automatically, with role-gated release, not just a logged record.
-
Operator-usable shop-floor capture
Tested by an actual machine operator during the demo, not just plant management, on the device they'd really use.
-
Actual costing per work order
Standard-versus-actual variance visible job by job, broken into material, labor and overhead, without a manual spreadsheet step.
-
Maintenance tied to the schedule
A machine on planned or breakdown maintenance shows as unavailable capacity in production scheduling automatically.
Where to Go From Here
None of the criteria in this guide can be verified from a feature comparison page — they only become clear once you put a system in front of your own BOM, your own routing and your own shop floor and watch what happens. QTT-ERP's Manufacturing module sits connected to Inventory, Procurement, Quality, Maintenance and Finance in one platform, and like the rest of QTT-ERP it's adopted in phases — a manufacturer can start on the Starter plan running core production and inventory, then grow into Quality, Maintenance and deeper costing as the business needs it, rather than committing to every module on day one.
If you're evaluating ERP for a manufacturing operation, bring an actual product structure to the next demo you take — a real BOM, a real routing, a real failed-inspection scenario — and judge every vendor against how it handles that, not against their slide deck.
Bring your own BOM to the demo
Book a free QTT-ERP demo and we'll walk through your actual product structure, routing and quality process live.
Book a Free DemoFrequently Asked Questions
An engineering BOM (EBOM) lists the components of a product the way it was designed — organized by function or assembly. A manufacturing BOM (MBOM) restructures that same list into the sequence and groupings the shop floor actually builds in, including routing steps, work-in-progress sub-assemblies and consumables the design drawing never mentions. If your ERP only supports one flat list, someone is reconciling the two by hand.
Enough to match your actual product structure, not an arbitrary number. A fabricator assembling from raw sheet and bought-out parts may only need two levels; a discrete manufacturer building sub-assemblies from sub-assemblies can easily need four or five. The real test isn't a maximum depth in a spec sheet — it's whether costs and stock consumption roll up correctly through every level without manual adjustment.
Standard costing prices a product against a predetermined material and labor rate set in advance, useful for quoting and budgeting. Actual costing captures what a specific work order really consumed — the material lot's true price, the labor hours actually logged, the scrap actually generated. Manufacturers that only see standard costs typically don't know a job lost money until the month-end variance report, weeks too late to act on it.
Basic scheduling (sequencing work orders on a calendar) is enough until you regularly have more confirmed orders than machine or labor hours to run them in the promised window. At that point capacity planning — checking a new order against real machine and shift availability before promising a date — stops being a nice-to-have and starts being the difference between reliable delivery dates and constant firefighting.
In a connected system, a failed inspection places a quality hold directly on the affected stock or work order, blocking it from shipping or moving to the next operation until someone with the right role clears it. Without that connection, a hold lives in a separate quality log while inventory shows the item as available — which is exactly how failed batches end up shipped to customers.
A standalone CMMS can track maintenance well in isolation, but it can't automatically stop the production scheduler from booking a machine that's down for planned service, or account for unplanned downtime in a delivery promise. Maintenance built into the same ERP as manufacturing and inventory means machine availability, not just machine history, feeds directly into what production commits to.
Written by the QTT-ERP Team
Queen Touch Technology builds QTT-ERP, a connected ERP platform for Indian manufacturers, distributors and service businesses. This guide draws on patterns we see across manufacturing implementations.