I'm currently in an AS9100 Lead Auditor training class. One of our exercises involves reviewing a sample manual and verifying it's compliance to Section 4.2.2 (same in ISO as AS). One of the clauses in the sample manual stated:

In our quality system, documented procedures are those procedures that are required by the ISO 9001:2000/AS-9100 standards. Other procedures , work instructions and documents are used for reference, guidelines and training purposes only and are not followed precisely as written

This apparently was based on a real life example and was not non-compliant to the standard. I know my instructor wants us to think out of the box, but it's very hard for me to get past 10 years of ISO auditing to accept that documents don't have to be followed. Someone help me see the light.

Thanks

Tom

In a process-based management system, what is important are the outputs of each process. Procedures are step-based collection of activities that define how to do something, and, because of past misinterpretations of auditors and users, generally have nothing to do with the output of the process, only with the output of the procedure.

It´s really not that much important how you get to the output needed if you consistently do so. Controls (and they´re generally related with procedures) are only needed if you do not consistently procedure the desired output (this is measured by the way by your process kpi which is related with the process objective, meaning the process output).

I'm currently in an AS9100 Lead Auditor training class. One of our exercises involves reviewing a sample manual and verifying it's compliance to Section 4.2.2 (same in ISO as AS). One of the clauses in the sample manual stated:
In our quality system, documented procedures are those procedures that are required by the ISO 9001:2000/AS-9100 standards. Other procedures , work instructions and documents are used for reference, guidelines and training purposes only and are not followed precisely as written.

This apparently was based on a real life example and was not non-compliant to the standard. I know my instructor wants us to think out of the box, but it's very hard for me to get past 10 years of ISO auditing to accept that documents don't have to be followed. Someone help me see the light.

Thanks

Tom

My only issue with it is that if an auditor were to observe a process being operated "precisely as written," it would be a nonconformity. If it were to say, "...not always followed precisely as written," it would be OK.

I'm currently in an AS9100 Lead Auditor training class. One of our exercises involves reviewing a sample manual and verifying it's compliance to Section 4.2.2 (same in ISO as AS). One of the clauses in the sample manual stated:



This apparently was based on a real life example and was not non-compliant to the standard. I know my instructor wants us to think out of the box, but it's very hard for me to get past 10 years of ISO auditing to accept that documents don't have to be followed. Someone help me see the light.

Thanks

TomTom, firstly, I would like to commend you for being upfront about your question. Sometimes, people come here asking for help with a situation similar to yours, but they pretend it is something else, rather than some type of training exercise.

The training you are undergoing and the instructor probably have some kind of "expected" answer for the scenario you describe. I don't know the expected answer. However, if this scenario is indeed based on an actual manual, we would have a situation where an organization is trying to preempt possible non-conformities in case an auditor finds a process not following the requirements of these "additional" procedures, work instructions, etc....

It is a silly game. What is the purpose of having "reference documents" if they don't serve the purpose to define the processes and activities?

ISO 9001 4.2.1 d) states documents needed by the organization to ensure the effective planning, operation and control of its processes, and emphasis is mine.

So, what you have here is an organization trying to create a preemptive loophole in case they are caught not following their own command media. They can not, in my opinion, state something in the manual that contradicts the standard they are supposed to comply with. A good discussion will ensue, I suspect.

PS. Is your instructor, proponent of out of box thinking, a habitual Cover?

The company I work for would love to use that in there procedures. They do not currently word it in that way but do it anyway.
But to help with your question.
My company references all customer supplied quality requirements. For example, our largest customer has requirements that cover everything from sampling, to gaging requirements for 3A threads. The problem with this statement, from my own experience at this company, is that some work instructions are required by each and every operator and inspector. How would a company define which are to be "followed precisely as written" and which are not? It may help them pass an audit, but when something goes wrong in the field there is nothing documented as to what was or was not performed during the manufacturing process. Work instructions can be ever changing on the floor but never make it to document control.

