Allowing change outside the normal process?

[pcnelson]

How do you deal with "small" changes to Released objects, drawings for instance? For example, a dimension is left off and needs to be added. Some here would like to allow users access to Set State to bump an object from Released to Unreleased, make the change, then bump it back to Released. I am uncomfortable with that for several reasons (below), but don't yet have an alternate solution. I can see the need, but how to define and control it?

1) Production Access

a) This essentially recalls the object from Production. As soon as the object changes from Released to Unreleased, Manufacturing loses visibility (Latest Released object). If the object is currently in production and someone in Mfg accesses that object, they would now either see nothing, if there was no prior Released object, or they would see an earlier Released revision. The last choice allows the possibility of building to an out-of-date print and all the errors associated with it. The first choice stops production until they regain access to the drawing.

b) If the object is not moved back from Unreleased to Released and is Revised, it remains as Unreleased in the history and is not accessible as a previously Released revision.

c) This method requires someone to manage all the objects that have been moved outside of the normal process and ensure that they are moved back to Released.

2) Data Integrity

a) Allowing open access to change states has the potential for unregulated and unapproved modification of (Released) data.

3) Accountability

a) Once an object has completed the ECO process, Engineering has given its approval that this object is complete, correct, and ready for production. Why would it then need to be modified? What defines a “small” change vs. a “big” change?

[MikeLockwood]

Seems overly harsh but best in the long run to require a new Revision for ANY change.

Consider that as soon as for example B.2 Released is out there, anyone can print it and use it - even if B.3 Released follows it by 10 minutes. Now you have two Rev B released documents that are different - and all trust goes out the window.

[DonSenchuk]

I was always told that any time you revise a drawing (as in change it) you should revise the drawing (as in Rev to the next letter). Pretty simple.

One could also check ASME (Y14.35) or some other standard to see how it's handled there.

[BrianToussaint]

Hello Pete,

I would think that a dimension left off would require a revision change. What if someone printed out the drawing and now there would be two different versions of the drawing at the same revision floating around. I would think that there would be the need for a revision. For something like that, why not have a "short path" in the change notice? We have an attribute for CN TYPE and if it is a drawing only change, it skips some of the approvers. Makes it shorter and it still has traceability as well as State control.

The bigger question could be what should you do for those pesky broken assemblies in CREO/ProE or if you are driving wtParts from CAD and need to associate or fix an association? That is where the somewhat legitimate gripe might be made to allow the user to Set State. However that can be taken care of by setting up a CN soft type and having the task control the States. It would be a really short process with the person doing the fixing and an auditor making sure that they didn't change a BOM or drawing. The CN process will take care of the States and release it in the end. There is no need for revisions, but that doesn't necessarily help with production access. For that you could always have the user work on the objects under the continue state until it is ready to be processed and then create the CN and close it really quick. However, where this should only be for assemblies and parts, if your production floor uses only drawings then they should still be able to see the drawing.

Allowing users to Set State could be very disastrous. Users are like water, in that anytime there is pressure, it will take the shortest path. So if there is a hole in the pipe, it will leak.

Brian Toussaint
CAD Administrator

Hoshizaki America, Inc.
"A Superior Degree Of Reliability"
618 Hwy. 74 S., Peachtree City, GA 30269

[BenLoosli]

There is nothing done outside the normal workflow that changes a released drawing. Any change requires a revision.

You can, as pointed out, use a short quick change notice with less approval, but the change must be documented.

If you tie your models and drawings together, then the model revision must be bumped, also.

As Mike pointed out system integrity is at risk if you have multiple iterations of the same revision at Released.

[pwilliams-3]

I completely agree with the responses so far. There should be absolutely NO changes made to Released objects. No exceptions. Always revise the object and re-release. Otherwise the definition of Released means nothing.

Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image001.jpg@01CE9DB9.E319C2F0]

[daniel.garcia]

If the change is that small our users will ask me, the admin, to set state to Design, they do the change and check in, preferably with comments, then I set state to released. They don't have permission to do that by themselves.

I myself keep track of all changes in an Excel sheet. What was changed, when to design, when to released, who asked it and why.

Other situations we use this approach:
- parent assemblies that lose references due to some change in components. PDF is the same but will fail. We don't change revision but fix errors.
- family tables where you change an instance but not the others. We nevertheless check in all of them. So we revise only the changed one, and set state of the others.

Best regards

Daniel Garcia

Enviado desde mi iPhone

El 20/08/2013, a las 17:47, pete nelson <-> escribió:

> How do you deal with "small" changes to Released objects, drawings for instance? For example, a dimension is left off and needs to be added. Some here would like to allow users access to Set State to bump an object from Released to Unreleased, make the change, then bump it back to Released. I am uncomfortable with that for several reasons (below), but don't yet have an alternate solution. I can see the need, but how to define and control it?
>
> 1) Production Access
>
> a) This essentially recalls the object from Production. As soon as the object changes from Released to Unreleased, Manufacturing loses visibility (Latest Released object). If the object is currently in production and someone in Mfg accesses that object, they would now either see nothing, if there was no prior Released object, or they would see an earlier Released revision. The last choice allows the possibility of building to an out-of-date print and all the errors associated with it. The first choice stops production until they regain access to the drawing.
>
> b) If the object is not moved back from Unreleased to Released and is Revised, it remains as Unreleased in the history and is not accessible as a previously Released revision.
>
> c) This method requires someone to manage all the objects that have been moved outside of the normal process and ensure that they are moved back to Released.
>
>
>
> 2) Data Integrity
>
> a) Allowing open access to change states has the potential for unregulated and unapproved modification of (Released) data.
>
>
>
> 3) Accountability
>
> a) Once an object has completed the ECO process, Engineering has given its approval that this object is complete, correct, and ready for production. Why would it then need to be modified? What defines a “small” change vs. a “big” change?
>
>
>
>
> Site Links: View post online View mailing list online Send new post via email Unsubscribe from this mailing list Manage your subscription
>
> Use of this email content is governed by the terms of service at:
>