Intelligent Part Numbers might be a good idea in “connected world”

November 4, 2015


Part numbers. This is probably one of the most discussed topic in manufacturing and related software domains. How to define Part Numbers? How to manage it using multiple systems? What schema to use? Engineers and software vendors are trying to figure out how to do it. Sometimes, it is very confusing.

Dumb numbers vs. Intelligent number is a quintessential moment of every discussion about Part Numbers. Few months ago, I shared my thoughts about why to use intelligent part numbers in 21st century. There are 3 reasons why intelligent numbers are good – independent from software; self-defined; can be used across multiple systems.

The traditional way is to think about Par Number as identifier in PDM, PLM or ERP system. This is still a valid assumption. However, manufacturing is getting more connected these days. As a result of this an increased number of people and related services can be interested to use part numbers outside of the system for variety of reasons – design contractors, suppliers, contract manufacturers, customer service teams, e-commerce website, etc. To hook them all to a single PLM system can be not feasible. It will might force to review the way systems are using part numbering schema.

One of the way to think about it is think about data and not specific numbering schema. Here is a link to one of my earlier posts from last year speaking about. The idea of disconnecting part numbers and classification from a specific application is one that I want to point out today.

My attention was caught by the development of Common Part Library (CPL) by Octopart. Check more about CPL here. Octopart is a software outfit developing search engine for electronic parts and helping engineers to build electronic products. The following blog post speaks about introducing CPL Part Numbers. It appears to be an interesting problem. You might think eventually, you search Parts and getting Manufacturing Part Numbers. But Octopart engineers had a different opinion and decided to invent so called – generic part, which is in my view an approach similar to how how most of PLM vendors did in the past. The following passage explains guidance Octopart engineers used to develop new part number schema.

The MPNs are not always easy to interpret, and as we developed a scheme for identifying generic parts in the CPL, these are the lessons we took from the MPN naming schemes: 1/ The part numbers should encode useful information. 2/ The part numbers should be readable without having to consult an external reference. 3/ The naming should be consistent across component types.

What I found interesting is how Octopart is using “soft” identification parameters to makes CPL Part Number meaningful for engineers search for parts. CPL part number is allowing to reference multiple parts without specifying manufacturing part number (MPN).


What is my conclusion? Octopart CPL approach to define meaningful part numbers is representing an interesting approach to build relationships between physical components manufactured by multiple vendors, but in fact can be interchanged under specific circumstances. You may think about it as “alternate” part in PLM solutions, but I’d consider Octopart use case generic and broader. It is an interesting attempt to build identification beyond organizational boundaries, which can be very helpful to engineers, contractors and manufacturers these days. Just my thoughts…

Best, Oleg

Pictures credit Octopart blog.


Why to use intelligent Part Numbers in 21st century?

September 18, 2015


Several people asked me the same question earlier today. It wasn’t tricky question. It was a question PDM and PLM pundits are discussing for years. And the question is “should we use intelligent or dumb part numbers. Do you think, I’m kidding? No, I’m not…

The number of articles and blog post about part numbering schema is overwhelming. It looks like all bloggers writing about CAD and PLM ((including myself) ) already posted at least one blog about that. Just to mention few posts – Part Numbering Schemes—Intelligent vs. Non-Intelligent; Intelligent Numbering: What’s the Great Part Number Debate?; Part Numbers are hard – how to think about data first; Connecting ERP to PLM.

I’ve heard a lot about the fact companies implementing PLM should use the opportunity and move from the practice of intelligent part numbers. It will save time and will make your life easier. So, you probably think intelligent numbers are in the past and you can see them in the back mirror of your new car. It might sound like that with an increased efforts to implement PLM systems by large and small companies these days. So, why people are still using intelligent part numbers? Until today, my conclusion was that people feel more comfortable with intelligent part numbers because of 3 main reasons:

1- It is self-defined and helps engineers to keep their existing habits and processes in places.

2- You don’t need to implement it using PLM, ERP or any other system.

3- It can be used across multiple systems.

Most of PLM vendors are allowing multiple options for part numbering schema. It includes both (intelligent and not) approaches in their PLM systems. It usually came with a large portion of explanations about advantages and disadvantages of both approaches. I thought that the answer is somewhat in the middle and development of intelligent part numbers can be an overkill for organization already decided to implement PLM system. So, customer should use technology, apply classification schema and treat part number as internal element of data model.

