Revise released objects only with a connected Change Notice

[BjoernRueegg]

In SMEs, the changes are not always planned to the last detail. The main problem is known, but which objects have to be modified is not always predictable.

With PDMLink 10.2 there is still no possibility to setup the system that a user can only revise an object, if it is connected to an Change Notice (Change Activity). A global Change Admin II creates the Change Notice and the Change Activities with the affected and resulting objects. The user can add the objects by himself to the Change Activity and revise it. Or he just revise it without Change Activity (if he has the rights to do it --> This is exactly the problem). Otherwise he has to call the Change Admin II to do it for him.

My idea is now, that the users should have the rights to revise released objects, but only if they are connected to a Change Activity.

It would also be nice if there is a Change Activity picker on the revise dialog. So he doesn't have to change to the Activity, add and revise the objects and than have to go back to the object again.

The process of the changemanagement ist good but in my point of view it's not userfriendly! It's just another layer on top of the PDMLink base functionalites.

Comment 27. July 2014

If a user needs to add a object to the Change Actitivty, the user shouldn't have the rights to change the assignee and reviewer! Only add and revise the objects.

[dhermosillo]

This would be great.  We have people constantly accidentally revising released objects simply because of the awful conflict window in Pro/E; it's so easy to scoll the selection to Revise and Checkout.

[DavidCobb]

Totally support the need for more granular control of the Revise action. Our current plan is to hide the Revise action from all non-Admin roles in every location other than the Change Activity (i.e., make it not visible at Folder, Workspace, object level). Not a perfect solution, but it should at least minimize the chaos that comes with having objects revised without being authorized for change, and having associated Part/CAD objects revised independently from one another. To the earlier comment, our default value in the Creo Parametric conflict window is "Continue"; also not perfect, but attempting to minimize the issue occurrences.

[BrianToussaint]

I am all for getting the action of Revise removed from locations other than on the CN.  However, I am guessing that there are companies out there that are not using Windchill for their change management system.

What we really are in need of is a way to get unwanted menu picks out of the system easily.  For example, my company uses the Change Request functionality of the system but do it through a web interface form instead of doing it within Windchill.  This is because it is a lot easier to fill out rather than trying to gather everything you need in Windchill.  For me, I would like to remove the Change Request button from the action menu easily also.

Profiles seem to be a start to this, but don't quite get us all the way there.

[DarrenStorey]

For items which are already released (ie subject to change) we plan to remove the manual revise option altogether. It will be performed programatically in the CN workflow. Once the CN is approved, the moment before the change tasks are delivered all the affected objects of all the change task will be revised, creating the resulting revisions. For us, this will force the use of change, and ensure the affected and resulting items are correctly populated. Also it will ensure the revise is performed at the very last moment. Revising in error, or before the change is approved can be a tricky problem to solve, so best avoided in my opinion.

Regards

Darren

[BjoernRueegg]

Hi Brian

You can remove the buttons from all the toolbars over the xml files within /codebase/config/actions. Use the custom_* xml files to make some changes.

[BjoernRueegg]

I understand that PTC wants to have the change management as an option. But it would be really nice and userfriendly, if the change management is enabled, the actions would penetrate deeper into the system and would take control.

[BrianToussaint]

Hello Bjorn,

Do you have any examples of how to do this?

[BjoernRueegg]

Hey Brian

What do you mean how to do this? Remove some actions?

[tcurry]

Darren,

This is nice, except when the affected object is to be obsoleted.  How do you handle that?

For us,  the lifecycle states have been customized to be "In-Work",  "Released", "Obsoleted".   Only a Change Notice completion can change the state from In-Work to Released and from Released to Obsoleted.

Therefore, in order to obsolete something, we must copy the Released object from Affected Objects to Resulting Objects just as it is instead of using the Revise tool between Affected and Resulting.  Then, the Change Notice drags the object from state Released to state Obsoleted when all participants approve and it becomes Resolved.

[tcurry]