As to the comment from mmantunes...It may not be important how you got to a consistently manufactured product until something goes wrong then the first question from engineers and supervisors alike is ... Did you follow the work instructions? Because it is the first step in eliminating factors to get to the root cause.

The training you are undergoing and the instructor probably have some kind of "expected" answer for the scenario you describe. I don't know the expected answer. However, if this scenario is indeed based on an actual manual, we would have a situation where an organization is trying to preempt possible non-conformities in case an auditor finds a process not following the requirements of these "additional" procedures, work instructions, etc....

It is a silly game. What is the purpose of having "reference documents" if they don't serve the purpose to define the processes and activities?

I agree with Sidney. If they're needed, one can state how & when and/or state when they can or should be ignored.

Often this kind of thing occurs when either procedures/documents aren't well structured (eg, procedures are far *too* prescriptive and more detailed than they need to be, or the structure doesn't allow for differences at the detail level) or they're not kept current. Either of which can be - and should be - fixed.

But I do wonder if it's actually the simpler answer, from the wording of the Q itself:

documented procedures are those procedures that are required by the ISO 9001:2000/AS-9100 standards
and if it's just the common old chestnut of 'we only have to have 6 procedures in our quality system because that's all ISO requires'. In which case the response is no, not OK, and the ref. that Sidney gave - ISO 9001 4.2.1 d)

As to the comment from mmantunes...It may not be important how you got to a consistently manufactured product until something goes wrong then the first question from engineers and supervisors alike is ... Did you follow the work instructions? Because it is the first step in eliminating factors to get to the root cause.

Yes, exactly so. You nailed it.

As to the comment from mmantunes...It may not be important how you got to a consistently manufactured product until something goes wrong then the first question from engineers and supervisors alike is ... Did you follow the work instructions? Because it is the first step in eliminating factors to get to the root cause.

I´m not saying that there should not be procedures, just that the process approach to quality system is not about having 20-plus-steps procedures for everything, when the most important is the process output and not the output of a single procedure. This "procedures for everything" was generally what was done in the past and the main reason for the implementation of the process approach.

So, i don´t see a need for every procedure to be included in the quality system. Only the key procedures, key controls and key indicators. Other documents can, in my opinion, be used just as guidelines and that would be ok. IF a NC happen, then you can see if these guidelines were followed and if not, maybe you need to put some control in the form of a and detalied step which HAS to be followed and put this in your quality system, but not the other way around (creating a web of procedures that no one will follow and consequently putting your system at risk of meeting a bad auditor which still thinks in the "write what you do, do what you write" way).

We have just made a change in how we handle these. We use Work instructions for when it needs to be done the same way or it can affect quality. The next tier below that is what we call Standard Work. These are considered the "Best" way to do a task but it can be done other ways without comprimizing quality. Work Instructions are auditable and Standard Work is not.
We just cleared an ISO audit and they had no problem with this approach. It does force you to look at the significance of the document!

So, what you have here is an organization trying to create a preemptive loophole in case they are caught not following their own command media. They can not, in my opinion, state something in the manual that contradicts the standard they are supposed to comply with. A good discussion will ensue, I suspect.


I think you're ascribing motive (trying to create a loophole) without enough evidence of intent. There are times when the best-laid plans go astray, and the documentation doesn't account for unexpected possibilities. To say that production should be delayed (and perhaps customers should be disappointed) while documentation catches up with necessary process changes is short-sighted, imo. Sometimes you have to do things on the fly.

I think you're ascribing motive (trying to create a loophole) without enough evidence of intent.Yes. Guilty as charged.:cool: There are times when the best-laid plans go astray, and the documentation doesn't account for unexpected possibilities. To say that production should be delayed (and perhaps customers should be disappointed) while documentation catches up with necessary process changes is short-sighted, imo. Sometimes you have to do things on the fly.I agree. I would not propose such nonsensical approach.

But to state in a manual that most of our command media does not need to be followed in a disciplined manner is also nonsensical, imo. Because, as already pointed out, how will the workforce know which requirements need to be followed and which ones do not?

