My simple question What should trigger BOM revision triggered a bloodbath of debates about FFF (form, fit and function) and turned out to be a very interesting conversation. Check out these articles – Has FFF killed and What the FFF happening? Jos’ article has a great list of references to the article and CM standards. If you need them one day- this is a place to go.
The debates came at no surprise. Besides terminological complexity, which I will address later, the topic itself is not complex to grasp. Change is a fundamental part of any product development activity. To believe that you can eliminate the changes would be very naive. So, changes will happen and should be managed.
One of the most widely used terms in the context of changes is revision. In a nutshell, it is referring to an attribute that can be used to distinguish one state from another state. It can be applied to software, hardware, documents, etc. For example, you can find a very powerful mechanism of revision queries in GIT tool used for software configuration management. Outside of software configuration management, revision is used in different tools such as document control, MRP and others. In a very broad sense, revision represents a change. Sometimes as a snapshot or description of changes (depending on what tool you use).
Another term that also used in the same context is version. I can see some downtrend in the usage of version compared to revision. In various tools, version term is often applied to documents or files (both CAD and non-CAD). In software, a version is used as a characteristic of files (eg. 1.43.223). In CAD/PDM software version can be a label or specific mark indicating some changes. The debates about the usage of versions vs revisions are endless. I’m not going to judge tools or people as well as trying to bring best practices.
I can see two aspects of the debates about change management and FFF. – (1) how to capture changes and (2) when to make a change. In this article, I mostly focused on the first one- how to capture and manage changes. Unfortunately, I can see how these two aspects mixed to create some change management spaghetti. Let’s clarify it a bit.
Revisions and Part Numbers
Part and Part Number is a universal way to represent anything in manufacturing. There are different types of parts, but commonly you can see them as standard parts and engineering parts. The classification can work for a single company, but when you look outside of the single company context, they might overlap. In such a way an electrical motor purchased by one company can be a standard Part Number, while for a a company manufacturing electrical motor it can be engineering part.
There is a need to distinguish between 2 states of data describing a product (Part Number). A simple way to do it by labeling them with Rev1 and Rev2. Depending on the stage and context, revision might be visible or not visible, but it will be there. The usage or revision will be different, but it will be there. As a company purchasing electrical motor, you might reference it by Part Number, but as a company manufacturing electrical motors, you will have revisions of the same motor referred to in the system tracking data and helping to distinguish between changes.
Revision and Bill of Materials
Each part might have a bill of materials. It is a recipe of what you do. Depends on the system, the bill of materials can be tracked and important or not. It is related to part types – standard, engineering, purchased, etc. If you purchase a part assembled by somebody else, you might not need to know about its Bill of Materials. But if you develop it, you should have it. Think about PCBA development process by contract manufacturing. A manufacturing company should be able to manage revisions of PCBA and be able to distinguish between each revision when communicating with CMs.
Bill of Materials (or Product Structures) are complex data sets, but in a nutshell Bill of Materials Management systems such as PDM, PLM or MRP, should be able to distinguish between two revisions. I will address BOM revisions separately, but for the purpose of this discussion suggest agree that Bill of Materials with Part Number might have multiple revisions and software should be able to differentiate between these two states.
Bill of Materials and Documentation
Bill of Materials (or Recipe in process development) is related to documentation. These relationships are complex because (1) they can be changed independently; (2) there are specific rules that can be applied to these changes. Companies are often struggling with these changes because these rules dictate what companies should do when changes are happening. Eg. Part can be changed, but the document should not reflect the change. Or the opposite – the document is changed, but Part remains the same. Tons of debates about how to manage it are reflected in the FFF articles I mentioned above.
Best Practices, Vendors, and Consultants
I love and hate this term. Best practices are used by software vendors to apply some methodology or processes embedded in the software. At the same time, industry consultants are using this term to sell their recommendations and provide it as a service to manufacturing companies. Now think about multiple vendors, manufacturing companies and consultants all together, mix it with standards and you will get a status quo of FFF debates.
What is my conclusion?
Revision is a fundamental mechanism to distinguish between two states of the data. Software configuration management tools made huge progress in the way changes can be managed during the development. PDM, PLM and ERP tools are still behind in the robustness of how data and changes can be managed. PDM tools do it for CAD files. MRP tools might have decent BOM and revision capabilities for production. PLM’s attempt to manage all these things together is still to complex for most of the companies. Companies are struggling with creating a well defined and simple process.
My recommendation for manufacturing companies is to define some ground rules for configuration management (including change management). Try to stay as simple as you can, but not simpler. For vendors, my recommendation to provide a flexible way to manage data and the process. Flexibility is a key, otherwise, you are dead in a bloodbath of debates about how your software can be used. And for consultants, my recommendation is to provide value to your customers in helping to navigate between best practices, customer requirements, and software capabilities.
Just my thoughts…
Best, 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.
