This is probably a really stupid question, but bear with me here.....

We're just starting gap analysis work for transitioning from QS to TS. With QS we have always maintained the "Quality manual" as a corporate level document that applied to all divisions... it's basically one of those "spit the elements of the standard back" documents, just vague enough to let all the divisions comply in their own unique ways.

Anyway, in looking at the requirement for a Quality Manual in TS, I'm trying very hard to get OUT of my QS mindset and look at this with fresh eyes. In doing that, it occurred to me that with QS I was taught (might be wrong) that the Quality Manual was a Level One document APART from your Level Two procedures, which were the "meat" of your program. Unless I'm just missing it, I haven't seen a similar breakdown (like QS's page 6 of the standard) for TS. So... the question I've taken forever to get around to is this...

CAN my procedure manual (my collection of all the various procedures and related documents) BE my "quality manual"? In QS I think that's definitely NOT do-able, but in TS I don't see anything to indicate it couldn't be. Why create a "higher level", Level 1 document if I don't have to? Not trying to be lazy here, but I'm not fond of creating "pretty", essentially non-functioning documents if I don't have to.

CAN my procedure manual (my collection of all the various procedures and related documents) BE my "quality manual"? In QS I think that's definitely NOT do-able, but in TS I don't see anything to indicate it couldn't be. Why create a "higher level", Level 1 document if I don't have to? Not trying to be lazy here, but I'm not fond of creating "pretty", essentially non-functioning documents if I don't have to.

Most of the QS "Quality Manuals" I've seen have been pretty lame. If you look at the TS requirements, you must ask, does what I have meet the requirements. I do not believe that your procedure manual will answer the questions of description of the interaction of the processes, nor will it have any justifications for permissible exclusions. However, these could be easily added in. The main thing is to look at you have agains the TS requirements and build from there.

Many organizations I am working with still want to use the old "Level One" docs. My concern is that this approach might be inconsitent with "process thinking". Arranging the manual by clause seems to be contrary to what the technical specification is attempting to do. IMO

Yup, I'm already thinking in terms of adding those kinds of necessary documents into our existing procedure manual, which does already have, for instance, "process flow diagrams" in there, that will be beefed up for the process interaction thing. I think I can make this work. Thanks!

Is the scope of your procedures manual a sub-set of the corporate Q Manual (i.e. you are one of many sites operating under a corporate Q Manual), or do you control the corporate Q Manual?

A couple items for thought:

it occurred to me that with QS I was taught (might be wrong) that the Quality Manual was a Level One document APART from your Level Two procedures

Very good point here. Not only apart from "normal ops" or SOP but it becomes viewed that it is not for every day consumption. Additonally it is titled a "Quality" manual which lends itself to being viewed as a quality department document only. We have had this discussion in another thread about a year ago so I won't belabor the point. However, here is the first separation.
Secondly, if it is a printed copy, it has been given to someone "as reference". Right now many of us are doing our "spring cleaning" and looking at stuff we haven't used or touched for the last year. Personnally I have books, clothes, etc. that are either in the trash or going to be donated. The company quality manual tends to be viewed the same way and I can't say I don't agree. If it has not been referenced for some time what is it's value to the company? If it doesn't have enough worth to be "referenced" then why bother? Get rid of it and rewrite it to be a useful tool!

I don't know if I'd use my procedures manual, but that may not be a bad idea depending on the company. I just want to emphasize that if you've found it to be non-value added and you're going to take the time and put forth the effort to restructure the manual, by all means make it useful! :agree:

David, the individual division's procedure manuals are a subset, I guess, of the corporate policy manual. But as I said at first, it's always been (IMHO) a totally useless/pointless document - it just parrots the QS standard and still leaves it up to the individual divisions how to practice everything in their own ways. It's something we pull out for an audit when asked, and everyone's all pleased that we HAVE one, but you have to knock the dust off it to read it. On the other hand, the procedure manual is much more a "living" document.

Didnt ISO9001:1994, and therefore QS9000, and the current ISO9001 say that your quality manual had to CONTAIN your procedures OR REFERENCE to them ?

Yes I think it did/does, hence in answer to your original question, yes you manual can contain your procedures.

But as others have already stated TS16949 requires you to adopt the process approach, a la ISO9001:2000 - hence I would try to get right out of the 'documentation levels' mindset and try to think in terms of 'process levels'.

We use the tier system
T1 is the QMs
T2 is the SPs
T3 is the WIs
T4 is objective evidence (FMs)

