Changing "Released" CAD Data in PDMLink

[ptc-680841]

Users, Abusers and Downtown Cruisers; I have two questions forthe users that are working with Pro/E and PDMLink. I am wondering if y'all are willing to share how your company handles these two scenarios in PDMLink:Non-Solid CAD Changes After Released: The models and drawing are at a RELEASED state, but there is something that needs to be changed or added in the 3D models. For example, you need to hide a Layer, add a Datum, fix a frozen or failing component's assembly constraint, add a Simp Rep, etc. We do not want to REVISE the model to bump it back to a state where it can be Checked Out, changed and Checked In. We are changing the model only, not the drawing. How are you handling this at your company? Make Minor Changes to A Drawing (or Model) During the Approval Process: The drawing is going through the process of being reviewed/approved. After ~10 people have reviewed it and approved it (Engineering, Manufacturing, Purchasing, etc.), one of the people in the process (Quality)finds a typo, or a layer that should have been hidden, or whatever. If the drawing is rejected, the review process has to start all over once it is fixed, causing a delay. How is your company handling this?Hopefully this is not too much of an "emotionally charged" issue for a Monday afternoon. Any input is appreciated! Thanks, Andy B.
This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[BenLoosli]

Non-solid changes: Change is done by an administrator, or the state is changed and a trusted designer makes the change and state set back. If the change may change what is visible on the drawing at this level or higher, the part is revised.

Minor changes to drawing: Since we only have 3 levels of signoff, the package is rejected, revised and resubmitted.

Thank you,

Ben H. Loosli
USEC, INC.

[DamianCastillo]

The scenario you just mentioned is a big issue for our company and probably many others. We have an SOP that says a Revision takes place when we change Form, Fit or Function of any Released product.

If you are adding a datum point to the model or correcting the spelling of a word in the drawing, it does not get a new Revision because the Form, Fit or Function was not affected.

Now, we are in the process of implementing Windchill 10 and this came up as one of my big issues with the way Windchill handles this. We can't use the "out of the box" setup for Revisions because it won't work for our company. I honestly don't see how any company would change their revision level for things like this but I know many do.

We came up with a custom revision scheme and a rule that allows us to accomplish this. Now this is all in theory and was tested during a demo, but we have not actually implemented Windchill yet. In the demo, it worked the way we needed it too with a draw back. The revision levels will have a letter and number such as this. A, A1, A2, A3, B, B1, B2, etc.

The letter is the Revision level and the number is the minor iterration. We are going to set up our system to automatically bumb up the minor iterration as you make changes and check them back into the system. If we need to make a real revision change to a released product, we can check it out, make the changes and then manually bump it to the B level which will be restricted to an Administrator.

The downside to this is that it's a manual decision that a human must make and they could potentially forget to request the Revision bump up. We have to play with this idea and maybe come up with a process of approval for all things checked into the system. Maybe this way we can catch when a real revision took place and have the admin. bump it up to B. Once it's in the system as B, all check out and check in would do is bump up the number to B1, B2, etc. Again, when a real revision is made, we need to manually bump it to C and repeat the process.

It's not perfect and I can't even tell you if it actuall works at this stage, but this is our plan.

If anyone has a better idea on how to handle this, please let me know. The idea of changing a revision just because you added a datum point to a released product is ridiculous to me. The Revision is a big deal for our products and they are visible to the customer. We can't just change it for things that don't affect Form, Fit or Function.

Thanks

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[ptc-1932745]

Just my $.02...



I think that in your case 'Just adding a datum point' IS affecting
F-F-F. Going to say, a datum that is specified as the full part face,
and then changing it to three datum points would require a revision.
Especially because you need to know that downstream suppliers are using
the product revision that you specify.



Unfortunately, deciding when to issue drawing revisions is similar to
being a 'little bit pregnant'. Typos, etc... are embarrassing to have
to issue a drawing rev for, but in the strictest sense, required.



