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 DoyleJennifer 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:

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)5 = 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.

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

  1. Comment in the Lean Six Sigma Canada discussion group on LinkedIn:

    I have been an advocate for eliminating troublesome so-called smart numbers for many years, and this is an excellent argument I can use to help support my cause. In my case, I have frequently needed to revise documents for the sole reason that the responsible department had changed its name – and as result the entire document numbering system for that department was no longer valid. Thanks for stating this so clearly and thoroughly.

  2. Pingback: Should an auto parts plant use “smart” part numbers? | Michel Baudin's Blog

  3. Pingback: A Practical Reason for Moving Beyond Smart Part Numbers | cazh1

  4. Pingback: Shortage of skills, not yet – but very soon – a wake up call (part 1) | Wiegand’s Watch | Michel Baudin's Blog

  5. although our database was originally randomly generated 6 digit numbers, as we brought new products into our plant from smaller businesses, often their databases were ‘smart’. So we went from 6 digit part numbers you could remember to 15 to 24 character part numbers that no one except the Material Planner for that line can remember. I am amazed, but we still have ‘fans’ of smart part numbers who occasionally suggest it as a solution…until I talk them out of it. It causes more problems than it solves in an active part database of 100,000 SKU’s

  6. Pingback: Are Part Numbers Too Smart for Their Own Good? | ENGINEERING.com | Michel Baudin's Blog

  7. Pingback: More Recommendations on Part Numbering | Michel Baudin's Blog

  8. HI Michel. I was searching on something and came across this great article and I was envisioning the same in a different level and scale and wrote an article about standardizing inventory parts across the globe. Here is the opening of my LinkedIn Article. Please read and provide your valuable comments. Thanks

    Presently every manufacturing firm maintains their own naming conventions for Inventory , purchase and Sales parts . Every firm maintains different naming conventions for the same part number , description. When firms do business in a B2B or B2C or B2C2B or whatever form information about these data is exchanged and is duplicated in different forms, names , unit of measure and part numbers.

    The exchanged information about inventory data is duplicated in two ways external and internal. For a manufacturing firm it’s suppliers maintain the data in the form of their sales parts with their own unique part number and description (external) which when coming to the manufacturing firm becomes Purchased raw materials with it’s own Part number and descriptions (internal).

    From supplier to end consumer of that part data is duplicated as the part moves from one to another.

    These duplication involves resources, time and money for the firms to maintain that data.

    Imagine how much duplication goes on for the same part Number such as a simple Item like a Nut or Bolt of a particular specification, across the world used by millions of companies and individuals with different bar codes, RFID’s tagged on the part numbers, descriptions and in different languages.

    I felt that there is a enormous benefit of solving this duplication of naming conventions for parts, BOM(Bill of material structures) etc by taking up the huge work of standardizing the part Numbers, Description , item properties and making it available in a particular formats to all the firms that deal with these data day in day out across the globe.

    The aim is to have one part number and one descriptions and one unit of measure across all global languages for all those who use that part.

    Similarly all the bill of material structures (product structures) which are most commonly used across millions of companies should also be pooled together and maintained as a single repository. … More

  9. There are already Universal Product Codes (UPC) used with barcodes, and Global Trade Item Numbers (GTIN) as part of Electronic Product Codes (EPC) for RFID. This means that efforts in the direction you are proposing are already underway.

    In addition, there are examples of worldwide systems of unique IDs in existence, from phone numbers to IP addresses, email addresses, and ISBN for books, that have provided obvious benefits. To support basic operations, each company needs unique IDs for all the objects it buys, uses, transforms, assembles with others, sells, and ships. To what extent do these IDs need to be unique in the entire world? That is the question that needs to be answered in order to justify the investment you are recommending.

    You are also advocating for the standardization of Bills of Materials (BOM), and I have a hard time following you there. There are many ways to break a product down into a subassembly tree for different purposes, such as purchasing, engineering and manufacturing. These BOMs are not intrinsic to the product. Manufacturers change them change over time to improve quality and productivity, and it’s really nobody else’s business. On these other hand, standard data structures to express BOMs could be useful. But who will generate and maintain them?

  10. Pingback: Manufacturing Data Cleaning: Thankless But Necessary | Michel Baudin's Blog

  11. Thanks so much for putting together a very informative website. I especially appreciated the article about “smart” part numbers. Our company sells parts for the ready mix concrete industry, and many parts sell into other related industries such as heavy duty trucks and material handling equipment.

    I have been with the company for 2 years, and prior to my arrival, an inventory system was put into place using software called Fishbowl Inventory. Within Fishbowl, we have Part Numbers, Product Numbers, and Vendor Part Numbers. The Vendor Number is easy – that’s just whatever number our vendor uses to identify the part. The Part Number is what is internally used to track inventory levels, create purchase orders, etc. Then Product Numbers (which are each associated with a Part) are customer facing – that is what the customer actually orders.

    So here’s my BIG problem. When the company was started they used the OEM numbers from the manufacturer for both part AND product number (and sometimes even vendor number depending on the vendor). Where I have a real mess, is I have multiple products under multiple parts, which are actually all identical and should all be under 1 part number. You can imagine the problems that can cause. Quick example: Freightliner sells their torque rod under part number 123456, we have a part and a product under number 123456. Peterbilt sells their torque rod under 987654, which we also have a part and product for. But in reality they are the same, and the vendor sells them to us under their number s-1745. If I have 1 Freightliner 123456 in stock in the system my sales guy doesn’t know it when the customer calls asking for Peterbilt 987654. To compound the problem, many OEM’s used TERRIBLE part numbers with forward slashes, dashes, leading zeroes, you name it – and yep – they’re in our system too, now.

    Hope that all makes sense – sorry to be so long winded!

    So I need some major help. I started out typing with the simple question in mind – what software do you use to generate these “dumb” part numbers? I like the concept very much, and could easily do just an ascending 7 digit numerical in Excel starting with 1000000 – but I guess I figured I’d throw the whole problem at you and see what you had to say. Looking forward to hearing from you!

    • Obviously, you need unique part numbers for your internal use, and I think the only reasons many companies are in the same predicament as you is that people set up these systems hastily, without considering the consequences.

      Your Excel solution can work, but I recommend avoiding purely numerical IDs, because, for IDs of equal lengths, it severely restricts the number of possible names. With numbers only you can have 100,000 5-character IDs but, with combinations of uppercase letter and numbers, you have > 60 million.

      Generating all the possible names can be done in a variety of ways:

      • With a complicated Excel formula or 3rd party Excel add-ons.
      • With an unconditional join query in an SQL database like Microsoft Access or MySQL
      • With a small program in any general programming language.

      Following is R code to generate all the 60 million names you can generate with 5 alphanumeric characters, and save the first 200,000 in a text file called five-char-IDs.txt:

      library(plyr)
      #Define the character set
      S < - c("0","1","2","3","4","5","6","7","8","9", "A" , "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z") #Create cartesian product data frame d = expand.grid(C1 = S, C2 = S, C3 = S, C4 = S, C5 = S) #Select the top 200,000 d <- head(d, 200000) #Concatenate the characters d = mdply(d, 'paste', sep = '') #Save the list of IDs d <- d["V1"] names(d) <- c("5-character IDs") write.table(d, file = "five-char-IDs.txt", sep = "\t", row.names = FALSE)

      The statement

      S < - c("0","1","2","3","4","5","6","7","8","9", "A" , "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z")

      defines the alphabet from which you are building the IDs. If you want to avoid leading 0s, you can define a separate alphabet for the first character in the IDs, such as:

      T < - c("1","2","3","4","5","6","7","8","9", "A" , "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z")

      and then you generate the quintuplets with:

      d = expand.grid(C1 = T, C2 = S, C3 = S, C4 = S, C5 = S)

      You can also takes this further and use a different alphabet for each position in the ID.

Leave a Reply

Your email address will not be published. Required fields are marked *