Here is the thing… Something is changing in the way companies are thinking and working these days. Manufacturing is getting more connected and it might force us to review part numbering schemas and the way we think about it. Obviously PLM or whatever other system(s) we use in engineering and manufacturing should have a way to identify data. As a result of this an increased number of people and related services can be interested to use part numbers outside of the system for variety of reasons – design contractors, suppliers, contract manufacturers, customer service teams, e-commerce website, etc. To hook them all to a single PLM system can be not feasible.

Also, product lifecycle span is becoming longer compared to a software lifecycle. The data you create today using one system will have to move to another system sooner than later. By developing intelligent part numbering schema, you can eliminate many problems in the future when you will be migrating data between systems and services.

I want to risk myself and share my opinion here. I can see an increased importance to use intelligent part numbering schema these days as we move into connected manufacturing eco-systems. Modern cloud-based engineering and manufacturing software will create a surge for companies to develop data schema independently from PLM system. It will also help to integrate systems and services together using Web APIs and web friendly integration systems.

What is my conclusion? The changes are coming to manufacturing. It is getting more global and connected with many dependencies and cross-company processes. In such eco-system intelligent part numbers can simplify processes and eliminate the need for additional data mapping. How engineering, manufacturing, procurement, supply chain and other software will handle new way to getting access to the data across systems? This is a big question and the note for software and system architects. Just my thoughts…

Best, Oleg

Image courtesy of Stuart Miles at


Existing data prevents companies to improve Part Numbers?

August 15, 2014


Part Numbers is a fascinating topic. I’m coming back to blog about what is the best approach to manage Part Numbers. My last post about it was – Part Numbers are hard. How to think about data first? was just few weeks ago. In that article, I outlined few principles how to keep PN separate from surrounding data focusing on different aspects of parts – description, classification, configurations, suppliers, etc.

Yesterday, my attention was caught by ThomasNet article – Are Part Numbers Too Smart for Their Own Good? The article nailed down a key issue why companies are still having difficulties with management of Part Numbers. Nothing works from scratch in engineering companies. Complexity of characteristics and history of existing Part Numbers and products are making real difficulties to adopt new PN management concepts. The following passage explains the problem:

Another problem with descriptive numbering is that the description can become out of date and irrelevant over time. Individual parts can have their own life cycles; if a part has been identified according to the product, what happens if that product is discontinued but the part continues to be used in a newer product? Or what if a manufacturer changes vendors and the part number contains the name of the vendor that originally provided the piece?

Gilhooley admits that some Ultra Consultants clients have decided that switching from descriptive to auto-generated numbering would require too much organizational change. Some companies stick with old systems, and some opt for hybrid systems that perhaps retain descriptive numbers for existing parts but use auto-generated numbers for new parts.

It looks like there is no single solution or best practice to solve the problem. The "traditional" engineering approach to keep options to manage a diverse set company configuration looks like the only possible way to solve this problem in existing PLM/ERP systems.

What is my conclusion? History keeps customers from moving forward. There are two aspects of complexity in Part Numbers: 1/ complexity of definition and data classification; 2/ historical records of PN in every company including catalogs and existing products. Together, they create a block to make any changes in existing PN schema and prevent companies from migration towards new approaches. New data modeling technologies must be invented to handle existing data as well as supporting customers to migrate into modern PLM and ERP solutions. Just my thoughts…

Best, Oleg

How to manage Document versions, revisions and Part numbers

March 7, 2014


Identifications, Part Numbers, Documents, Revisions. Despite initial simplicity these terms are often create confusion in organizations and lead to additional misunderstanding. Design and Motion blog post When a version is just a version and a revision is more made me think again about differences between document revisions / version and part lifecycle. In my earlier post – BOM 101: 5 “Don’ts” for Bill of Materials Management, I’ve been talking about differences between Part Numbers and Document Numbers. One of my "don’t" recommendation was not to use the same numbers for documents and parts. Design and Motion article gives a good explanation why it is important. Every PDM system (article speaks about Autodesk Vault, but it will be similar for other PDMs) is allowing to use revisions and versions for CAD and other documents. Here is passage explaining the difference

A version is an iteration, something that is different than before.When programmers develop software a version is typically a minor software update, something that addresses issues in the the original release but does not contain enough to warrant a major release of the software. A revision is a controlled version. Webster’s dictionary describes a “revision” as the act of revising, which is to make a new, amended, improved, or up-to-date version. Back to the software analogy, a revision is seen as a major release of the software. Something that introduces new features and functionality, as well as fixing bugs. In the engineering world we use revisions to document the changes so that anyone can understand what was changed. Versions are usually temporary, revisions are permanent. What I mean by this is that during the design phase I will quickly build up versions of the design, however 5-years from now I will only care about one version, the one that was released.

