Change Request Input from multiple users

[cmckenna]

Has anybody any suggestions as to what object to use within a Change Request to gain impact inputs by multiple functions who may be affected by the change before final approval of the CR is granted?

E.g. When when Function A raises a CR, it is decided that Function B and C will be impacted, and will need to provide an input to the CR before it is granted approval at the CRB stage.

I want to give the Change Admin the ability to send out an object or action to these Functions to enter their inputs, and receive notification once complete, so they can schedule CRB. And I would like these inputs to be non-visible to the other functions, but visible to the Change Admin and other admin users.

I have looked at using an action item, but this is non-subtypeable,and not sure if each one can be access controlled to the specific group of users. Would the Change Analysis or Change Proposal object be able to fulfill this need, or are these objects only applicable in earlier versions of Windchill?

Another other suggestions, or similar examples would be appreciated.

I am currently using Windchill 10.2

Thanks

[mbonitati]

Hi Conor - Raytheon currently has a customized capability (Common Usage) that is based off the Related Products and the where-used of the Affected Objects.  It looks at the Affected Object to see what other product is using it and then looks at that product's team and pulls users in a specified role.  Those users will get a Reviewer task where they can enter their inputs.  They can also be at the CCB level.  Their votes will not stop the workflow but will let the owning program be aware of any impact.

[bsindelar]

Conor,

Thinking about ways to do this without custom solutions, what you are suggesting, to me, sounds more like something that should be handled via the following:

• Use workflow/team template to capture the possibility for Functions A, B, C, etc and the need to designate and require input from them.
• Workflow can be sub-routed to require these inputs as necessary.
• In order to get the requirement down for Functions only to be able to see their own inputs and not others, yet allow admins to see all function inputs, I'd try using WTDocument soft-types, one for each function, called something like "Function A/B/C CR Input" for each one.  You could make the WTDocument not even require content - just use attributes as necessary to capture the input.
• Set up ACLs for each accordingly.
• Regardless of where these WTDocs exist, use the "attachments" functionality on the CR and attach them via the WTDocument URL (this way you can relate the CR to the WTDocument, but also allow for editing/revising of the WTDoc as well).

This way, when the CRB vote finally arrives, all people can see the URL links from the CR attachments to the WTDocs, but only admins can actually access "all" Functions actual WTDocs details page, and Functions can see only their own.

This solution requires no custom code.

My company works with all things Windchill.  If you'd like to discuss this further or if you have any other questions about what we do or how we can help, feel free to contact me at robert.sindelar@eccellent.com or go to our website at www.eccellent.com.

[cmckenna]

Thank you both for your replies. I think Bob's response was along the lines of a solution I was looking. I will investigate this option further.

And Mary's suggestion is something I would hope the process to eventually reach, once we get something embedded.

Thank you both for your help!