milanschuurmans - Thursday, September 17, 2009 10:06 AM:
Hi all, i'm new to ARAS Innovator and I'm trying to find out how stuff works and I'm running into some questionmarks for the change process on exisitng, released structures. I've noticed that an ECN change on a lower level part in a BOM structure doesn't mean the relation to the parent part changes to teh new part revision, but rather points to the old, superseded revision. Tutorioals say, I need to revise the Parent part t also, and manually change the relation to the new revision, but I cannot see where the ECN will phade out? If I need to revise all the parents of revised parts, I would have to revise ALL parent Parts all the way up to the top-level assembly. This would mean, the ECN doesn't phade out, where I expect that this will have to be the case in a real-time situation. maybe I am doing somethin wrong so I would like to get some help/pointers.
My situation is as follows:
I have a BOM structure, multiple levels deep and I want to change a part component which is located at the lowest level of my BOM. In order to do this, I create an ECN, connect the Part Component as affected Item with action revise. The revise is interachangeable since I want to simulate an administrative change and not a physical change. When I complete the ECN, I see that the part component is revised and released and the old revision is superseded, which is behaviour as I expected..
However...
My Released BOM structure is still pointing at the superseded revision of my Part component, where I expected it to point to the new released revision. I simulated an administartive change, so the form-fit-function of my part component is unaffected and so are all parent parts. With what I know now, i would have to rveise teh partent part in teh same ECN and manually change the parent child reation to the new revision, but since I have also revised the parent part now, I would have to revise its parent part also and so on... Teh ECN never phades out untill teh top level part...
Ron - Thursday, September 17, 2009 10:31 AM:
If I am not mistaken, the default behavior of Innovator part life cycle is Fix, meaning that the item in a released state will always point to the version of the children at the time of release. In order for the item to be updated you would need to include all the where used items of the affected part in your ECN. or you can change the lifecycle of parts to use Float at the Release state.
You will want to have a full understanding of how Float vs Fix relationships works before you make your decision on which method to use, both have their pros and cons. I used a different schema where I fixed the item at the Supersede state (snap shot of the configuration for historic purpose).
Hope this helps
milanschuurmans - Thursday, September 17, 2009 11:10 AM:
Correct me if I am wrong, but if I have to include the where used (parent) Part also, this would mean I am revising that parent part also. In that case, the parent of the parent Part will be pointing at a superseded revision also. In that case I am just moving my issue to a higher level in my BOM structure and I still have a released part, pointing at a superseded part which has a newer, released revision. To solve this, I would have to revise the whole structure above the initial afected item, which means my ECN doens't 'damp out'. Since my initial change is just an administrative one which doesn't affect the form fit function in any matter, it seems sensless to me to revise anything else but the initial item and leave the rest of the BOM structure as is. eg. this means that the ECN 'damps out' on the initial part and only affects that initial part.
In case a change is of a physical matter, I am used to a situation where the engineers make the decision on which parts are affected in their form-fit function and they are the ones who are responsible to include only the affected parts in the ECN. eg. They decide on which parent part the ECN 'damps out'.
As you may understand, I don't want any released part pointing to a superseded part which have newer, released revisions, so I would like to have the system shift the BOM releationship to the released part automatically. For snapshots, I prefer effectivity dates and otherwise people can still trace back on how the structure was by looking at the 'revised' history date and time of parts.
btw I have taken a look at the relationship 'Part BOM' and the out-of-the-box configuration says it is 'floating' but I don't see the "floating" behaviour. Maybe it's just a bug? I am working with version 9.1.0 build 5488.
Ron - Thursday, September 17, 2009 11:40 AM:
You are correct in your assumptions, for every affected item you must do a where used to see what is affected and each affected item gets rev'ed up. Some compaines will use major minor revision schema to handle this. but it does put a bit more work on the Change specilist.
The fixed vs float I wa talking about is on the Part default Lifecycle Map, if you look at the Part Lifecycle map and click on Released icon you will see it's Item behavior = Fixed. You can change this to float, but your history will be gone.. If you were to look back in time to a different effective date and opened the item, the BOM items would be pointing to the latest and greatest versions. This is why I changed the Superseded state from Float to Fixed, thus allowing the historic history, of course this will only work on items we deemed important to track. If a lower item is changed and we do not include it's parent part or the parents parent part in the ECN the change will not be recorded in the upper levels (ie they will always float to the newest version). Works for us.
milanschuurmans - Friday, September 18, 2009 5:36 AM:
I've checked the floating vs. fixed setting, but I've just set the 'Part BOM' relationship on 'Hard Float' so it would not be overruled by teh Lifecycle map. Again, i got some behaviour which I was not hoping for; as soon as my child part got his new revision in preliminary state, it already got its relationship to the parent part. Now, i am facing a situation where I have unreleased parts in my released BOM structure instead of superseded parts...
Anyway, with your last reply yesterday and my checking out today, I see this is just the behaviour of ARAS innovator and I was just expecting something that isn't there. In my opinion, a BOM relationship should have one 'current', 'pending' and some 'historical' instances to point to the currently related part, the preliminary part that will become related after it is released (if any) , and the formerly related parts that are now superseded (which are still related for baselining purposes of course). ARAS doesn't support a way of working like this (yet?) so I must admit I am a bit dissapointed at this.
My uestions are answered anyway, so I have to thank you for your quick and clear responses. You've saved me a lot of time trying to figure stuff out. Maybe untill the next forum topic! :-D
Brian - Tuesday, September 22, 2009 8:28 PM:
I went through a similar process when I first started investigating Innovator with a similar set of questions. After some discussion and investigation on Revisions for parts came to the conclusion that parts do not have an intrinsic revision and that the nominal Revision of a part (or assembly) is the collection of released documents which make it up at that point in time (moving baseline).
By definition a revision for a part should be Interchangeable in Form/Fit/Function as you have already indicated. So it shouldn't matter which revision of a part/assembly someone is working with and the revision should not be (should not have to be) marked on the part or assembly since it shouldn't matter.
If the change results in a failure on the Interchangeability test then it really should be a new part number anyway.
If you accept this basic idea then it doesn't matter that the revision changes "rattle up" to the top level assembly since it is not a reported piece of data. In fact it ultimately should give you better traceability from the finished item to the actual product configuration that makes it up. It does mean that you have to track finished products by serial number or batch number and make sure you can relate these to a nominal Revision of the final product so that you can see all of the documents which make it up.
The out of the box functionality for Innovator follows the recommendations made for a CMII process.
Regards,
Brian
