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 246 other followers