It’s about Interchangeability and Traceability

It's about Interchangeability & Traceability

On 6 February 2020 Oleg Shilovitsky posted the article: What Should Trigger BOM Revision? Where he wrote: 

“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.”
AND

“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.”

My assumption is that you put parts on stock based on the part number and not the revision. If would put parts on stock based on part number and revision, the revision is no longer a revision, but becomes part of the part number. A good example of how not to control changes to parts is given by Joseph Anderson from IpX in this video that was recorded during the ConX19 event in San Diego: What is the ROI?:
Now coming back to the quotes of Oleg. If you change a component, and after the change it remains fully interchangeable and you can achieve your traceability requirements without changing the part number, you can just revise the documentation of the component, you do not even need to revise the parent assembly.

However if you change a component, and after the change it is no longer fully interchangeable and you cannot restore interchangeability, you need to issue a new part number for that component. Why? Because you need to be able to keep them apart and while revising the documentation alone, will allow you to keep the design history, you lose traceability when the parts get made and flow downstream. When you change the part number of the component, you by definition have to revise the Bill of Material of the parent assembly and maybe, depending on the change, you even need to issue a new part number for the parent assembly as well and you continue doing so until interchangeability has been achieved and you can achieve your requirements for traceability without changing the part number.

FFF (Form, Fit, Function) criteria, while important, are not sufficient to determine if you need to issue a new part number or not. In my previous post Re-Identification, I explain why a Re-Identification decision tree is an important tool for companies to assess the impact of a change and that interchangeability and traceability are the key criteria for making a re-identification decision, where FFF are a subset of the interchangeability criteria. 

Also in the comments of Oleg’s article, Dick Terleth is clear about this:

“However, FFF defines exchangeability of a component (and assembly) before and after a change has been applied. Using FFF only during development and engineering phase you might end up with a lot of new partnumbers, that might never have been nor will be manufactured.  There are some additional questions to answer, even when FFF criteria are not met. Questions like: has the part been produced one or more times? Will we be able to retrofit new parts in all delivered units? (and will that be done??). Is the part a spare part, can it be seperately ordered? So, in some cases we can use the same part (and assy) number without assigning new identifiers.”

Re-Identification/Interchangeability assessment

Where can you find information on re-identification/interchangeability assessment? Please check out the following sources:

The Institute for Process Excellence (IpX) has excellent training material and a very good re-identification decision tree. So consider signing up for one of their public courses.

Frank B. Watts wrote a good book: ENGINEERING DOCUMENTATION CONTROL HANDBOOK, Configuration Management, Second Edition, which describes interchangeability in chapter 4. There is a newer edition, but I have not assessed the new content yet. But in any case the best advice by Frank. B. Watts gave in his book on this topic is: “When in doubt, change the part number”. As this is always the safest decision. That does not mean you should not use a decision tree, but sometimes when the answer isn’t obvious or there are different opinions, changing the part number is the way to go.

Also Jörg Eisenträger has created a decision tree to assess interchangeability, which is a good starting point. Although one important aspect is missing for me, which also came up during the review I did last year of the second edition of the book Configuration Management: Theory and Application for Engineers, Managers, and Practitioners, by Jon Quigley and Kim Robertson.

This comment regarding re-identification even ended up as a quote:

“What is often forgotten is that while form, fit and function (FFF) still applies, there are changes to the way service has to deal with the part. This is something that is not seen if you let the design engineer make re-identification decisions where manufacturing engineers or service engineers have a better view on these types of things. Next to that traceability is often overlooked in re-identification decisions. For instance, the need to re-identify a part because you need traceability that otherwise cannot be ensured. “

Even if items remain fully interchangeable after implementation of a change, it is not necessary the case that they can be used without modification to the instructions in the field. For instance if some of the components in a buy assembly are now glued instead of bolted together, while the form, fit and function of the assembly itself is still intact, can still require changes for the service engineers, that have to perform repairs to that assembly.

Can you automate the re-identification decision?

Finally, in one of the comments of What Should Trigger BOM Revision?, Oleg asks whether it would be possible if you could automate such a re-identification decision?

Short answer: No, but you can help people during the impact assessment.

What does this mean. First a decision if a change requires a new part number, is not one that can only be taken by a design/development engineer. There are traceability requirements and field service requirements, that cannot be solely answered by an engineer and requires input from people with a supply chain, manufacturing and service background.

Also the question if you can restore interchangeability by rework or scrapping the old parts, requires input from your supply chain, as you need to know where these parts currently reside and if you can find them and in a controlled way scrap or rework them.

