Every PLM programme has one meeting where a room of senior engineers argues about part numbers for ninety minutes and resolves nothing. It is the least interesting conversation in the whole implementation and the one with the longest shadow, because every structure, every change record and every ERP integration built afterwards inherits whatever was decided — or worse, inherits the fact that nothing was.

Here is the argument, compressed, so you can have it once.

The two options

Intelligent numbering encodes meaning in the identifier. BRK-SS-014-M8 tells you it is a bracket, stainless, variant 014, M8 thread. Humans can read it without opening anything.

Non-significant numbering does not. 100294718 means nothing on its own. Meaning lives in attributes — material, type, thread size — which are searchable, filterable and reportable.

Almost every organisation's instinct is the first. Almost every experienced practitioner recommends the second. That gap is worth explaining rather than asserting.

Why the intelligent scheme fails

It is not that encoding meaning is wrong in principle. It is that meaning changes and identifiers cannot.

The taxonomy always runs out. Two characters for a commodity code gives you a comfortable ninety-nine categories, until the year you acquire a company that makes something you have no code for. Now you are either inventing a category that does not fit or extending the scheme, which means two schemes.

The encoded attribute changes and the number lies. The stainless bracket gets revised to aluminium. The part is functionally the same, the drawing carries forward, but the number now says SS forever. You either accept a permanently misleading identifier or issue a new number for a part that did not functionally change — which breaks every historical reference to it.

People start reading the number instead of the record. This is the failure that actually costs money. A buyer sees M8 in the identifier, orders M8 hardware and never opens the drawing where the change to M10 was approved last month. The number becomes an unmaintained duplicate of data that lives properly somewhere else, and the two disagree exactly when it matters.

It leaks to people who should not have it. Send a supplier a BOM of intelligent numbers and you have sent them your product taxonomy, your variant strategy and a decent guess at your volumes.

Non-significant numbers have none of these failure modes, because they make no claims. A number that says nothing can never be wrong.

The three objections, answered

"Engineers need to recognise parts at a glance." They need to recognise parts, which is a search and display problem rather than an identifier problem. In any competent PLM the part number appears beside its description, and search on attributes is faster than decoding a string. If your team genuinely cannot find things, the fix is the search configuration, not the numbering scheme.

"The shop floor reads numbers off drawings." They read what the drawing title block shows them, and the title block is yours to design. Put the description, the material and the revision on it in large type. Nothing requires the identifier to carry that load.

"Our legacy numbers are intelligent and everyone knows them." True and important — which is the next section.

When you have inherited a scheme you cannot change

Most readers are not starting clean. The realistic position is a legacy intelligent scheme, decades of parts using it and no appetite for renumbering.

Do not renumber. It is expensive, it breaks external references you do not control, and it delivers nothing a customer can see.

Do this instead:

Freeze the old scheme and stop extending it. Existing parts keep their numbers forever. New parts get non-significant numbers from a generator. You will run two conventions for years, which is fine — you are already running one that does not work.

Promote the encoded meaning into attributes. Whatever the legacy number encodes, populate it as real properties on the item, backfilled from the number itself where you can parse it. Once material and commodity are attributes, every report and search works the same way across both schemes.

Never let a new number encode anything. The single rule that prevents the next generation of this problem.

The rule that actually matters

Whichever scheme you land on, this is the part that decides whether it holds:

The identifier is generated by the system, never typed by a person, and never reused.

Manual entry produces collisions and typos, and typos in identifiers are uniquely damaging because they create a plausible-looking part that is not the part. Reuse — recycling numbers from obsolete parts — is worse: it silently corrupts every historical record that referenced the old part, and it usually surfaces years later in a warranty investigation, at the exact moment you need the history to be true.

Settle numbering before you build anything that consumes it. It is a ninety-minute argument if you have it now, and a migration project if you have it later. That asymmetry is the whole point of sequencing a roadmap by dependency rather than by who is asking loudest.

Working paper. If you are about to have this argument and want a second pair of eyes before it becomes policy, get in touch.