There was a thread some years ago about creating all kinds of work
arounds when you have to change a BOM on an assembly drawing without
having to issue a rev for the parts in the BOM in order to add a
parameter that would not affect F-F-F. If you were still using a
paper-based system, changing the assembly drawing would be the end of
it, but in the digital realm, needing to add a parameter to a part file
creates a rev of the parts as well as the assembly.



In my experience, you need a way to issue an interim change notice to be
attached to the documents as a supplement. I have had Aerospace
customers do this as an 'ADCN' or Advanced Document Change Notice. This
way they could make small revisions/clarifications to the document
without creating a full revision. At some point in time, all of these
ADCN's would roll up to create a revision, but on older projects where
there was no labor available to incorporate the change formally to the
drawing, this could take years.



I suggest that you use the strictest definition of the revision
workflow. It may be painful in the short term, but will enforce a
thorough checking of the designs in the future.







Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

[davehaigh]

Chris,
I'm pretty sure your confusing ProE datums with Y14.5 datums. There are a lot of times you need to go back after part or assembly is released and add additional datum features so it can be assembled differently for another assembly. Or you may want to turn off some layers in the model and save the layer status. Or you might even want to just change the color of the part or some surfaces on the part. None of which affects the form, fit, or function. As long as the topology of the part isn't changing and you're not changing the Y14.5 datum definition your ok.

One of our divisions here allows the model files to have different release levels from the drawing specifically for these types of changes.

David Haigh

[DamianCastillo]

Adding a datum point or datum plane does not always change the F-F-F. Our products are not tied to a digital feature that is added to a 3d Model. Out product is tied to a released history that the customer is familiar with.

We have some Released assemblies that we want to add a datum point too, for no other reason than to constrain things differently for an overlay report for internal use. This datum point is not affecting anything realted to F-F-F.

Our products have external revision letters that are not only visible to the customer but very important to the customer. If we have to make an improvement to a product due to some issues with the current design, the revision letter on the new products is what the customer looks at to make sure they received the newer design. They may need to send back the inventory of the current revision level back to us. Let's say this new design is working great. The customer is aware of the revision level of the design they are using and are happy with the results. We can't change the external revision level just because we added some datum point to the model. This datum point does not affect the product the customer is currently using and we are not going to spend the money making brand new tooling to change a letter from B to C on the product.

It makes no sense for us to ever change a revision level just because we added some insignificant change to the model or drawing. If it does not change it's F-F-F, it should not get a revision. If we desided to change the color of our models for all our catalogs because we think the current color does not print as well, I am NOT going to update the revision level of the model, drawing, tooling and product for this chagne. It's ridiculous.

I am sure there is a solution out there to make systems like Windchill work more intelligently than it does today. Accepting a flaw in flexibility with a system is not something we should have to swallow. If software is not felxible enough to handle real world situations like this, we should not simply accept it as a good practice when it's clearly not.

Just my opinion.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[ptc-1932745]

My $.02 more ($.04 total),



I agree that in the cases you highlight, you would not be making changes
to a paper based system, but that is not what Windchill is meant for.



We had a similar situation for our engineering documents, we decided
that our paper drawings are our 'bible' and the 3D models that support
these drawings are not, and do not need to be controlled by revision.
We rev control the pdf's of the drawings, but not the models and
assemblies. We do not use Interlink or Windchill for this reason.



Whether we like it or not, systems like PDM in general and Windchill in
particular will drive us to use model-based definitions. Unless we
start drawing again in 2D, the drawing will always need a model of some
kind to be the 'parent'. There are workarounds such as the ADCN method
I described earlier, but I don't foresee Windchill being a system where
the drawings are rev controlled, but the part models are not, or a
system where the drawings are the parent of the part models.



If you need to add a datum point for an internal inspection, or 'tweak'
the part color or texture for a catalog, I suggest that the only way to
do this without revising the part model in question is to create a new
model, and incorporate the original part model features using something
like inheritance. Then you can take this new model and add features
like extra datum points or colors and textures without revising the
parent.



