How to allow new iteration at same revision for released EPMDcoument

[gchampoux]

I find that I have lifecycle or domain policies a little too strict.

Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).

We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.

Recommendations?

Gerry

[avillanueva]

What about creating a Promotion Request?

[sdrzewiczewski]

I'm assuming that your "Released" iteration you want to stay Released. I
think you are trying to emulate Ilink 3.x functionality. Where you could
set the state in the workspace and then check in?

Can you further explain what you want to have happen?

Thx

> What about creating a Promotion Request?
>

[gchampoux]

Several people have asked why we need this functionality.
There are several reason:

• Some drawings that are not controlled by configuration management, users are allowed to check-out and repromote at the same rev letter. At least, this is what we do in Intralink 3.4.


• Sometimes, a model needs to be tweaked in a manner that does not affect its' drawing. For example: Adding datum features to aid assembly.


• We often have multiple manufacturing plans for a part at a single revision. Therefore, we allow (in 3.4) to check-out a released drawing & planning models, and make changes at the same revision letter. We have parameters to identify the differences.

Gerry

In Reply to Gerry Champoux:

I find that I have lifecycle or domain policies a little too strict.

Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).

We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.

Recommendations?

[JosephCugini]

Gerry,

This brings up a question that I have had for years. How does one
maintain configuration control on the models that make up a formally
released drawing? Since there are multiple ways/reasons why a released
model may need to be modified and checked in that would not require a
change to it's current released revision (layer status change, model
color change, feature redefine/cancel, datum addition, circular
references, etc).



Your suggestion of granting "set-state" policies seems to make sense but
then what would prevent someone from setting the state of other
parts/assemblies/drawings without going through a release process? You
could setup this up for only administrators but that seems like it would
become an administrative & configuration control nightmare over time.



At our site we use another PLM system for document (drawing) release and
official CM control. We process all CN's through this system against
the drawing, conduct configuration control boards and release the CN's
for incorporation. This system is considered the "record of authority"
for all released drawings. Intralink 3.4 is used as the
"work-in-progress" management tool of our CAD data. When a drawing is
released in the PLM tool our drawing supervisor promotes the drawing
(and it's dependents) to the Released state in 3.4. When a user needs
to modify a file they just change the state back to working. The new
part does not get released until the drawing is revised and subsequently
released. This creates a situation where an engineer may inadvertently
change a part without a released CN.



As I continue to learn 9.1 I'm hoping to tie this down and work
promotion request into the mix but I'm having difficulty understanding
their use case and how/when to override them with the set state
capability.

[cc-2]

Hi Joseph

there must be some historical background to maintain 2 different systems to do the same thing. I see, personnally no advantages in doing so. Anyhow to answer Gerry. We have the same situation but we did not grant everyone access to change the state back to development or In Work directly with a Set State. It was difficult enough to explain the users why they needed to change the set to Released at the first place and what a Revision level was (surprisingly enough but there are historical reasons for it). So to ensure released data are revised when they are supposed to be revised and simply change to development when they are supposed to, we have identified and trained a limited but sufficient number of users (we call Super Users) who have the authority to change the state back to development without creating a new revision.

We try to educate our users that a new revision if when any of the 3F changes otherwise there is no need. In case of doubt they ask one of our super users who in turn will reexplain the user the differences and take the appropriate action. Nonetheless, all users can change back to development but only with New Revision

This seems to work pretty well so far.

[JosephCugini]

In response to the statement, "there must be some historical background
to maintain 2 different systems to do the same thing"



Yes, we have been in production with a different PLM system for managing
drawings, CN's, CR's, baselines, CDRL's, work packages, action items,
Clear Case, DOORS integration, electronic material release & lessons
learned for over 10 years. We stayed with Intalink 3.x because it
managed ProE CAD data easily and inexpensively. While there is some
overlap between what the two tools do we cannot make a business case to
replace the existing Enterprise PLM (and legacy data) with Windchill.
It appears as though in this life time this will have to be something I
have to deal with (unless the two vendors merge J)



While I could go down the path of implementing our current PLM vendors
solution for CAD management, I would prefer to stick with PTC's solution
because they have a proven solution for moving legacy data from 3.4 and
because they will have the tightest integration with ProE. It also does
hurt that we already own Intralink 9.1 licenses.

[ptc-46674]

Gerry

I'll chime in in this one, I think you have created these lifecycle or domain policies correctly and for good reasons. They are not to strict in my opinion and they are the same at most companies. There are also sloppy proe users at every co. I have ever been at that do not follow good modeling practices. "people not using the proper start parts, not using the proper layers, blanking layers that contain needed datums, axis, points etc." Then when they have the model and drawings checked in and released to production. They come back and say I need to change the released model back to in-work without chaging the Revision so I can make some small changes to it?

Simple answer No! I've been burnt by these types of request to many times, engineers or designers come back and say I just need to turn on this layer or create a contruction datum plane I'm not going to change anything else.... yeah I've heard that one before,and then they notice some hole doesn't line up exactly or they add something else to the model that they missed etc... This will later get discovered by a vendor or manufacturing or somewhare else down the line and all of the sudden the integrity of the whole data base is in question!. The answer is a polite No!

Send me an email request letting me know what you need done and I or someone on the administration staff will set it back to in work and turn on the layers, create the costruction datum plane, etc... and set it back to released.

It only takes one inconsistancy in the engineering database to be discovered and from that point on people will not fully trust the integrity of the data.

Dave

In Reply to Gerry Champoux:

I find that I have lifecycle or domain policies a little too strict.

Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).

