Version/Iteration Control on Change Objects

[mbonitati]

Could there be version/iteration control on CNs/variances.  It is a bit confusing to users where if you searched for a change object or even looked within the product's changes folders, you would see the change object's version (ex, 1.1, 2.1).  Yet within the actual change object there is no iteration. If version/iteration control is not offered on change objects, why do you display it as a Version on searches and folders?

What we were looking is the ability to iterate change objects (CN123456 Rev 1.1, Rev 1.2, Rev 1.3, etc.).  Our users are concerned about the after submission and during routed approvals of change objects (but not yet approved) where changes may have to go back to rework (due to reviewers/customers comments).  The customer states they can't really tell what changed since the CN doesn't iterate.  They want some way to distinguish that there have been updates to the change object.  Yes you can put comments on the object that you updated it but if you were to resubmit the CN (for example) to the customer there is no indication on the CN or its history that it has been modified/updated. (For example on documents, during the review cycle, when you add attachments and make changes the document iterates until such time that you release it (Doc 123456 Rev A.1, A.2, A.3).  Once it is released, you would then revise the document. (Doc 123456 Rev B.1)). Our users/customers would like the same concept for change objects (CN123456 Rev 1.1, 1.2, 1.3) and then once it is approved you would revise the change object (CN123456 Rev 2.1).

Hopefully it could be flexible enough that if some of your customers want to keep things as they are (Revisions only) there would be a preference to do that.

[STEVEG]

The Version doesn't show for me in either the search results or the Changes folder.  I'm on 10.1 M050.  Is this in 10.2?

[JimTVancouverCa]

Is this affected in any way by the preference that controls whether change objects can be revised or not?  I haven't had chance to try this myself, but would be interested to see if anyone had.

[STEVEG]

Evidently it does.

Versioning Change Management

[MikeLockwood]

The preference is "Change Modification Tracking."

With this preference set to Yes, one sees Change Objects with Revisionsf (some times column says "Version").  Revise also shows up as a user action, depending on Revise Transitions in the change object's Lifecycle Template.

Under History, Revision History, one can see / access each Revision.

Edit changes the current Revision, no Iterations.

The OTB Workflow Templates for all OTB change objects include a conditional with a branch and code at the beginning that is used only if the object has been Revised.

In general, it all works very well.

[mbonitati]

I believe the Change Modification Tracking preference is only related to revising the object.  As Mike stated, "With this preference set to Yes, one sees Change Objects with Revisions".

It doesn't allow for Versions (ex 1.1, 1.2, 1.3, etc).  Users want to see the change object iterate when they change it (prior to being approved).

We are using 10.2 and our Change Modification Tracking preference is set to Yes.

Iterations do not display on the actual object but does display when you do searches and within folders.

This is what is confusing to the users.

[JimTVancouverCa]

We're exchanging Version and Revision interchangeably a bit in this discussion I think.  Recall in PTC land Revision = Version.Iteration.  As I understand things with Windchill, iteration occurs after check-out and check-in of suitable objects.

Perhaps others more knowledgeable than me can expand on this fact: Doesn't workflow history show who has done what, since as a workflow routed item, a change object can only be with one person, or perhaps with one resource pool at a time. 

So for the users who is asking to see the iteration change, perhaps what they are really asking is: "How can I tell where the workflow is in it's predefined path?"  So far I've only seen tabular lists of the workflow progress, but again I'm not a master in this area. Mike Lockwood‌ or Lewis Lawrence‌ would likely know.

- Jim

[MikeLockwood]

Easy to get tangled in terminology, but essential to be fairly precise with it.

Each Windchill object type "inherits a variety of interfaces" which determine it's behavior.  These can include "Versioned," "Foldered," "Numbered" etc.  Discussion here is about "Revision Managed" and/or "Iterated."

Documents and Parts are both - resulting in Revision.Iteration.