In our former system  (a competitor),  we had an attribute, if you will, for every object connected in the Change Request Affected Objects area.  The value in the field specified what we wanted to do to each object.  If we set that value to Revise,  the object was automatically revised when the Change Notice was created.  If the value was set to Obsolete,  the object was simply added to the Change Notice as  "To be Obsoleted",  which happened once the CN was completed.

[BrianToussaint]

Hello Bjorn,

Yes I was wondering if you had examples of how to remove the actions.

Thanks,

Brian

[BjoernRueegg]

Yeah, thanks PTC! I'm looking really forward to this feature. Is there any timeline for it? Windchill 11???

[BjoernRueegg]

Hi Jeffrey Zemsky‌

Do you think this idea is implemented in 11.0M020? I do think it's the right direction, but still not that comfortable for the users! They need to know the CN Number to get to their Tasks. I would like to see a wizard with assigned Change Tasks so he needs only to choose the correct Task. A user doesn't know the Change Notice number. 

[JeffZemsky]

Bjorn Ruegg‌ I am not sure I am following your comment or its relation to the idea posted?

[BjoernRueegg]

Jeffrey Zemsky‌ with 11.0M020 you can now add an object in the workspace as resulting item to the Change Task. This function has just a small relation to the idea. I'm wondering if you have any roadmap or can provide any information about the implementation plans?

[OliverDroop]

In my opinion the best approach for PTC and you would be a new preference which would hide the revise action for non-admins everywhere beside on change activity. This will force the user to add existing objects as affected. The add from workspace helps here aleady. The add to change task is also good for new objects where no precedessor exists even the user will need to copy it to the resulting table .

This will give much flexibility but enforces the process of ECN.

I only see one drawback which needs to be taken into account and these are objects which are not change notice relevant. These should be able to be revised without anotice ECN.

Maybe decision needs to be taken ALL or NOTHING which makes it easier and can be controlled by yhe preference or a customization hook should be provided if special logic is required based on object type.

[tcurry]

Everyone,  the behaviors I'm seeing described here are all configurable in 10.2 with defined roles and access rights definitions.  With the exception of hiding the revise action in places other than the Change Task.  I think when we implemented exactly that,  it was indeed a mild customization.

But I can speak to it being entirely possible to configure your EPMDocument soft types,  WTPart types, and WTDocument softtypes such that some require an approved Change Request,  while others can be revised by right click or Actions menu.

We have one basic WTPart type, the normal EPMDoc types, and one WTDoc type which are:

   - release controlled by CN process (no CR needed)

   - revision controlled by CR + CN  (must approve CR before the revise button will appear on the CN Change Task)

Then many WTDoc types which are:

   - release controlled by Promotion Request process

   - revision controlled by Document Author role definition (must have the associated author role in the context in order to see the revise action in right click or Actions menu)

Now, all of that said,  these were configurations and possible some mild customizations that we paid PTC for.  My understanding of Windchill 11 is that you will have more flexibility as the site admin or  organizational admin to configure user roles and which roles see what menu buttons in which areas.  That's one of the big enhancements that they have advertised to us,  that we shouldn't spend too much time or money customizing that kind of thing in our 10.2 system,  because it will come OOTB configurable with version 11.

[JeffZemsky]

Bjoern Rueegg‌ - ah you are responding to a different idea, not this one.  Yes - in the future that would be a good enhancement for streamlining.  In testing and discussions with users we found that users did know their CN numbers in practice.  We should take any further conversation back to this thread

Initiate a release process from workspace actions menu

[BjoernRueegg]

I'm thinking of a checkbox in the type and attribute manager. So we can choose for each type if it's revisable only per Change Notice or without.

[BrianToussaint]

What about a preference where you list the types that are revisable only per a Change Notice?

[BjoernRueegg]

Wouldn't it also make sense to copy this idea for supersede parts? In Windchill it's possible to create supersede links. Normally this needs to trigger an ERP action and this is normally triggered by the change notice.

[BenPerry]

Should the status be changed to Delivered as of 12.0.0?

[JeffZemsky]

With Windchill 12.0.0 and 12.0.1 there have been enhancements to enable (via Profile) to show the revise only within the Change process