Why “Smart” part numbers should be replaced with keys and property lists

Nomenclature matters. What you call parts, products, and resources, and how you attach technical, commercial, and administrative data to their names determines how easy they are to retrieve in daily operations and to analyze for planning or control purposes. Manufacturing, worldwide, is overwhelmingly dominated by part numbering systems  that are called “smart” because they embed data about materials, dimensions, number of holes, or other characteristics into part numbers, as in CEP-134M10FB-TT1234\R4, where each group of characters has an encoded meaning, for example  CEP for Capacitor and R4 for Revision 4.

In concept, these systems are a 100-year old legacies of the paper-and-pencil age, and obsolete in the age of databases. The alternative is to have part numbers that are just unique IDs, or primary keys in database terms, with all the data attached in the form of property lists in plain text. I propose to call it the key approach. The case for the key approach is overwhelming, and the technology to use it available. But nearly all manufacturing professionals active in 2012 have been educated in the old method, and taught that it was smart. They are unaware that it should be replaced.

In addition, people who have spent years mastering a complicated, antiquated system are always strongly attached to it and oppose its abandonment, as it would make their hard-won expertise irrelevant. This is why, for example, command-driven information systems were successfully marketed long after they had been supplanted by graphic user interfaces in home computers. It is also the reason spelling reforms almost never succeed. Part numbers with encoded information are a deeply rooted legacy.

These are great hurdles to overcome, requiring missionary work. Of course, even if this post is persuasive, if leaves unanswered the question of how you migrate from “smart” part numbers to the key approach, in an existing organization with legacy information systems. It is an essential question, and needs to be addressed separately, once the desirability of this transition is established, which is our point here.

Let us begin with detailed explanations of the value of the key approach.  First, it does not in any way limit functions. In addition, it has the following advantages:

1. It reduces training costs.
2. It is not affected when product information changes.
3. Part numbers are short, and therefore easier for humans to work with.
4. Part numbers are distinctive, even for similar parts, thus reducing picking errors.
5. Nomenclature errors are more easily detected and corrected.
6. Property lists in plaint text on labels are easier to read.
7. Property lists support data mining.
8. Product catalogs from different companies can be merged without loss of information.
9. Company-private information is not unintentionally disclosed through part numbers.

Much of the material below is based on a recent discussion in the APICS discussion group on LinkedIn, initiated by Elvi M., and including contributions from Patrick Doyle,  Jennifer Verellen, Joseph E. Harrington, Ph.D., Felipe Sanchez Ryckewaert, Martha M. Munson, PMP, Greg Pope, and T R Volpel CPSM.

Origins of “smart” numbering systems

Such systems have been introduced in libraries in the 19th century. In his latest movie, J. Edgar, Clint Eastwood highlights the role future FBI director J. Edgar Hoover played in the development of the Library of Congress cataloging system, in which “BX 378.5 .M38 1968”  breaks down as follows:

• BX = Books on Religion
• 378.5 .M38 = Shelf Address
• 1968 = Year of publication

In the 1910s, it made sense because it allowed trained users to locate books quickly. You could search the card catalog by author, title or subject, and then locate the book by its call number, as shown in Figure 1:

Figure 1. Using a library card catalog

Awareness

Most manufacturing professionals see nothing wrong with “smart” part numbers, to the point that they extend the approach to every aspect of operations, resulting, for example, in expense reports with lines like “HK0010 DB-ENG-122 M-3 RK 23.50,” which translates to  ” Helmut Katz spent €23.50 for dinner at the Ratskeller while working on the DaimlerBenz Engineering project.”

“Smart” part numbers have grown such deep roots in manufacturing operations that few managers or engineers are even aware of the unnecessary costs they generate in training and routine decoding, and of the obstacles they place in the way of manufacturing data mining. Some academics do realize that there is something wrong: in his 2005 textbook on Product Lifecycle Management (PLM), Purdue University’s Micheal Grieves reports that “With the implementation of PLM, smart part numbers are generally replaced by sequential part numbers.” In their LinkedIn profiles, however, several recent Purdue graduates report implementing “smart numbering systems” during internships in manufacturing companies as late as 2009!

