In the last days of 2023, Martin Eigner posted about Form, Fit, and Function and one of the topics in there was the revisions of Parts. I thought about adding my comment, but it was difficult to capture everything in a short comment. So with this post, I try to provide my insights into the topic, which will be a rewrite of an existing post from a couple of years ago: HELP!!! Parts, Documents, Data & Revisions. And if you want to learn more about part re-identification, please check out the book I released last year The Essential Guide to Part Re-Identification.
Parts and revisions
I think we can all agree, and even most experts, professional literature, and standards are clear on this: Parts do not have revisions. As stated on buyplm.com:
One part number = one bin location. Revision is irrelevant.
I also liked this comment from Peter Ebbesmeyer on the post from Martin Eigner:
If parts are revised the revision should also be managed in the entire end-to-end process in addition to the part number. As a result, all revisions of a part would have to be kept in stock in the spare parts business. In my opinion, this would make logistics considerably more complex. Peter Ebbesmeyer on LinkedIn
So why do PLM tools have revisions for parts?
Well in many PLM tools, some of the metadata is stored on the revision of the part and also the Bill of Material and relations to documents and other objects depart from the revision of the part.
So what does this mean? Does a part have a revision or not?
Look at it this way: A part number is a reference to a thing in the ‘physical’ world. Parts are described by datasets. Datasets can be documents or structured data and datasets have revisions.
Dataset: A set of information stored in digital or physical form that must be released as a whole and can be released separately from other datasets.
The problem though is that, in a lot of systems, not each dataset is uniquely identified and does not carry its own revision. To efficiently change part documentation, it is required that each dataset has its own number and revision for it to have its own life cycle. That means the Bill of Material, CAD Model, and the metadata of a part must have their own number and revision, which is oftentimes not the case.
Three Different solutions to revise a BoM
ERP solutions typically have a different kind of model to deal with the BoM. The validity of a BoM line is managed as a from/to date a.k.a. a start/end date. Over time you will have all BoM lines linked to the parent part directly. One of the reasons for this is that phasing out the old and phasing in the new part will take time. For instance, you might still have stock of the old part and the implementation strategy is to use up the old stock first before phasing in the new part. To enable this both the old and new parts need to be in the BoM and a phase-in/out date is added to manage the transition.
The CM2 solution is based on the concept that parts do not have revisions, only datasets have revisions. That means that like any dataset, the BoM is represented as a separate object with its own revisions. As also shown in the below conceptual model:
As you can see in this data model, parts do not have revisions, but all the datasets do have revisions. I even separated the CAD part from the part itself. This allows the evolution of parts like P2 being superseded by P4, which is captured by the same CAD Part dataset but a different revision of that dataset. I can now for instance change the metadata of part P1, without having to revise the BoM (Bill of Material). That does not mean you can only solve this through a data model, but this is a way to do it.
Conclusion
I do not believe there is one right solution for everything. It depends on the particular use case. I’m an advocate of having both the CM2 solution and the ERP solution as the gold standards which will cover most use cases. Note that in the CM2 Baseline, a.k.a. as-planned/as-released baseline, the BoMs are used as a hierarchy for the product documentation and the Baseline will use the ERP concept with from and to dates to show this hierarchy.
The common PDM/PLM solution is not preferred as it combines different types of information into one revision, creating ambiguity about what has changed. Which is by definition a bad practice, and it also makes planning changes to documentation more difficult. A BoM change typically requires to be done first as it needs to be communicated to ERP for generating the planned orders. Other documentation of the same part can be delivered a little later. In the PDM/PLM solution either you have to do it all at once or release multiple revisions of the same part. Having that flexibility is important.
Header Photo by Photo by Chris Lawton on Unsplash
Outstanding explanation and examples on the discussion of revisions on parts. Thank you.
Pingback: Precise Bill of Materials Don't Exist - MDUX
Good article summing up the various schemes. I am curious what your take is on how modern PLMs deal with enterprise data. Classic PLM has each department/domain rally around the “Part”, which is that data collector you mentioned. Modern PLM tends to separate these and connect them rather than unify into the single part object. The manufacturing item is connected to the engineering item but has it’s own data structure and revision as that department may change their mind about the details of making it. In this case, a change would have a ripple effect to the downstream data. Example: Do I need to add an operation due to the new revision?
On to the assembly, how to incorporate the new revision? In a multi-department/domain world the engineering definition of the BOM may differ from the manufacturing. Can we assume that revisions just float? Is the only alternative that you revise both all the way up from seat to battleship? How are any connections across the two domains/departments handled in such case?
CAD is also interesting. A revision of a part may cause the assembly that calls it in to fail in mating conditions. In this case the data in the revision may be different enough to cause problems, suggesting a need for more precision to revision rather than less. Since CAD is many times the basis for the BOM this seems relevant. If the CAD is revised or the drawing based on CAD need a change how does this relate to the Part or BOM of the Part,
My sense is that a configured approach based on effectivity, not new revision objects is the way to do this going forward. It can handle the revision or reidentification with a similar lower cost of incorporation while keeping separate but connected multi-domain structures in sync (digital thread). The upper levels of a BOM are handled by a “Part” object but are they really “Parts”? My sense is they are really objects meant to manage the configuration of a combination of children. A configured (150%) approach does the same thing without much of the downside.
I am curious what you think on this.
Thanks for your comment Jeff. I think there a different layers of data models. On a business layer a part is always a part regardless if you look it from Engineering or Manufacturing perspective. However in PLM and ERP you will implement these with different objects that have their own data associated. And that is all fine. But a item in PLM and a material in SAP that share the same Part nr. Are just representations of the same Part. Check also this post: https://mdux.net/understanding-the-impact-of-changes/.
When you revise your CAD and your mating conditions fail you should have re-identified the Part. I wrote an entire book on that topic but here is here you can find the re-identification tree from the booK: https://mdux.net/part-re-identification-it-is-not-about-the-tree/
When it comes to the 150% concept, there are many different flavors and while they do add benefits there are also downsides. Managing a 150% CAD structure requires you to use configuration rules in CAD and very well established interface agreements. This is not something easily implemented in an organization that is not used to this. Moving to this concept requires planning and making small iterations.
Pingback: The Future of CM - Achievements - 2024 - MDUX
We’re planning a design in which all datasets will be independently revised with given effective dates. The new dataset revision will replace the older revision on all the parts that reference it. We will have to do some custom work to make this possible, as the PLM software does not allow for this functionality. We will also have to build a custom report (and possibly a custom view) to get the BoM resolution for a given date based on the effective dates of all the parts and datasets in a product structure.