Why Your Parts Catalogue Doesn’t Know What a Part Is

Ask most maintenance or procurement systems a simple question — “what replaced this part” — and watch how long the answer takes. If it takes longer than a lookup, the system doesn’t know what a part is. It knows what a part number is, which is a different and much weaker thing.

Industrial parts taxonomy gets treated as a solved problem, usually by pointing at a classification standard — UNSPSC, ETIM, eCl@ss — and assuming the job is done. Those standards genuinely solve one problem well: telling you what kind of thing a part is, consistently, across catalogues and organisations. They do not solve the problem that actually causes outages, warranty disputes, and audit failures, which is knowing the lineage of a specific part over time.

Three relationships a classification code cannot carry

A part number’s history is not one fact. It is at least three different relationships, and most systems collapse them into one field, which is where the trouble starts.

Supersession is a manufacturer’s formal statement that part B replaces part A — same function, sanctioned substitute, usually because A is discontinued. Cross-reference is a different claim entirely: that a part from a different manufacturer is functionally equivalent to yours, useful for sourcing but carrying none of the original manufacturer’s warranty or engineering sign-off. Alternate is looser still — a part that will physically work in the application but was never formally validated as equivalent by anyone with authority to say so. Treat a cross-reference as a supersession, install it in a safety-critical system, and you have quietly removed the manufacturer’s engineering assurance from a component nobody flagged as changed.

A classification code tells you all three of these parts are “the same kind of thing.” It says nothing about which relationship connects them, which direction it runs, or who is authorised to have made that determination. That distinction is exactly what most PIM and ERP implementations never model, because the vendors selling those systems are, as the keyword research behind this piece confirms, built for ecommerce catalogues — where a superseded SKU quietly redirects to its replacement and nobody needs to reconstruct the chain three owners and two ERP migrations later.

Where it actually costs money

Take a marine engine-room spares register — a case that sits close to home for a lot of the operators I work with. A critical pump seal is discontinued by the OEM and superseded by a new part number. If that supersession is recorded only as a note in a procurement system, and the maintenance-management system still references the old part number against the equipment’s technical file, a routine parts order during a voyage can produce a component that is functionally fine but not the one the class society’s records say is fitted — a discrepancy that surfaces at survey, at exactly the moment nobody wants to be explaining a paperwork gap. Multiply that by a fleet’s worth of rotating equipment and years of incremental supersessions, and the register drifts steadily further from what is actually fitted, in a way that is invisible until an audit or a failure forces the reconciliation.

The same pattern recurs in energy and manufacturing spares, where alternates get installed under time pressure during an outage and the informal substitution is never fed back into the system of record, because the system of record has no field for “alternate, not superseded, installed under deviation.”

What a model built for this actually needs

Getting this right means separating the classification axis from the lineage axis entirely. Classification — UNSPSC, ETIM, eCl@ss, or an internal scheme — answers what is this. A parallel supersession graph, directional and typed by relationship (supersedes, cross-references, alternate-to), answers what happened to this and who said so. The two axes are related but not the same structure, and collapsing them into one “related parts” field is the single most common modelling shortcut that causes the problem in the first place. Done properly, a technician or auditor can ask “what is currently fitted, what superseded it, and on whose authority” and get an answer that traces cleanly back through the equipment’s history — the same standard of provable, traceable evidence I write about across every regulated sector on this site, just applied to a parts bin instead of a compliance register.

This is the same standard, incidentally, that shows up wherever a regulator asks for traceable lineage rather than a static inventory — the Cyber Resilience Act’s SBOM expectations for software components run on exactly this logic: not just what is currently shipped, but what it replaced and on whose authority. A physical spares register and a software bill of materials are different domains solving the identical structural problem.

This lineage problem shows up one layer up the stack in ISO 15926 asset registers — same failure pattern, applied to the equipment rather than the parts inside it.

If your spares register can tell you what a part is but not what replaced it, why, or on whose authority, that gap tends to surface at the worst possible moment — an audit, a survey, or a failure investigation. See the underlying argument on why the data model has to come before the tool, or talk through a technology control assessment for a maintenance or spares estate specifically.