So, typical document (e.g CAD assembly or drawing) will have document number and additional version / revision. One of the common mistakes (especially in small companies) to use document number as identification for parts. This is wrong. The right identification for parts is Part Number. Parts have no versions and revisions. The lifecycle schema for parts can contain revision as a property as well as reference to document (including document revision). In order to manage differences between part and lifecycle, companies are using interchangeability model. Usually, unique part number is identifying part until both parts can be mixed in the same bin location. As soon as next design or other change will make a change, new part number will be assigned to the part. Two parts can be considered as "interchangeable". It means the functional and physical properties are equivalent in performance, reliability and maintainability. Based on that, two parts can be used without requiring special procedures (such as selecting for fit or performance) and without altering the part itself or any other part. In addition to Part Number, lifecycle status can be applied to the part to identify the level of maturity. Typical examples of lifecycle statuses are – pre-release, production, last time buy, obsolete and some others.

Management part lifecycle is completely different document versions and revisions. These are separate processes. The alignment between them can be set by assignment of specific document revision to be related to design of a specific Part (Part Number). This relation can be set inside of PDM/PLM system (in case system manage both documents and parts). In case part lifecycle managed by another system (e.g. ERP), that system will be responsible to establish relationships between released documents (drawing) representing a specific Part number.

What is my conclusion? Despite visible simplicity, it is absolutely important to separate document and part lifecycle in every PDM / PLM implementation. Document number and Part number cannot be identical. The special mechanism allowing linking between specific Part (number) and released document (including revision) should be implemented. It is important to set this rules from the early beginning to prevent future part / documents management mess. Just my thoughts…

Best, Oleg

BOM 101: The four pillars of every BOM management solution

January 17, 2013

I suggest you an experiment. Invite two engineers and ask them to provide a definition for some of PDM/PLM related terms. I’d not be surprised if you will get more than two definitions. It is not unusual to spend lots of time during PLM software implementation meetings to define terms, language and meaning of things. Regardless on terminology, I found BOM to be a central element in every product development organization and business. It contains a recipe of your product, process and, at the end of the day, becomes a lifeblood of your product development processes. Thinking about BOM management solution, I can see four major things that need to be defined, discussed and clarified.

BOM and Part Lists

Bill of Materials (BOM) is a list of all items required to make a parent item. It includes components, raw materials and sub-assemblies. You may also include intermediate items identifying in-process elements to facilitate planning and other manufacturing processes. Depends on industry, people can call BOM differently. For example, in process industry, it can be called recipe or formula. Opposite to BOM, Part List is usually a term used to call a single level list for a specific level of assembly or sub-assembly.

Part Number

This is one of the most tricky defined terms in a whole product development and BOM management story. Here is a short definition. Part Number (PN) is an unique identifier that identify a single object in bill of material. However, the trick is how to define object and how to keep it consistent with your processes. Assigning part numbers is often complicated and one of the most discussed topics. The traditional definition of FFF (Form, Fit and Function) helps to identify the right objects. Interchangeable parts, substitiute items, special parts – this is only a short list of issues that comes into the discussion around part numbering process.


Think about navigation system with the road between different places. Now imagine part numbers. Routing is a roadmap that defines the path of part numbers across manufacturing floor by specifying workstations and labor time associated with every station. Usually routing applied to manufactured parts or items.


Drawings represents a significant part of history and confusing engineering habits. Historically, drawing is the place where people put bill of materials for a product. It also solves the problem of Bill of Materials distribution in the company. At the same time, BOM on a drawing brings lots of disadvantages. In many situations, people don’t need drawing, but only need bill of materials and/or part list. Another point of confusion is numbering system. The discussion is about applying part numbers on drawings. In most of the situations, it represents the limitation of systems used for product development (PDM/PLM). To separate between Part Numbers and Document Numbers is the most reasonable ways to manage it, in my view.

What is my conclusion? Regardless of what systems you plan to use, I recommend you to have cross-department organizational discussion about these four pillars. Usually, it helps to understand product development processes. Engineering and manufacturing are two main organizations usually involved into BOM processes. To clarify terms will give you a tremendous value during PDM/PLM system implementation and integration with ERP. Just my thoughts…

