Welcome to this week's TBT blog. Part Number blogs always draw a great amount of conversation, so we look forward to seeing your comments below. And, this particular blog concludes our guest blog series from Paul Peck. We are grateful for his contributions and look forward to working with him in the near future!

When we set up PDM systems, we are thinking a lot about drawings, documents, files, and product structures. We might even be thinking about complete product life cycles, and how the items we buy, make and sell will be evolved over the long run. We know that the item information we convey will be the key driver in the Enterprise Resource Planning (ERP) system. But probably not enough thought goes into the design of the part number itself. Maybe we should give it a very close look. It's "key" to how we interface CAD, PLM, ERP, etc., and it deserves careful consideration. As it turns out, the lowly "Part Number" has a history of its own, being a "key" driver in the evolution of "relational" database technology by being the "lingua franca" enabling modern business systems, including ERP itself. Here's how that happened.

Prior to the advent of computers, components and products were identified by various means: sometimes description, sometimes drawing number, sometimes vendor part number, etc. Typically, inventory was managed on a minimum/maximum re-order methodology. When the stock balance of an item got low, near the "min", it became time to order more and replenish inventory up to the "max". Theorists even went so far as to use differential calculus to determine the "economic order quantity" (EOQ) whereby non-linear-per-unit ordering costs were balanced against linear-per-unit carrying costs. But there was a fundamental flaw with the min/max/re-order point method and the goofy EOQ formula. The assumption of steady-state demand rates and steady rate component consumption was unrealistic. Demand was not steady state – it was "lumpy".

In the 60's, long before the days of "Big Four Consulting", the computer giant of the day, IBM, was engaged by numerous large companies to solve this material requirements planning problem. One of the challenges was going to be to convert inventory information to "electronic data", but there was a huge problem: file systems, up to that point, had been "decks" of 80-column punch cards with "fields" of punched holes. The cards would be fed into the computer sequentially, at the beginning of the "job" by the job control language (JCL) commands. These card images with their fields of data would later be moved to tape drives and disk drives, but they were essentially big flat files (decks) with records (cards) that could be evaluated (read) into the machine one at a time, sequentially, and had to be processed in one pass.

In manufacturing, there is no set number of components per assembly, and so there could not be a set number of "fields" to show the parent-component relationships. (The key word being: relationship). So, there would need to be a separate flat file that listed components, and a way to "relate" the two files, thereby linking the components to the assembly. Enter: the relational database. At about this time, IBM developed one of the first one-to-many relational database programs named DBOMP (Data Base Organization and Maintenance Process). It embodied, among other things, the concept of the record "key", a special "field" in every record that made it possible to electronically look up a particular record without having to read the entire file each time.

Also at this time, IBM had a manufacturing consultant named Joe Orlicky, who was helping companies like Toyota, Black & Decker and Case Tractor with the requirements planning problem. Of course, Joe knew about IBMs DBOMP. He knew that the records would all need a "key" to tie it all together. So, he created a new "field" to become the item record's "key." This "key" would be a unique identifier for each item – necessary to "relate" items to their parents and components in the DBOMP relational database environment. This "key" would also be necessary to "relate" an item's supply to an item's demand. At Black & Decker, the first company to use IBM’s MRP, they called this strange new field the "IBM Number". Without these new "IBM Numbers" in the world's first relational database system, the data couldn't "relate". We call that key the Part Number today.

So, with the addition of a "key", big Joe was able to use the new DBOMP database as the world's first bill of material processor, and developed what is known today as MRP - Material Requirements Planning. With DBOMP, IBM mainframe computers could handle the one-to-many relationship between assemblies and their components, thus making it possible to calculate exactly how many parts were needed as demand changed over the time domain, and the information could be used to generate replenishment plans accordingly. Orlicky became famous, and wrote the original book on MRP. MRP evolved into ERP, and became the framework for modern business systems. The rest, as they say, is history.

Which brings us to the structure of the Part Number itself. It is crucially important to get this right. It's the "key" to the product record, fundamental to the ability to "relate" components to parents, and supply to demand. There are serious considerations regarding Part Number when setting up Product Data Management system, the source of product data for MRP/ERP systems.

Form, Fit and Function.
We hear these terms, and sometimes have different opinions about what it means. Literally, it means that if the new or changed item is of a different form, or doesn't fit in all the same applications, or performs a different function, it should have a different part number. An easier way think about this is by asking the following questions:

