Procedure Change Request Form - "ISO Procedures" Document Changes

[LesPiles]

Hello everyone,

I was wondering how you handle requests for changes to your ISO procedures.
When I joined the company for which I am currently working, an Engineering Change Request (ECR) form was used. Document Revision of procedure was indicated in footnotes by the Engineering Change Notice (ECN) Number.

Considering that ISO procedures are management procedures and want to disassociate from the "engineering culture" a we judged a little too strong, we have abandoned the ECR form explaining to employees that Engineering Dpt. is not involved in any way.

Traceability of changes would be covered either by referring to a corrective or preventive action request (CAR or PAR) id, or by creating a table at the end of the document illustrating the history of changes.

However, over time, we have noticed the following negative elements:
• Few of our changes come from CARs or PARs (unfortunately we are not focusing on internal audits so that document changes don’t originate from CARs,
• Change Requests from originators are not submitted to the Quality Department but rather changed documents (eg they did not involve us ... ah, these silos!) - changes are already made once submitted,
• the results of the submitted corrections are often disappointing (both cosmetically and content).

It's nice to be a "process owner", but being a process owner doesn’t give to the person “all the rights”. We still have to:
• ensuring consistency,
• plan integration (obviously, the department that makes corrections always hopes to see its corrections to the procedures "immediately" processed, notwithstanding our priorities), etc.
• determine impacts on other higher level procedures (SOP -> QAP -> Manual) ("the pyramid").

We would therefore like to return to a change request form for a change to a procedure, in order:
• to "control" the change,
• to be informed from the beginning,
• to authorize it (important point);
• to report impacts to other procedures,
• to be assured of a correct deployment,
• to prioritize corrections in everything that needs to be done, and
• why not, to appoint a resource from the Quality Department (the secretary that we do not have yet!) to make the changes in order to guarantee consistency of format.

My question is: Can you give me an example of a form used in your organization and / or comment on how the change requests to ISO documents work in your organization?

Thanks to all !

LesPiles

 

[Stijloor]

Quick Bump!

Can someone help? Thank you very much!

 

[Golfman25]

Well the more obstacles you put in front of the change, the less change you will get. And I think running all changes thru the Quality Department is a bad idea as it creates an us vs. them mentality. A lot will depend on the makeup of your organization. But I would try to keep ownership of changes as close to the end users as possible, with maybe a review or veto by Quality at most.

 

[Pancho]

We have three nested PDCA loops. Changing to the system AND documentation is the Act part in each of these loops:

1)
Wiki changes. All documented information is on a wiki, and everyone in the organization is empowered to make changes. The wiki automatically records who changed what when. This is by far the fastest way to make quick improvements and avoids having to request changes and fill out forms. Over 90% of changes to our system/documentation are made this way. Obviously these are corrective actions, but they get done on the fly and don't produce a long paper trail. We can see them in wiki stats, tho. Also, process owners are notified when documents change and they can revert the changes, but this seldom happens.

2)
Formal corrective actions. When someone notices a non-conformity (in process, product, or whatever), and is not sure how to best fix it, she opens a Corrective Action Request in our Bugzilla-based CAR database. Complaints as well as internal and external audit NCs are logged in as CARs. The initial form for CARs has fields for Summary, Description, Type, Process, Subprocess and number of NCs (that's all). Type is one of the following: occupational hazard, client complaint, audit, internal complaint, supply NC, tendency, preventive.

The Bugzilla record can hold an asynchronous discussion that the process owner leads, as well fields for root cause analysis, corrective action, etc. Improvements made to the system as a result of formal Corrective Actions are usually larger than those in (1), and often require simultaneous modification of several documents. But even so, the total number of changes to documented information is less than 10% of all. This is not to say these changes are not important. They are.

3)
Improvement projects. Actions required on the system that demand more time or money than our regular work allows are elevated to "Improvement projects". These will get assigned a project manager, a budget, their own wiki, and are followed up in periodic meetings until complete. The number of these are negligible, maybe half a dozen per year, but they are the biggest changes to our system.


So that's how we handle requests for changes to our ISO procedures.

 

[Duke Okes]

Google "document change request form" and either click on some of the links and/or click on Images.

 

[Crusader]

Well, I have this "Process Change Request" form that was created just recently. Someone asked me to create a brand new form to document changes to a process before it actually changes or does not. This form is a first stab and we have used it twice. No complaints yet other than I don't really think we need it. But, I was requested to create it and implement it.

Would this work for you?