Awareness of the issues is perceptible in blogs on PLM and CAD , as, for example, in the following:

• PDXpert
• Beyond PLM
• Ricky Jordan
• Josh Ming

Advocating the replacement of a method that its promoters got away with calling “smart” is an uphill battle. Who would want “dumb” systems instead? The first step may be to come up with an attractive generic name for alternatives, which is why I am suggesting we call it the key approach.

The key approach

Figure 2 shows an example of the key approach to an item and the characteristics that are usually embedded in a “smart” part number.

Figure 2. The key approach to part numbers

The item is uniquely identified by the key “13AB5,” and the nomenclature database has a record for each property of each item, in the form of a name-value pair. There are different views of what an item is. In some cases, the same key is used for all revisions, and you tell the revisions apart by their number. In this example, each revision has its own key, and contains the key of the prior revision in its property list, so that you can trace back the history of the part through multiple revisions.

Neither the property names nor the values contain any abbreviations or codes. They are all in plain text. In particular, you may notice that, where applicable, property values include units, while “smart” part numbers usually don’t. This is an important detail in multinational companies where metric and imperial measurements coexist. There is no need to store these characteristics in short fields. You can use as many characters as you need. 30 years ago, data storage space was expensive; now it is not.

Different items can have different property lists. Metal tubes have a length and a diameter; potato chips, expiration dates. The property values can also change over time without the item itself undergoing any change that would justify a new part number. For eample, if the item is a product that undergoes a drop in demand, its volume category may be downgraded from A to B, and it may then no longer have a dedicated warehouse location.

Reducing training costs

Unless the users of part numbers, in materials handling, production, engineering, production control, purchasing, or sales, are able to retrieve the information embedded in a “smart” part number, embedding it was a waste of time. But, in order for this to happen, hundreds or thousands of people would have to be trained on issues like the meaning of the field in characters 5 to 8 of a part number. In reality, it doesn’t happen. In pursuit of data mining, I often have to parse “smart” part numbers and find that, outside the department in charge of master data, very few people have a clue. When asked what a part number means, they have to painstakingly decode it field by field from a spec.

With the key approach and characteristics listed in name-value pairs in plain text, the information is accessible with no training, which is why it is used on e-commerce sites like Amazon. Each product’s unique ID is Amazon’s ASIN, which may designate anything from a book to a waffle iron. The Product Details are given in a list of name-value pairs, and this information is immediately obvious to a first-time visitor. You don’t have to take a class.

Historical continuity and traceability

Patrick Doyle used 1-015-113-029-2 as an example of a “smart” part number, meaning that it is a single part (1), used on a phone (015), is a diode (113), supplied by Diodes R Us (029), and is revision two (2).

Such a part number contains data that is subject to change as you may, for example, decide to switch suppliers. This puts you in a dilemma. If you change the part number so that it contains accurate supplier data, you break the continuity of your history with that part, or you keep the same part number and violate your own convention. If you do change the part number, you can still retrieve the complete history by maintaining a table of name changes, but it adds complexity.

With the key approach, instead of 1-015-113-029-2 and a dictionary to translate all properties into plain text, you have something like the following:

• Part ID: EA5D4, a unique key unique, with no embedded data.
• Property list in database, keyed on Part ID = “EA5D4”:

Where-used: iPhone
Family: Diode
Supplier: Diodes R Us
Revision: 2

All the properties can be changed without affecting the key, and the complete history of production volumes, deliveries, and quality problems can be retrieved with the key.

Short names, easy to work with

