Filter by Category
Filter by Author
Now that we have seen the most simple change in my previous blog post, let’s talk about the revision mechanical engineers will hate : THE NON-INTERCHANGEABLE REVISION !!!...
On my french blog I wrote a blog post about some suggestions for a flexible configuration management solution. I’ll reproduce the article in English soon for a broader...
Now that we have seen the most simple change in my previous blog post, let’s talk about the revision mechanical engineers will hate : THE NON-INTERCHANGEABLE REVISION !!!
A non-interchangeable revision is an evolution of an item which will replace the previous revision and for which there is enough change that any assembly or container consuming this item will be impacted. Anyone managing an assembly containing this part will have to take a decision to either decide that the impact is limited and their assembly can just be “interchangeably revised” or they would have to either have a renumber or or non-interchangeable revision again.
Same example as in the previous blog post, we have a released structure. Each node has a name (A,B,C,D,…) and a 2-digit version number (x.y).
In my previous blog post I had a question about the R node. So let’s try to better explain what is happening in this step.
The fact that R is consuming C2.0 and not C1.0 can be discussed and it is mainly a choice that should be left to the the manager of R. If this person knows it’s going to take a year to release C2 and the design of R is ready for release with C1, than they may want to use the already released version knowing that it might be superseded soon. In our example we believe the manager of R wants to work on the coming revision 2.0 of C.
Now the conclusion of this revision. Let say, you did your impact analysis but didn’t take any decision on which assembly to impact. You move forward with the release of the new revision and consequently supersed the previous one which should not be used anymore.
Now, what should happen is an marker, like a flag on any assembly consuming the previous revision (we named it obsoFlag). It should represent the fact that you have a released assembly containing a superseded part. If you were to send this to an ERP for production it should be blocked (But this doesn’t mean that something sent to the ERP prior to the revision should be block).
The good thing about a non-interchangeable revision is that every assembly consuming the changed item will be noticed. So there should be no risk of human-based decision on a change which could change the behavior of your product.
The issue that I believe mechanical engineers will raise (and that’s why I believe we could have both options) is that for every revision you have to take actions on all the impacted items.
Combining interchangeable and non-interchangeable revision allows to have best of both worlds and re-conciliate different engineering fields. what is your take on this?