The 00 standard allows one to use the QM as a (sales) information tool. We have reduced ours to just that, as it should be and not a regurgitation. One can combine the QM and SP, but do you want to send all that info to potential Customers?

IMHO this is a very good oppurtunity to change your system.
Most of the proceudres need editing anyway to update them to the reality.
The demands for TS are for only 7 procedures and whilst I do not say that you have to thow all the others away there is a case for changing some to work instructions.
The QS demand for documentation of demands was exagerated and as we know most procedures are not read.
I beleive that a short description of your process in the QM instead of a long procedure is a more effective way of dealing with the situation as in a few pages the staff can get an over view of the working methods. This is the real reason for the QM.
Is there really a need for a long procedure on say set up verification or rather: " The control plan describes the manner in which the set up is verified"

:bonk:

During our transition from QS to TS2 the first thing I did was to throw away the QM and start with the procedures. Next I separated out the 7 required and started a second book. Then I started defining the processes starting with the COP's. Then I eliminated unnecessary procedures or converted them to a work instructions.
HINT: you can easily convert a procedure to a process definition.

Do you have a CB yet? If not, I suggest you obtain one before you start the process. The first item that needs to be approved is your scope. Secondly they will have their own forms that need to be completed that they will use for auditing purposes. You could be doing duplicte paperwork, your own and theirs.

Seems as I recall about a year ago a Cove member telling us all that a Q Manual per se was not required at all. That you could indeed call your collection of other documents your QM as is touched-on above. Am I wrong? Maybe they will re-share their insights, plus their additional experience over the last year on that, here. ;)

My assistant just went to some TS training and they told him there were 6, not 7, required procedures? What 7 are you noting?

Read the following "real slow" and think about what it says.....

4.2.2 Quality manual
The organization shall establish and maintain a quality manual that includes
a) the scope of the quality management system, including details of and justification for any exclusions (see 1.2),
b) the documented procedures established for the quality management system, or reference to them, and
c) a description of the interaction between the processes of the quality management system


a) How many words does it take to address the scope of your QMS? If you can't claim exclusions why worry about this part?

b) How much documentation do you need to "reference" your procedures? Would a MS Word Table do, or an Excel spreadsheet?

c) Does this really take a lot of words? Couldn't you just flowchart this?

It seems to me that if the manual was really, really planned out it could be as small as a comic book instead of as large as some dumb congressional report. Only put into your manual what truly has to be there and then just reference all the gobblety-goo.

I beleive that the number of procedures required by TS are 7. These are:-
4.2.3 Control of Documents
4.2.4 Control of Quality Records
6.2.2 Training
8.2.2 Internal Audit
8.3 Control of Nonconformity
8.5.2 Corrective Action
8.5.3 Preventive Action

Aha! Our current procedure manual for QS has Corrective and Preventive combined in one procedure, thus his 6 versus 7. I suspected that was the difference. Thanks!

Example:

A company is QS/ISO certified.
External Auditor discovers they have another site which performs some assembly work on a small qty of product before the car company gets it.
The Division of the corporation that ends up having “ownership” of this little operation writes a separate quality manual and is ready for auditing.
Auditor looks at the manual and decides they don’t need this quality manual, that their local procedures are sufficient. Auditor then includes the little assembly operation in the scope of the corporate QS/ISO certification.

I would wager that it has been a year since our auditor has asked to see the "Manual". The formal manual is just not a big issue. Again, why waste the time if it's not going to be used? Make it a tool not an anchor.

4.2.2 Quality Manual states:

The organization shall establish and maintain a QM that includes:

a) the scope of the quality management system, including details for any exclusions.

b) the documented procedures or reference to them

c) a description of process interaction

I think this point is about auditor´s point of view, it depends on the CB, and like all the international standards everybody wants to have the reason in what they are saying, for some may not be a Major NC but for other not having a QM apart from SP could be a serious thing.

Since you are upgrading from QS, you can do as many others have done ( my self included ) add the TS requirements to your old QS manual and start dealing with the next thing.

From IATF Guidance to ISO/TS 16949:2002.
On page 30 there is a Readiness Evaluation sheet. This shows what has to be submitted to the Certification Body prior to an on site audit. This includes Quality Manual

This shows what has to be submitted to the Certification Body prior to an on site audit. This includes Quality Manual
Rea,
This is exactly what I'm talking about. The Quality Manual becomes an item for Registration/Certification purposes only! How often do you reference your owners manual for your car, water heater, TV, etc. Is there another way to do it? I think so. My point is that there needs to be some value added purpose to creating, publishing and maintaining the "manual". If you listen to most of the people here, the main function of the Quality Manual is to give a shelf a purpose!!!!:frust: :bonk:

you listen to most of the people here, the main function of the Quality Manual is to give a shelf a purpose!!!!

The only real exception to this is I find it is very useful in the development and initial implementation of the system. It can give you a type of indicator showing what has been done and what still needs to be done. But once you are up and running, it is pretty much used for external purposes.

db,

This is my take as well. During development of the QMS the QM provides us guidance as to just what the heck we're gonna do and not do in building this QMS. I've basically regurgitated the std. with a few add-ins when I've done them in the past, for better or worse. But I liken it (the QM) to the foundation of a building -- you gotta have it or you can't build further, but after it is done you cover it up with other stuff and (hopefully) almost never see or think about it again. Does this mean you don't need it to start? Not for me.

There may be better or easier ways to do it than regurgitating the std, which I am open to hearing. Jim Wade has stated one way which, although it may work for some, I probably would not do. Maybe you can just say "here is our company name and loacation, here is what our company does, here are my exclusions, here are my ref's. to level 2 and 3 stuff, and in the QMS we do whatever ISO9001-2000 says to do".

Mike

Why regurgitate the standard, why not just refer to the standard ?

The 1994 standard required us to outline in our quality manual how the company met the requirements of the standard, which led to the vast majority re-writing the standard almost verbatim, just substituting 'the supplier shall' with the words 'we will'.

The 2000 edition no longer has this requirement.

Any thoughts as to why this was taken out ??

Martin,

That was kinda the point of the last sentence in my last post. Sounds reasonable to me. But, for whatever reason, I don't recall any of the QM's posted on the Cove doing it this way, and our esteemed host and consultant Marc advocates regurgitating the standard for, I assume, SOME reason. But as I said -- I'm open to alternatives to regurgitation!

Any thoughts as to why this was taken out ??

Because it was stupid!?

Well I would not be allowed to post my own (or rather my present company's) but rest assured it contains no verbage from ISO9001:2000.

It does contain a quality policy, a statement of the scope of the QMS, an organisational structure, defined responsibilities and authorities, and the good old process maps (well hyperlinks ot them anyway, just in case the auditor get all anal about them not being in a document titled 'quality manual') - oh and reference to the procedures.

I would like to know Marcs reasoning for rewriting the standard in your QM - can only think this is old advice from the 1994 era.

We do get a little benefit from our QM, tho mostly during audit time. I don't regurgitate the standard, but I do use it as a detailed outline for the manual, addressing under each heading how and/or where our system meets the requirements of the standard. The benefit we have found comes not so much from cross-reffing the procedures (I have a matrix that works beautifully for that), but from including information (a.k.a. institutional knowledge) that isn't documented elsewhere.

Perhaps this was a bigger benefit for me, since I "inherited" the system, but I've found that over time it was difficult to remember the answers to and rational for our approach to some sub elements of the standard. The manual became a nice place for short answers that were otherwise not documented or awkwardly addressed via procedure.

Like the analogy to the owner's manual, when all is going well you shouldn't need it. But is sure is nice to have when a question arises and you don't have a quick answer.

Hi, all.

I work for a small company, and when we were preparing for the 2000 ISO transition, we sort of wrote (regurgitated) our quality manual as a last gap analysis. For each section, the proc. number is referenced, so we knew that that particular section was covered.

Is this an elegant way to do it? Don't know, but it worked for us. A larger company might have trouble with this approach.

Craig

Level 1: Quality Manual: Why you do it and where to look for it.

Level 2: Procedures: Tells people what they are responsible for and what they have to do.

Level 3: Instruction: Tells people how they line by line to do the job they were hired for.

Level 4: Forms: Used to document results of the entire system.

Am I incorrect in this???

Think about it folks, the quality policy is the weakest and least enforcible document in the company. Just like the way it was designed to be.


Al...

Al,
I couldn’t agree with your comment about the policy. In a survey on the cove, a while back, most people have a manual which is a regurgitation of the standard. These are the people with meaningless manuals, and often policies – but may well have a good management system.

Policies need to have clear objectives, which are finite and achievable, not glossy wish lists. Policies should be sufficiently clear to allow strategic planning to flow from them, otherwise they are nothing more than corporate Viagra.

Randy said:

Read the following "real slow" and think about what it says.....

4.2.2 Quality manual
The organization shall establish and maintain a quality manual that includes
a) the scope of the quality management system, including details of and justification for any exclusions (see 1.2),
b) the documented procedures established for the quality management system, or reference to them, and
c) a description of the interaction between the processes of the quality management system