“Smart” part numbers tend to be preposterously long, and therefore practically impossible for people to remember. No matter how large a field an ERP system or MES provides for part numbers, some company “smart” numbering system will exceed it. In the key approach, the part number’s one and only job is unique identification within the scope of the system. There may be another object by the same name at the other end of the world, but not within the plant or the company.

A sequence of just 5 uppercase letters and digits is mercifully short and easy to remember. It provides (10+26)⁵ = 60.5 million possible IDs, and that is enough to meet the needs of even a high mix production organization for a long time. Some prefer to use digits only, but it reduces the name space to only 100,000 IDs.  Allowing lowercase letters would increase it to 916 million, but few people would reliably make the difference between “13AG5” and “13aG5.”

Distinctive part numbers

“Smart” part numbers give similar names to similar parts, which makes them more difficult to tell apart during picking and increases the risk of picking errors. Hergé’s  Tintin stories feature the two dim-witted detectives named Thompson and Thomson shown in Figure 3:

Figure 3. Thompson and Thomson

The only way to tell them apart is from the shape of their mustaches, and their nearly identical names don’t help. Now, in Figure 4, consider the following two, nearly-identical screws and their nearly identical part numbers:

Figure 4. Nearly identical parts with nearly identical part numbers

One of the screws is 1/8 in shorter than the other, which, with “smart” part numbers, results in only the last digit being different. How much more likely are they to be confused during picking than if their names were A23GT and 92WRT?

Detection and correction of nomenclature errors

The only way to be sure a part number is read and written accurately is respectively by reading it automatically from a bar code or an RFID tag, and by printing from the master database. Typing, handwriting, copying and pasting, and even selecting from a long pull-down menu with similar entries is error-prone, particularly when performed with data that has been extracted from an ERP, MES or PDM software system into an electronic spreadsheet. Besides typos, part numbers may have interchanged characters, be truncated, or be misinterpreted by the destination software, as when, for example, Excel treats a part number like a number and lops off leading zeros. And the slightest error in a part number is enough to make the consolidation of data about it from multiple sources impossible.

The above is true no matter what part numbering system you use. The risk of error, however, is much higher with “smart” part numbers than with keys, because they are two to three times longer and more similar, so that a part number with a typo may point to a different, existing part rather than nothing.

Labels with plain text characteristics

Several participants in the APICS discussion, and particularly Martha M. Munson, and Greg Pope, expressed concern about the human-readability of labels. For example, if no information is embedded in a part number, how can material handlers locate it in a warehouse? In fact, the key approach is not to hide this information but to separate it from the identification itself. As shown in Figure 5, all the data in Figure 2, or a relevant selection from it, can be printed on a label.

Figure 5. Box label with characteristics in plain text

Note also that all the characteristics on this label are printed in plain text. The best, cheapest and least error prone standard is using whole words from the native language of the work force. If the bolt category is called “Bolt,” no training is needed to recognize it. If you call it “256,” you need a dictionary. Human readability is, of course, not the only concern in daily operations. You also need to use bar codes or RFID tags for machine readability.

Support for data mining

The most convenient input to manufacturing data mining is a table in the dimensional model, meaning that some columns contain reference data — used for filtering and aggregating — and facts — the measured quantities or observed attributes for which you want to identify patterns. All the characteristics embedded in a “smart” part number are part of the reference data. You want to be able to analyze quality for parts made from a given raw material, or within a dimension class, etc.

Retrieving this reference data by parsing “smart” part numbers is a major effort, that has to be repeated with each naming convention.With the key approach, on the other hand, turning the property list of Figure 1 into the table of Figure 6 is just a matter of using a crosstab query in Access or a pivot table in Excel.

Figure 6. Item properties crosstab for data mining

Merger support

