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.