Why generic ERP breaks on a building materials catalogue

Generic ERP fails in building materials because it assumes one unit of stock is interchangeable with any other unit of the same product. In this trade that is rarely true. Two boxes of tile from different batches are not the same. Two slabs of marble are never the same. A pipe fitting has compatibility rules. The item master cannot express any of that, so people work around it — and the workarounds are where the system quietly stops being trusted.

The implementation is not usually at fault. The data model is.

What does generic ERP assume?

Four things, all reasonable for most industries and wrong here.

• Stock is fungible. Quantity 40 of an item means any 40 will do.
• An item is a thing. Not a family of related things with rules between them.
• Variants are a short list. Size and colour, perhaps a dozen combinations.
• You sell what you stock. Not something manufactured to a customer’s dimensions.

Each assumption breaks somewhere in building materials, and where it breaks determines which workaround appears.

Where exactly does it break?

Segment	What the model cannot express	The usual workaround
Tiles	Batch and shade travelling with stock	Batch typed into a text note nobody queries
Stone	Every slab individually identified	Each slab becomes an item with quantity one
Sanitaryware	Product families and valid combinations	Combinations checked by memory at the counter
Pipes	Compatibility between diameter and class	A printed chart beside the terminal
Doors	Configuration priced per opening	Quotes built in a spreadsheet outside the system
Adhesives	Coverage that depends on application	Coverage worked out on a calculator

Look at the right-hand column. Every workaround moves a decision out of the system and into somebody’s head or a document beside it. That is the actual failure — not that the ERP is wrong, but that the important information no longer lives in it.

Why does the item master become unusable?

Because the standard escape route is to create more items, and it compounds.

A stone business that creates an item per slab adds hundreds of items a month, none of which will ever be reordered. Within a year the master holds tens of thousands of dead records and nobody can find anything. A tile business that creates an item per batch does the same thing more slowly.

The second escape route is free-text fields. Batch, shade, calibre and slab dimensions get typed into a description or a note. That is not data — you cannot filter on it, report on it, or stop someone selling the wrong thing with it. It looks like the information is captured, which is worse than it obviously being absent.

How do you know this is happening to you?

Six symptoms, in rough order of how early they appear.

• Someone keeps a spreadsheet alongside the ERP, and it is the one people actually check.
• Stock says available, the warehouse says not really — usually because the available quantity is the wrong batch or a reserved slab.
• Quotations are built outside the system and typed back in as a total.
• One person is the system. Their knowledge of which combinations work is load-bearing, and they cannot take leave.
• Reports get corrected by hand before anyone senior sees them.
• New staff take months to become useful, because most of the job is undocumented.

If three or more of those are true, the problem is structural. More training will not fix it.

Does this mean replacing the ERP?

Usually not, and we would advise against starting there.

Your ERP is probably doing its core job perfectly well — finance, purchasing, statutory reporting. Those parts of your business are not unusual, and replacing a working accounting backbone is expensive, risky and slow.

The more effective pattern is to put the industry-specific layer where it belongs and connect it. Catalogue, batch, slab identification, configuration and quotation live in a system built for the way your products actually behave. Orders, invoices and stock movements flow into the ERP, which continues to be the financial record.

That is a considerably smaller project than a replacement, and it fails less often — because you are not asking one system to be excellent at two very different things.

The work is mostly integration, which is unglamorous and where most of the risk sits. We have written about that side of it under system integration and modernisation.

Common questions

Can this be solved with ERP customisation?

Sometimes, and it is worth asking your vendor before assuming otherwise. The caution is that heavy customisation of a packaged ERP tends to make upgrades painful, so you trade a data model problem for an upgrade problem. Ask what happens at the next major version before committing.

Is an industry-specific ERP the answer?

If one genuinely fits your segment, it can be. Verify that it models the specific thing that breaks for you — batch, slab, family, configuration — rather than simply using your industry’s vocabulary in its marketing. Ask for a demonstration using your own awkward products, not theirs.

How long does a layered approach take?

It depends on how cleanly your ERP exposes data, which varies enormously. What is predictable is that the integration and data reconciliation take longer than the interface, and any estimate that says otherwise has not looked at your data yet.

What if our data is already a mess?

It usually is, and that is normal rather than embarrassing. Cleaning it is part of the project, not a prerequisite — but be prepared for the audit stage to surface disagreements between systems that nobody knew existed.

More on this: tracking marble slabs and build, buy or neither. For how we work with this trade, see building materials.