Workflow and Lifecycle templates are only Iterated, resulting in just Iterations in their history (available only to admin's).

Change Objects are Revision Managed but not Iterated (exposed if the preference is set).

Objects which are both have user actions: Revise and Check Out / Check In.

Objects which are just Revision Managed have only Revise; changes to a Revision are made via Edit.

This info doesn't grant anyone's wishes that the system behave differently than it does, but may make the request more precise.  In essence, what is being asked for is that change objects be both Revision Managed and Iterated - likely enabled via preference.  They are currently Revision Managed via Preference.

[mbonitati]

Hi Mike - it is easy to get tangled in terminology.  What we are asking for is that change objects be both Revision Managed and Iterated - likely enabled via preference

[JimTVancouverCa]

Out of curiosity,

Are you packaging up change data and sharing to another PLM system?  Your user story makes this product idea understandable to me if I think of it like that.

If not exchanging the change object to foreign PLM system, does your use case relate to rework cycles within the workflow design where an approver may send it back with comments saying " Items missing, or description unclear" etc, and then it comes back and they have no way of knowing if the submitter actually changed anything, is that another way to characterize this product idea?

I wonder if some kind of differences report capability on change objects from one state to another would be useful, and .. for that you'd likely need the iteration concept.  I wonder if that would require a change to the database schema to implement such a feature.

[HugoHermans]

Hi Mary,

If I recall correctly, we had configured Windchill to have revisions on change objects.  I'm not sure about iterations, but we could revise a CN to a higher revision.  We turned it off again, but the functionality is there (Windchill 10.1).

BR, Hugo.

[JeffZemsky]

Mary,

Do your users need the history of what changed (what changed, by whom and when)?  If they had this would they really need the iterations?  Trying to get back to the user needs, rather than the technical discussion.

[GregoryPERASSO]

Hi Jeff

In our case . an history will be great (with or without iteration):

-attributes

-object linked

-effectivities application or modification

in addition to history tracking for change objects.   We study the Revise behaviour for change objects. It is great, but as an Enterprise  Change process can run along a long time.  it would be great if we can choose (by prefererence) to copy forward the running workflow to the new Change object Revision, instead of stopping it and starting a new one .  In order to keep all Tasks votes , variables etc ...

regards

Gregory

[JimTVancouverCa]

So many things happen around change management, there's the ideal way, then there's the pleadings that come from the org, "I just want to add this one thing, what do you mean the Change has processed to far?  Why can't I add this?"  or "Can I hold this open as a bucket to catch all the stuff, but oh yeah, can I have that one item released right now so I can order it?"

Does this speak to a training and team coordination deficit?  Perhaps.

I agree with comments above about some utility to revising and iterating and seeing change history, on a change object itself for long running changes. 

Though I have seen in places where I've worked the following: changes can be made to be executed fast, reliably, and in smaller chunks so that the change object itself doesn't become some epic saga.

Best Regards,

- Jim

[mbonitati]

Jeff,

According to our CM community, they need the iterations to track review, comments, and approval from the customer although the history would be a double bonus.

From what you stated above, I would think that having a history of what changed (what changed, by whom and when) who accomplish their need.

[JeffZemsky]

We do not plan to iterate the Change Objects.  We do have future plans to add detailed capture of the history of updates to change including attribute and relationship changes.

[CristinaDeRivas]

Hi Jeff, "We do have future plans to add detailed capture of the history of updates to change including attribute and relationship changes." Is this already included in Windchill 11.1? My customer is also looking for this, as Audit Trail is very important for them. Regards, Cristina

[schathoth-2]

Hi Jeff,

Has this been implemented in any new version of Windchill ?

Thanks,

Shibin

[jcugini]

Hi Jeff,

Our business has a strong need to understand what has changed and by whom on the various Change Objects.  This is in support of rework loops in the Change Process where our Change Admins need to see what was modified on the change (attributes, attachments, etc) from the last time they performed a review.  

Regards,

Joe

[SyedInfy]

Hello Windchill Experts,

Do you got any possible configuration or minor customization to achieve this feature??

I got a similar requirement and have to go a long way to achieve this with so many customizations. If you got any simple solution. please let me know.

Thank you!!

[RABOU_Francois]

Hello, same need to have an history of changes done for Change Objects (Variance, Problem Report, Change Request and Change Notice) like for Parts and Documents.

If a change for a Change Object occurs like modification of attribute (custom or not), attachment (addition or removal), association (adidition or removal) we want to know who did the change, when this change occurs and possibly compare the previous iteration with the new iteration.

For the moment we did a customization (workaround) to register what kind of modification is done, who do that, when and with an optional comment. It's a specific table displayed to the users to register these changes.

[olivierlp]

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.