Best, Oleg

A Geek’s View on Part Numbers

August 17, 2011

I feel a bit geeky today. I posted about part numbers, document number and numbering few times in the past. These posts sparkled an intensive discussion about all possible and impossible data schemas, intelligent numbers and standards for part numbering. I want to give you a bit different approach to think about Part Numbers – Regular Expressions. First of all, what is that? This is how Wikipedia defines regular expressions.

In computing, a regular expression, also referred to as regex or regexp, provides a concise and flexible means for matching strings of text, such as particular characters, words, or patterns of characters. A regular expression is written in a formal language that can be interpreted by a regular expression processor, a program that either serves as a parser generator or examines text and identifies parts that match the provided specification.

Navigate to the link to the following article – How to use regular expression to search better and save time? Take a moment of time and read it. You will find a lot of interesting tips how you can create various queries that fits your numbering models for documents and parts. The article provides good examples on how to use regular expressions and link to additional resources.

What is the conclusion? I hope you enjoyed my "geeky tips". Speaking seriously and thinking about practical aspects, regular expressions are good only when your PLM software supports them. Did you get any experience with this in the past? Can you share any examples of regular expression usage in your PDM/PLM software?

Best, Oleg

PLM Think Tank July Top 5

August 5, 2011

Summer time is usually good for vacation. I’m taking this week off with family traveling from Boston to Quebec and Montreal. I’m sharing with readers on Twitter, Facebook and Google+ some of the road pictures. Take a look on few occasional shots I made on my way from Boston to Quebec with a short stop in Maine.

Road To Canada via Maine, Rt. 201

Evening view from Vieux-Quebec

Vieux-Quebec evening

Now let’s move to traditional monthly PLM Think Tank Top 5 for July.

Autodesk PLM – Fast Second?

Blog post about future of Autodesk PLM was top ranked in July. People want to have a better way to manage their data and processes. According to Autodesk, most of PLM implementations today are about data management. Existing PLM vendors are doing mostly data management. Autodesk is doing an excellent job in data management using Autodesk Vault. So, the goal to fix processes and workflow sounds like a reasonable one. Autodesk is getting a huge advantage to research all available PLM implementations. The second-mover opportunity is on the Autodesk side. However, Autodesk will have to come with something radically different to prove their approach is better. Last, but not least – processes are tightly connected to the data in organizations. Autodesk will have to implement an efficient access to product and company data from the cloud to successfully deploy their new cloud-based process management software. Here is a challenge and a potential danger in process-oriented cloud strategy.

PDM, Part Numbers and the Future of Identification

The discussion about Part Numbering and Identification was hot. I found Numbering topics are always drive a lot of discussion. There is no silver bullet that can solve the problem of Part Numbers and data identification in manufacturing companies tomorrow. Data related problems cannot be solved overnight. At the same time, application of new technologies that were developed on the web for the last 10-15 years can provide a step by step plan to solve the current “data disaster”.

My Experience with Dassault V6 PLM Cloud on Amazon

Dassault innovation on the cloud drives a lot of interest. I’ve shared my experiments mostly with n!Fuze App. Dassault Systems is definitely pioneering in the development of PLM applications on the cloud. They are probably the first mindshare PLM vendors potentially making cloud available for a mainstream. The idea is cool – you subscribe, pay money or make a trial subscription and… magic happens. The overall impression I’ve got – it is something new. There are lots of small missing pieces, which are probably normal in the first release. In my view, time is now the most critical aspect for Dassault engineers – the idea is cool, but the details are what important in Web 2.0 environment.

The Future of CAD without files?

The topic of future of file-less CAD systems is important, in my view. I think innovation will come in this space soon. I think the computing and information paradigms are shifting from file-oriented to data (and web) oriented. The initial signs are here. The speed of this movement is questionable. Manufacturing is slow changing environment and engineers are very reluctant to changes.

PDM vs. PLM: Implementation Gaps

The topic made by Fisher/Unitec blog raised main questions and active discussion. I can clearly see the gap between an organizational need to have a robust and scalable system to support product development (let’s call it PLM to be consistent with industry terminology) and maturing of PLM and PDM implementation. For me, bottom up approach makes more sense. People are trying to stay away from complexity these days. The next generation of PDM/PLM will need to take it as an axiom for a future success.

Best, Oleg


Get every new post delivered to your Inbox.

Join 290 other followers