cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Lifecycle question

Highlighted
Regular Member

Lifecycle question

I am working on developing lifecycles for our conversion from Intralink to PDMLink.

I am trying to figure out a process problem

During the Lifecycle, I am having users use Promote to get it to go to the proper Released state. As an action from the promotion, I define the lock state as Under Review.

For now, I am keeping the approval process very simple and have a list of approvers. Where I am having problems is that the approvers want to touch the CAD object before they approve the object. Most of the time the purpose is to call up a drawing and add approval information before the document is actually released into PDMLink.

I can always have the approvers reject the submit, make the changes and then resubmit, but this seems to be a bit more work than what they want. The approvers also want the file to remain in a locked state so that no one else can make changes at that time.

The other method I am testing is to allow the approvers access to the files in the Under Review state. In the Lifecycle I added Revise for the Under Review state. I then restrict access using my Policies to only the approvers. This seems to work until the Approver actually checks in an object. This check in seems to break the approval process. After the approver checks in the object, then any approval or reject from the assignments does not place the object to the selected state and stays at the Under Review State. I can add Set State to the Lifecylce so that the Approver can move the file to the desired state. I am a bit wary of defining a process that actually breaks some defined process (the approval process gets broken). I have done funny work arounds in Pro/E and they always seem to come back and bit me where the sun does no shine.

I am wondering if anyone else has had this problem and how did you solve it?

I am not familiar with Change management and I am trying to avoid this for now but if that is a better way, I had better learn fast.

Ronald B. Grabau
ME Applications Engineer
HP - Houston

2 REPLIES 2
Highlighted

Lifecycle question

The Promotion Process is intended to either Approve or Reject a package of
work. If any of the objects need to change the Promotion needs to be
rejected, the changes made and then a new Promotion submitted.



As you stated if you submit a part 1234.prt A.1 it goes to Under Review.

If the Approver role has permission to change this object they Check it out,
modify something and Check it in, it is now 1234.prt A.2

The Approver now approves the promotion, but the Promotion is for A.1

What happens is A.1 is set to Released, or whatever the target state was and
A.2 is left at Under Review.



I was told by Tech Support that is intended functionality.






Highlighted

Lifecycle question

Agreed - as Steve says below you are approving that "package" of work - in fact a promotion request is really just that, the system generates a "baseline" or "snapshot" of objects to be approved. This is really how it should be - you don't want modifications happening to the baseline of objects that someone spent their time collecting.

The bigger question is, why put approval information on the drawing? It is redundant - the information is in PDMLink so why reinvent the wheel - why do all the extra work of putting that information on the drawing when PDMLink does it for you, automatically? Of course once you start down that path people will say "well we have always done it that way" - those people need to make the paradigm shift!

When I managed an implementation I received a lot of initial pushback when I stripped all the approved by/checked by/drawn by junk off the drawing. But you know what? Once it was done I never had anyone come back to me and say "hey, how do I get this information now?" Once people see that they can easily access the information from the system they will realize the redundancy (and wasted time) of putting stuff like that on the drawing.

The way I see it the only intention of the drawing is to document exactly what that version consists of, nothing more, a drawing should NOT be used as a change documentation tool (at least not in this century :))









Kevin Alexander

Senior Application Engineer - TriStar, Inc.
Announcements