Please let me (and the group) know what your final decision becomes,
these are some of the issues that cause us not to implement systems like
Interlink, or Windchill.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

[DamianCastillo]

Chris,

Thanks again for sharing your perspective.

I personally believe that the lack of flexibility or options on how revisions are controlled in Windchill is a limitation to the software. We should not let a limitation to the software drive common sense.

Tthe reality is that sometimes companies must add things to the 3D model that have no affect on the actual product's design or current revision level. The limitation of Windchill not having some intuitive mechanisim to address this is a falt of the software and not the practice that companies have used for revision control.

Windchill is supposed to help protect our data and our designs while preventing errors. If this comes at a cost of forcing companies to change the how revisions are controlled, I think there is major room for improvement with the software. Changing a $10,000 tool to add a new revision letter for simply adding a digital feature that has nothing to do with the products purpose is not acceptable. Confusing the customer on what product inventory they actually have by giving them multiple revisions that are 100% identical is not acceptable. Not allowing the customer to clearly understand what products were actually improved by a new revisions letter is not acceptable.

Thanks again for everyones input. I only hope PTC is listening and can figure out a way to add the flexibility required by many companies.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[ptc-593619]

I only hope PTC is listening and can figure out a way to add the
flexibility required by many companies

Either that or maybe a third party can supply something that the users
want and/or need rather than a "one size fits all" with a "take it or
leave it" attitude?



Richard A. Black

Lead Design Engineer

Eaton Corporation

440 Murray Hill Road

Southern Pines

NC 28387 USA

[TimKnier]

I think one question everyone has to ask themselves is, can you trust your users? Even though we're not on Windchill, we have the same issue with our database manager. Opening your 3D models up for minor tweaks that wouldn't affect the drawings or overall design, also could open them up to inexperienced or unscrupulous users looking for a shortcut that could really make a mess of things. How do you prevent that? The software is trying to do that by locking things down. Take away the locks and you could have trouble. Fortunately our database manager does allow for some flexibility in this but there is still a danger.

Tim Knier
QG Product & Support Engineering
QuadTech
A Subsidiary of Quad/Graphics
Sussex, Wisconsin
414-566-7439 phone
-<">mailto:->
www.quadtechworld.com<">http://www.quadtechworld.com>

[lylebeidler]

As a CAD admin/engineer for a company that may be "upgrading" from Intralink
3.4 to a Windchill solution this year, I've been following this discussion
with interest. It sounds like PTC abandoned the "Revision + Version"
paradigm in Intralink when it introduced Windchill. Is that the case? If
so, I'm with Chris - I think that was very shortsighted. The Version
handled things like adding datum points or CSO's very well; the fact that
the Version was automatically updated, where the Revision was a manual
decision, often based on Form, Fit, & Function, was a good idea. I don't
see why PTC abandoned this.

For us, to work around this, we may simply add a text parameter to our
models, call it, say "MGS_REV" and use that in place of the Revision
parameter in Intralink. We'll just have to update it manually. For those
of you who've already made the jump, does this sound like a good idea?



--



Lyle Beidler
MGS Inc
178 Muddy Creek Church Rd
Denver PA 17517
717-336-7528
Fax 717-336-0514
<">mailto:-> -
<">http://www.mgsincorporated.com>

[DamianCastillo]

Tim,

You have a very good point and the short answer for me is NO.

I would love to say that I can trust my users, but I know from experience that if they can get around something, they will. It's like telling a kid not to get a cookie from the cookie jar. It becomes their mission in life to get that cookie.

Having a system that locks down the correct process is key but not having any flexibility or options on how it does it is what I think can be improved. If you want to keep people out of your car, you can weld the doors shut and weld sheetmetal over the windows. That's a little extreme and a different approach can give you the security you need while making it practical for everyday use.

Windchill currently locks everything down so tight, that you don't have the flexibility to do real world things with your cad data and not cause some drastic revision change in the process.

