Most MRP buying processes start with the wrong question. “Which system is best for a company like ours” produces a shortlist assembled from review sites, and review sites rank on review volume, which correlates with marketing spend and almost nothing else.
The question that actually narrows the field is different: which capability thresholds has this business already crossed?
A threshold is a point where something in the operation changed and made a class of software insufficient. Before you cross it, the extra capability is dead weight you pay for. After you cross it, no amount of discipline compensates for not having it. There are five that matter for manufacturers under about 100 employees, and where you sit against them determines your tier far more reliably than any ranked list.
Work through them in order. Each one has a trigger you will recognise from your own shop floor, a capability that becomes non-negotiable once the trigger fires, and a rough price tier that capability lives in.
Threshold 1: BOM depth
The trigger: you make something out of something you also make.
A single-level bill of materials — finished good, then a flat list of purchased parts — is handled adequately by a spreadsheet and by almost any inventory tool. The moment a sub-assembly exists as a stockable, countable, costable thing in its own right, that model breaks. You now need the system to know that the frame weldment consumes four legs and two rails, that the finished bench consumes one frame weldment, and that the cost of the bench includes the labour spent building the weldment.
What becomes non-negotiable: multi-level BOMs with automatic cost roll-up. Specifically, the ability to change the cost of a purchased part at level three and have the standard cost of the finished good update without anyone rebuilding a spreadsheet.
Two capabilities usually arrive alongside it and are worth checking for at the same time. Phantom assemblies let you group components logically — a hardware kit, a fastener set — without creating a stock item and a work order for something that never sits on a shelf. Where-used queries let you answer, in one click, which finished goods contain a part that a supplier has just discontinued.
Where the tier boundary falls: most entry-level inventory tools stop at one level, or support two with awkward workarounds. Genuine multi-level BOM handling with roll-up is the first real dividing line between inventory software and MRP software. It is available at the bottom of the MRP tier, so crossing this threshold alone does not push you upmarket — but it does push you out of the inventory-tool category entirely.
Deeper: Multi-Level BOM Explained: Levels, Phantom Assemblies and Where Costing Goes Wrong
Threshold 2: Lot and serial traceability
The trigger: a customer, an auditor, or a regulator asks a question you cannot answer from records.
The question takes one of two forms. Forward: “this batch of material was defective — which of my customers received product made from it?” Backward: “this unit failed in the field — which supplier’s material went into it, and when?”
If either question would currently require a person to spend a day reconstructing an answer from delivery notes and memory, you have crossed this threshold. In practice most manufacturers cross it before they notice, because the requirement arrives as a customer contract clause rather than as a law.
What becomes non-negotiable: lot, batch or serial identity captured at goods receipt, carried through every consumption and production transaction, and queryable in both directions. The specific granularity depends on your product — serial numbers for individually identifiable units, lot or batch for anything produced in runs.
The test to apply to any demo is blunt: ask the vendor to run a genealogy report from a raw material lot forward to shipped customer orders, live, in their demo data. Vendors that store lot numbers as a text field on a document — which is common — will not be able to do it.
Where the tier boundary falls: basic lot capture is widely available. Bidirectional genealogy reporting that survives multi-level production is not, and it is the single most common reason a manufacturer outgrows an entry-level tool. If you are in food, beverage, pharma, medical devices, aerospace or automotive supply, treat this threshold as crossed on day one.
Threshold 3: More than one stocking location
The trigger: the same part number exists in two physical places and both quantities matter.
This is not only about a second building. A consignment stock arrangement at a customer site, a third-party fulfilment warehouse, a van stock for a service crew, and a quarantine area for incoming inspection are all separate stocking locations the moment you need to know what is in each of them independently.
What becomes non-negotiable: stock tracked by location rather than in aggregate, transfer orders as real documents with in-transit visibility, and allocation logic that can decide which location fulfils a given order.
The subtle requirement is availability. A system that shows total on-hand across all locations will happily let you promise a delivery date against stock sitting 400 kilometres from the customer. Availability has to be location-aware or the number is decorative.
Where the tier boundary falls: basic multi-location is common at the entry tier. Bin-level location within a warehouse, directed put-away, and transfer orders with in-transit accounting sit a tier above and are usually badged as warehouse management rather than MRP. Do not buy the upper tier for a second building — buy it when picking accuracy, not location visibility, is the constraint.
Threshold 4: Routing and capacity
The trigger: your delivery promises depend on whether a specific machine or a specific person is free.
Up to a point, lead time is a function of material availability. You can promise four weeks because that is how long the steel takes. Past a certain volume, the constraint moves: the material is there, but the CNC is booked solid for three weeks and everything queues behind it.
Once that shift happens, a BOM is no longer enough. You need the operations as well — which work centre, in what sequence, with what setup and run time — and you need the system to know what is already committed to those work centres.
What becomes non-negotiable: routings attached to BOMs, work centres with defined capacity, and at minimum a load view showing committed hours against available hours per work centre per week. Finite scheduling, where the system will not overload a work centre and instead pushes the date out, is a further step and genuinely harder to implement well.
Be honest with yourself about the second half of this. Routing data only works if the shop floor reports against it. A routing nobody confirms produces a schedule nobody trusts within about two months. If you cannot commit to shop floor data collection — barcode scanning, tablet confirmations, something — do not buy scheduling capability, because you will pay for it and then run the shop off a whiteboard anyway.
Where the tier boundary falls: basic routings and a work centre load report exist in the MRP tier. Finite capacity scheduling, sequence-dependent setup optimisation and drag-and-drop Gantt rescheduling sit meaningfully higher and carry both a licence premium and an implementation premium.
Threshold 5: Integration surface
The trigger: somebody is retyping data from one system into another on a recurring basis.
Count the systems that hold data your MRP would need or produce: an accounting package, an ecommerce storefront or three, a POS, a shipping platform, a customer portal, a CAD or PLM tool. Then count the manual re-entry points between them.
What becomes non-negotiable: a documented REST API with webhooks, plus native connectors for whatever you actually run. Native connectors matter more than they should, because a native QuickBooks or Shopify connector is maintained by the vendor and a custom integration is maintained by you, forever.
Three things to test before committing, because they are the ones that fail in production rather than in demos:
• Rate limits. A connector that syncs 200 orders a day may or may not survive your peak week.
• Webhooks versus polling. Polling on a 15-minute cycle is not real-time stock, whatever the marketing says.
• Sandbox availability. If you cannot build and break an integration somewhere other than your live company, every change is a production change.
Alongside the API, ask about in-app customisation — the ability to add a field, a validation rule or an automated email without a developer. That capability is the difference between a system that fits your process and a process that bends to fit the system.
Where the tier boundary falls: this threshold does not track price cleanly, which is why it is worth checking separately. Some entry-tier products have excellent APIs; some expensive ones charge per connector and meter API calls. Judge it on its own.
Deeper: MRP System APIs: What to Test Before You Commit to an Integration · Integrations
Putting it together
| # | Threshold | The trigger | What becomes non-negotiable | Tier |
| 1 | BOM depth | You make something out of something you also make | Multi-level BOM, automatic cost roll-up, phantoms, where-used | Entry MRP |
| 2 | Traceability | Someone asks a forward or backward genealogy question | Lot/serial identity through every transaction, bidirectional reporting | Entry to mid MRP |
| 3 | Locations | The same part exists in two places and both counts matter | Location-level stock, transfer orders, location-aware availability | Entry MRP (bin level: WMS tier) |
| 4 | Routing and capacity | Delivery dates depend on machine or labour availability | Routings, work centres, committed-vs-available load view | Mid MRP (finite scheduling: higher) |
| 5 | Integration surface | Someone retypes data between systems every week | Documented API, webhooks, native connectors, sandbox | Varies independently of price |
You are priced by your highest crossed threshold, not your average. A ten-person shop that has crossed threshold 2 because of an aerospace customer needs traceability that a fifty-person shop with simple commodity products does not. Headcount is a poor proxy; the thresholds are a better one.
Thresholds you have not crossed are a cost, not a safety margin. Capability you are not using still has to be configured, still appears in every screen, and still needs to be explained to every new user. “We might need it later” is how implementations acquire six months of scope for features nobody ever turns on.
What to do with this
Score yourself honestly against the five, then take the highest one you have genuinely crossed and use it as the entry requirement for every vendor conversation. Anything below it is disqualified regardless of price. Anything two tiers above it is a project you will not finish.
Then reverse the demo. Do not let a vendor walk you through their standard sequence. Give them three of your own scenarios — one BOM with a real sub-assembly, one traceability query, one order that has to be scheduled against a constrained machine — and ask them to run those. What a system cannot do in a demo it will not do in production.
Start a 15-day free trial and run those three scenarios yourself, or book a live demo and hand them over.
Two to three. BOM depth and multiple locations are the most commonly crossed. Routing and capacity is the one most often bought and least often used, because it depends on shop floor reporting discipline that has not been established yet.
It means the workaround you are currently using has a cost, and that cost is now measurable. Quantify it — hours per week, error rate, the last order that shipped late — before deciding. A threshold crossed six months ago with no visible pain is not urgent.
Sometimes, for thresholds 3 and 5. Rarely for 1 and 4, because BOM structure and routing sit at the core of the data model rather than at the edges. A bolt-on that has to reconstruct your BOM to work is not a bolt-on.
ERP adds finance, HR and broader business functions around the manufacturing core. It is a different axis from these five thresholds, not a sixth threshold. A manufacturer can need deep MRP capability and very little ERP, or the reverse.
Not reliably. Price tracks user count, implementation model and sales cost as much as it tracks capability. Check the five thresholds directly rather than inferring capability from the price. The gap between what a system costs and what it can do is exactly what this exercise is designed to expose.
Recent Comments