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.
