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...
Wow, this blog took a dramatic 180° turn. Don’t worry, this is still talking about PLM and more precisely about the Fit, Form, Function (and Safety for some companies)...
When it comes to PLM, it is difficult to have a clear opinion on business models. These last few days I have seen multiple business models and pricing configuration from PLM...
I wish you all a happy new year. My blog colleagues all came up with predictions for either the coming years or like oleg and Jos, for 2030. There are some very interesting...
I just stumbled upon a video from CNBC just yesterday about the rise of Open Source. It gave me a strange reaction at first. Open source is getting bigger every day. NPM packages...
What is the language your PLM solution has been built with? It is something that barely comes up in PLM evaluation. Does it matter? I think so, but in order to know why it matters...
PLM solutions are mostly web-based nowadays. To access the main User Interface of these PLM solutions you need a web-browser. Web browers are eating 3 languages: HTML CSS...
Many years ago, I had fun creating a stopmotion video to explain what PLM is. Today I wanted to gather all the videos on youtube which actually have “what is plm” in...
Don't start a PLM project without knowing what an ETL is
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?
