In my previous article on Impact analysis, I talked about how important good change impact analysis is and how to facilitate this. One of the critical elements of facilitating a good change impact analysis is Re-identification.
Even though the term might suggest this, re-identification is not about changing the ID of an existing item. When you say you need to re-identify an item, basically it means that either the set of requirements have changed in such a way that interchangeability can no longer be achieved, which requires this set of requirements to be identified with a new item or that there are traceability requirements that cannot be achieved without re-identification.
Important to note: re-identification is driven from requirements.
Re-identification decision tree
Many, if not most companies will have some sort of re-identification decision tree to help in making the right decision with respect to the impact of a change to an item. Typically re-identification decision trees have two possible outcomes, namely ‘Keep using Item’ or ‘Create new Item’ or something along those lines.
But why do you need a re-identification decision tree? If you would always create a new item for every change that impacts an item, you do not need the tree. Naturally there is cost involved in creating new items instead of keep using the same item. So in essence you only need the re-identification decision tree to check if you are allowed to keep using the same item.
Meaning if there is a change and upfront the responsible team decides to re-identify without using the decision tree. This is fine. But if the team does not want to create a new item, the team must use the decision tree to verify if it is allowed to keep using the same item and not re-identify.
Why because if you do not create a new item (re-identify) and keep using the existing item, while interchangeability is compromised or there are traceability requirements that cannot be achieved without re-identification, the downstream consequences can be severe. It can result in longer down times in the field or requires full product swap instead of module swap or functionality not delivered to a customer, etc. The cost of these consequences is significantly higher than the cost of creating a new item.
Backwards or partially interchangeable
But what if the change is not fully interchangeable but can achieve backwards interchangeability, meaning you can replace an old item with a new item (not the other way around) in all applications, or what if the change is partially interchangeable because it can be used in some applications but not all? Especially for service this is important information that needs to be captured as part of the decision to create a new item.
The main advice here is: Do not to use logic in your numbering scheme but work with relationships.
Adding logic in your numbering scheme like business line or lifecycle of the part or backwards interchangeability is not a best practice. What if you assign a product to a different business line? You need a new number or accept that the logic has exceptions. I have also noticed that people find it more difficult to apply a re-identification decision tree on meaning full item IDs compared to meaningless item IDs.
Before I close, I would like to ask you a question: Who should take the decision for re-identification of an item? Let me know what you think.