• • Can we take the new/changed item and use it interchangeably with the
     old/unchanged item – whether it is used on a Sales Order, a Work Order, or a
     Purchase Order?
• • Can the new or changed item be used as a replacement for any item that shares the
     same part number?
• • Will we always be able to "co-mingle" the inventory, such that we don't care which
     one gets used, whether for new shipments, or for repairs to older product?

If you can say yes to all the above, keep the part number the same, and just "bump the revision". No bill of materials needs to be changed, unless you simply want to show a rev bump" at the where-used assembly level(s) for change traceability – could come in handy if you are wrong and should have used a new part number! But if the answer to any of those questions is "no", or even "maybe", a new part number is called for, every time.

Fixed Format and Length.
This is not required by most system software, but is highly recommended. There is a huge benefit to all North America phone numbers being 10 numeric digits chunked up 3-3-4, and all social security numbers being 9 numeric digits chunked up 3-2-4. When a strange format or alpha character appears, or if there's a missing character, it is clear that there's a mistake. A lot of thought and ergonomic study went into these formats. The same concepts apply for part numbers. I strongly recommend against variable formats, variable lengths (makes it hard to tell if you have it all), and mixtures of alpha and numeric (causes confusion like I vs. 1, or 0 vs. O, etc.). Keep in mind that a hyphen, a dot and an underscore are characters themselves, not equivalent to one another, and will affect how things are sorted. The demand for item 12345-678 will not be matched to the supply of item 12345_678.

Avoid Over-Intelligent Part Numbers.
Don't get fancy. There is no way a part number can codify all the intelligence in the item/product record. That's why God gave us PDM/PLM systems and relational database systems. Every citizen of this country has a Social Security number, and 9 unintelligent numeric digits (chunked up 3-2-4) allows for a unique number for a billion citizens. Let the intelligence be with the Social Security Administration, not in the SS# itself. Fed Ex tracks every package it ever sent with 12 numeric digits (chunked up 4-4-4) with no intelligence whatsoever. If you want intelligence with that, simply enter it in their tracking system. The North America telephone network has operated with 10-digit telephone number for 40 years (chunked up 3-4-4). Most of the challenges the telecom companies have faced in coping with these 10 digits has centered on the need to remove the intelligence originally baked into the system that required things like a "0" or "1" in the middle of the area code. Undoing this "intelligence" cost the industry millions and delayed feature deployment by years. Let that be a lesson to us.

Revision is Not Part of the Part Number.
If a revision is "baked" into the part number field – then every time it gets changed it's a whole new part number –which means that it is going to be unrecognized by the Bill of Materials and a brand-new item with regard to the inventory system. If that's what you want (a new "thing") make it a new part number. What revision means, by definition, is that you have "revised" the item, but the part number remains the same. That means that the parent's bill of materials does not have to be changed, and that the item, despite being revised, and is still interchangeable with any other item that is being tracked with this part number. Don't forget the Form/fit/Function rule above. If you know that at any time in the item's future, the new revisioned item will not be interchangeable, go ahead and give it a new part number. Think about inventory – will you ever want to segregate by rev? If yes, then Rev is not what you want – you want a different part number unless you want people to be digging in stock bins reading revisions visually.

Software Makes Hardware Different. 
There are some that think that software doesn't matter when it comes to part numbers. After all, it's just bits, not atoms, right? How could bits change the item? If this were this simple, then Windows version software and Mac version software could be sold under the same part number. If software doesn't affect part numbers and revisions, then motherboard makers can change the BIOS at will, without telling their computer manufacturer customers. And disk drive users wouldn't care how their devices were formatted. Of course, software does matter – just ask the guy trying to jail-break his phone. All software, firmware, micro-code, etc. that differentiates product must be put under the control of part numbers and revisions, just the same as if it were a physical component. Most Product Data Management systems have a special classification for intangible items – you can call it "document number", but the concept is the same – any change is a Revision, unless it causes the item to not be interchangeable – in which case it needs to be a new Part (or document) Number.

So, raise a glass and toast the lowly Part Number. Give it the respect it deserves. It drove the development of business computing. It was the "cause celeb" for the development of the relational database systems by emphasizing the importance of relationship. It is largely responsible for enabling materials management and engineering to get on the same page with computing power. It's not the house, it's not the car – but it is the "key". Design it thoughtfully, just like you would your products.

[Edit: Repost from 2012]

Learn More about Part Numbering!