Agile linkage to individual item versions

I’m relatively new to PLM and Agile.  My company is in the midst of designing our initial PLM environment using Agile 9.3.4.  I may not be articulating this well, but one struggle we are having is how Agile does not appear to manage item versions as a stand alone object. 

Example; I’d like to relate a part A which is at version 1 to document X, but then when the part A goes to version 2 I’d like a relationship to document Y.  When I model this in my Agile environment I loose the relationship to doc X when I look at the history of part A.   

Another Example;  I’d like to be able to see the attribute history of a part or document.  The attributes can be updated of course, but when I review previous versions of the part/doc, the attributes only show the latest.  The history of attributes is not easily viewed as far as I can tell.  

Has anyone else had trouble with how Agile handles versions and has a workaround been found?

Thanks

Add Comment
4 Answer(s)

Delaney – 
1- In order to tie a document to a specific part revision – I think you might find it better to Add documentX to the BOM of Part A (rev 1) instead of the Relationships tab.  
The BOM is rev specific so when you change Part A to rev 2 – you can redline the BOM to replace documentX with documentY.  These changes to the BOM will be remain tied to each revision and can be viewed by changing the rev dropdown on the part record.  To differentiate the Doc from the rest of the BOM – it is best to add the document with a quantity of zero or “REF” and to use a zero as the find num for the document so it always shows at the top of the BOM.  

2- As mentioned above – changes to the BOM are rev specific, but changes to Item Attributes are not.  The history tab will capture attribute changes, but the latest change will appear on the Title Block regardless of what rev you are viewing.

Agile Angel Answered on May 11, 2016.
Add Comment

Agreed with Danny, relating a document to the BOM of a Part is better than using the Relationship tab. You have better control over which revision the document if good on, and which ones not.
 Also, in Agile, there is no concept of “versions”. An item has revisions, and that is what is released and controls it’s information. Versions are usually considered a subset of revisions, and as such it is not supported by Agile.
 As for attribute history, you can view what has changed (and when, and by whom) in the history tab. In addition, you can make an attribute change-controlled, and so the values are stored for each revision of the part. So if you had a UoM of “KG” for rev A, and then changed it to be “Gram” for rev B, if the attribute is set as change_controlled, when you view rev A you would see “KG”, and when looking at rev B you would see “Gram”. Note that this introduces a fair amount of overhead when changing from one rev to the other, but if you only set a few attributes as change-controlled, you won’t notice.

Agile Angel Answered on May 12, 2016.

Kevin –  The ‘Change Controlled’ setting only controls whether the attribute must be modified/redlined on a change object or if it can be modified on the item record directly. I have not seen it have any impact on what is displayed on the item record.  Change Controlled or not – the latest value for the attribute is displayed regardless of what revision is selected.

There are a few Title Block attributes (like “Description”) that are Revision Controlled, but this is, unfortunately, not a configurable setting.

on May 12, 2016.
Add Comment

Thanks for the responses Danny and Kevin, very helpful to me, although I’m sure these concepts seem pretty basic to most users.

Follow-on questions.
1)  Similar to the relationship versus BOM question above.   In the BOM, I want a part X at revision 1 to reference document A at revision 1, but then I make a change.  Part X and document A each go to rev 2.  I want doc A rev 2 to be on the BOM for Part X rev 2.   How can I preserve that the rev 1’s go together and the rev 2’s go together?  It appears that when I view back in history on the part I can’t really tell what revision of the document was used at that time without drilling deeper into the dates of the changes to determine when the document revisions were active.   

thanks again.

Agile User Answered on May 12, 2016.
Add Comment

Agile is designed to follow some basic rules of item interchangeability (form, fit, and function) regarding item numbers and revisions.    When a new revision is released for an item – all BOMs that use that item are automatically updated to use the latest revision.  New revisions should be created if the revised item remains completely interchangeable in all applications with the previous iteration.  If the modified item  is not completely interchangeable to previous iterations – a new item number should be created instead.

It sounds like Doc-A (rev1) and Doc-A (rev2) are not completely interchangeable since they need to be tracked separately (tied to different items and/or revisions) –  as such, it is best practice to create a new Document that can be tied to the new part/revision.

Agile Angel Answered on May 12, 2016.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.