We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.

Recommendations?

Gerry

Dave McClinton

MCAD System Administrator

McKesson Automation

724 741 7760

david.mcclinton@mckesson.com

[BrianSullivan]

Hello Joseph,

Typically an object should reach "Released" only once per Revision. Any changes to the object requiring a revision change... (Use of Revise Function)

However, you case of Non-Geometric Changes (CAD Standards such as Naming Datums, Color of Models, etc..) is a common use-case. The question is how do you track the difference with your end-users. How do you know they do not abuse the alternative path. (Set State does not give us the communication history or approval process for the non-geometric change other than the Promotion back to Released). The other issue is for Down-Stream Users... (Manufacturing Floor is usually ok as they are typical given only View Access to Released Items but others like Purchasing might see the change in state and wonder why and not have any communication history.

Maybe you could also consider:


1. Promotion: You can set up your system to allow users to promote from "Released" to a new state "Refine Model". This was you capture the request and it is at a different state that you new WIPs/Inwork/Concept type work. They can make the Non-Geometric Changes and then Promote from "Refine Model" to "Released" Again giving you opportunity to Review the changes (And Hopefully catch a Geometric Change).

2. You could consider a New Workflow for your Change Process in Windchill... Since you state your ECNS are over in another system... A Non-Geometric Change Notice that can also use the Custom Review/Refine Functionality. The Resulting Objects can be set to Refine via Workflow and User can work on them then when the ECN completes it gets reset to "Released" you've also get captured the information for the change and the review communication.

Brian Sullivan
TriStar

[gchampoux]

Thanks to everyone that responded.
Although we cannot do some Windchill things identically as we did in 3.4, all of your input and advice was very helpful in understanding how Windchill is intended to work.

As I suspected, what we want to do is not practical in Windchill.
However, we can develop some new policies & procedures to meet our needs.

Thanks again.

Gerry

In Reply to Gerry Champoux:

Several people have asked why we need this functionality.
There are several reason:

• Some drawings that are not controlled by configuration management, users are allowed to check-out and repromote at the same rev letter. At least, this is what we do in Intralink 3.4.


• Sometimes, a model needs to be tweaked in a manner that does not affect its' drawing. For example: Adding datum features to aid assembly.


• We often have multiple manufacturing plans for a part at a single revision. Therefore, we allow (in 3.4) to check-out a released drawing & planning models, and make changes at the same revision letter. We have parameters to identify the differences.

In Reply to Gerry Champoux:

I find that I have lifecycle or domain policies a little too strict.

Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).

We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.

Recommendations?

[leger.xavier.pr]

Hi Gerry,

Due to our experience, I would not recommend to try to implement the I3.4 behavior (allow new iteration at same revision for a released CAD doc).

We had some of those objects in Ilink3.4 and when migrating to PDMLink we discovered that when trying to retrieve 'latest released' objects in an assembly configuration, it would miss the correct iteration. Let explain, you have Part1 in Asm1. Part1 has those version.iteration status :

1.3 Released

2.5 Released

2.6 In work

When you will retrieve (add to WS, or checkout) Asm1, with Latest Released configuration, you will get 1.3 in your Workspace. That was really annoying for us. It's less if you always use As Stored configuration. We've seen other cases (search I think), where the 2.5 iteration was missed by the system.

For PTC, it was working as designed in this case.

No one else noticed this pb in PDMLink 9.1 ?

Best Regards

Xavier LEGER

[LSivertsen]

Hi Xavier

We have also seen problems in this scenario concerning access permissions for roles.
We have a role called "View released". They are only able to view released material. In your scenario they would only be able to see 1.3. 2.5 would be hidden for them. PDMLink checks the access to a part on the latest iteration in every revision. PDMLink does not check all iteration in every revision.

This is only a problem for us for the 3.4 migrated objects as we do not allow it to happen in PDMLink. It is a major problem because we still use the "old" part in production. We would love to have this problem fixed.

I would not recommend letting a newer iteration be created in a lower state in the same revision.

Best regards
Lisbeth Sivertsen