Documentation Pyramid - Transitioning from one document control system to another

T

tkevmoore

This may seem like an off the wall question but my company is in the midst of transitioning from one document control system to another and we are using this opportunity to winnow out duplicate, outdated or otherwise unnecessary documentation. We have numerous controlled forms (have a document number & revision) that are not referenced in any procedure. There are also controlled forms that may be referenced in a work instruction, but that work instruction is not referenced in any other documentation (procedure or policy). My contention is that both of these need to be linked to some documentation otherwise how are we to know when or how they should be used. Also this would seem to be implied with the documentation pyramid of Quality Manual at the top followed by Procedures, Work Instructions, Forms, & Records.Am I off the mark on this?

Thanks for your always informative feedback.

BTW: we are an AS 9100 house.
 

AndyN

Moved On
Re: Documentation pyramid

For the documentation to be a description of a 'system', you'd expect that there was some linkage, IMHO. So, I believe you're correct.

I have a different view about the use of a pyramid to describe documentation, however. Especially since the advent of the process oriented requirements of ISO 9001 and, hence, AS9100. I'd recommend throwing it out as an old fashioned concept. Modern standards don't rely as much on documented procedures, emphasizing the use of documents to describe/control the processes of the qms.

Therefore, it might be that a WI is all that's required. Indeed, if a form is correctly designed, it might be the only level of documentation under a high-level description/diagram of the 'sequence and interaction' of those processes...
 
B

brahmaiah

This may seem like an off the wall question but my company is in the midst of transitioning from one document control system to another and we are using this opportunity to winnow out duplicate, outdated or otherwise unnecessary documentation. We have numerous controlled forms (have a document number & revision) that are not referenced in any procedure. There are also controlled forms that may be referenced in a work instruction, but that work instruction is not referenced in any other documentation (procedure or policy). My contention is that both of these need to be linked to some documentation otherwise how are we to know when or how they should be used. Also this would seem to be implied with the documentation pyramid of Quality Manual at the top followed by Procedures, Work Instructions, Forms, & Records.Am I off the mark on this?

Thanks for your always informative feedback.

BTW: we are an AS 9100 house.
It is difficult and not mandatory to link all forms to the manuals mentioned in the documentation pyramid.But the general convention is to reference (link)procedures in the apex manual and reference(link)forms to procedures.You have to list forms at the bottom of the procedures.
V.J.Brahmaiah.
 

dsheaffe

Involved In Discussions
You will probably end with with as many opinions on how to approach as there are members on the forum, but in the end of the day, take them all on board and find the approach that will best fit your needs (and you might find it won't be a single approach, but a combination of many).

I am currently going through a similar process, but I have 3 seperate QA systems that I am trying to consolidate into one. So in general terms, this is how we are trying to approach it. Our starting point is process maps, starting at a relatively high level and then where appropriate, more detailed maps below. Linked to the process maps will be a combination of procedures, work instructions and forms - depending on the need (eg, we don't want to create a procedure for no reason just to link to a work instruction).

So we do have a "traditional" document structure, but only where needed. So if all we need is a process map and then a form, that is all that we will have. What will happen though is that we will ensure that we don't have any "orphaned" documents where we have a procedure, form, etc that doesn't eventually link back to a process map.

Dave
 
D

DrM2u

Like dsheaffe said, you'll end up with many approaches to this but you'll have to build what suits you best. I have two bits of information to add for your consideration.

First, below is a link to sample Change procedure (I already attached it in another thread) that makes a direct reference to specific forms and general documentation. Note that there are no form numbers, just names. This makes it easy to identify what a document is without needing an index. The revision corresponds to the last date when the document was created/edited. The control is via limited access to the editing capabilities and via using the Change form to review & approve release or changes before implementation.

ECO (Engineering Change Order) Implementation checklist/work instruction

Second, there is possible to have forms that do not link to a procedure. The ISO 9001 and many other standards do not require documented procedures for every process or instructions for every task. The one thing to keep in mind when reviewing the need for a form is if that form will become a record. In other words, is it a form to collect data and retain as a record or is it a form just to collect data for whatever reason? The form needs to be controlled if it will be retained, otherwise there is no need to control it. After all, you can collect some data on a napkin then transfer it to Excel for analysis, let's say. Your colleague might do something similar with another set of data. Will you control the napkin or the way you draw a table on it and organize your data? The correct answer is 'only if you are going to retain that napkin as a record'.

Hope this helps along with the other input.:cool:
 
J

JaneB

You will probably end with with as many opinions on how to approach as there are members on the forum, but in the end of the day, take them all on board and find the approach that will best fit your needs (and you might find it won't be a single approach, but a combination of many).
Well said and excellent advice.

Our starting point is process maps, starting at a relatively high level and then where appropriate, more detailed maps below. .... we will ensure that we don't have any "orphaned" documents where we have a procedure, form, etc that doesn't eventually link back to a process map.
Sound approach and reasoning.

there is possible to have forms that do not link to a procedure.
Yes it's possible to have forms that don't link to a written procedure, but ultimately every form should be used in a process.

No form exists in isolation from a process.

Whether or not there are written procedure/s for the process (and indeed, whether or not the process itself is documented) is up to the organisation to decide.
 
J

JaneB

You have to list forms at the bottom of the procedures.
Not true. You don't.

This may be a preference of yours, you may believe it's normal, good practice, standard practice or anything else in your opinion, but it's most definitely not mandated anywhere, nor required.
 
B

brahmaiah

Not true. You don't.

This may be a preference of yours, you may believe it's normal, good practice, standard practice or anything else in your opinion, but it's most definitely not mandated anywhere, nor required.

I have suggested a widely used format which is based on ISO/TR 110013 Guide lines. YES, it is not mandatory.
V.J.Brahmaiah
 
Last edited by a moderator:
J

JaneB

I have suggested a widely used format which is based on ISO/TR 110013 Guide lines. YES, it is not mandatory.
The clarification is important. Yes, I agree it's an often used format - I even use it myself at times.
:topic:
Mr Brahmaiah, you may think I and others are being picky here (and on similar occasions), but there is a big difference between the following two types of English statements. The difference is critical.

  1. One way to do this is to list forms at the end of a procedure.
    I often recommend listing forms at the end of a procedure.
    XYZ Guidance document suggests listing forms at the end of a procedure.
    A common way of doing this is to list forms at the end of a procedure.
  2. You have to list forms at the end of a procedure.
    You must list forms at the end of a procedure.
    Forms must be listed at the end of a procedure.
    Forms shall be listed at the end of a procedure.
When sentence constructions like #2 are used in English, the meaning is that it's mandatory. Not optional, not just one way of doing something, not guidance, but mandated.

Given that we're in a forum that regularly discusses what is mandatory (prescribed by a Standard) and what is not (including guidelines, opinion and belief), the distinction is far from minor.

Bottom line: when someone says something in the Cove that isn't true and has zero factual basis, other knowledgeable Cove users will contradict you. :nope:

If you continually choose to use sentence constructions like those in number 2 on occasions when it is wrong to say so (ie, isn't true), you will be regularly contradicted.

Why not consider adopting sentence constructions like those in number #1, making plain that you're simply expressing an opinion? It would be so much clearer and easier for all. :yes:
 
Top Bottom