Procedures - Documenting the other requirements without procedures?

[ISO dog]

Only six procedures are specifically required for ISO 9K:2k (as opposed to 15 or so in ISO 9K:1994).

Obviously the committee wanted to cut down on the number of procedures. How are we supposed to document the other requirements withour procedures? Memos?

I'm not trying to be clever, I really don't know.

 

[Don Watt]

Originally posted by ISO dog:
Only six procedures are specifically required for ISO 9K:2k (as opposed to 15 or so in ISO 9K:1994).

My view is that you develop the procedures necessary to run your particular type of business, therefore you may have only 6 or you may have 66 depending on your requirements (for example we have different procedures for process control depending on the nature & type of process).

As long as you cross reference which procedures relate to each clause in ISO you shouldn't run into problems.

 

[Jim Biz]

ISO-dog - Glad you asked the question --- I struggled a bit with that one myself.

If the final version requires only 6 procedures - thats from a numbereing viewpoint only. If you count each sub-clause as a separate procedure - include the new additions as separate procedure items then how many are required?

I did this a while back so the figures arent exact - but as I recall the number of sub-clauses in the 1994 version was almost 59 possibles (if you view all sub-sections like 4.1.2.3 as a candidate for a separate procedure. Counted the same way the new version was almost 66. I did not however make a determination of which sub-clauses can/should be easily combined. Our current system covered the 1994 version - 59 or so sub-clauses with 27 separately numbered
procedures. When the new version is final I'll determine which of these it make sense to add to and which need to be set-out on their own merits. But remunbering and reducing our system to 6 procedures that are 35-40 pages long seems to be a non workable option.

Regards
Jim

 

[barb butrym]

Let me just say this about the number of procedures.....its the people who count them that make all this "ISO stuff" less valuable. The standard is saying its important......so we require these as a minimum....(they can all be in one !!!!!...if you want one long one...as above) as long as it is formally documented, reviewed, authorized and referenced in the QA system manual. But hell...if absence of a procedure affects the product quality ...even if the standard doesn't specifically spell it out...you're gonna need a procedure...so what makes since...counting them or creating what you need as a company?

Its also my opinion that renumbering makes no since..I don't plan to recommend it...but I do plan to recommend, to new implementations, my favorite numbering system that has no tie to the standard paragraghs, except on the master list.

[This message has been edited by barb butrym (edited 20 April 2000).]

 

[Jim Biz]

Barb- Cant' say I totally disagree with your viewpoint- My interest in counting the sections -and the only value to it - lies in the fact that most of the people I work with internally really want to understand how many "action items" are required by the standards,how many have been added, and where the additions will be placed, so they can maintain a clear-path-to and easily find the relevant information. - therefore the identifying "action number" breakdown.

Who declared 6 are required - Where it started or Why the new version is being generally promoted as requiring only 6 procedures - I'm not sure of - but I do agree with you that how many "procedure documents" has little to do with satisfying the requirements as long as what you decide on covers all the required actions.

 

[isodog]

Clarification alert!

When I wrote there were only six procedures required, I meant there was only six places in the DIS where it says "A documented procedure shall be established" 5.5.6, 5.5.7, 8.2.2, 8.3, 8.5.2, and 8.5.3 (count em!). This is in contrast to 1994's "The supplier shall establish, document, and maintain documented procedures..." that is in, I believe, in sixteen sections.
Surely you may write as many procedures as you want, but, for instance, 5.6 Management Review has no language requiring a procedure. If the committee wanted a procedure there, They would require one (since they do that in other sections, see above). My question is what the %$%#@ did they have in mind other than a procedure? If I could do it with a memo, the control overhead would be significantly reduced.
Dave

 

[barb butrym]

now to take the other side......

if you don't need a procedure don't do one. the committee is allowing you options that would serve you better...if there are any. I typically do not do a management review procedure for instance....even for 9000.1994.
What do I do? A bit of meat to the QA manual describing an agenda, action log and minutes as the record.

Sometimes its semantics...a flow chart to me is a form of procedure and I let it stand alone, to others its not...its a "flow chart" and then they write it again, attach it, and then call it a procedure.

With so many variations, you gotta talk the same language before you get into interpretations, or at least be flexible. The committee is allowing you to present what works for you, just be ready to justify it.

 

[Jim Biz]

Barb: The more I think about this the more I tend to believe we are all pretty much on the same page here if we’re as you point out “willing to take the flexible viewpoint”. Number them - however, count them - however (or not) describe the size of the animal in numbers - paragraphs - pages “shall do’s” or your own other terms so to speak. Define it as a procedure/document/flowchart/controlled memo or just plain “document reference” --- if it satisfies your auditor….. However, address in writing all of the language in a fashion that that can be justified and proven during an auditing surveillance -- for your particular business.

Back to the original posted question: “How do they expect us to document this?” would everyone agree that we can do it “as we wish” as long as we write something addressing all the expectations that the standard contains in a reasonable manner??

 

[isodog]

But it makes a BIG difference if I create a procedure and control it than if I just write a memo about how I am going to do something like contract review.

doesen't it?
Dave

 

[Marc]

Originally posted by isodog:

But it makes a BIG difference if I create a procedure and control it than if I just write a memo about how I am going to do something like contract review.

doesen't it?
Dave

Answer? Controlled memo (quality record).

You document what you need to document. Check against requirement. Ask: Do I need anything else?

The point of all this is that you have to be able to explain how people know what to do. If the folks on the dock all know that chemical product X-1235f1-4QQ cannot be shipped unless it's at least 45 degrees F outside because if 'spoils' if it is exposed to temperatures of less than 38 degrees F, then you don't need a procedure. As an auditor I'll pull 2 to 4 aside and ask about this product. "It's January and you have to ship product X-1235f1-4QQ to Genrad. What is the procedure?" I'll expect something like "...product X-1235f1-4QQ is temperature sensitive. In January it's typically cold so we require a heater reefer." Auditor: What is the requirement?" Auditee: "...If it's less than 45 degrees F outside, we require a reefer." Auditor: "...How do you know when it's below 45 degrees out side?" Auditee: "...We have a thermometer outside on the dock." Now if the employee really wanted to impress s/he could say "...I check the weather channel in the mornings and know what the predicted weather is along the route. So even if it's 48 degrees here and I'm shipping to Toronto, I know Toronto is expecting 15 degrees - So I order a reefer..." I won't go into whether the wearther channel is calibrated, but I think you get the idea. Does the employee understand the requirement and does the employee understand the implications of a screw up with respect to product thermal stability.

Quickly, I want to say I define a procedure as a way of doing something whether it is documented or not documented. No more, no less. Again, I do not define 'documented' as requisite to a methodology being called a procedure. If you ask how I start my car, I tell you how I do it. It is a procedure. It is my procedure. May be I derived it from my owners manual (that thing the manufacturers ensure are comprehensable to total idiots {...Do not start the car while in gear...}). It is my procedure - I don't need a flow chart. I know how to do it.

Let's face it. There have to be some road maps. How far and how deep you document is a function of how well employees are trained with respect to aspects such as process complexity, employee turn over rate for the position and numerous factors.

You simply determine what systems you have to document while considering you company.

If you're 12 souls and your turnover rate is 0 for the last 10 years (I actually had a client like this - no kidding), every one knows what to do so documented systems is not a big deal. Auditor asks and everyone can tell exactly what to do.

If you have 20,000 employees you are going to have many master systems documented (road maps). And in any given facility with respect to any local process and also with respect to aspects such as employee turn over rate, you have to determine what has to be documented and what does not. And you have to be ready to explain why you document what you do document and why you do not document what you do not document.

What you do not document, you must train.

Get out of the 'required procedures' trap.

Comments welcome.

[This message has been edited by Marc Smith (edited 22 April 2000).]