Here is something that just happened today. We have a released product. QA wants us to provide them a Validation report that compares our Casting to the 3D model. We use Geomagic Qualify and our 3D Laser Scanner for this type of work. We need to add a coordinate system to the 3D model that Geomagic Qualify can use for the purpose of doing the Validation and getting the report back to QA.

Adding a coordinate system does not change the Form, Fit or Function of our product. In fact, it has NOTHING to do with the product we sell, but we are wanting to do some internal studies to make sure our product is the best quality possible. No one can convince me that adding a coordinate system for this purpose should force a Revision change on the product.

Windchill needs more flexibile options for handling this type of everyday work. The people at PTC are sharp individuals and their must be a way to make Windchill secure while giving it some felxibility. I hope they are working on it.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[DonSenchuk]

Having read through this thread, I must bemisunderstanding something, so please forgive me if this is the case.

What is it exactly that we're asking the software to do? I ask because the general feel seems a lotlike the complaints are all over the map describing a problem, specifying how to use the software to overcome the problem, then saying the software can't overcome the problem.

The ability to change drawing/model for minor details after it's released -- details like adding a datum axis or changing the color of a single surface for better contrast -- without increasing the revision level? Doesn't that exists with the ability to set up individual accounts or groups or roles to check those released objects out? The Product Manager role springs immediately to mind. It doesn't have to be a system administrator; just pick your most responsible software user and train them when it's okay to do this or not to do it.

If no user is responsible enough with the software and the internal company processes doesn't address this issue, no software is going to change that.

Someone mentioned having the adminmanually set state to allow users to check out, modify, then check in, but that simply gives the user a sort of ad hoc product manager permission, just for those few files instead of for everything within that product. If no user can be trusted (again, no software is going to address this) with product manager permissions and the admin is setting state on individual files, a workflow can be created to change parts to a state that allows modification, then changes them back upon completion. A manager fires off the workflow, it changes state of objects within it, the assignee checks them out, modifies and checks them in, finishes the assignment and the workflow changes the state back to released. This would limit the assignee to only changing those specific files.

What about the ability to track these "less significant" changes? If they're so insignificant that you don't want your vendors requoting a new revision (usually increasing price along the way) or your customers getting confused, just don't track them. If they have to be tracked, iteration history will do that for you. It's also my opinion that if they're significant enough to be tracked, then they're signifcant enough for a drawing/model revision. Revising is how significant changes are tracked.

This is opening another can-o-worms, but hey, why not bring it up? I was previously exposed to a different methodology concerning revisions. If the form, fit or function changes in such a way that the part in question is no longer 100% backward and forward interchangeable, assign a new number. In this way, when the customer says he has P/N 123456, it doesn't matter what revision he receives as replacement, it's always interchangeable. Then revising the drawing for minor changes is irrelevant from that standpoint. Of course this doesn't help with vendors requoting for simple changes like fillet size or other changes that don't affect that forward and backwardinterchangeability.