a) How many words does it take to address the scope of your QMS? If you can't claim exclusions why worry about this part?

b) How much documentation do you need to "reference" your procedures? Would a MS Word Table do, or an Excel spreadsheet?

c) Does this really take a lot of words? Couldn't you just flowchart this?

It seems to me that if the manual was really, really planned out it could be as small as a comic book instead of as large as some dumb congressional report. Only put into your manual what truly has to be there and then just reference all the gobblety-goo.

I agree 100%. I must say that technically it says there must be a quality manual, but how you define a 'quality manual' becomes the issue. One could have everything in a big binder and say "This is it" or one could have a 'brief' (the comic book, if you will). Definitions can be everything...

I typically suggest having a QM, even if very brief, to establish/define the overall structure of the company's systems (at least the portions which apply). To me it was always the Skeleton on which everything hangs. I've never done an implementation without at the least a basic quality manual.

I have a presentation that deals with documentation from back in the days when I was doing QS implementations. I'll try to dig out the powerpoint file and post it as an attachment.

Personally, I think many people get too hung up on the quality manual.

A last thought is this:

As each of you expresses views on quality manuals, remember that the size and complexity of the company play a very large part. I have done implementations at small, non-complex companies which had everything - procedures and all - in their 'quality manual'. On the other hand, companies like Motorola have quite a document structure to flow down not to mention to keep in check (in reality an impossibility, if you know what I mean) that its almost mind boggling. There's Schamberg, then all the sectors, and all the plants. Multiple quality manuals. Get's complex.

So - in all this bear in mind that there is no 'One size fits all' with respect to quality manuals (and to many other things as well, for that matter).

David,

Can we agree that most policy manuals are basically useless after the document audit?

The policy manuals I have worked on reference the level 2 procedures which usually make up a good portion of a companies operating principles and usually alighned to whichever standard applies.

My personal opinion is that work instructions are the method to ensure a consistant product.

Who uses the Policy Manual? Everybody that does not have a job or a function at a facility.

Who uses the procedures? Usually the internal auditor and/or the management rep.

Who uses the work instructions? The people that make the product and pay our salaries!!!!!!!!!!!!!

M Greenaway said:

Mike

Why regurgitate the standard, why not just refer to the standard ?

The 1994 standard required us to outline in our quality manual how the company met the requirements of the standard, which led to the vast majority re-writing the standard almost verbatim, just substituting 'the supplier shall' with the words 'we will'.

The 2000 edition no longer has this requirement.

Any thoughts as to why this was taken out ??

Because the requirement was stupid - one thing they got right in the rewrite. But let me digress.

Jump in the way back machine and in 1991 through 1997 - auditors wrote you up if there was anything in the standard that was not in the manual (or referenced and addressed somewhere). You couldn't just say "hey - we didn't write about design because we don't do design." The auditor would say "Where do you say that in your documentation?" The easiest way to stop the BS was to make your QM a copy of the standard with 'addendums'.

I carried this over for a while. Attached is a QM from a company I worked with in 1998-99 in an implementation to the 2000 standard. Technically they registered in June 1999 to the 1994 release but we used the 2000 DRAFTS as our guide. The attached is the manual when they did their 'upgrade' to the 2000 standard in their first 2001 'checkup'. It 'passed muster'. You can see I stayed with the manual as a skeleton, a hanger, a pointer.

Note that in the attachment, the company did all their procedures - except detailed work instructions - in SmartDraw (flow charts). They did one heck of an excellent job pulling everything together into an integrated, simply expressed, system. Everything was on their intranet. There was a 'tree' which aligned with the elements. if looking at a system, the flow chart had related forms, etc., and just click on the form and you were into their database with the form as the front end. I was (and still am) seriously impressed.

Anyway, here goes the attachment.

Just my 2 cents.

Al Dyer said:
David,
Can we agree that most policy manuals are basically useless after the document audit?


Al,
I've seen plenty of companies that fit this mould (that's Aussie spelling), and the level one docs are frequently useless from the time of writing, and after a few years are totally out of sync with the lower level documentation.
I've also seen some really clever policy manuals that are useless because they aren't used in the workplace, due to a lack of training, understanding, etc.
Either way it's a failure of management to implement a system of doing business that ensures they deliver "product" (using 1994 definition) in full, on time, to A1 spec, and ensure a fair and healthy profit for the business.

