Document Control ECO (Engineering Change Order) or QMS?

somashekar

Leader
Admin
1. Missing Part Number on redlines
2. Typographical errors
3. Incorrect redlines
4. Incorrect revision on Artwork
5. Incorrect Specifications
6. Inadvertent removal of CE mark
7. Vendor can’t print gridlines (Inadequate Design Transfer)
8. Missing DEHP symbol from finished labels
9. Sterilization Code inadvertently changed from GAMA to EO

All these shows just one process.

The lack in depth of review and approve process of a C/O

My question is whether you can ever get 100% perfect C/O's with no mistakes? Since no process can ever be perfect, including generating Engineering Orders, what is an acceptable number of defects or errors. I can't think of a way you could ever Poka Yoke a change order system. Engineers are useally very careful but they too can occasionly make an error.

My answer is YES.
It is not about perfection, but about application and review / approve hierarchy, who know well what is needed, and when an C/O meets that, it is good for now, till a new input calls for an other C/O.
C/O must come out of need and not out of error, miss, slip, oooh I forgot stuff.
C/O is a serious stuff that can effect adversely a huge quantum if careless about anything, big or little stuff.
 
Last edited:

Wes Bucey

Prophet of Profit
This may be slightly off the topic of C/O's but I am working on a CAPA for a failed effectiveness check related to Engineer Orders or C/O's. They pulled a sample of several dozen C/O's and looked for errors such as:

1. Missing Part Number on redlines
2. Typographical errors
3. Incorrect redlines
4. Incorrect revision on Artwork
5. Incorrect Specifications
6. Inadvertent removal of CE mark
7. Vendor can?t print gridlines (Inadequate Design Transfer)
8. Missing DEHP symbol from finished labels
9. Sterilization Code inadvertently changed from GAMA to EO

My question is whether you can ever get 100% perfect C/O's with no mistakes? Since no process can ever be perfect, including generating Engineering Orders, what is an acceptable number of defects or errors. I can't think of a way you could ever Poka Yoke a change order system. Engineers are useally very careful but they too can occasionly make an error. :frust:
One set of eyes is rarely enough. It's the reason most organizations require multiple approvals before a document is finally adopted into a system. The problem arises when folks in the approval chain merely "rubber stamp" a document without actually examining it to assure its correctness and validity.

In my own organization, we certainly had some "missteps" during the approval process, but I can't remember one that ever went through the entire set of approvals with an error undetected until AFTER final adoption.
 
Thanks Wes,


You are correct generally there are people on assigned to the Change Review boards who should and nearly always find any critical issues, but the minor issues many times are overlooked.

Like so many other processes, there are defects or in this case errors that might be considered critical to the change being considered for change and others that are more what i would say are cosmetic or clerical errors. Clerical errors generally are not going to affect the change under consideration, but those changes that affect patient safety would be very serious and shouldn't be tolerated.

We are trying to figure out first what if anything that can be done to reduce errors in general, but certainly those errors which I would consider Critical should be zero. Beyond what I am asking is how to write an effectiveness criteria that would allow for some number of minor or clerical errors without failing the effectiveness check again. If there were critical errors those would fail the effectiveness check but not minors unless they are too numerous.
 

Wes Bucey

Prophet of Profit
Thanks Wes,


You are correct generally there are people on assigned to the Change Review boards who should and nearly always find any critical issues, but the minor issues many times are overlooked.

Like so many other processes, there are defects or in this case errors that might be considered critical to the change being considered for change and others that are more what i would say are cosmetic or clerical errors. Clerical errors generally are not going to affect the change under consideration, but those changes that affect patient safety would be very serious and shouldn't be tolerated.

We are trying to figure out first what if anything that can be done to reduce errors in general, but certainly those errors which I would consider Critical should be zero. Beyond what I am asking is how to write an effectiveness criteria that would allow for some number of minor or clerical errors without failing the effectiveness check again. If there were critical errors those would fail the effectiveness check but not minors unless they are too numerous.
The issue comes down to WHO is in the approval chain, WHAT they think their individual purpose is when the document comes to them for approval.

If the document concerns "engineering" - probably should have engineers (more than one) in the approval chain, examining it from an engineering perspective, to assure critical matters of engineering are not missed because of inability to recognize or understand the engineering aspects of the subject.

Similarly, as the subject matter impinges upon other areas/departments of the organization, individuals with expertise in those areas should also be in the approval chain. It may be all well and good for an engineer to specify a special feature or characteristic of a revision to a product, but someone needs to look at it from a MANUFACTURING point of view to determine if the organization has the capability and capacity to execute that change in terms of equipment and skill set of personnel.

THEN, someone else to look at it from the standpoint of inventory and logistics - are different materials needed? what do we do with existing inventory? is a new patent involved? what about pricing? packaging? labeling? marketing? etc.? etc.?

The point is the APPROVAL TEAM SHOULD BE CROSS-FUNCTIONAL and each should be aware his/her expertise is always critical to the review and approval process, never just a way station where someone says, "Ho hum. This came from George, it's OK to save time and just sign my name."

One final point: It is a TEAM, not adversaries looking to one-up each other. They need to work toward a common goal of an effective, efficient change, not a game of finger pointing to gain advantage over someone else on the team. It is never a game of GOTCHA.

So, to achieve this TEAM, the selection and training process is important. A person on an approval team is chosen for expertise to add to the process, not merely selected because he happens to be a favorite [or "unfavorite"] of the department head. The organization needs real input. The TEAM does need training of the kinds of things that each of their specialties is expected to be specially checking plus the kinds of things they might "casually" notice as they review the document.

Last comment on the TEAM: each person should be proud to be on the team; anyone who feels it is a burden probably needs to be replaced, retraining probably would not change such a mindset. This means a top manager with the power and authority to make a change needs to periodically interview team members and review their work to determine whether he/she is a contributing member or deadwood.
 

Wes Bucey

Prophet of Profit
May I suggest you add the following to the cover sheet which accompanies any changed document as it makes the rounds for approval before becoming the most recent version?
Quote:
_Change Classification
_Class I - Form, Fit, Function
_Class II - Clarification, Correction
_Class III - Long Lead Release Only

ChangePriority
_Low
_High
_Medium

Engineering Change Notification
     
Reason
_New Release
_Revision to Existing
_Design Change
_Product Improvement
_Post-Production Modification
_Customer Request
_Supplier Request
_Other (explain below)

Stock

_Stock is not Affected
_Utilize Remaining Stock
_Purge Stock and Rework
_Purge Stock and Scrap
_Other (Explain)

Impact

_Incorporate on Next Order
_Incorporate on Next Installation
_Affects Current Production Units
_Affects Fielded Units
_Not Affected (New Release)

Cost & Schedule

_No Cost Change
_Cost Increase
_Cost Decrease
_No Schedule Change
_Schedule Delay
_Schedule Improvement
 
Top Bottom