What a garment ERP actually covers
Five stages, and the value is in the joins rather than in any one of them.
- Order and costing. The buyer’s order, the specification, and what it costs to make at that quantity. Everything downstream references this, which is why a change here should propagate rather than be retyped.
- Bill of materials. Fabric, thread, buttons, labels, packaging, per unit and per size. This is where spreadsheets fail first — a size ratio change means recalculating consumption across every material, and doing that by hand is where the arithmetic errors live.
- Cutting and marker planning. How the pattern lays on the fabric width and what that means for consumption. A percentage point of fabric wastage across a large run is real money.
- Production tracking. Where each order is: cut, stitched, finished, packed. This is the question a buyer asks and the one nobody can answer without walking the floor.
- Dispatch and invoicing. What shipped, against which order, invoiced how.
Any of those can be a spreadsheet. What ERP sells is that they are the same data, so a fabric price change updates the costing and a delayed cutting date moves the dispatch estimate.
When you genuinely need it
The trigger is not volume. It is coordination failing, and the signals are specific.
Nobody can answer “where is order 412” without walking the floor. The clearest signal there is. If tracking lives in someone’s head, that person is now a dependency.
Two people maintain two versions of the same sheet. The moment the answer to a question depends on whose file you open, the spreadsheet has stopped being a system.
Fabric is ordered twice, or short. Consumption calculated per order, by hand, with no view of what is already committed against other orders.
Costing is a guess. You quote from memory because working it out properly takes an afternoon — which means you do not know which orders actually made money.
Multiple units or outsourced stitching. The point where coordination genuinely exceeds what a shared file can hold.
Two or more of those, consistently, is the signal. One of them occasionally is a process problem wearing an ERP costume.
When a spreadsheet is the better answer
Which is most of the time, and no vendor will tell you so.
One unit, one line, one person who knows everything. A well-built workbook beats ERP here, because the coordination cost ERP solves does not exist yet. What you are buying instead is a licence fee, a migration and a training burden.
Fewer than a handful of live orders. If the whole production state fits on a whiteboard, it should be on a whiteboard.
Job work rather than your own production. If you are cutting and stitching to someone else’s order and materials, most of the ERP surface is irrelevant.
The failure mode worth naming: units buy ERP, find it too heavy to maintain, keep running the spreadsheets alongside it, and end up with both. That is worse than either — now there are two sources of truth and one of them is expensive.
Before buying, fix the spreadsheet. Consistent SKU codes, one file rather than several, one person owning it. Half of what looks like an ERP problem is a naming problem.
What to check before you buy
| Signal | Buy | Stay on a spreadsheet |
|---|---|---|
| “Where is order 412?” | Nobody can say without walking the floor | One person knows, and is there |
| Versions of the truth | Two people, two sheets | One sheet, one owner |
| Fabric | Ordered twice, or short at cutting | Committed against one order at a time |
| Costing | Quoted from memory | Repeat styles, known cost |
| Units | Multiple, or outsourced stitching | One line, one supervisor |
Five questions, in the order they matter.
Does it handle size ratios natively? Generic manufacturing ERP frequently does not, and garments are size-ratio-shaped from end to end. This is the single most common mismatch between a generic system and an apparel unit.
Can it do marker and consumption planning? Or does it expect a number you calculated elsewhere? If the latter, it is not really a garment ERP.
What happens when an order changes mid-run? They always do. A system that assumes orders are fixed once entered will be worked around within a month.
Can you get your data out? Ask specifically for an export you can open in Excel. Software that holds your production history hostage is a problem discovered at the worst possible moment.
Who maintains it on your side? The real question. ERP is not software you buy; it is a process someone has to keep accurate every day. If nobody in the unit owns that, it will be stale in a quarter and you will be back on spreadsheets with a licence fee attached.