:topic:
I´m not saying that there should not be procedures, just that the process approach to quality system is not about having 20-plus-steps procedures for everything, when the most important is the process output and not the output of a single procedure.

MMantunes, I agree with you that one doesn't need 'procedures for everything' and the process approach is most definitely not that.

But I think that there's some indication that we're starting to go off topic here and into a different discussion. (I may have contributed to this!)

The OP's original question related to a question about whether a particular manual complied with requirements, and more specifically, whether a statement in the manual was OK or not.

But to state in a manual that most of our command media does not need to be followed in a disciplined manner is also nonsensical, imo. Because, as already pointed out, how will the workforce know which requirements need to be followed and which ones do not?

Again, I think you're assuming too much. A well-disciplined, effectively-trained workforce understands the requirements and understands the conditions under which they may be breached. While I might have worded the passage in question a bit differently, I have no problem whatsoever with its apparent intent. If "the organization" is running amok as a result of the dispensation, it should be apparent to an auditor.

The OP's original question related to a question about whether a particular manual complied with requirements, and more specifically, whether a statement in the manual was OK or not.

Jane, i might be interpreting the original question wrong, but it seems to me that Tom was asking WHY the statement was right (..was not non-compliant to the standard..), not IF it was right or wrong. That´s why i tried to explain my view based on the process approach and why i think the statement was right. So, no off-topic IMHO.

A well-disciplined, effectively-trained workforce understands the requirements and understands the conditions under which they may be breached

