Revise Action in Change Notice Only

[BrianToussaint]

Is there a way to remove the Revise selection from the Action menu and force them to Revise through a Change Notice? We are currently on 10.1.

Thank you,

Brian

[DarrenStorey]

Brian we would also like to do this. Maybe even perform the revise action programmatically on the affected items in each change task, via an expression in the change notice workflow. That way the new revisions are created at the last possible moment. To stop the revision being created only for the change notice to be rejected.

Removing the revise action from the UI is a customization. Revise from change and revise are different actions.

Watch out though, you cannot remove the revise from within CAD so easily, if at all. If anybody knows otherwise please share.

I thought to simply remove the revise transition on the lifecycle, and then rely on the programmatic revise in workflow. Not sure if this is possible if there is no revise tranistion defined in the lifecycle.

Darren

[MikeLockwood]

The team at Alcon struggled with this for a good long time in the past as a fundamental requirement for the system. Seems that it's helpful to consider this from a lttile bit broader perscpective.

The posted question is how to manage Revise permissions / actions such that people have this available only on an approved change. Added to that is an additional desire to Revise programmatically.

Bottom line - After being immersed in this for 15 years, I strongly recommend using a two-phase lifecycle / Revision scheme (e.g. Numbers, then letters or the reverse). This has to be set up with "state based versioning" such that the following are accomodated:

- During development, Revise is freely allowed and there is little downside. Give the permission to all Engineers. The permission is Revise from a specific state used only for Development.

- For every object, there is a one-time step such that the next Revision jumps to the next "seed" (e.g. from Rev 3 to Rev A); further Revisions are B, C... The permission is given to a much smaller group, Revise from the state used to get to production.

- Once "Production Released" a different set of states (within the same Lifecycle) is used. Revised is from Production and this permission is given to only those Engineers authorized to make production changes.

Separately, the collector preferences used for Revise (and for populating Change Objects) have to be fine tuned. Recommendation is to err on the side of less automatic collection and put the responsibility for correct collection on the CAD user assigned to make the change. Note: Have to be very careful about programmatic Revision where new objects are created as part of the change and other objects are obsoleted and/or allowed substitutes are involved.

////

So - If you are already in production, this is of no use, right? Lots of these in using Windchill - by the time you decide how you want to configure it you can't make those changes. In this case, you probably can in fact add addtional states to your existing lifecycle, along with additional Revisions for development. All this is far easier with a few good diagrams - I'm thinking of writing this up carefully and publishing to the world. May in fact make this one of my consulting specialties going forward.

[DarrenStorey]

Mike

Hope life is treating you well as a consultant?

I completely agree with a 2 phase lifecycle. The ability to enter revision control before engineering change control is a use case shared by us. Whether you need state based versioning is another discussion.

Restricting who can revise in phase 2 compared to phase 1 is certainly easier to implement than programmatic revise.

I may have completely overlooked something here, but I do not currently understand the use case whereby the list of affected objects could be different to the list of resulting objects. When is it not OK to revise all affected?

My understanding is that new objects may be “required” because of a change but “new” objects are not affected or resulting from change. Similarly obsoleted parts are not changed, you just decided not to use them anymore and removed them from your product configuration, by changing where used.

Do you perhaps have some downstream activity that only responds to a new revision rather than a change of state?

Darren

[MikeLockwood]

Comments on "when not revise all affected."

1. Need to carefully collect from the affected - as a CAD user familiar with the data. User who created the change request may have only added the drawing. May be models, WTParts to collect. May have to address family tables, envelope parts, skeletons, process assy's etc., etc. Wary of automated or programmatic revision, although less wary if collection is diligently done by a human first..

2.May not revise all in this particular case: Some objects being obsoleted at the same time as their replacement is being released. Objects to be obsoleted are moved from affected to resulting.

3. At times with family tables and tabulated drawings, may be necessary / desirable / policy to keep cerain Revisions in synch, so will have manually select to skip some Rev's.

May be more (I think we have had some over time) but can't think of any more at this point.

[DarrenStorey]

Mike, interesting - thanks for clarification.

Diligence

Whether the person filling in the change task is more diligent than the person filling in the change request is an important point. Also whether change admin or CIB feel it is their responsibility to check, and if necessary edit the affected and resulting objects in the change tasks. At the end of the day somebody has to take responsibility for what is affected and that needs to happen before the resulting revisions are created.

Not revising all affected

It depends if you are using the change "transition" for states changes relating to initial release and obsolescence. You might do it another way, through promotion or custom transition in the lifecycle which is triggered elsewhere. Interested to know if you consider "released" and "obsolete" as change or just find the change transition a convenient way make these state changes happen?

Revisions syncing / manual revision setting

This has been on my mind a bit recently. Consider the following

1. What you technically need to revise because you are editing it.
2. What you should revise because even though you didn't change it directly it has been "significantly" affected as a CAD dependent of the object you did change.
3. What you are told to revise because of policy.

Number 1 - easy.

Number 2 - always down to human judgement. The rule of change interchangeability applies to more than physical parts in the bin.

Number 3 - is an attempt to compensate for poor judgement in number 2 or remove the need for people to thing about it to much. "Lets revise anyway to be on the safe side".

Is number 3 better or worse than number 2 - that's a question?

Does it make any difference on this topic - I would say no. By policy or by good judgement somebody still has to put the right objects in the affected table. This is a separate issue to whether you revise all affected or not.

Regards

Darren