That tangent aside, what else are we looking for aside from the ability to check out released objects for "less significant" changes? Because that exists within the software as-is, in multiple ways. Since that ability exists, is this boiled down to needing to track these "less significant" changes more easily than viewing the iteration history? Or is it simply a matter where users cannot be trusted, so the admin is doing all this work (and feeling frustrated that users can't simply do this work correctly)?

[DarrinHiebert]

We're not on Windchill, and I've been following this thread with interest.



We're currently on a third party PDM that does NOT allow bumping revisions
/ versions without a change. ANY change, requires a revision level
change.



On the surface this may sound bad, but in reality, we like it that way.
It removes ALL loopholes from what's a change and what isn't. If you
touch it, and make ANY change, that's a change folks.



I wouldn't go so far as Timothy to say is it an issue of can you "trust"
your users, but I'll guarantee you that if there's a loophole that can be
exploited, and changes can be made without revisions, users will find that
and exploit it. I don't think that users would maliciously use this
functionality to bypass changes, but I think that they would make changes
that may not fit your companies criteria for what a change is and what a
change isn't.



And, to Chris's point, my companies position is that if you add ANYTHING
to a model, you're making a change. Our models are our bible. With our
system there is no room for interpretation of what's right and wrong,
what's allowed and what isn't. It's pretty cut and dried. But, I can
also see how other's may not like this type of system, but I guess that we
don't know any different because it's always been that way here.



YMMV.

[BenLoosli]

They have not abandoned this at all.
In Windchill you have your revision letters/numbers and an iteration number for each time you save that file.
Just like Intralink 3.x, once a file is released, it prevents normal users from modifying the file. As an admin, I can check out, make a minor change and check back in the same revision level part, juts it will have a higher iteration number.

The issue comes down to who has the rights to make a change to a released file and how much are they trusted!


Thank you,

Ben H. Loosli
USEC, INC.

[BenLoosli]

As an administrator, you can add the coordinate system and check the changed file back in at the same revision level.


Thank you,

Ben H. Loosli
USEC, INC.

[DamianCastillo]

Don,

You obviously know more about Windchill than me. We don't even have it up and runing yet. Let me be clear in that PTC did find a solution to minor changes and how to control them. The process requires manual intervention and users have shown that they make many mistakes when allowe the feedom to do so. The solution provided to us will require the "Administrator" to bump up the revision level as needed, but the end user can choose to check the product in as a minor revision regardless if they changed the product drastically.

There is a way to make it work, but it opens up room for error which is why we purchased the software to begin with.

Can there be a more intelligent way of having the system provide the flexibility while automating it at the same time? I have no clue and hope someone here can share a solution.

The lack of flexibility that I mentioned in the past is based on breaking automation and control in order to make things work as they should.

Is there an automated way for Windchill to notify me for approval before an end user check's something back into the system as "Released"? If there is, I would love to learn more about it. At least this way the manual process requires approval and can prevent the end user from just checking things in.

Thanks

P.S. I am a veteran Pro/ENGINEER (Creo) user with over 18 years experience. I know almost nothing about Windchill and will start my journey to learn it this year. So any help from the guru's would be great.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[lylebeidler]

Thanks, Ben, for that clarification. That is good to know.



--



Lyle Beidler
MGS Inc
178 Muddy Creek Church Rd
Denver PA 17517
717-336-7528
Fax 717-336-0514
<">mailto:-> -
<">http://www.mgsincorporated.com>

[DamianCastillo]

Ben,

As the "Administrator" to be. I would not be the person doing the actual work on the model. The Engineers' will. Is there a way to have Windchill 10 request approval from me before a user can check something into the system at the "Release" state?

If so, this would prevent Chaos. My biggest concearn is that the end user can check it in and choose not to notify me that a new Revision letter is required.

Thanks

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[bbenitez]

We have two "Admins" with privileges for just these occasions, and to
Maintain the integrity of our Family Tables.

They will review the file and force the check-in - and this only happens
once in a great while.

BUT

There will always be the "clever" who manage to try and cheat the system -
fortunately for us in our organization, we have no such clever individuals.

This makes life so much easier.



Regards



Anthony R. Benitez

Senior Mechanical Designer

Drafting Supervisor

Applied Research Laboratories

The University of Texas at Austin

[ptc-1932745]

I agree that it's either changed or it isn't. And remember, you will
probably have to formally document (and explain to an auditor) why/how
you are changing your CAD models and adding a manual step to the PDM
system to either 'roll back' the rev, or hold back the released status
of the models.



In the case above where a CSYS was added for inspection would fit in
well with my idea to create a new derivative model using an inheritance
feature for this purpose. The parent would not change revisions, the
derived model would be free to revise for internal reasons, and
everything has a history and is rev controlled and easy to explain to an
auditor.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

[Tundra]

And I second that motion by Ben....

In Reply to Ben Loosli:

They have not abandoned this at all.
In Windchill you have your revision letters/numbers and an iteration number for each time you save that file.
Just like Intralink 3.x, once a file is released, it prevents normal users from modifying the file. As an admin, I can check out, make a minor change and check back in the same revision level part, juts it will have a higher iteration number.

The issue comes down to who has the rights to make a change to a released file and how much are they trusted!


Thank you,

Ben H. Loosli
USEC, INC.

[ptc-1932745]

Excellent point. Creating interface groups, construction planes, etc...
would certainly not be seen by the 'end user' of the part drawing. But,
we are also keeping our internal customers secure buy locking down the
model. Someone inadvertently moving a datum plane or csys, etc... does
not change the F-F-F as far as the end use customer is concerned, but
can really screw up someone else internal to company.



No system is perfect, but as it is designed now, Windchill (and probably
most systems) will be very careful to ensure the integrity of the
models. Maybe the solution is to keep the part from being setup as
'released' until later in the testing / proveout phase to keep from
having so many revisions.



I can see that this could be a problem mostly for hardware, where you
may want to add/change an interface for placement. This will cause the
hardware item to be revised, and trickle down to many assemblies that
are automatically marked for revision as well. In this case, it may be
advantageous to consider these parts not to be rev controlled, but I
don't know if Windchill can do this.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

[BenLoosli]

You would only have a limited number of administrators who have the rights to check in a file at the released state.
You can use email notifications when files are checked in.

Thank you,

Ben H. Loosli
USEC, INC.

[DamianCastillo]

Thank you for the great feedback Ben. I also want to thank everyone else for their feedback and perspectives. I am here to learn form all of you because this is a new area for me.

I will look into my options and see what makes the best sense for us. I simply can't allow Windchill to dictate what get's a revision and must find a way to control it with privileges, etc.

In Reply to Ben Loosli:

You would only have a limited number of administrators who have the rights to check in a file at the released state.
You can use email notifications when files are checked in.

Thank you,

Ben H. Loosli
USEC, INC.

[davehaigh]

If you let the model revision be different than the drawing revision you solve all these problems.

Initial Release
Model = A.3
Drawing = A.5

Model only change
Model = B.2

Drawing and model change
Model = C.4
Drawing = B.3

You can show the revision and release state of the model and drawing in a table on the drawing. They don't have to be in sync that's what PDMLink is for to keep track of these relationships.

[cid:image003.jpg@01CCE0C9.5F1D0F10]


David Haigh

[DonSenchuk]

"...when allowed the freedom to do so."

I see where you're coming from now. Users, especially super users like admins or product managers, must be held accountable.

Like so many examples in the past, PTC's "solution" sounds like they half listened to the problem, then gave an answer. It sounds like their solution is to allow users to check stuff out for minor modifications, then check it in regardless of what they've done to the model/drawing. If I read you correctly, that doesn't even come close to being a solution to they problem you're describing, IMO. In fact, going down this route would be far worse than having the admin make all the minor corrections.

I don't know your internal process, so of course I can't really be sure if my input would work.

For normal revisions, where the drawing/model actually is going to be revised, it sounds like your normal process would work. There are workflows within Windchill that can automate this process as well, but no company I've worked with has used out of the box workflows. That means custom workflows.

As for changes without a revision, such as the aformentioned spelling errors or addition of a datum axis, I see two big options.

1. Within Windchill is a role called Product Manager. The PM can be set to check out any object, modify and check back in. Find a user (or a couple) that you trust not to abuse this power. Explain the pitfalls of this power. Do not give their standard account this permission; create a separate PM account for the user(s). When doing normal work, they will log in with their normal accounts. Only when asked to do changes to released parts will they log in with their PM account. I'd also explain that if the parts this is done to change more than insignificantly, the data will be deleted and the work will have to be done over. I know that's rather harsh, but sometimes you have to use a hammer to drive home the point.

2. Create a workflow that a reviewer/manager can fire off. Limit who can start this workflow.This workflow can set the life cycle state to one that can be modified. (You could even make a life cycle state specifically for this process.) The workflow creates an assignment for the user. The user does the work and checks everything back in. Before the work flow is finished, the reviewer/manager is given an assignment to look at the work that was done. He can reject it back to the user for correction, orapprove it as complete. Only after he approves the workflow does the object get set back to the released (locked) state.

You asked if there is a way for Windchill to notify you before the user checks in the work. With enough time and money, anything is possible, but I'm not confident the workflow commands as they currently existcan handle this. Option #2 comes closest, allowing a review before setting the drawing/model back to released, but it has already been checked in by the time the review takes place.

While I certainly don't consider myself a true Windchill guru, I've been exposed to it enough to have a fair idea what it's capable of regarding this particular problem. If this wasn't clear enough, let me know and I'll do what I can to clarify what I'm talking about.

In Reply to Damian Castillo:

Don,

You obviously know more about Windchill than me. We don't even have it up and runing yet. Let me be clear in that PTC did find a solution to minor changes and how to control them. The process requires manual intervention and users have shown that they make many mistakes when allowe the feedom to do so. The solution provided to us will require the "Administrator" to bump up the revision level as needed, but the end user can choose to check the product in as a minor revision regardless if they changed the product drastically.

There is a way to make it work, but it opens up room for error which is why we purchased the software to begin with.

Can there be a more intelligent way of having the system provide the flexibility while automating it at the same time? I have no clue and hope someone here can share a solution.

The lack of flexibility that I mentioned in the past is based on breaking automation and control in order to make things work as they should.

Is there an automated way for Windchill to notify me for approval before an end user check's something back into the system as "Released"? If there is, I would love to learn more about it. At least this way the manual process requires approval and can prevent the end user from just checking things in.

Thanks

P.S. I am a veteran Pro/ENGINEER (Creo) user with over 18 years experience. I know almost nothing about Windchill and will start my journey to learn it this year. So any help from the guru's would be great.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[jonesc]

Don,
with regards to the "Super user" login.

At a previous company we used this method but made sure the normal user login did not have super powers and the super user login did not have day-today powers or functions.

This forced the Super users to NOT use the Super user login for everything and avoided "accidents"
It also helped when tracking who made changes that each Super user had their own Super user login.

[DonSenchuk]

I mention giving a single user two accounts because I was that guy for awhile. I had my normal account that I did day to day work with, plus I hada second account as a Product Manager where I could correct minor issues with CAD parts/drawings, revisions, life cycle states, etc. You're correct in saying it avoids accidents, but only if the admin trusts a single user not to screw things upby accidentally using the PM account for normal work.

In Reply to Craig Lobban-Jones:

Don,
with regards to the "Super user" login.

At a previous company we used this method but made sure the normal user login did not have super powers and the super user login did not have day-today powers or functions.

This forced the Super users to NOT use the Super user login for everything and avoided "accidents"
It also helped when tracking who made changes that each Super user had their own Super user login.

[pperry]

In most situations released data should not be changed -- there is legal ramification for this (think OSHA certification). To blame the tool is being a bit naive. The problem is users are depending on the tool and NOT checking things as well as they should (or are being pressed to get things done more quickly than humanly possible). If a datum is visible on a drawing and that drawing was pushed to release, it is not the fault of the tool. If the corporation's process is objects should not be modified when they reach a released state, that is not the fault of the tool.

When I first started in PDM the vendor told me a two very wise statements. What is the best thing about a PDM tool, it can do whatever you want it to do. What is the worst thing about a PDM tool, it can do whatever you want it to do.

Windchill is very flexible, best practices through going to several companies has put limits on some freedoms. Can Windchill change any object in the database, if you want it you -- but do you really want it to? Can Windchill be designed to allow a group of users (other than Administrators) to change released objects -- it certainly can. My question would be in I am making several changes at released I maybe need to look at my process because certain steps are being missed. For the gentleman that need a coordinate system for verification, why not make that part of the process so that every model has that -- it no verification is required no harm. If verification requirement comes after release, then no change is required.

This discussion should not be about Windchill, Windchill is just a tool. This discussion should be about the process of getting objects to be production ready and what is the best way to insure those objects are ready for anything.