Off on a Tangent:
You can rarely find "Cost of Quality" practical info from real life - case study. Is it because they didn't bother capturing the info, didn't know they should have early enough in the project, knew that quality doesn't reduce costs, etc???
It's because most companies don't care if it reduces costs (but they do know having a system to collect, process and evaluation this info WILL cost them money) they just know they have to have the certificate?

Unless one of your POLICIES is to achieve a defined ROI for all expenditure, then no one's interested.

Completely off on a Tangent:
May be we need QA Managers like the "Fat Controller", and make sure all our policies and systems are "really useful".

David said,
"Unless one of your POLICIES is to achieve a defined ROI for all expenditure, then no one's interested."

That I can agree with. Should be the first step in the decision making process.

1 of our yearly objectives is to achieve a certain EBIT %. We have noted 3 categories that really drive this figure; Indirect Labor, Indirect Materials and Cost of Non-Quality (rework, scrap, supplier issues, etc.).

Dave said:
(but they do know having a system to collect, process and evaluation this info WILL cost them money
I will disagree here with a condition. If you have proper metics set up a majority of the info is already available, so any cost is minimal.
Most companies I've worked with have some type of system to track repairs and parts on their equipment. It is not that difficult to modify that system to track ROI on major expenditures.

SteelWoman said:

Yup, I'm already thinking in terms of adding those kinds of necessary documents into our existing procedure manual, which does already have, for instance, "process flow diagrams" in there, that will be beefed up for the process interaction thing. I think I can make this work. Thanks!


I've already done what you are suggesting and my auditor had no problem with it. With a few cover sheets and process descriptions, you should be fine. :thedeal:

Any thoughts as to why this was taken out ??

db:
Because it was stupid!?

Marc:
Because the requirement was stupid

Great minds think alike! :thedeal: :agree:


Okay, so I finally lucked out and got one right. Even a broke clock is right twice a day!

:bonk:

So if we all agree that the requirement was stupid why do we continue to proliferate the stupidity ?

Honest answers only please.

Quote:
M Greenaway said: So if we all agree that the requirement was stupid why do we continue to proliferate the stupidity ?

The way I do it is this:

If the company is jsut starting out (no pre-existing QMS) then I kinda do the regurgitation thing with one twist. I have them write how and where they meet the "shall". I find this helps them in the initial implementation. This way I know they understand what the requirements are and how the requirements relate to their organization.

If the company is upgrading, I recommend nothing more than a matrix showing where, in their QMS each requirement is met. Once again this is really only useful in ensuring their system addresses all of the requirments.

Make sense?

Jim said,
"The message on the streets from the 'quality' community (consultants, quality managers and registrars) is that 9000:2000 is really not so different from its predecessor. Therefore, stick with the bad old habits and you can easily 'transition' [what a weak word that is!]. As for the process approach, that's all verbiage, procedures and processes are the same, ..... "

That may be the message from the ISO9K2K but it is not the message I receive (so far)from our CB for TS2 registration.
Our recent "practice" audit with our CB focused on COP's ; inputs, outputs, activities, support processes, linkages and measures. With emphasis on "measures".
In addition you must have available a customer profile (CB specific) for each of your OE customers that list the customer specific requirements. You must have objective evidence that you have addressed each one on the CSR's.
For example, how do you meet the internal auditor requirements for Ford nad GM?

The quality manual is a collection of procedures that are required and/or needed to document the exixtence of your QMS, the scope and a description of the interaction of the COP's.
The manual will be reviewed for content as described in para. 4.2.2. It will not be used as an auditing tool by the auditor. Naturally, each step of the specification will be audited using a checklist, as in previous audits. However, the checklist is used in conjunction with the COP's. During the Mfg process audits the control plan is used.

Key items for TS2: COP's, CSR's, Measures, Process Definition, Supplier Quality Management.

Note: The above comments are IMO based on interaction with our CB.

WOW: Do not attempt to make the transition before contacting a CB.

Al, the point in my original post was that the Level 1/2/3 mindset was a part of QS - spelled out in the beginning of the standard - but specifically NOT a point in TS... so maybe we can/it's time to move away from that mindset. We're just starting the Transition to TS and I'm trying real hard to put away my QS pre-conceptions and look at TS with fresh eyes. It's opening up some interesting possibilities when we're able to get away from what we THINK the standard says versus what it ACTUALLY says.

SteelWoman said:

It's opening up some interesting possibilities when we're able to get away from what we THINK the standard says versus what it ACTUALLY says.


AMEN - and add to that "what we ACTUALLY need" and then perhaps we'll get value for our effort and end the insanity :)