The possibility that the company might merge or be acquired is usually not a consideration in the design of its nomenclature. However, considering how often such events occur and how far reaching their consequences, it should be. When companies merge, their catalogs of products and parts should too. Merging information models, and nomenclature in particular, is always difficult and time-consuming. Mergers are mostly of unequal companies, and the larger company’s system becomes the merged company’s standard, even when the smaller company has a better one. In true mergers of equals, this situation often goes unresolved for years, with both divisions’ legacy systems remaining in operation, and possibly, their real-time content meeting through integration middleware and their histories in a data warehouse. To focus on what happens we part numbers, we consider two hypothetical mergers. In the first, both companies have “smart” part numbers; in the second, both use the key approach. Real situations, of course, have many other patterns.

I have never seen two companies with identical “smart” part numbers. For them to use different naming conventions is good for uniqueness after the mergers, because it makes it highly unlikely that they will have assigned the same name to different products or parts. As the software systems themselves usually do not constrain the naming conventions — except for the total length of part numbers — you can upload another company’s part numbers, and end up with a catalog that commingles part numbers based on both conventions.  But this adds further complexity for data mining, because, to retrieve the information embedded in part numbers, you now need to parse names generated with two different conventions, and to identify which convention each name is based on. The management of the acquiring company intends to standardize the part numbers on its own system, but implementation has a way of being postponed indefinitely.

Two companies using the key approach have a higher risk of key conflict, especially if the keys are sequential auto-numbers, because both companies will have products with keys 1, 2, 3,…, 4384, needing disambiguation. This is a problem that is usually not anticipated when systems are first implemented, but can be avoided by instead selecting names at random from a large name space. For example, if 20,000 keys are chosen with equal probabilities among the 78.3 billion  possible combinations of 7 digits and uppercase letters, then 99.7% of the time, no two will be identical. You would still need to search for duplicates just in case, but you only have a 0.3% probability of finding one.

The European Union had this problem with ZIP codes, and resolved it with country code prefixes. Another option, if you have two products both named 4384 by different companies is to rename one of them 4384.1. Any change to keys is undesirable, because all references to that key then need to be updated. This can usually be managed within one system, but not within all the ad-hoc extracts and spreadsheets that users have generated.

Merging the property lists from two companies systems is work in any case but is easier to do with property lists than with “smart” part numbers, where it requires you to develop a sophisticated parser. The properties in both systems are likely to have both different names and sets of values for the same data. The name value pair (Material, Steel) in one system may by (Mat’l, STL) in the other, and the engineers need to build a dictionary to translate them. At first, you may translate the data only in the data warehouse, which is sufficient to jointly mine the data from both systems, but, eventually, you would want to standardize the property lists across the divisions.  When you do this with the key approach, you deal with issues of  meaning that have to be addressed anyway as part of a merger. With “smart” part numbers, you also have to resolve format issues that are unrelated to meaning.

Data security

The protection of proprietary information is the only legitimate reason to encode and encrypt data. During development, for example, the marketing names of products are not used for fear that they might leak to competitors. Once a product is made and sold, all units often bear serial numbers that must be encrypted lest they provide competitors with information about production volumes. As mentioned in Data Mining in Manufacturing versus the Web, the use of plain text in serial numbers on World War II German tanks allowed British analysts to estimate the numbers produced from the serial numbers of the units that were captured or destroyed. The serial number of my iPad today is DKVG805HDFHY, from which Apple competitors can deduce nothing unless they know how to translate it back to a production sequence number.

“Smart” part numbers do not provide much security, as anyone who cares to can reverse-engineer them from actual products and labels. For example, on the Lands’ End catalog, once you find out that Men’s Regular Short Sleeve Jacquard Polo shirts are item#40600-5A63 in Regular sizes, and item# 40600-6A69 in large sizes, it doesn’t take Sherlock Holmes to guess that the numbers preceding the dash identify the polo, and the alphanumerics following it, a size class. A “smart” part number is like a house key that would carry information about which door is opens; a thief cannot infer your address just from your house key simply because this information is not on it. Likewise, in the key approach, a product ID by itself will not reveal anything to your competitors.