From the category archives:



In my recent post about bill of materials – Bill of Materials (BOM): process or technology challenge? I touched the variety of topics related to BOM organization – multiple BOMs and need to manage BOM located in different systems. My main question at the post was around how to make the work with multiple BOMs easier? The problem is tough and the answer is not easy and straightforward. While I was googling the internet to find what others think about this problem, my attention caught TeamCenter PLM blog post – Bill of Material Lifecycle. This posts presents multiple BOMs as a result of changes in the product lifecycle – design, manufacturing, service. Here is a passage I captured:

It is interesting to discuss on BOM lifecycle and its evolution from conceptual stage to full fledge manufactured product to maintenance. In this blog I will explain through life cycle of BOM across the product life cycle done as in house development. The BOM lifecycle can varies based on overall process of company for example some company might only manufacture as order hence they As Build design BOM and they directly CREATE Manufacturing BOM from it.

All together, it made me think that concepts of data, lifecycle and process is often  can create a confusion and overlap. I want to clarify these concepts and present how they can be combined together to manage single BOM in the organization.

1- Data

Data is the most fundamental part of Bill of Materials. It combined from data about product, assemblies, parts and relationships between them. Fundamentally, assemblies and components are connected together to form the result data set representing a product. This data set can be presented in many ways – tabular, hierarchical and many other forms (eg. graph). Data about parts leads us to the place where information about product, assemblies, components, supplies and manufacturers is managed. This information can reside into one of the following systems – CAD, PDM, PLM, ERP, SCM and others.

2- Lifecycle

Lifecycle defines the difference between bill of materials of the same product, but associated with different product development periods (stages). Here is the example of some typical  stages – concept, design, manufacturing, service. However, these stages are not the same for many companies and can reflect industry, specific business practices, regulation and many other aspects. It is very important to capture relationships between Bill of Materials of the same product (assembly) in different lifecycle stages. Missing lifecycle stage connection can cause a lost of very important product lifecycle information and product development traceability. In some regulated industries such

3- Process

Process is a set of activities that defines Bill of Materials data as well as changes in a lifecycle. Sometimes process can be very informal- save of assembly and parts using design system. It will product design BOM data. However, with the complexity of product development and specific organization, some processes are including changes of data, lifecycle stages as well as people involvement. If you think about ECO process, it might change few bill of materials, lifecycle stages as well as product/part information.

What is my conclusion? The problem of bill of materials management must be separated into three distinct problems: 1/ how to create data with BOM? 2/ how to control product dev stages and differentiate the same BOM across the lifecyle; 3/ how to provide tools to manage process and people to work with data and stages. All together, the problem is complicated. However, separated into these pieces it can help you to build a strategy for your BOM management regardless on tools you are going to use. Just my thoughts…

Best, Oleg




Parts and Documents are two different objects in engineering, product development and manufacturing. While “part” usually represents physical object, “document” usually represents specification, drawing or 3D model of part. Even it it sounds obvious, Document and Part management is not an easy and simple task.

In my post – How to manage Document versions, revisions and Part numbers, I’ve been mostly speaking about the need to have separate numbers for documents and parts. I also mentioned that bad practice to use the same numbers for both document and part, can lead to significant complexity and mistakes. At the same to implement a system or multiple system to manage Documents and Parts is complicated. Below I described potential three typical configurations you may find in companies related to document and parts management.


Even PDM is not very new technology, you can still see many companies that not using PDM. If this is a case, you have a good chance to see documents (CAD and non-CAD) spread out in the network and shared drives. Without centralized document management system, a company is creating numbering convention how to provide document numbers. A good chance that you will see lots of Excel spreadsheets to be used for Parts and BOM management. Very often, a company will be using similar number convention for parts and mix it together with usage of OEM and supplier part numbers. You can also see homegrown system to manage Part Numbers in a separate database.


This is very typical situation where engineering and manufacturing are splitting responsibilities into silos. Engineering department is using PDM system (very often from the same vendor as CAD system) and manufacturing (as well as rest of the company) is using ERP system. Within this schema, PDM system is taking control of documents. Document numbers usually generated by PDM system according to predefined naming convention. Item masters and parts are managed by ERP. The complexity of this model is to link between documents in PDM system and parts/BOMs in ERP system. In most of the cases, the integration between them is manual or using batch import/ export procedures. Optionally, PDM system can manage parts (typically engineering parts).


It is not unusual to see both PDM and PLM systems co-exit in the same company. Similar configuration can be achieved by combination of PLM and ERP system. In the last case, PDM module is part of broader PLM offering. The specific characteristic of this type of environment is management of parts and engineering BOMs in PLM system. Sometimes, you can see PLM systems is responsible also for manufacturing BOM management. This configuration provides the most consistent way to interlink between Documents and Parts. Both numbers are available in PLM system which can use them. The weak part of this configuration is complexity of integration between PDM/PLM and ERP. Synchronization of Part Numbers and Document Numbers among all systems is a challenge that may potentially lead to data inconsistency.

What is my conclusion? The information about documents and parts is located across organizational departments and systems. At the same time, to manage them in a consistent way is very important. Regardless on the number of systems and the way to manage Document Numbers and Part Numbers to keep them separate and maintain linkage between them is the first priority. Just my thoughts…

Best, Oleg




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



PLM and Magic of MBOM planning

January 21, 2014

Manufacturing BOM (MBOM) is an interesting topic. After all design and engineering operation,  MBOM defines how product is going to be actually manufactured. While most of PLM / ERP debates about MBOM are going around “who owns what”, the most fascinating part that I found in MBOM is related to the nature of manufacturing planning. The […]

Read the full article →

Holidays, PLM Education and Free Math Books

December 25, 2013

Holidays is a time for gifts. I remember a sentence that stuck in my memory from my childhood – book is the best gift. I didn’t find documented confirmation, but I think this statement goes back to Gutenberg era. Back that time, books were very expensive and it was a very valuable gift. Well, nowadays […]

Read the full article →

The Ugly Truth of Multi-BOM Management

December 17, 2013

Bill of Material (BOM) management is always fascinating topic. It sparks so many debates and introduce a large set of diverse opinions. I can even say that I have a special passion to speak about BOM on my blog. If you want to catch up on my recent posts about BOM, you can try these […]

Read the full article →

Why PLM should not think about ownership?

October 10, 2013

Enterprise software business is complicated. It often comes with questions of system responsibilities and ownerships. IT usually holds primarily responsibility for cross company software stack. At the same time, divisions and departments often try to influence IT and make their own decision related to what software to use independently. One of the terms came out […]

Read the full article →

BOM: Apple of Discord between PLM and ERP?

September 17, 2013

BOM Management. Multiple BOM Views. These topic are always drives lots of discussion in a real life and online. There is no question about importance of BOM in product development, engineering, manufacturing… Literally, you cannot do anything without Bill of Materials. Few weeks ago, I came with the topic that generated a very good and […]

Read the full article →

CAD and Design Interaction: 50 years in 3 videos

September 6, 2013

My father was engineer. As a child, I’ve been coming to my dad’s office to watch how engineers designed metallurgical plants and heavy industrial machines. Back that days, the design was all about drawing boards and paper. Fast forward in our days. Lots of things changed. Our design interaction is not with a paper anymore. […]

Read the full article →

PDM 101: Engineering Document Management Fallacy

August 30, 2013

We love new technologies and trends. However, from time to time, I want to get back to basic topics of engineering and manufacturing software. The topic I’d like to discuss today is Engineering Document Management (EDM). This post was triggered by DM vs. EDM article by Scott Cleveland on 2PLM letter. Here is the passage Scott […]

Read the full article →