ISO/TS 16949 vs. QS 9000 - Comparison of the two standards

[Sam]

Has anyone here who has made it through a TS upgrade audit successfully argued AGAINST having an audit checklist, and if so, how?

How did you then answer to the "organization shall audit it's quality management system to verify compliance with this technical spec" thingee? Do you have your QMS listed as a SEPARATE process in your system?

I do not use a checklist or the specification.
Having said that; the checklist that is required is found in the AIAG manual "Quality System Assessment Checklist". Based on the errata sheet for this manual this checklist is now "highly Recommended". Too satisfy that requirement I insert my COP definition in the appropriate spot.
What I use is a process flow diagram and a "crib" sheet listing questions based on Man, Machine, Material, Method, Measurement, inputs and outputs.

IMO a QMS is a process and should be audited as such. Develop and define the COP's using the specification, the CSR's and the turtle diagram. The turtle diagram will aid in further defining the process.
Once you have identified your COP's and determined the interaction then you can audit the entire QMS as a process using the method described above.

 

[howste]

Don't bother - this is simply the requirements put in tabular form, clause by clause and the audit questions don't add any value . One just does not audit in this way...

I agree that one "does not audit in this way," but that wasn't the intent of the checklist as it is written. When I audit, I audit processes in whatever order I want, then record evidence in the appropriate place on the checklist. That checklist was written to do 2 things:
1) As SteelWoman wanted, to make sure that all requirements of the standard have been met
2) Give an examples of questions that might be asked for auditors-in-training.
True, every question may not be the best, but if a new auditor is having trouble getting started, it at least is a starting point.

 

[SteelWoman]

Two things:

1) Isn't the IATF checklist booklet intended for use by Registrars? When our registrar first pointed it out to me, it was as a reference document, something THEY had to use, but not us. Am I wrong on that? The language of the whole book and even the Errata statement seem to imply that. When the auditor was telling us about it she had just completed HER certification to TS, and was saying they are so "element" leery that they were not allowed, in their training, to HAVE the checklist on their person, but at the end of the audit they were expected to fill it out?? That falls in line with the Errata statement about it being a tool, and process audits are not to be ELEMENT driven.

2) I actually took my original "gap analysis" I did for TS, that listed every "shall" and showed how we did (or early on, did NOT) meet the shall, and then after all was said and done only modified that document slightly and kept it as a "Shall Matrix" tool for my internal auditors. For each shall, it shows the procedure(s) we have that addresses it, references the process that applies to it, etc. One of my internal auditors, after using it for the first time, said "This Shall Matrix ROCKS!!!" (obviously an "under 30 yr-old auditor). It's been a useful tool to give both experienced and inexperienced auditors a "launching point" when preparing to audit a process.

 

[Sam]

Two things:

1) Isn't the IATF checklist booklet intended for use by Registrars? When our registrar first pointed it out to me, it was as a reference document, something THEY had to use, but not us. Am I wrong on that? The language of the whole book and even the Errata statement seem to imply that. When the auditor was telling us about it she had just completed HER certification to TS, and was saying they are so "element" leery that they were not allowed, in their training, to HAVE the checklist on their person, but at the end of the audit they were expected to fill it out?? That falls in line with the Errata statement about it being a tool, and process audits are not to be ELEMENT driven.

2) I actually took my original "gap analysis" I did for TS, that listed every "shall" and showed how we did (or early on, did NOT) meet the shall, and then after all was said and done only modified that document slightly and kept it as a "Shall Matrix" tool for my internal auditors. For each shall, it shows the procedure(s) we have that addresses it, references the process that applies to it, etc. One of my internal auditors, after using it for the first time, said "This Shall Matrix ROCKS!!!" (obviously an "under 30 yr-old auditor). It's been a useful tool to give both experienced and inexperienced auditors a "launching point" when preparing to audit a process.

Yes it does apply to the CB auditor, however they may ask you to fill in the blanks.
The gap analysis is a good tool to use in determining where all the "shalls" are described, however, if you cannot provide traceability "FROM" the specification and the CSR's "TO" your process definitions and vice/versa, then your processes are not effective or efficient.

 

[mangard]

Checklists

8.2.2.4 Internal audit plans - states, in a note, that 'Specfic Checklists shoud be used for each audit'.

Your auditor is therefore right to expect some kind of checklist.

How you implement this is a matter for you.

Like you, I'm not in favour of checklists at all. They go completely against the spirit of the process approach! Accomplished internal auditors would be able to carry out an audit or any area, without any specific aids and pin-point problems and areas for improvement.

Some form of 'checklist', however is a valid tool, particularly for new auditors. I suggest a 'dynamic checklist' based around the tutle diagram. Every audit you do under TS is likely to be 50% planning and review of the performance data with the other 50% as a verification exercise. The 'checklist' would come out of this initial activity.

It would be acceptable to construct a turtle diagram of the area being audited, highlighting areas of interest and concern for physical review. Add the clauses and you can then used that to demonstrate areas seen.

Keep all notes, etc... those can be presented as evidence of a checklist and line of investigation.

Another useful device is to list each audit in a matrix and cross reference against the main clauses of the standard. Over time, you will then be able to see which clauses have been been covered by a review.

Hope this helps.

Ramesh Manga

 

[Helmut Jilling]

By the way, let me throw one more question out there.... when our auditor was last here, back in November or so, doing our hopefully FINAL audit to QS, she mentioned that it was a REQUIREMENT that an audit checklist be utilized. I told her I didn't think that was true, but at the time I didn't have a moment to look it up. Sure enough (it's difficult always being right ) the standard says it's a "should" not a shall.

We've never utilized audit checklists, and with the move AWAY from Procedure audits to Process audits, I'm even less inclined to put them into place. I was approaching this from the angle where the Mgmt Rep would maintain a "master checklist" each audit cycle of the clauses in the standard to make sure we hit them all during the audit cycle, but that's a rather laborious task for me to complete post-audit and I can't find any real value in doing so.

Has anyone here who has made it through a TS upgrade audit successfully argued AGAINST having an audit checklist, and if so, how?

How did you then answer to the "organization shall audit it's quality management system to verify compliance with this technical spec" thingee? Do you have your QMS listed as a SEPARATE process in your system?

I think Manguard's answer (post #15) says it pretty well. Also, keep in mind, my information is that IATF rescinded the QSA checklist book. They really are nervous about auditors even hinting they are following a clause based checklist. Manguard gave good guidance, and when I audit, that could likely satisfy my search. Two additional items I'll add. For my consulting clients, I created a process based checklist. It is a generic six page template, covers the kinds of questions the turtle would address, and, very importantly, adds a list of common linkages to support processes to remind auditors what links to look for (training, doc control, gages, maintenance, customer complaints, performance metrics, objectives, etc.). Also, I encourage them to use their control plans, work instructions, etc, as "checklist" as well. They can mark questions and write answers right on their (uncontrolled copies). This all becomes part of the audit records. Works pretty well in audiotr training, because it gives them a (process-based) road map.