Jim, i think you really got to the point here. Well-trained, disciplined and conscious (as in "i know what i have to do and the dependencies on me doing the right thing") workers do not need to have a controlled document documenting every step of what they´re well trained to do. If things go wrong in the end of the process (and not necessarily in the end of the "non-documented procedure", it will be apparent to management by using the right process indicators, and them they can exert more control if needed.

I have no problem whatsoever with its apparent intent.You assume you know the intent. I confessed I made assumptions about the intent of the text. Neither one of us really know the "intent", because that is a fictional manual from a classroom course exercise. If "the organization" is running amok as a result of the dispensation, it should be apparent to an auditor.True, but the OP scenario is just a desktop review exercise. Our perspectives are different. Your perspective is from an implementator who wants some degree of flexibility, instead of dogmatic, cast in stone, pieces of command media. Which I fully support, by the way.
My perspective, on the other hand, is from an external auditor, exposed to a myriad of games people play in order not to be "written up". Since the OP was (or is) participating in an auditor training course, I think he has to wear the hat of an auditor for the purpose of the exercise, when making his considerations. As an auditor I would (at least) flag that comment up and discuss with the author of the manual what exactly they mean by it.

Lots of very good and sound points from all.

Alas, quite often the fictional manuals used in such exercises are very poor; too often just made up examples, and could be much better (at least in my experience!)

As an auditor I would (at least) flag that comment up and discuss with the author of the manual what exactly they mean by it.

Me too.

:topic:

'MMantunes'? An amusing handle... but perhaps you do a lot of whistling while you work.

…just to butt in… I believe that procedures (or working instructions) are made not really for the person who is already working on that process for a very long time…

…I believe, procedures & working instructions are made for: :read:

- to standardized the step by step execution of an activity... to at least minimize “variance” that can contribute to the defect…

- for new employee or personnel who is going to perform the activity… it should serve him as guidelines of how to execute the activity step by step in a correct manner (even without the full supervision on the old timers)…

(there could be more significant reasons but those two I have given, for me, is already valid reason to establish and document your workplace)

…just imagine, if a certain process has no documented procedures and the only person who knew how to do it suddenly vanish on the surface of the earth without trace!?! :mg: this is one thing that ISO wants to prevent…

Sometimes you have to do things on the fly.


You do not build or maintain aircraft on the "fly"! No pun intended here. I'm a licensed A&P with literally thousands of hours of maintenace experience and the equivalent af hundreds of A-B-C-D checks, and regardless of my competence and experience I would not work on an airframe without using the relevant documentation. You do 1 thing out of sequence or deviate 1 time from what is required the results could be catastrophic. We ain't talking building a widget for a car bumper or headlight fixture in this scenario, we're talking aircraft, and procedures or work instructions are not "guidelines" like the "Pirates Code".

If work instructions/standard operations/whatever you want to call them, aren't to be followed then what is the point in having them?
Either enforce their use or get rid of them! What would be the point of having an instruction that is optional? What next? Writing instructions such as "Load part A into machine B, if you feel like it"?:sarcasm:

I certainly don't agree with including a "get out of jail free" clause in a quality manual! IMHO

We have also overlooked a number of other aspects of the organization - including the people doing the work, the management 'style' and the complexity of work being done.

McDonalds is a great example of where all three issues come together and still the process has to be (rigidly?) adhered to.

We have public (health) safety considerations, tasks performed by often inexperienced staff, plus a rigourous need for consistency but relatively simple production tasks. The process documentation is certainly not viewed as "guidelines", to be adhered to or not at a whim of the associate!

…just to butt in… I believe that procedures (or working instructions) are made not really for the person who is already working on that process for a very long time…

…I believe, procedures & working instructions are made for: :read:

- to standardized the step by step execution of an activity... to at least minimize “variance” that can contribute to the defect…

- for new employee or personnel who is going to perform the activity… it should serve him as guidelines of how to execute the activity step by step in a correct manner (even without the full supervision on the old timers)…

(there could be more significant reasons but those two I have given, for me, is already valid reason to establish and document your workplace)

…just imagine, if a certain process has no documented procedures and the only person who knew how to do it suddenly vanish on the surface of the earth without trace!?! :mg: this is one thing that ISO wants to prevent…

Let's add "Preservation of Knowledge." The most important asset an organization has.

Stijloor.

I was looking through ISO 10013 - 2003 Quality Management System - Guidelines for Quality Management Systems Documentation recently (as one does, when one is over-Olympic Gamed!;)

It lists all of these as purposes & benefits of having documentation, and even added in that ''includes but is not limited to' phrase as well!:

a) describing the quality management system of the organization;
b) providing information for cross-functional groups so that they may better understand interrelationships;
c) communicating to employees management’s commitment to quality;
d) helping employees to understand their role within the organization, thus giving them an increased sense of
purpose and importance of their work;
e) providing mutual understanding between employees and management;
f) providing a basis for expectations of work performance;
g) stating how things are to be done in order to achieve specified requirements;
h) providing objective evidence that specified requirements have been achieved;
i) providing a clear, efficient framework of operation;
j) providing a basis for training new employees and periodic re-training of current employees;
k) providing a basis for order and balance within the organization;
l) providing consistency in operations based on documented processes;
m) providing a basis for continual improvement;
n) providing customer confidence based on documented systems;
o) demonstrating to interested parties the capabilities within the organization;
p) providing a clear framework of requirements for suppliers;
q) providing a basis for auditing the quality management system;
r) providing a basis for evaluating the effectiveness and continuing suitability of the quality management system.[/I]

Now, not all of these will be applicable in every single organisation, but it's a good list to do some thinking about, and at least some of them will be. Sometimes folks forget that even if they don't 'need' the procedure themselves (because they know how to do it properly now), there's still more than one purpose to having one.

And no, it sure as hell isn't to do the 'load A into B if you feel like it'!

That said, it's sometimes hard for engineering/manufacturing (with its focus on the exact) to understand that at times procedures do need to leave decisions up to the intelligence of the responsible person. It's infinitely easier - and mroe intelligent - to write a step that says something like 'escalate complex cases to to the MD' rather than attempting to write a procedure that states what an employee should do in every single case.

As always, horses for courses. I take a lot of comfort in knowing, when seated in an aeroplane, that the building & maintenance thereof IS specified down to the super fine detail!