A blog by Oleg Shilovitsky
Information & Comments about Engineering and Manufacturing Software

What Should Trigger BOM Revision?

What Should Trigger BOM Revision?
Oleg
Oleg
5 February, 2020 | 3 min for reading

Change management is one of the fundamental elements of product lifecycle control. In a nutshell, it is all about changes. And when you do changes, you would like the system to track it and provide a way to differentiate between different revisions.

The topic seems to be so obvious, so you would expect companies to figure out it a long time ago. Unfortunately, it is not that simple and I’m getting questions about how to track revisions of products (BOM) and Items (Assemblies and Parts) all the time. Here is one of the latest questions coming from one of my readers:

Do you have any specific thoughts on what should trigger BOM revision and what should not? I have found that companies struggle with this definition all the time

The best advice I ever heard is “don’t revise the ship when you revise the toilet seat”. It says all you need to know. But the devil is in details. If you will be revising upper-level assemblies each time you make revisions of the components, you would be never stopping and you will be swamped in the changes.

Today, I want to give you some ideas about revision management in the Bill of Materials. I will not be using any system examples. My goal is to give yo a common sense of revision management rather than focus on specific PLM or ERP system implementation.

New component revision

It all starts with components and their revisions. As the design is moving forward or changes are happening, the revision of a component will change. There are different approaches in managing revisions – some include major and minor classification. Some others apply FFF (form, fit and function) criteria. Regardless of what approach you take, you end up with the collection of component (item) revisions.

A new revision of the assembly

This is one of the key questions, you need to answer. Despite the simplicity, this question represents so many different activities. If you always do, you will be swamped by tons of changes and a waterfall of documentation updates. If you don’t, you can miss some important change and it will lead to incompatibility, mistakes, and delays.

To change the upper assembly revision or not, this is a question. The rule I recommend you to follow is base on the FFF criteria and need to differentiate between two assemblies using components before and after. If the difference is not impacting its Form, Fit or Function, then you should not roll the revision of the upper assembly. And if yes, then revision of the assembly goes up. And you should apply the same decision up and up and up.

Where used and Impact Graph

One of the most important services you need to have when working with assembly and component revisions are to be able to fine all usages of the item in the product structure. In other words, you navigate the product graph upstream from sub-levels to upper levels and collect the impact analysis graph.

Regulation and impact graph

Regulatory complaisance plays a huge role in product design and manufacturing these days. The rules are so complicated that you cannot literally figure out if the product you design and manufacturing are compliant and what means some component changes. Therefore to have an intersection of these two graphs – revisions and regulatory compliance is extremely important.

What is my conclusion? Revision mechanism is an important element of data management infrastructure for product development. To have clear defined rules on what is the revision level, how revisions are changed in structures and how it is intertwined with manufacturing and procurement is extremely important for efficient production planning and manufacturing. Just my thoughts…

Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing cloud-based bill of materials and inventory management tool for manufacturing companies, hardware startups, and supply chain. My opinion can be unintentionally biased.

Recent Posts

Also on BeyondPLM

4 6
11 May, 2019

I missed CIMdata Industry Forum this year in Ann Arbor. So, I’m catching up these days on the topic of...

11 January, 2011

I had a chance to watch Jason Green’s video interview by TechCrunchTV Sarah Lacy. Take a time, watch and make an...

15 April, 2020

Do you know what’s Conway’s Law? I didn’t… Until last week. I was learning how organizational structure can impact the...

26 May, 2016

Cloud is one of the top trending topics in PLM space. After initial resistance, all PLM vendors are currently supporting...

9 December, 2017

My attention was caught by the following tweet coming from PTC CEO Jim Hepplemann: When I co-founded Windchill nearly 20...

4 September, 2013

Data vs. Process. The egg or chicken of PLM industry. This topic is  near and dear to many people in...

15 November, 2011

Process vs. Data. I think, this topic not requires a special introduction. In my view, every PLM implementation is facing...

20 February, 2022

In the world of business, technology is ever-evolving. With new advancements in software and hardware, businesses are able to operate...

16 December, 2016

One size doesn’t fit all. It is hard to standardize enterprise software. Engineers are always in a disagreement how to...

Blogroll

To the top