Next to the fact that it requires a very good registration of your actual configurations in the field and an accurate overview of all stock, assessing the impact of a change to understand how it impacts the requirements of a part, is something current state of AI is not able to do. Maybe in the future, but there are other challenges here as well, same as with a fully autonomous car like potential legal ramifications, if you such an AI would make a mistake and as a result somebody gets hurt or even worse, killed.

However an AI can help in assessing potential impact. The I4.0 Committee of the IPX Congress is looking into possible use cases and will publish articles in the course of this year.

History of interchangeable parts

And for those of you who like to understand the history of interchangeable parts have a look at these 2 posts:

230 Years of Interchangeable Parts – A Brief History” by Christoph Roser

Review of “Engineering the Revolution” by Ken Alder” by Michel Baudin

Header picture By Christoph Roser at AllAboutLean.com under the free CC-BY-SA 4.0 license.

4 thoughts on “It’s about Interchangeability and Traceability”

  1. Thx for your article,
    I still don’t have a clear understanding of how revision should be handled. Years ago, before we all went part-centric. The document was something that would get more revisions. For example, the quality of some processed materials you purchase is not good therefor you are revising some tolerances on your drawing. You didn’t really want to update the part, “just the tolerance” and you believe it’s FFF and keep going. Same for some surface treatment, there was a missing info for some manufacturer, you add it and it’s FFF so you don’t change the part revision, just the doc sent to your supplier.
    What are the change examples that might be FFF for a Part change (not just the drawing)? To me, FFF is trying to avoid complexity. The more complex the product is, the more dangerous every FFF decision will be. I believe there is a better system.
    I’ve read Engineering Documentation Control Handbook, and I don’t get a clear answer. I believe there should be a correct answer. As long as we don’t have clear rules we’ll still have issues like this GM case : https://www.nbcnews.com/storyline/gm-recall/document-gm-engineer-ok-d-no-new-part-number-ignition-n78566

    1. @Yoann Maingon. Thanks for your comment.
      I know PLM systems have revisions on parts. However this confuses a lot of people, because you do not have different stock locations for the same part number with different revisions. IpX’s CM2 methodology is also clear about this. Parts do not have revisions, only documents have revisions.
      The reason for a part revision in a PLM system is because it contains the Bill of Material (a dataset or document if you will). So when do you need to rev a part? Simply when you need to change the Bill of Material or when you add or remove a document (because often times also the relationship to documents is managed via the part revision). But the big question is does the change to the bill of material result in a interchangeable part? If not, revising is not an option, you need a new part number if yes, then a rev of a part (BoM) is sufficient. I hope this answer helps.

      1. Coming back to this after I finalized watching J. Anderson speech.
        The real issue here is the document itself. The document is a Blob with lots of different information not classified seen from a document versioning system. If I’m adding a constrain, or changing a manufacturing process info, or a changing a BOM quantity from 5 to as-required. If these elements appear in a same drawing they could all have the same impact on versioning.
        If these data were not drowned in a document, but classified as data elements in a database, we could more precisely define which type of information has which type of impact. I might be a bit harsh on this opinion but I believe that a lot of material from configuration management is outdated because of the document Blob.
        I believe cm2 gathers some great practices for those who are still document-centric despite having a more granular PLM system.

        1. I do not agree with the assumption that CM2 is document-centric. Yes for CM you need to identify impacted datasets (a set of information stored in digital or physical form that must be released as a whole and can be released separately from other knowledge artifacts) to be able to estimate cost of a change and to be able to plan deliverables for implementation of the change. However CM2 also explains that information needs to be structured linked and owned, while not all of the objects and linkages are part of the CM level impact analysis, these are important for the experts in the expertise domains that have to assess the impact of a change and in the end create or update this information. See also https://www.mdux.net/we-need-a-cross-platform-interface-for-impact-analysis/ where I highlight the difference between the different levels of dealing with information. You do not plan the update of a single bomline, you plan the update of a BOM. But the expert needs to know exactly what the change will be. However for planning the change typically knowing you need to update a BOM, a 3D model, a test plan, a process plan is the enough to estimate the amount of work and cost involved. But for execution of the work and for understanding the solution needed, it is critical that you need more than just a dataset. You need both and a PLM system needs to support both. The following article might also shed some more light on the different levels: https://www.mdux.net/a-glimpse-into-the-future-of-cm/

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept the Privacy Policy

This site uses Akismet to reduce spam. Learn how your comment data is processed.