Quality Manual Organization and Structure including Numbering [Elsmar Cove Index (Ar)]

Marc

9th November 2001, 02:04 AM

Originally posted by John The Auditor

One of my favorite manual contain 60 linked flowchart - that's it.I don't think that the issue is that simple, but I agree with you. The problem generally lies in that companies that have been in existence for a while already have procedures in place. In addition, my ISO 900x experiences - dating back over 10 years - is that many auditors will be going through the documentation and say "Well, what about line item x? Specifically where does it say that in your supporting procedure?" To me it was, early on, enough auditor bull - give the auditor something simple enough that everything is there and directly points the auditor to the appropriate documentation. And don't miss even 1 line item. I have since prepared my clients for, and expect (sorry :( ) a really stupid or pricky auditor. If we 'get a good one' - all the better. If we get a 'picky' one we're prepared.

I can't remember if it was in a thread here or in the ISO ListServe *** DEAD LINK REMOVED *** but there was a good discussion on whether you even need a quality manual. There was some good back and forth. I personally 'require' clients to have a quality manual because they are so simple to do and they serve as a directory - pointers if you will - to fulfillment of the requirements.

It also may be that you know what you're doing. The 'Call for Auditors' has brought every known type of soul out of the woodwork and into auditing. Just as it has in consulting, I will add, being a consultant. Everyone seems to have taken early retirement and is now an auditor or consultant. I have run into some of the stupidest auditors that the world has ever seen. Many (most?) simply do not accept the 'outline' idea.

A quality manual is so easy to do - and for most 'starters' ties everything together that I've never seen it as an issue. I'm in the middle of my third and 4th update to the 2000 version and have a simple, fill in the blanks manual. Take old manual, bring the pointers over. Check old manual for additions (they all have modifications to some degree specific to the company) and bring them over. A morning's job if you stick to it.

Do I agree with you? Yes. But I bet that to the largest % of auditors that would be like waving a red flag in front a bull. In part I say this because I went through something similar (auditor ignorance) with flow charts in 1995. The auditors came in and it took close to an hour of negotiations before the auditors would conceed that flow charts are, in fact, procedures. It was the first company that I did all the level IIs in flow charts. The auditors had never seen such a thing! Though converted and dated in1996, if you take a look at these old flow charts (http://Elsmar.com/pdf_files/flowcharts/) you can see some the originals. They have been posted there (here?) - free - for almost 6 years now to give people ideas about how to approach simplifying documentation.

This last June I finished up with a client who had everything on the intranet in chart fashion. It was really neat. Started with a top level 'company' flow chart - sorta like a tree and all the sub-processes were branches. Everythig was interlinked. No - no Mickeysoft bull and bugs - just a cheapie program (which is really, really nice, called SmartDraw). Systems flow charts were so linked that - click on a 'referenced Form' and it would open right up. I originally argued against it and its complexity, but they over ruled me and did it - and did one heck of a job. I still think they over did it, but it really is nice.

Again - I agree with you, but reality aften smacks us in the face when we're not prepared. I just wish I could remember where that thread on whether or not you need a quality manual is. If I run into it I'll come back to this thread and post the link.

> The whole system conains not one word of ISO speak

The only 'Iso Speak' is in the quality manual its self. Limiting it to that space can do wonders.

> Another is a 600 person project managment group whose
> total manual is about 30 pages.

If you're referring to the quality manual, the 'form' I use is about 21 pages, 10 point Ariel, includes the 'Figure 1 diagram, complete index, references, etc. I don't think that's too long.

Jim Biz

9th November 2001, 09:03 AM

As a 3rd party auditor please stop giving me the regurgitation of the manual. I konw you dont mean it.John- a truley refreshing comment -
If I knew that YOU were going to audit our system - I would gladly "revert" to the style of our origional efforts back in 96.
(It was a "combination of" charts & COMPANY wording - on how we were intending to satisfy the standards language.)

I was told at the time that It was "not sufficient" and could not be effective because it "strayed" from the standards language itself. Our Auditors comment - I must see the standards reflected in your manual word for word - <u>mirror image</u>. (we even argued over minor wording differences - and vs and/or)

Well needless to say - I was at the time unanimous in my opinion - at that point even our local consultant was questioning my efforts although he understood what we had done - his position was we had "left ourselves open" to too many questions and arguments.

My management folks took a very strong line on this & cleaned up the issue thru the only channel they could control (that would be ME) ) -- told me to do "whatever was needed" to get through the registration - no need to stick to your guns at this point & have it be a cause for expensive 2nd or 3rd audits to obtain the registration - RIGHT?

Frankly - I can't POSITIVLEY - say our big gun mgr's "mean it" - but I can tell you "I mean it" and remind them "the standards require this-and/or that" every chance I get..

Kevin Mader

9th November 2001, 02:45 PM

Question: what is the definition of “rolled our own”?

This is a long standing discussion, but I think an important one. I must admit that many of the Quality Manuals I review are reiterations of the ISO Standard. Some are purely canned products and for me, this says a lot about the organization using it.

Second Question: what does this group think the ‘masterpiece’ effort would look like?

Regards,

Kevin

Marc

10th November 2001, 06:17 AM

> I was told at the time that It was "not sufficient" and
> could not be effective because it "strayed" from the
> standards language itself. Our Auditors comment - I must
> see the standards reflected in your manual word for word -
> mirror image. (we even argued over minor wording
> differences - and vs and/or)

This is precisely why I require a manual and why I wrote what I did. I do learn from experience (well, sometimes I do and sometimes I don't - but this time I did) that it's not worth a pissing match over words - which is what audits sink to quite often. Verbal battles and interpretative BS.

> Question: what is the definition of "rolled our own"?
>
> This is a long standing discussion, but I think an
> important one. I must admit that many of the Quality
> Manuals I review are reiterations of the ISO Standard.
> Some are purely canned products and for me, this says a
> lot about the organization using it.

In my military manufacturing days - and again when I entered automotive - there were requirements for a quality manual and/or a product quality plan. Somewhere in the contract there would be one. This was before ISO 9001 was popular - well, in the case of my Mil experience before ISO was released. Customer quality manual and/or quality plan contents were usually dictated more by bullet points (minimum contents index). So - you could sorta write your own. You addressed issues like how you deal with nonconforming product - but you wrote it and auditors were not looking for verbiage as the ISO auditors often do. Their interest was that a system existed, was documented and followed. You can see this to some degree in ISO 9000:2000 where they list the concepts. Since we all have ISO 9000:2000 handy (don't we? :confused: ) take a look at Annex A Figure A.9 - Concepts relating to conformity. There are some concepts auditors would look for. But they didn't pick your ass hairs over verbiage like the ISO auditors so often do. This is where I first understood the term Meeting the Intent.

One thing to remember is prior to about 1990 not many companies even had such a thing as a quality manual per se.

To me, Roll You Own is where you describe your system as it exists and that certain fundamental concepts exist within the system (such as segregation of nonconforming product as an element of your nonconformance system) without resorting to ensuring every single word in a 'standard' is - somewhere - repeated.

> Second Question: what does this group think the
> 'masterpiece' effort would look like?

I prefer the 'Roll Your Own' for every system except the quality manual. And it will look like - what you do (specific to your company). The 'quality manual' has evolved into - well, a standard within its self.<hr>I should point out that even though I talk about a 'canned' manual which I use for implementations and upgrades, I expect certain tailoring in each company. That is to say, there is the standard - word for word - and you have your references. You always have to take a look at the company and at the manual and at the procedures as a whole. Typically there are some 'notes' or other additions or clarifications added here and there.

John The Auditor

11th November 2001, 12:15 AM

As a 3rd party auditor I can only make one comment to those of you who are tired of auditors who demand manuals that mimic the standard word for word, who reject procedures because they are not in the right format, etc.

FIRE THEM !!!!!!!!

You pay them a lot of money and if you are not getting value treat them like any other poor supplier - GET A NEW ONE!!!

Until people start to to take control of their ISO registrations and demand that narrow minded auditors are no longer welcome the problems will continue.

Another hint - find auditors who have a lot of busines experience - especially those that have had excellent sales careers - they know what customers want.

Avoid the person who has spent an eternity as an inside resource in quality - they can write a procedure that looks great - no one wnats to uses it though.

Remember accountability to a customer for a quality issue is not the same as accountability to your company for the customer and the revenue generated

Marc

11th November 2001, 12:46 AM

The easy answer is Fire Them!

You reach a point where you can't keep calling the registrar and telling them to "...send another auditor because this one wants us to ....". Or finding another registrar. It's an expensive, time consuming process. Hopefully a company will choose a 'good' registrar to begin with. But that in its self is not always the case.

Unfortunately - nearly all the auditors I have ever dealt with want to 'see the words'. For something so cheap and quick to do as a 'quality' manual (which I prefer clients call their 'systems' manual, it's simply not worth even going through the possibility of spending the time with a 'difficult' auditor. Anyone who wants to take a chance of getting an auditor such as you is welcome to take the chance. To me the odds are just not worth it and it's not a big deal.

> Until people start to to take control of their ISO
> registrations and demand that narrow minded auditors are
> no longer welcome the problems will continue.

I don't see it as a 'control' issue considering probably 80% (a guess) of the auditors out there don't think like you. It's line by line - by the book for them. My only true concern is an auditor's ability to see the requirements in light of the type, size, etc. of company they are auditing. For example, in an insurance company - what is nonconforming product and how do you deal with it? What does a corrective action system look like in an insurance company? It's these issues (like the auditor who did a writeup for use of whiteout citing legibility of quality records in the old 4.16 and one other clause I forget off hand) in a situation where whiteout wasn't a risk factor and the 'record' was not a defined quality record (which he decided should be - and demanded that "...next audit it will be one of your quality records..."). These are things which bring thoughts of changing registrars.

Me? I say sweat the big stuff. Don't worry about an issue of providing a quality manual which word for word repeats the standard.

JodiB

14th November 2001, 12:05 PM

Having worked for a registrar, I felt ashamed of myself for "taking the easy way out" and being "unimaginative" in creating a manual that follows the standard's numbering system, and being almost anal in making sure that I used all the key buzz words in each section. I did take a bit of literary license in saying some things but for the most part I just wanted to make sure that all the right words were there and couldn't be argued with.

At least this way, I feel somewhat confident that our manual will pass scrutiny and is one less thing for me to worry about.

It feels great knowing that the majority has done the same thing!

:confused: But now I have a question: Someone mentioned to me somewhere that I should consider having an appendix of approved procedures ( or attachment, or something) with the manual, as opposed to referring to the procedures within the sections. This was to allow me to add/ subtract, etc. the procedures without doing a revision of the manual.

The Organization Chart is something else that is supposed to be an attachment for the same reason.

My question is : are these pages rev'd individually then? Do I put some sort of rev level on them?

And in the page numbering of the manual (both on the page and as referenced in the Table of contents), are these attachment (or is it "appendix" ? ) pages listed consecutively or do they have a different numbering scheme? The org chart is inserted around page 8.

I have other things like a figure of the documentation pyramid, and a table of responsibilities for the QMS.

Any help is appreciated!:bigwave:

David Mullins

14th November 2001, 07:44 PM

Put 5 quality managers in charge of 5 identical companies and you'll get 5 diverse views on what should be in the manual.

As one of the "made my own recipe" manual people, I'd ask this:

If we forgot about compliance with ISO 9001 and asked ourselves what should we have in the primary 'mother' document for our company (assuming a fully integrated system), what would we include.
Also, before being able to answer that, we need to determine what it is that we are attempting to gain from having this document.

Based on Marc's poll, and not wanting to start a bun fight, I'd say less than 10% of quality managers would be in a position to answer these questions. Aternatively (saving my rear end here), others probably can answer, but went for the safety net in terms of the appearance/structure of the manual.

So, how does your company benefit from the manual, and what did you put in it to meet these needs? (And therefore, why did you put the other stuff in it?)

For Lucinda's question, I'd say if you're expecting to update stuff that's in the manual more regularly than yearly, then just refer to it and make it a separate document (and make that manual smaller!).

JodiB

14th November 2001, 07:50 PM

Oh but Bloke, I have to have reference to my procedures in the QM.

And, as you say, the QM should provide information on my company that we feel should be communicated to whomever has an interest in the QM (like a potential client or outside registrar) So that is why the org chart is there. As an "attachment", I thought that it did make it somewhat of a separate document that was nonetheless connected to the QM. Doesn't it?

David Mullins

14th November 2001, 08:03 PM

Lucinda, yes, reference it, as I said:

Originally posted by David Mullins
just refer to it and make it a separate document

My companies Quality Policy has to be in the manual, right? I reference it, and other policies, and other level 2 docs (system level procedures, if you like).

Org chart, suit yourself. Mine states position titles, not names, so I've left it in the manual because it is important, and something which was previously unknown across the organisation (can you believe). The names get aligned to the position in a system procedure called "level of authority schedule", which is a matrix of positions/people and responsibility categories, with the intersecting box describing the level of authority.

Forget the registrar. You've got a manual to provide the starting point/launching pad/GO space on the monopoly board for your staff to follow and understand the system. Second purpose is as a marketing tool - provided in tenders etc. So don't make it long and complex.

Marc

14th November 2001, 08:11 PM

> But now I have a question: Someone mentioned to me
> somewhere that I should consider having an appendix of
> approved procedures ( or attachment, or something) with
> the manual, as opposed to referring to the procedures
> within the sections. This was to allow me to add/
> subtract, etc. the procedures without doing a revision of
> the manual.

That's the 'Master List'. They're nice in some cases. See Doc_Matrix.pdf in the pdf_files directory as an example. But I put references in every section - the relevant document(s) - within the quality manual.

> The Organization Chart is something else that is supposed
> to be an attachment for the same reason.

Keep org chart separate. Doesn't even have to be a part of the manual physically. Org charts are often frequently updated.

> My question is : are these pages rev'd individually then?
> Do I put some sort of rev level on them?

Rev and control like any other document. There are so many systems it's - well, up to you. With smaller clients, I encourage them to use date with a revision history on disk (past versions - not a listing of exact changes).

> And in the page numbering of the manual (both on the page
> and as referenced in the Table of contents), are these
> attachment (or is it "appendix" ? ) pages listed
> consecutively or do they have a different numbering
> scheme? The org chart is inserted around page 8.

When an auditor asks about the org chart we go to who ever controls it and show the auditor. Its not an appendix, or an attachment or anything but a stand-alone document.

You're over complicating things IMHO.

E Wall

29th November 2001, 03:32 PM

I have to concur with Marc. You NEED references (not attachments) in the manual to lead someone to the exact procedure that supports the process described without having to get anyone else involved! Unless you have very few documents or lengthy titles, I would surprised if (with very limited knowledge...not someone trained or already familiar with the system) someone new could take the ball and run with it...which is (IMHO) always the best learning method.

JodiB

29th November 2001, 07:14 PM

Yes, I know I have to reference the procedures. I structured the manual to address each part of the standard in order. Within each clause part, I have two sections: Policy,and Responsibilities. I used to also have a third: Procedures. So for 4.2 for instance, there is the general verbage related to our policy and practice for documentation, and then a part that describes functional responsibilities. With a third part there, procedures, I would list the applicable procedures such as control of docs, control of records..

But advice of one of my instructors was to not list the procedures after each section because we may add or remove(?) or change the name of, or whatever, the procedures and this would require a revision of the manual. He said that if I had an "appendix" of quality procedures that listed all the procedures in one place, then the "appendix" could be updated without changing the manual itself - or at least requiring a revision.

So the question is how do I number this appendix, and is it still considered a reference to procedures within the manual if it is an appendix - or would a statement under 4.2 referring to an appendix of procedures be "reference" enough.:confused:

So yes, I'm a big dummy. Completely clueless.

And I have little tables of information within the manual too,(like showing the structure of our documentation) and they are "Figure 1" or "Table 1", and I don't know if these pages are number consecutively with the manual or if they are un-numbered, or if they have their own little numbering scheme like ii and iii.:bonk:

This is what I was trying to ask. Is this any clearer?

David Mullins

29th November 2001, 07:55 PM

Lu,
Lots of ways to do it.
Yes you're better off with the procedures referenced in one spot in the manual.
If you put it in an appendix with the intent of updating the appendix without revising the manual version, you'll simply need to control the appendix in addition to the manual. That is, list the appendix in you document register (or whatever you call it) as a separately controlled document, albeit an attachment to the manual.

Personally (And I'm one of the people who made up a structure to suit the company not the standard) I think you're overdoing the content of the manual. Document structure diagrams are great for awareness training, or even pasting in the doc control procedure, but not the manual. Likewise the responsibilities stuff. People won't (imo) go to the manual for responsibilities, they go to procedures or job descriptions. I'd use the structure and content of your responsibilities information as the basis for briefing management, etc, on their responsibilities - this is a course I actually run with managers and supervisors during the implementation phase.

In short, the advice you received was correct about not including things in the manual which will change on a regular basis (let's say more frequently than annually), as you'll be reproducing the manual for every revision. Keep the manual simple - That's been said soooo many times here, I don't know why people insist on re-writing 9001 as their manual.

PS - In the electronic version of my manual (accessed from a shortcut on everyones PC desktop which takes you to a basic index of the whole business sytem - without buying any software), the list of procedures (which is bookmarked (for direct hyperlinking) within the manual) is used as the master list (date of issue control stuff) and are hyperlinked to the procedures (files stored on server) for instant access. Likewise in the forms manual, job description manual, etc. The manual also contains an easy find index that matches words or phrases to procedures. So If you want to know the process for applying for leave you can look under leave, sick, annual, maternity, paternity, long-service, holidays, etc, etc. and they take you to the correct procedure or form. (I getting off the subject, but I'm trying to display the versatility of not being bound to a 40+ page manual that reverbages ISO 9001)

Hope I'm helping?????

Marc

29th November 2001, 08:41 PM

Originally posted by Lucinda

But advice of one of my instructors was to not list the procedures after each section because we may add or remove(?) or change the name of, or whatever, the procedures and this would require a revision of the manual. He said that if I had an "appendix" of quality procedures that listed all the procedures in one place, then the "appendix" could be updated without changing the manual itself - or at least requiring a revision.

So the question is how do I number this appendix, and is it still considered a reference to procedures within the manual if it is an appendix - or would a statement under 4.2 referring to an appendix of procedures be "reference" enough?Ummm, yes and no. :ca: As always, depends upon the complexity of the company. But in most companies the answer is Yes. The references in the 'quality' manual are to top level systems and while the referenced documents may change internally, as long as the identification doesn't change there isn't an issue. So - typically referenced documents in a quality manual are almost always relatively stable. You're not going to have an organization chart one week and obsolete it the next week. Your level II nonconformance system document - the top level (level II) - will be there even if changes to it are made internally. Why would you want to rename a high level document like that?

The key is how far down you go in your references. You surely wouldn't reference a process instruction, as an example. If you did - yes - your 'quality' manual would be constantly under revision.

A simple way to tie everything together is in a document matrix. I guess you could make it an appendix. I don't see why you'd need to or want to. One I've had posted here for years as an example (a study in simplicity) is in the pdf files directory and as I remember it's titled Doc_Matrix.pdf. It ties everything together pretty well. It has really come in handy for my clients going through 'the upgrade'. Of course, we had, as in the example matrix I cited above, procedurs identified by disk file name or document title. So - even the ones with paper manuals - they already had 20 divisions of documents. We kept the 20 divisions as 'sections'. Because the ID of any given document was unrelated to the ISO 1994 numbering system, there was no need to change the base of their systems. I steered clients away from linking to the ISO 9K numbering scheme years ago. So all my client does is takes the blank manual (well, I'm doing the initial tailoring) and inserts the references from the old manual as they correspond in the new numbering / classification scheme. Two 'new' flow charts and - voilia - they're done. Time for the upgrade audit. This year I have gone through two and I have 2 on deck.

By the way - I just uploaded the base manual I've used with 4 clients now (remember - it's just the base. It has to be tailored) to the Members Access directory (it's been available to the premium folks - along with a lot of other stuff - for a while now). :thedeal:

Marc

29th November 2001, 08:54 PM

Originally posted by David Mullins

PS - In the electronic version of my manual (accessed from a shortcut on everyones PC desktop which takes you to a basic index of the whole business sytem - without buying any software), the list of procedures (which is bookmarked (for direct hyperlinking) within the manual) is used as the master list (date of issue control stuff) and are hyperlinked to the procedures (files stored on server) for instant access. Likewise in the forms manual, job description manual, etc. The manual also contains an easy find index that matches words or phrases to procedures. So If you want to know the process for applying for leave you can look under leave, sick, annual, maternity, paternity, long-service, holidays, etc, etc. and they take you to the correct procedure or form. (I getting off the subject, but I'm trying to display the versatility of not being bound to a 40+ page manual that reverbages ISO 9001)Excellent way to bring everything together.

> Likewise the responsibilities stuff. People won't (imo) go
> to the manual for responsibilities, they go to procedures
> or job descriptions. I'd use the structure and content of
> your responsibilities information as the basis for
> briefing management, etc, on their responsibilities - this
> is a course I actually run with managers and supervisors
> during the implementation phase.

I do have some responsibilities defined within systems manuals for the main systems. Since the positions are high level, they rarely change in smaller companies so the issue becomes moot. The poit being, I agree that responsibilities are spread out throughout many documents / procedures/ etc.

David Mullins

2nd December 2001, 08:13 PM

After a little discussion with Marc, I think the size of the company plays a major role in determining the practicalities of the structure of the QMS.
Marc's base manual reminds me of the pre-1994 days when we used quality plans instead of manuals and layed out the responsibilities in the plan document.
I concede that smaller companies who go for certification are better off making compliance as transparent as possible, and thus benefit from following the Standard approach to structure.

However, I believe, to get the most out of your management system, you've got to be develop one that has a structure that is specific to the organisation, it's products, needs, customer types, etc. Benefits tend to be specifically targeted in this style of structural approach, rather than the across the board gains realised by companies implementing a proper management system for the first time.

So (in summary) I guess the size of the company and maturity of the management system both play a significant part in determing QMS structure.

Marc

3rd December 2001, 01:50 AM

My Rant of the Week:

I find David's post consistent with my 'signature' here where I clearly state: One size does NOT fit all. To me, every client, every company, is an individual.

There is no doubt that the size is a factor (only one of many). Not to mention complexity of the operation(s) and processes. The manual I shared with you was for a company of about 12 souls - total - manufacturing, office folks, and the company owner. It was 'tailored' (more than most because of the small size of the company) so that they did not have to write a bunch of procedures which they did not have before they went throuh implementation and do not need. It was akin to the 'old' Quality Plans because the company only does one thing - mix chemicals in their 3 'vats'. There was a reason for putting many of the things they do, as well as defining many responsibilities, right into the manual - no need for another document. Other than specific work instructions (individual batch mixture procedures, for example) the company only had about 8 to 10 procedures (flow charts) total. In addition, their whole 'systems manual' (10 point Arial font) was 33 pages, which included index, quality policy, etc., etc. When you only do one thing and you're that small a company, no matter how you do it it's going to look like a product specific plan - they unload tanker, pump into vat, mix, drain into drums or totes and ship. No heating, no chilling, nothing but mixing. Easier and more simple than baking a cake. Just a bigger bowl and a bigger mixer. Every day, week in, week out - for almost 50 years now that's all they have done.

Nor do they have the weight behind them (size factor), should a disagreement arise, to want to take a chance on an idiot auditor. Working with Motorola, we had a lot of leeway on many issues that involved "...showing them the words..." that this small company would have had a harder time arguing about. Heck - we had heated arguments several times over "...where the words are..." even implementing at Motorola (I will grant you that was QS-9000, not ISO 9001).

1994-95 was the turning point for me in turning to a 'copy the manual' approach. It was when auditors started the word game. Or at least 1994-95 was when I was first stung by the "...I don't see those exact words..." writeups. It was not enough to say "...We didn't write anything about identification and traceability because it's not relevant in what we do..." Nor was it enough, for example, in addressing 4.3.2 (the 1994 version) to not somewhere state list item B "...any differences between the contract or accepted order requirements and those in the tender are resolved...." The company could both explain and show where and how they did this, but the company was written up because they did not specifically state those words somewhere. I particularly remember that writeup because the company owner went ballistic saying, amongst other things, that's since they do it and can prove they do it, why are the exact words from the standard necessary? He asked where it says a company has to repeat every word the standard contains. The owner genuinely realized at that time that the document (ISO 9001:1994) and registration was not just the BS he had thought all along, but worse. Audits could end up as little more than pissing matches.
****************
The manual I reviewed from David was essentially the answer to a somewhat recent question: Can your quality manual consist of a list of references, a flow chart of your main system(s) and none of the verbiage at all from the ISO 9001 document? I must distill that to what it is - a List of Reference Documents approach which includes a column as to which clause of the standard the document satisfies. The list simply follows the numbering scheme of the standard. It is no more than a list of references - pointers to documents. In fact, if I had shared the document matrix with you from the small company whose manual I shared with you, you would see it looks much like your quality manual! You can see it, however, by downloading the 'example' matrix above. It's what that 'study in simplicity' was drawn from some years ago. And none of it has changed due to the 2000 revision. They only had to change their systems manual. Documents are already categorized, as well. Add the few extras like an org chart, basic flow of processes, quality policy, etc. and you could not say there is a difference between your quality manual and their document matrix other than that they put the 'compliance' words in their system manual rather than in supporting documentation.

I do agree with the approach where it's practical and appropriate. :agree: It's quite simple: It's a Cross-Reference Matrix. I personally feel it is the most logical approach. But I don't look at it as sgnificantly different. 'The Words' have to be somewhere and they are obviously in the supporting (referenced) documentation when you do a 'systems manual' from a list (cross-reference matrix) appproach. Where you put the words, in my opinion, isn't relevant. What is relevant is that they are someplace. Whether you take the time to write them in the 'systems manual' or in the supporting documentation, you're still taking the time to write it. This said, it will soon be known if the revised standard will change the way auditors audit. It's supposed to, but I haven't seen it succeed.

Often times it's simply a matter of an auditor not seeing the 'right' words. That's why I take the 'copy the standard' approach. It has not been a problem when an auditor says "...I see you say you do it, now show me and explain...". It HAS been a problem with an auditor saying (and this is the stuff I just love): "...I can see you are doing it and your explaination is fine - you obviously comply except you don't specifically state that you do that. Now, if you'd just add xxxxxxxx to your procedures or in your manual or somewhere we'll be in business..."

I have for years argued the 'intent' issue. Many people say "...intent, hell! If it says do it then you do it!..." Were that it was that simple. It goes further than that (in part) because issues of verbiage continue to pop up. I can hear the rumbling now from some auditors: "...Well, that's not the way I audit!..." That may be the case, but I can't be assured that every time an auditor visits a client for a registration or surveillance audit that you will be their auditor. I have to prepare my clients for 'worst case' idiot auditors. And I teach my clients to be ready to fight an auditor's interpretation if they believe it's a 'bad' interpretation. To do this it is, of course, requsite that they themselves understand the standard, what it is asking (requiring) and can relate it to their business. This is the reason I for many years argued against 'part time' quality people (consultants on contract for a day or a few days a month, really) even in small companies. I expected my clients to not need me any more after their registration audit. I believe it was discussed in a thread here where I was soundly thrashed by a bunch of folks saying "...we're too small to need a full time quality person..." That's when my 'enlightenment' came and I now explain this option to potential clients. This also came up in a thread where a consultant advertised that they would serve as management representative through the audit and 'hand the system over' after the registration audit. I freaked out because my paradigm was my responsibility as a consultant was to teach the people what they needed to know - including the standard, what the words meant and how they applied to their company.

I will say that when one starts talking about a 'structured' approach I want to scream. I have never had a client (this is not to say unstructured companies are not out there) that did not have basic structures in place. The little company whose manual you reviewed was well structured long before ISO. In so far as how one structures one's systems manual - I see that as a minor thing. One looks at what one has and defines what is needed. Then an approach is determined based upon what exists and what is needed. With almost every client I have had (maybe by luck?), they had systems which were if not compliant, nearly so. All they needed was to understand the standard (and how it applied to them), tidy up some loose ends and provide something to tie everything together - the 'systems manual' did that.

The same for the new 'process approach' of ISO 9001. The reorganization of the standard confuses more than clarifies. Process Approach and Structured Approach should both be in Bullshit Bingo! squares. Buzzwords. We're talking business basics 101 now. Of course, I also think the word Quality should be in one of the squares...

To end my diatribe - I want to cite two examples of how stupid some auditors are for those of you out there thinking I'm overboard on making first assumption that a client will get an idiot auditor.

Case 1:

An auditor comes in and writes a client up for something that a previous auditor (in most cases several previous auditors) went over (yes - in detail) and said was fine and met the requirements. Now we have a 'smart auditor' who really knows his/her stuff (obviously the other auditors didn't) and - all of a sudden their system is not compliant.

Case 2:

I had a client who registered back about 1997. They went along fine for several years. Of course there were the usual "...well, the other auditor was wrong..." incidents, but one day the company owner called me laughing his :ca: off. The auditor tried to cite them for ineffective internal audit system (a major finding) because for the last 2 rounds there had been no findings at all. I was in the middle because they contract their internal audits to me. So - why was he laughing? He stopped the audit and all went to the conference room. They got the registrar's representative on the telephone. The company owner explained the citation for an ineffective internal audit system based upon no findings. The owner explained that for the prior two years the registrar's auditors (visiting at 6 month intervals) came up with no findings. He explained that if the auditor was correct - that a lack of findings is evidence that the internal audit system was not effective - that it followed that since the registrar's auditors had no findings in their previous 5 visits that the registrar was obviously sending unqualified auditors and he wanted his money back all the way to, and including, the registration fees.

Of course, the 'finding' was dropped. It was decided that - gee, well, maybe no findings means that everyone is doing their jobs and doing them correctly. Personally, I wish he had kicked the auditor out the door and sued the registrar. While I won't name the registrar because of my link to clients which use them, I will say they are a major player in the registration game and have been for years.

Hope for the best, but prepare for the worst. YOU may get the Auditor from Hell!

> So (in summary) I guess the size of the company and
> maturity of the management system both play a significant
> part in determing QMS structure.

In addition to a few other factors. In summary, I agree :agree: with you 100% :thedeal:

One last thought: Enron and Mr. Lay. I wonder if Enron was registered.

Neelanshu Varma

3rd December 2001, 03:38 AM

I had come across the attached article and had downloaded it from the net - hope you all will find it interesting. It is related to QMS architecture.

Though the article is focussed on SO9001:1994 standards and software industry, IMHO most of it is applicable in the current context and applies to other industries as well.

Neelanshu Varma

6th December 2001, 06:25 AM

These guidelines by ISO Technical Comittee clarify many of the issues that have been raised related to Flowcharting and Manual structure.

*** DEAD LINK REMOVED ***

Marc

6th December 2001, 07:10 AM

Also see: http://www.bsi.org.uk/iso-tc176-sc2

It's the ISO TC 176 SC2 Home Page

Tom W

5th March 2002, 03:12 PM

Marc - when we wrote the manual we loosly followed the ISO / QS numbering. Since then we have revised here and there, and one of the changes I made was to align with QS numbering as close as possible in the level 1. I find this easier during audits and even internally when we do training involving the requirements.

I am currently looking to convert to TS, but am not sure if I should wait for 2002 version or go with 1999 version that I now have.

Aaron Lupo

8th March 2002, 01:29 PM

Here is a copy of a QM that I wrote for 9K2K you are welcome to download it and use it as your own (provided you make the necessary changes to fit your business). I would appreciate any feedback.

:)

noboxwine

19th March 2002, 07:22 PM

--From a New Guy. Great forum. A lot of knowledge about this crazy mixed up world of COMPLIANCE.
--Of the 3 or 4 QMS manuals I've been a part of writing, I honestly can't remember too many times any format added a lot value to improvement of the organization. It's been more efficient for me to regurg the standard for 3rd party compliance.
--Then, spend the extra time on developing visual, user friendly, colorful, flow chart type Process Instructions that will make a positive impact almost every time.:thedeal:

gpainter

20th March 2002, 08:08 AM

Most tier 1 QM add no value that I have seen. Mostly a selling tool. The new standard helps in this area and I am glad to see that most companies converting to the 00 standard are in fact downsizing the QM.

noboxwine

20th March 2002, 12:16 PM

Yes ! Isn't it interesting that the new standard is ever hinging upon actions resulting in bottom line improvments and satisfaction; As opposed to just a selling tool. There's hope for all us Quality Types, yet. It's about time !:agree:

David Mullins

20th March 2002, 07:56 PM

Originally posted by noboxwine
It's been more efficient for me to regurg the standard for 3rd party compliance.

--Then, spend the extra time on developing visual, user friendly, colorful, flow chart type Process Instructions that will make a positive impact almost every time.andOriginally posted by noboxwine
Isn't it interesting that the new standard is ever hinging upon actions resulting in bottom line improvments and satisfaction; As opposed to just a selling toolWhilst I find the comments in slight conflict, and I'm sure they weren't intended that way, I would like to give noboxwine a job.
I'll write a Quality Manual which regurgitates the standard, and s/he can front senior management, middle management, fornt line management and the staff to explain how the primary document of the system should be ignored by them, as it's standard related crap that is inconsequential to the actual implementation and operation of the management system. No Personal Protective Equipment will be provided.

PS: It's OK to put wine in a box, that way you know which stuff not to drink.

juliedrys

20th March 2002, 11:48 PM

Originally posted by noboxwine
--From a New Guy. Great forum. A lot of knowledge about this crazy mixed up world of COMPLIANCE.

--Of the 3 or 4 QMS manuals I've been a part of writing, I honestly can't remember too many times any format added a lot value to improvement of the organization. It's been more efficient for me to regurg the standard for 3rd party compliance.

--Then, spend the extra time on developing visual, user friendly, colorful, flow chart type Process Instructions that will make a positive impact almost every time.I agree with this post. I recognize that the standard does not require that the manual include anything more than the scope, the reference to procedures and the description of the interaction of processes. However I find it useful to include the policies in this document, and what that means is addressing the requirements of the standard; the path of least resistence here is to keep the structure and most of the words of the standard.

I've seen this provide some value in that there are many execs who wouldn't dare to read the standard but would spend the time to read and comprehend the quality manual. The manual can in a sense translate the standard for them.

Other than that, when is the manual most often used? I find that the most frequent audience is either auditors or the handful of customers who want a copy. With this in mind, the standard-centered approach makes sense. It doesn't make me completely happy, but it makes sense.

Beyond that, I realize that the policies themselves don't have near the impact that the lower-level documents do, so I prefer to spend my time making useful and usable flowcharts/process maps. These are the documents that people are actually using.

Julie

David Mullins

21st March 2002, 01:53 AM

Originally posted by juliedrys
I prefer to spend my time making useful and usable flowcharts/process maps. Sounds costly on a consulting basis!

Is a "paraconsultant", like a paramedic - Someone with virtually no qualifications or experience but will take a look at it for you?

juliedrys

21st March 2002, 03:22 AM

Originally posted by David Mullins
Sounds costly on a consulting basis!Indeed, it can be. It's more common for me to help them design the look and feel of the documentation and teach them how to do it. This is better for them in the long run anyway.

Sometimes we provide a technical writer (not at consulting rates) who's trained in the format. But there's always the small customer who just doesn't have the time or personnel to commit to writing documents. In any case, the content has to come from them.

On a related note, one of my customers showed me a fax they got from a company that was selling a CD of 250 "ISO Procedures and documents" for $199. Guaranteed to achieve registration! :rolleyes:

Julie

SteelMaiden

21st March 2002, 09:41 AM

Originally posted by David Mullins
Is a "paraconsultant", like a paramedic - Someone with virtually no qualifications or experience but will take a look at it for you? :( Careful David, you may need the services of a paramedic some day. The ones I know, I would trust more than a lot of doctors.

David Mullins

21st March 2002, 08:03 PM

Originally posted by SteelMaiden
Careful David, you may need the services of a paramedic some day. The ones I know, I would trust more than a lot of doctors.I was the quality manager of the first acute health ambulance service in Australia to be certified to an ISO 9000 standard, so I am confident I know (knew) the game from an Aussie viewpoint.

The definition of paramedic, causes paramedics concern!

As far as Doctors versus paramedics goes, no contest - Doctors hands down. I've seen too much first hand evidence of the results of paramedics when their skill level let the patient down (yes, that happens with doctors too, but from a statistical point of view - no contest).

JodiB

8th April 2002, 10:23 AM

[i]Originally posted by Jim Wade
Put the stuff required by clause 4.2.2 anywhere you like in your system and tell the registrar (in the interpretation document) that you don't have a Q manual but they can find scope, justification, procedures and process descriptions here, here and here. If they want to call those places collectively a Q Manual, fine.
[/B] I don't think you can get away with saying that you don't have a QM since 4.2.2 says that you shall have one and that within it you will have specific things. If you want to make the argument that these items live in disjointed pieces of documentation within the organization and therefore your QM lives here and there and there, well that just sounds ridiculous to my mind. Why make things harder than they have to be? If you have these items of documentation then why not bundle them into one place? I haven't looked up the specific definition of "manual" but I would hazard a guess that it means a compilation in one place.....

Aaron Lupo

8th April 2002, 02:38 PM

Originally posted by Jim Wade

We structure a system sensibly (with the business in mind) and then say to the auditor "we don't use the term Quality Manual, but the stuff you want to see is all there, isn't it?. Are you seriously going to run the risk of losing the business of being our supplier by insisting that we put those three bits together, when you can't explain how that will help us achieve 'quality'?"

And - to use your phrase - we "get away with it" :)

rgds Jim

Jim just curious who is your Registrar? How much do you pay to obtain your certificate??

"The quality management system documentation shall include:"

b.) "A QUALITY MANUAL"

Also you say write this for the auditors eyes only, on numerous occasions we have had our clients ask for the Quality Manual, you say it is not important for the Managers or people that do useful work to know where it is. I disagree espically where I work, becuase that is where we document our Quality Policy.

Randy Stewart

8th April 2002, 02:50 PM

"The quality management system documentation shall include:" b.) "A QUALITY MANUAL"

Does that mean we have to title it a "Quality Manual"?
What if we title it Level 1 document?

We're talking spirit and letter here. What is the purpose, this is like saying that 4.1.2.1 mandates the use of org charts.
I have a book with the Level 1 - Quality Manual and the Level 2 procedures in it. It is for Registrar use only and marked as such.

Our Quality Policy is posted all over the shop and documented and controled in our "Business Operations Manual".

Aaron Lupo

8th April 2002, 03:44 PM

Originally posted by Randy Stewart

Does that mean we have to title it a "Quality Manual"?
What if we title it Level 1 document?

We're talking spirit and letter here. What is the purpose, this is like saying that 4.1.2.1 mandates the use of org charts.
I have a book with the Level 1 - Quality Manual and the Level 2 procedures in it. It is for Registrar use only and marked as such.

Our Quality Policy is posted all over the shop and documented and controled in our "Business Operations Manual".

Randy, call it whatever you want I don't give a darn if you call it a Business Manual or whatever. You guys think ISO is tough try working in an industry regulated by the FDA.

As far as for the Registrars use inly what do you show your clients when they ask to see your QM or whatever cute little name you give it? Do you tell them you don't have one?

You say your QP is posted all over the shop and it is documented and controlled in you cute little Business Operations Manual. So you also have a list of where the QP is posted in your shop correct? If you don't you should simpliy for the fact that if and when it is changed how do you know where it is and where it needs to be re-placed?

These are JMHO so take it as you see fit.

James Gutherson

8th April 2002, 08:44 PM

ISO Guy, we don't have a quality manual, and we told our registrar, and any one who asks, that we don't.

We have an intranet site that, amongst other things, (from ISO9001/2000 - 4.2.2)
'
includes

a) the scope of the quality management system, including details of and justification for any inclusions

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

'

ohh and we try not to use the 'Q' either.

To us this makes a lot more sence than having a great wad of paper with the word Quality Manual on the front that no one in the organisation will ever see.

The intranet site however, everyone see's, and uses to access forms, records, procedures, background to procedures, databases, upcoming news, performance data etc.

Granted we are not like private industry (we are a regulatory government department) and don't need to sell our services to anyone, but I have been there also and would never use a QM as a sales brochure anyway.

Remember that this standard was written for all types of business, in every country of the world, so there are going to be a lot of different approaches. And anyway, aren't we supposed to now be auditing with regards to the effectiveness of the system. If something is working, producing the results they want and meeting the requirments of the standard, how can we tell them that it is the wrong way to do things?

JodiB

8th April 2002, 09:17 PM

This is baloney. If the intent was simply to have this information available then it would have been stated that way. Like many other requirements. But it wasn't. The writers quite clearly said it would be in a manual. Period. While there will always be some folks who want a pat on the back for being "clever" in weaseling around this simple and clearcut requirement (as well as others), I think it is hogwash. I'm also not impressed by being able to bully or fast talk a registrar into what amounts to flagrant disregard of the standard, for this or any other requirement. Buying a cert is distasteful and receiving one for a system that is obviously not compliant by threatening to take business elsewhere is just that.

There is no allowance for a company to find business sense in the standard's requirements as a test of applicability. So whether or not a company thinks it adds value is quite beside the point if you are asking for certification of compliance to the standard.

Ok, so just my opinion. And an attitude forged by working for several years to guard the validity and integrity of the certification process.

James Gutherson

8th April 2002, 09:56 PM

The standard says

4.2.1 General

The quality management system documentation shall include
a) ....
b) a quality manual,
c)...
.....

Note 3. The documentation can be in any form or type of medium.
(my bold)

Then it goes on to define what is required in the quality manual

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 inclusions

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.

It clearly says the documentation can be in ANY form or TYPE OF MEDIUM.:evidence:

My Intranet site is my Quality Manual, as well as a lot more. (but it is not a dust collector!)

This is in NO WAY weaseling around the requirements of the standard.

JodiB

8th April 2002, 10:50 PM

Originally posted by James Gutherson we don't have a quality manual, and we told our registrar, and any one who asks, that we don't.I agree that it can be in any medium. You score that point. But despite having the information available in the format of your choice, you still proclaim that you do not fulfill this requirement of the standard. Your own words. You say that despite having this electronic version of everything that the QM is required to contain, you don't have a quality manual .

So either you do or you don't. If you don't , then you are not meeting the requirement.

James Gutherson

8th April 2002, 11:26 PM

Ok I get what you are saying, I think. Perhaps I didn't explain fully.

That is what I told our registrar, "We don't have a Quality Manual per say.", then I said that "What we have is an Intranet site that fulfils the requirements of a Quality Manual" as defined in the Standard. BTW our registrar is the largest and most respected in Australia and they have no problems with it.

We don't use the word 'Quality Manual' anywhere, except in the cross reference matrix prepared for the registrar. I know that it (the intranet site) is 'in effect' a Quality Manual, but our staff just know it as "the web site".

This is something that provideds value for us and still meets the requirements of the standard. A binder with some pages copied from the Standard and the words "the organisation" replaced by a company name is IMO of no value to the organisation, the only value is to a lazy registrar. (I'm not saying this is about your QM, but about the majority of QM's I've seen.)

Randy Stewart

9th April 2002, 08:40 AM

While there will always be some folks who want a pat on the back for being "clever" in weaseling around this simple and clearcut requirement

I guess I would rather be a weasel that brings value to the company I work for than a lemming that blindly runs the company down because he must conform to the letter.
Don't you see how rediculous this is??? Does it really matter what it is called or where the content is stored. Isn't it more about being able to show and prove that the intent of the standard has been upheld????? I have always attempted to go into implementation with the notion that the "ISO & QS standards do not prohibit the use of reason".
Here is a perfect example of why suppliers do the "ISO dance" as Marc put it. And why a certificate or registration means only that a system was found in compliance at a particular moment in time. The registration audit becomes nothing but a snap shot in time and losses it's intent and purpose.:ko:

So whether or not a company thinks it adds value is quite beside the point if you are asking for certification of compliance to the standard.
In other words - Resistance is Futile :eek:

Mike S.

9th April 2002, 09:09 AM

Originally posted by James Gutherson
That is what I told our registrar, "We don't have a Quality Manual per say.", then I said that "What we have is an Intranet site that fulfils the requirements of a Quality Manual" as defined in the Standard. BTW our registrar is the largest and most respected in Australia and they have no problems with it.

We don't use the word 'Quality Manual' anywhere, except in the cross reference matrix prepared for the registrar. I know that it (the intranet site) is 'in effect' a Quality Manual, but our staff just know it as "the web site".
_____________________________________

Here's my perspective for what it's worth...

So you DO have a quality manual. You just choose to call it something else. If that makes you happy and suits your organization's needs, wonderful. Your registrar calls it a quality manual, so you meet the standard's requirements.

A rose by any other name...

Mike S.

SteelMaiden

9th April 2002, 09:20 AM

Originally posted by Jim Wade

So, be contrite, and create a handy book (that's what a 'manual' is).

Sorry, I am not going to create a book. Our system is intranet, and that is what you get. Most of the auditors have liked the intranet format. I have used it for ISO 9002-94, QS and now 9001-2000. I have never had a nonconformance against not having a "Quality Manual" We have one, it is electronic. If auditors want an uncontrolled paper copy of certain areas for their use in the audit, fine. But I've never been asked to print out the entire portion of the web that would comprise the level 1 documents with the exception of the initial desk audit, and even then only 2 of the three implementations. The QS certification desk audit was done by e-mailing an electronic copy that the registrar viewed using his browser.

So, even though I think that to state we "don't have a quality manual" is perhaps a fallacy, there is no requirement to have paper copies floating around. Please try to remember that we all do business differently and just beacause you do something one way it doesn't mean it is the only way.

Obviously they have the electronic equivelent "We don't have a Quality Manual per say.", then I said that "What we have is an Intranet site that fulfils the requirements of a Quality Manual" as defined in the Standard. and their registrar was satisfied that it met the intent of the standard. How that becomes fraudulent, injurious to the integrity of the certification system, or anyone trying to weasel out of something is unclear to me. But, I'm just a good ol' country girl without a lot of book learnin' beyond my Associates Degree, so I guess I could be wrong.

Or maybe there's room to change your paradigm? :agree: :truce:

Randy Stewart

9th April 2002, 09:23 AM

A rose by any other name...
You can complain that the flower has thorns or enjoy that the thorns have the flower!!!
As with the "Quality Manual" it's all in how it is perceived.
:smokin:

JodiB

9th April 2002, 09:40 PM

as long as you recognize that it is still a rose even if you want to call it a petunia...

Whether your QM is on the network, is delivered by lazer light show, or is spelled out with Campbells alphabet soup, you've got to have one. And it's got to have the critical elements. You cannot proclaim that you don't have one, and it should (iMO) be in a consolidated location. Otherwise, all you have done is have the required information available "somewhere". Which is not (IMO) what is implied by the requirement to have a manual. I believe the intent of the manual is to have this upper level information content in one assembled place to provide an overview of the company's QMS in a easy-to-see-it-all-at-a-glance and easy-to-distribute-to-all-interested-parties format. I certainly don't think that it has to be a hardcopy.

Regardless, I think that if you look critically at what you have and you find that you have assembled what you describe as your top level documentation in a structured place, you have built yourself a QM whether you like it or not. And if those required elements are nowhere to be found within that upper level documentation, then you fail to meet the requirements of the standard.

Steel, James' post regarding the fact that he does indeed have a QM negates any of my previous comments that may have been construed as being aimed at him. Apparently what his registrar witnessed was indeed the QM.

I do find it somewhat amusing that "interpretation" applied by a registrar as to the intent of the standard is welcomed and is not a dirty word when the "interpretation" call goes the company's way..... Otherwise the shouts are " where is the shall?" :vfunny:

James Gutherson

9th April 2002, 10:16 PM

Truce Lucinda?:truce:

As a professional paid to ensure that our organisation meets the requirements of the Standard I know what we have in in effect a quality manual, and my registrar know that too, but it is far more valuable to us than a book regurgitating the layout and words of the standard.

I'm going to leave this now, I know you must be upset with the Stars going from Division champs to out of the playoffs, and the mighty San Jose Sharks taking their rightfull place as Pacific Division Champions.

PS. I lived in San Fran for a while and just can't help having a dig at a Texan;)

Randy Stewart

10th April 2002, 08:51 AM

I do find it somewhat amusing that "interpretation" applied by a registrar as to the intent of the standard is welcomed and is not a dirty word when the "interpretation" call goes the company's way.....

I agree with you Lucinda, and this is exactly what makes the water murky. Believe me, I don't twist our system just to make it more difficult for the auditor. I have to sell it to the company and to management in terms they understand and can accept. I may have to "repackage" it for the auditor in order for it to make sense to them and for ease of auditing (i.e. separate book, etc.) but I don't see it as trying to weasel out of something.

I know that the external auditors have a job to do and they have requirements to follow. But when they come into a work place it is viewed as a challenge to that company. My interpretations (or misinterpretations) may result in an NC, but the auditors interpretations or misinterpretations may result in lost jobs. Since I started working in this field I have seen 4 QMs and 2 ISO/QS Coordinators fired due to audit results. I'm sure there were some other factors in there, but the releases came after a bad external audit (2 registration, 3 surveillance, 1 upgrade). So you see when you (the auditor) place your quality system template (mind set) on our quality system(s) it may mean my job!
I remember the case study in the Lead Auditor Class where the company has the news media in house etc., etc. and you have to tell the CEO he is not recommended for registration. One of the first things the trainers did in the senario was to fire the QM during the closing meeting. It is real life.
In a perfect world we would all be on the same page, same paragraph and pronounce the words the same. But until that time we must remain flexible in our interpretations and ensure the intent is met.
:truce:

JodiB

10th April 2002, 10:22 AM

QUOTE]Originally posted by Randy Stewart
But until that time we must remain flexible in our interpretations and ensure the intent is met.
:truce: [/QUOTE]

I think the difference may lie in what we consider to be the intent of this requirement. I see it as an attempt to have the information in an assembled location, and others may simply see it as a requirement to have the information. I feel if the only requirement was to have the information, then a quality manual would not have been dealt with separately under the documentation requirements.

So perhaps that introduces a new line of discussion: Why was a quality manual specified to include these items of information (under 4.2.1 and 4.2.2) rather than simply listing them along with the other required documents in 4.2.1? The procedures (4.2.1c ) - or reference to them - and the Policy (4.2.1a) are components of the Quality Manual (4.2.2). The QM does not exist without these two components - why did they list quality manual as if it is a separate and special sort of document?

Bear with me, I'm playing the pick-it-apart game to try to understand the intent.......

So while the QM can consist of the whole bucket load of procedures plus the two additions...(a network site with everything in one place), A simple directory of procedures without the two additions does not constitute a QM, right?

Which brings me back to the first question, why weren't the additional items (description of processes, scope of QMS) listed among the general documents section 4.2.1? Why even mention a "quality manual" at all??

What is the Quality Manual supposed to bring to the table?

gpainter

10th April 2002, 11:03 AM

I think that the new standard used the info from the registrars, the registered, consultants, etc. to make the standard better, as in the case of the QM (Tier 1). Everyone knows that the only areas of real info. in the majority of the 94 QMs were in 4.1 and to some extent in 4.2. Generally the rest of the QM was a waste. I applaud the change. One knows what is needed by 4.2.2, if you want more - go for it!!!

M Greenaway

10th April 2002, 11:27 AM

Absolutely right Lucinda.

If we can bend the rules that far what else can we get away with ?

No training perhaps ?

No management representative ?

No calibration ?

In fact nothing that is required in the standard ?

What would ISO9001 certification mean under these circumstances ?

Randy Stewart

10th April 2002, 12:45 PM

My experience would say that the Quality Manual only brings dust to the table. Reason being is that it is only referenced during an audit.
The Quality Manual is a high level document that outlines the basis for the system - an outline. It provides targets for the overall quality function of the business. In other words a place for the auditor to start (doc audit). The normal everyday function of the business/system is governed by the process flows, procedures and work instructions. These SOPs (if you will) are derived from the targets outlined in the manual.
(This next item maybe the cause of our disagreement) QS requires us to have a "Business Plan" (4.1.4) to show where we want to company to go. IMO if these 2 documents don't mesh you will see a complete breakdown of your system. You have 2 plans or manuals that can't see eye to eye.
If we can agree on these 2 premises, we can come to the understanding that a blend is necessary. By requiring that the 2 be separated and maintaining a "pure" QM it promotes and drives the separation between MFG and QA.

M Greenaway

10th April 2002, 12:49 PM

OK so the Quality Manual might only be used by auditors, but as it is part of your companies desire to have ISO9001 certification because it opens up business for you, then your QM adds value to your business.

Doesnt it ?

Randy Stewart

10th April 2002, 02:13 PM

I don't remember any of us stating that the QM didn't add value. The issue was the interpretation of what a QM was (form or function). If I read your question right, you're advocating that keeping a QM just to maintain or get a certificate is beneficial?? I can't believe that, it must be a misprint!!!!:eek: :vfunny:

What I have attempted to do here is to integrate our systems (MFG & Quality). By maintaining and using a separate book titled "Quality Manual" it negates this integration.

Majority of the items I have talked about and have had my arguements about revolves around this integration. Our manufactuing operations must embrace, believe and implement the "Quality Objectives" or those of us in the US auto industry are doomed. JAMA members have done this for years, it is such a stretigic part of their organizations it isn't even discussed - it is their culture. You will not hear a Toyota employee talk quality outside of the operation/process, because they are so intertwined they are one in the same. They don't have Quality Manuals, Business Manuals, MFG Manuals - they have 1 and it's an Operations Manual, there is no separation.

This is why I will not operate with a separate "Quality" manual. I'll have one for the auditor and it will be maintained.

It has taken me 3 years to get this far in integrating and I'm not going to change in order to maintain a certification. Our customer is now our parent company and the outside supplier requirements are no longer applicable. We do not maintain our certificate because of the business oportunities, we maintain it because we believe in the system.
:thedeal:

Michael Christie

10th April 2002, 04:32 PM

I know that I come to the forum to find better ways of doing things, not ways to circumvent the rules....

I have all of our quality system on the intranet, with a central access point, sort of a "one stop shopping" site. My long term goal is to be able to do management review from this site, as well as have it as a general access point. I have a "quality manual" there, as well as procedures, forms, reports, corrective action system, and all those other things that help a factory run right. The necessary information is available to any computer terminal in the company. Copies can be obtained from a printer.

ISO 9000 is a model for a quality management system. I am rather dismayed that the focus goes to the word "quality" rather than "management". Every business has a management system. Maybe it isn't documented, and maybe it doesn't work well, but it is there. I am sucessful in my heart when I make this management system work better. Quality is inherent in a properly operating business. We all know that!

I really think something is seriously wrong when a company perceives that it must have more than one "manual" to describe it's business model. I agree with what Randy Stewart is talking about, an integrated system. Why can't the quality elements be integrated into an "operations manual" or any other description of the overall management system? Or, for that matter, what is the real difference between them?

M Greenaway

11th April 2002, 05:01 AM

There are really two seperate issues to consider here, firstly obtaining a certificate for contractual reasons, and secondly operating an effective QMS. Each has its value, and the best companies combine these two desires. However you must appreciate that not all companies are multi-national conglomerates that have huge potential cost savings/wastes that necessitate a mature and effective QMS. Most companies are small businesses that just need the certificate to do business - this does add value to the business and is worth doing, however battling with a registrar over some arty farty QMS has little benefit to them.

Get over it guys.

I also think that hiding the term 'quality' so that it is almost non-existant does not serve the true purpose of the QMS or the business. What do we do, not comply with ISO9001, not talk about quality, have no quality manager or quality staff - just hope that people have been born perfect ? Wishful thinking guys !

Randy Stewart

11th April 2002, 08:55 AM

The main priority of receiving certification isn't for a debate with the auditor. Nor is it to show-off how tricky or slick the system is. I don't care if the new title of the QMgr is Convicted Felon and the Qual Manual is called the Book of the Dead. Does the system operate within the parameters and guidelines of the standard and does it meet the requirements, should be the questions asked.
Maybe I'm wrong in believing that there are different ways to comply, but I don't believe that the standard was drawn up to be a cookie cutter where every companys' system would look the same.
Just because I dust off a "Quality Manual" for the auditors doesn't mean our system isn't in compliance. I have a ton of objective evidence to prove we comply.
Going over our discussion here, isn't it obvious how interpretations vary from individual to individual. I've been through the classes and been through the audits, and I still may look at issues differently (no doubt). If I'm wrong, I'm wrong but there is still enough auditor in me to say "show me".
I have really enjoyed this topic and I trust that no one involved feels I have picked on them or challenged their professional expertise. Honestly.
:agree: :truce:

Randy Stewart

11th April 2002, 09:46 AM

they must have a certificate, will be defensive and make their own business-oriented interpretation. You are in the latter category, it would seem?
The requirement by our customer(s) isn't there anymore. We don't have to maintain the certification. GM & DC never have required us to be registered because we do prototype work for them and Ford no longer requires it because they own us now (wholly owned subsidiary).
I worked with the Dearborn T&D guys to get them ready for their ISO registration and assisted in developing the R&M requirements (TE-9000) for T&E design houses (mainly production fixtures and dies).
Currently working on the move to TS16949. I guess you can put me in that group, we are maintaining until we register to the new "standard". It's just not a must.

obaraguy

12th July 2002, 10:40 AM

Does anyone give copies of this manual with supporting documents to each department? Such as specific procedures pertaining to their dept., forms pertaining to them.......etc.
I've done this because upon implementation of our "new" system, I felt it was the only way to get each dept. familiar with the procedures and also to verify the procedures match what they are actually doing (even though I asked how they did things in the beginning)

Claes Gefvenberg

12th July 2002, 10:54 AM

Yes. Everyone here can access our manual and all procedures - on the intranet.

/Claes

Paul Simpson

12th July 2002, 11:20 AM

Interesting thread, I voted for the tailored approach and here is why. In my life as a QM and consultant I see two roles for what I do ...

1. translate ISO 9k2k, 14k, etc etc requirements into language the people I work with can understand and

2. translate the work that the organization I work for into words that the external "experts" can relate to the wording they are used to.

I prefer to do the second part in person but will (at a push)provide a cross reference of organization's processes and sections of the highest level document / intranet site to those clauses that he / she needs to tick off on the audit plan before he / she can give me the certificate.

SteelMaiden

15th July 2002, 10:55 AM

obaraguy said:

Does anyone give copies of this manual with supporting documents to each department? Such as specific procedures pertaining to their dept., forms pertaining to them.......etc.

Not sure if this will help you or not, but all of the work instructions are named to denote the area they pertain to, i.e. LB-001 would be for the lab, SA is for sales, etc. we have an index with the work instructions entered under their corresponding areas. The forms are also listed under the area where they are filled out. If there are work instructions that are for ALL employees, they are named GN for general.

We also have created an SQL data base that controls documentation. Each document has a "route" associated with it so when changes are made everyone on the routing list is notified. I think I had stated somewhere in previous post that these notifications are tied to the employees' time cards electronically and must be read and acknowledged before the timecards are submitted. The notices clearly state that if the employee does not understand the revisions they must contact the supervisor or manager of their area. The acknowledgements are saved as records for training purposes.

E Wall

17th July 2002, 12:32 PM

obaraguy said:
Does anyone give copies of this manual with supporting documents to each department?

We dual systems since the 'shop floor' doesn't have access to the intranet..but then again, they rarely ever ask or need to refer to higher level documents. All staff (including supervisors and leadmen) can view the intranet which has Quality Policy, QA Manual, Specifications (Product, Material, Test Methods and Process), Work Instructions, and Forms. The SOPs are posted at point of use on the shop floor along with a manual containing any work instruction needed for reference in that department (and forms are in filing cabinets in dept used as well as master copy at the copier machine).

Alli

18th July 2002, 07:07 PM

I have just rewritten our Quality Manual. Although the 1994 version was number using the standard I felt as though the 2000 was easier to use key elements and reference the standard in the paragraph. Since we are a small manufacturing chemical company I struggled with the exclusion for design but have given the draft to the upper management for review. He chuckled when he read my mission statement (I don't think that this was required, just looked good) and asked where I got it from because he didn't think we had one!!!! My interaction is basically a diagram with arrows going back and forth between each section (Management, Customer Service, Manufacturing, Logistics, Lab, Purchasing, etc.) to our main focus of the customer. Since we have decided not to hire a consultant, I have had quite the task. I started with the quality policy (added to the existing to meet the requirements) and then went to the manual. Now I am getting to the nuts and bolts of the new standard. These forums and the workgroups that I have joined have provided me with lots of information. Thanks for all who read and have responded to my questions.

tarheel

22nd July 2002, 04:19 PM

Does anyone think the quality manual is really useful. Of all the documents I think are needed for a quality system, this one is one I see as absolutely being unnecessary. The document usally resides in a file cabinet (or network drive) and only comes out for customers or auditors. Am I the only one with this opinion?:thedeal:

gpainter

22nd July 2002, 04:33 PM

Agree, after the desk audit most auditors never look at it only the customers request it from time to time. The 00 standard does make a move toward a more useful document.

MrPhish

22nd July 2002, 04:38 PM

The Quality Manual in my QMS is the single point where all of my procedures, work instructions and other quality related documents come together. It is the table of contents of my entire QMS. I created it because the standard said I had to have one ... for the registrar to give me a certificate.

Understanding this relationship bewtween workers and a quality manual, I took the context of the QM and created the same table of contents affect in a graphical format I called a Process Mapping Tree (PMT) using standard flow charting symbols. The result is a lot less text, but the exact same road mapping of all procedures and instructions within the QMS. The outcome has been great. My employees use the PMT on a daily basis to perform the necessary quality functions while the actual QM is hardly ever used. In effect, I gave the employees a simple EQUIVALENT tool they understood and use all the time. On the other hand I left the text driven, dust collecting QM for the registrar because they required it and the text driven format is what they are use to seeing. My next step is to convince the registrar that the PMT is THE quality manual and thus have one less document to update.

noboxwine

22nd July 2002, 04:49 PM

tarheel said:

Does anyone think the quality manual is really useful. Of all the documents I think are needed for a quality system, this one is one I see as absolutely being unnecessary. The document usally resides in a file cabinet (or network drive) and only comes out for customers or auditors. Am I the only one with this opinion?:thedeal:

I have NEVER used it for anything other than 3rd party requirements. Waste of time, space. Just as useless as 5.5.2- "shall appoint .......Management Rep". Duh...............:bonk:

I can't believe I am still doing this for a living. What a joke.

Tom W

22nd July 2002, 04:51 PM

In most cases I would agree that companies make the QM very generic and it only states the shalls. But if an organization looks at ISO or QS or TS and sees that it could help them and not just go through the motions, then they can add to the shalls and build a solid quality manaual that acts like a company overview and references meaningful procedures. The policies located in the QM don't have a lot of meat but they should say something about the organization in a way that makes customers feel like the process actually means something. I get sick and tired of reading posts on this site that imply that the ISO / QS / TS / AS / etc. standards are just a joke or a front for money making. If a company is serious about the process and actually utilizes tools to improve based on the guidance from the satandards, then it obviously will help. Nothing is free in this world and as long as customer require things, suppliers will do them. The question is which companies will do them as a minimum and which companies will truely implement and try to get better. Customers what cheap services and suppliers, but they also what it done right the first time.

Companies that are required do get certified, but take it as a way to truely improve business are the ones that customers will go to, because the outputs will be better over time.:bonk:

Say what you do; do what you say and get better at it and you will have success. Get certified because you have to and don't put much stock in it and join the rest of the chapter 11 companies out there that could not stay afloat in the lean times. I am not saying that QS is the saviour of companies, but it is a good tool that can assist a company in it's quest to get better and more market share. Any company can say the are "High Quality On-Time" but prove it to your customers, or better yet to potential customers. Implementing a meaningful and useful system based on a standard should be seen as a improvement tool and technique rather than a requirement.

I will get down off my soapbox now.

tarheel

23rd July 2002, 04:46 PM

MrPhish, I would be very interested to see what you have done, if you are willing to share. It sounds interesting. Send me a private message and I will give you my e-mail. Thanks.

MrPhish

23rd July 2002, 05:30 PM

Tarheel, I originally posted a JPG copy of my PMT on this other thread: ISO 9001:2000 - Types of Processes Other Than Product Realisation Processes (http://Elsmar.com/Forums/showthread.php?s=&postid=35679#post35679)

My post and file link are at the top of page 2. Also be sure to check out Julies sample file at the bottom of page 2.

tarheel

24th July 2002, 05:32 PM

Thanks for the input. Good job. I really like the concept

km2red

6th August 2002, 04:09 PM

I work for a company that has many plants and 1 corporate office. Every site (including corporate) holds their own separate certificate, however corporate is listed as a "supporting function" for all sites (for design, purchasing, etc.).

We are currently beginning to transition the plants to TS, but still have QS plants. To make it even more confusing, our corporate office is registered to ISO 9000:2000 (since we, as our own entity, don't meet the requirements to be QS or TS). So, our quality manual covers: QS-9000, ISO 9000:2000 and TS 16949:2002.

I agree with the majority that the quality manual is a bunch of crap. But I have the registrar keep saying to me that especally with TS and ISO 2000, it should be a valuable document. (I think they just want document review money...)

But I do have a question. One of the requirements of ISO 2000 and TS 2002 is to have your processes and the interrelation between them defined in your QM. Has ANYONE figured out how to do this yet???? (for a company that does more than sort rocks...). A project in our company could take about a million different paths depending on the nuances of the customer. It would be next to impossible to create a flow chart with more than 5 boxes but less than 200. Our registrar hasn't rejected the manual yet (of course, I just sent it in this morning...). Anyone have any ideas? :frust:

tarheel

6th August 2002, 04:32 PM

Hi KM2red,

Dont' get to bogged down in trying to define every product path.
We broke our flow down into the major departments such as sales, purchasing, manufacturing depts, etc. Then I listed what some possible inputs and outputs would be. Our auditor said that was suffiecient to satisfy the standard. Here is a quote from their own interpretations they give their auditors. "The org. is not required to produce system maps, flow charts, lists or processes, etc. as evidence to demonstrate that the processes and their sequence and interactions were identified. Such documents may be used but are not mandatory." I think that gives you a lot of leeway, of course your registrar may have different interpretations.

km2red

6th August 2002, 04:41 PM

:ko:

I'm beginning to think the word "interpretation" means "what ever will make me the most money". I had an instructor come through for a TS Implementation class telling everyone that the QM only had to be 5 pages long and the processes and their interactions could be defined by the flow chart in the 9000:2000 standard. (this, of course, made him VERY popular with the ISO coordinators who hired them for site training).

My registrar thinks you should list out all of your processes and their interactions. (hence: a longer documentation review and most likely (although: Please God no....) modifications needed to the manual and another doc. review).

gpainter

6th August 2002, 04:43 PM

For 9001-2000 many are using the cross reference table provided by ISO to show interrelationship. If you have a reference section in your System Procedures that will show it. Many are using the model provided in the introduction.1 We have taken the approach that the old 94 elements are now processes (sub).

Mike S.

7th August 2002, 10:41 AM

gpainter,

I'm kinda dense sometimes. I don't understand what you are saying. Could you elaborate please?

gpainter

7th August 2002, 11:08 AM

This was in response to KM2RED's post. Most seem to be taking the interaction of processes to extreme! If it adds value to the system then "go for it" In the introduction section of the standard .2 process approach last paragraph shows and says it all. The chart in the same section figure 1 clearly shows the distinction between the processes of the QMS and the manufacturing processes.

km2red

7th August 2002, 11:15 AM

gpainter said:

The chart in the same section figure 1 clearly shows the distinction between the processes of the QMS and the manufacturing processes.

I agree, but the reqirement of the standard is:

"4.2.2 c.) a description of the interaction between the processes of the quality management system."

Which I (and my registrar) interpret as how does sales interact with purchasing, etc. Our problem is, sales could interact with purchasing a million different ways or not at all. We have so many areas of engineering, and the path that one product takes (and the interaction between those processes) is not the path that another product will take.

So...I end up with:

Sales--->Design (although, not always)---->Purchasing----->Manufacturing

as a flow chart, or a flow chart that is so convoluted, it doesn't do ANYONE any good!!! :bonk:

M Greenaway

7th August 2002, 11:27 AM

km2red

I am sure in a few years time we will be questioning the value of this process 'map' required by the standard (if not already).

M Greenaway

7th August 2002, 12:19 PM

Or even more harmful, not spelling out the requirements to understand processes (and causes of variation).

gpainter

7th August 2002, 12:25 PM

If you go with the key processes it can be "not at a detailed level." I think the key in your statement was" Which I (and my registrar) interpret" If you have decided to use flow charts that is what the auditor has to audit. The best advice (IMO) is to do as the standard does. Do a chart like fig. 1 with a statement: This is a model of X X Companys'Process based QMS which shows the interaction between the processes.

Mike S.

7th August 2002, 12:46 PM

Who actually pays attention to these process maps in the Q manual, anyway? Serious question. What real-world purpose do they serve?

M Greenaway

7th August 2002, 12:51 PM

Mike

Probably none.

But real process mapping is a useful tool.

gpainter

7th August 2002, 01:07 PM

Yes, all Manufacturing Processes will fall under 7 as was intended. All the others have key processes too. You used the word "key" 4.2.2 c does not call out "key"
Are several ways to describe the interaction, you have to decide. Another question is interaction, is that direct or indirect interaction. This is what I like about this forum, you get a lot of ideas. You can use 1 or combinations of them. It will also get you thinking outside the box.

Mike S.

7th August 2002, 01:19 PM

I'm not trying to be confrontational, maybe I'm being dense again. But who says you need a process map drawn out in flowchart or other format in order to understand and manage your process, or make improvements to it? I think I understand my processes well without taking the time to draw them out from start to finish in sequential order with inputs, outputs, interactions, etc. If it helps someone to see it all on paper, okay, but I don't think I need it to understand my processes, so to me it seems it would be a waste of time -- except if I need it to please the ISO auditor of course. So, I'd probably take the easiest route I could to make the auditor happy and then never look at them again. Of course, if I'm being stupid just tell me...

Randy Stewart

7th August 2002, 01:59 PM

Okay take a deep breath, relax and look at the intent. You don't have to put every detail of the interactions down, just what would make sense. Don't go through the exercise just to have something that states -- 1) receive order, 2) process order, 3) deliver -- what's the use of that? To know that Purchasing receives quantities and other customer expectations from sales may be useful, etc. Remember the 6 basic parts that define a process; 1) Has an owner, 2) Is defined, 3) Is documented, 4) Linkages are established, 5) Is monitored, 6) Has records maintained. If you can't pick those out from your flow or map you may have to get a little more detail. However, if those items can be identified you done a good job. I haven't seen an auditor that would not accept it. There may be more links than what is on paper, but we can always go beyond our flows and procedures without being hit. IMHO, this is the way to go. As many of you know from my posts, I HATE DOCUMENTING FOR THE SAKE OF DOCUMENTING. If it's not useful I don't do it. I have enough to do with my time.
:agree:

Randy Stewart

7th August 2002, 02:58 PM

I was still on the upper level stuff. Here's how I was looking at it. If you have (2) defined the process, then you have established the resources required, and, if you have (4) established linkages then you have determined where the inputs are coming from and where the outputs are going to. By no means was this meant to define the only parts or portions of a process. This is basic stuff. I agree with you that resources and "WELL" defined inputs and outputs are needed. To show our interrelationships between process I don't think you need to get that deep for your QM (IMHO). That's all.

M Greenaway

7th August 2002, 03:25 PM

Mike

In a corporation our size I believe process mapping is a very useful tool in identifying and understanding how processes that have evolved over a number of years, from various peoples tinkering from their own perspective, actaully operate. From this useful data we can then look at re-designing our processes so that they are more effective and efficient.

But true that in smaller companies it could be unnecessary.

Mike S.

7th August 2002, 03:27 PM

A person, at least a dense one like me, sure could get corn-fused about what really is required in actually documenting one's processes -- for the satisfaction of an auditor that is, as you can always ask your internal customer if the detail is enough or not.

Tarheel said "We broke our flow down into the major departments such as sales, purchasing, manufacturing depts, etc. Then I listed what some possible inputs and outputs would be. Our auditor said that was suffiecient to satisfy the standard."

If I understand gpainter correctly, (perhaps I do not) all one needs to do is transfer an exact copy of Figure 1 from section 0.2 of ISO 9001 to your QM to be in compliance with the minimum requirements of the standard, but I don't see how that would explain anything about "our" processes to anyone.

Other posts I've seen show process flows using fancy flowcharting/graphics programs that have tons of detail and great complexity.

So.... Do you need to show all processes, or just "top level" ones? What are "top level" processes? Do you show all possible inputs and outputs or just "some" or "major" ones?

Let's say your small company bakes cakes. You send out flyers and have a web site for marketing but also get some word-of-mouth advertising; take orders by phone, internet, or occasionally someone stops by your shop to order; you purchase cake mixes, eggs, oil, and icing based on orders; mix-up the batter; bake the cake; icing the cake - sometimes adding special decorations or writing; and finally deliver the cake.

I can see very complex flow diagrams with lots of arrows everywhere for this simple business process flow description, or I can see basically the text I've written doing the job. But, what is needed?

Sorry in advance for asking :)

M Greenaway

7th August 2002, 03:33 PM

I think......

The standard only requires the top level 'model' that you describe, such as that shown in the standard itself or the many derivatives posted to this forum. I believe this is only mandated for external audit purposes.

Proper process mapping is a specific tool that serves another purpose, which perhaps we dont want to be dragged into discussing here.

.....I think

Randy Stewart

7th August 2002, 03:41 PM

I'd NEVER do anything that ISO 9001 seems to say - or an auditor suggests - unless I was convinced that it's in the best interests of the organization in question.

On the other hand I guess that, once we have a decent process description, we might as well use that and not do something special for the 'quality manual'

My loudest approval on this Jim. I don't have a QM either and the only Quality Procedures we have is in the "Quality" Department (which is planned to be phased out over the next 3 years). It has taken a long time but with the help of our operations group we are starting to knock down the barriers between Quality and the Manufacturing or Business environments. IMHO the first step is in the nomenclature, we start the division there and it follows the whole system through. But we have had this discussion before.

I just want to add one more point here. If you come from a inspection background, how often did you see someone submit a part to be told if it is good? Not for to tell them they were wrong but more like - here's the part, tell me if it's good or not. Anyway, this use to get to me so when I go through audits I go in with the attitude that we have the greatest system in the world and it is up to the auditor to "PROVE" to me that I'm wrong. This goes beyond their individual opinions and such. Just like I have to show them evidence, they have to show me evidence.

The last 3 external audits I have done, this wasn't the case. In 2 instances the systems were good, but you could tell no one "believed" in them. It was like auditing with multiple guess records and procedures. If they passed or not isn't the point I'm trying to make. Don't set up a system just to fulfill the requirements. If people can't grasp it, it's going to fail. Human nature states that what I don't understand, I fear. And what I fear I destroy.

Mike S.

7th August 2002, 03:59 PM

M Greenaway said:

I think......

The standard only requires the top level 'model' that you describe, such as that shown in the standard itself or the many derivatives posted to this forum. I believe this is only mandated for external audit purposes.
______________________

Martin -- If so, that is one screwy requirement. As an outsider how would I know anything about your processes by looking at that generic "Figure 1"?

_______________________

Proper process mapping is a specific tool that serves another purpose, which perhaps we dont want to be dragged into discussing here.

.....I think
______________________

Nah, drag us into discussing it. I think I know what you'll say, but go ahead, I may be missing some points.

7th August 2002, 05:04 PM

I'd NEVER do anything that ISO 9001 seems to say - or an auditor suggests - unless I was convinced that it's in the best interests of the organization in question.

This really scares me. I think this is about the fourth time in as many days that I agreed with Jim. Either he is coming around, or I am coming around, or we are just both communicating better. :eek:

My personal recommendation is you take Jim’s quote and post it on the top of every monitor in the place. It is YOUR system and it needs to work for YOU, not the registrar!

I have been beat up quite badly on occasion when I say that process mapping is not required. The standard requires you to know and understand your processes. You must identify them and describe their interaction. Process mapping is one good way to do that. I have seen companies that have approached this like filling out an FMEA. “Just put something down for the auditor.” This does nothing for the organization and for the auditor.

gpainter

7th August 2002, 05:54 PM

Many different ways to handle including: transfer of figure 1,using a process wheel, using the cross reference in the appendex of the 00 standard, if you have a reference section to each procedure that would also show it(as you reference other related procedures), flow diagrams,etc. Would like to here from a registered company on how they took care of it???

Mike S.

8th August 2002, 09:57 AM

I thought 9000:1994 had some vague/open to interpretation sections in it - and I still do -- but compared to 2000 it seems positively clear. Some of that may be familiarity, some of it may just be the way my brain is wired, but I'm convinced that part of it is that 2000 really does has more ambiguity in it than 1994. Then again, maybe I'm just nuts!

Randy Stewart

13th August 2002, 02:15 PM

Mike if there is anything to be clear on is this:
It is YOUR system and it needs to work for YOU, not the registrar!
If you are getting registered just to register, don't waste your money. The standard is a guideline only, yes there are a few things it says you must do, but it doesn't tell you how. That is up to you. Going back to the small business that bakes cakes - the standard may tell you that the cake needs to be packaged and the ingredients need to be approved (so you don't give anyone a type of disease) but it won't tell you the amount to use. That's yours to figure out.

Mike S.

13th August 2002, 05:27 PM

Stew,

I agree with what you said. But, my point is several intelligent folks here apparently cannot agree on what the "average" ISO auditor (if there is such a thing) will require to give you the certificate or what the true intent of the standard is in this area.

Let's say my cake baking biz from the previous page works great without needing to formally document the sequence and interaction of the processes in a flowchart, diagram, text doc or anything else. It is a 3-4 person Mom and Pop shop. They don't need this documentation to run their biz but let's say they DO need the ISO cert in order to keep their top customer, who just made ISO certification mandatory regardless of previously demonstrated excellent performance by the bakery. This does happen in the real world, unfortunately.

So this cake shop owner just wants to do the minimum required in this instance, regarding this requirement, to get the cert as this doc. will probably never get looked-at again. So, what is the minimum required to meet the standard? Just re-print Figure 1 from section 0.2 of 9001? Or make a complex diagram showing all processes and all possible combinations and permutations of interactions? I don't know if we can get a consensus on that.

I guess in the real-world you gotta go by trial-and-error with your registrar.

Randy Stewart

14th August 2002, 02:26 PM

Mike I understand what you're getting at. I'll say it again, if the registrar doesn't like it, challenge it. They're human (I know sometimes it is hard to tell), they make mistakes too. Make them prove you are not in compliance, question the decision. Going back to your example again: I know mom & pop never go on vacation without shutting down, but if they were going to pass the business on to someone so they can retire, I bet the recipes are written down somewhere. And that by showing the order in which the ingredients were added (without quantities) and showing that I mixed the batter before I put it in the oven, I would have a flow that would pass an audit. It would probably take me an afternoon to have my stuff ready for the auditor, and that is from scratch!
Don't make it more difficult than it really is.

They don't need this documentation to run their biz but let's say they DO need the ISO cert in order to keep their top customer, who just made ISO certification mandatory regardless of previously demonstrated excellent performance by the bakery.

Real world top customers also de-source you no matter what certification you hold. And they will keep you even if you don't hold a cert.

:eek: :eek:

Mike S.

14th August 2002, 02:39 PM

Stew,

You could be my auditor any day. :)

Are you saying that work instructions that specify the sequence of operations could serve to satisfy 4.1 (a) and (b) provided there were WI's for each "major process"??? So if Mom and Pop's bakery baked cakes on one line and pies on another, and had a WI for each, they'd be covered?

Randy Stewart

14th August 2002, 03:42 PM

Basically, yes. How much deeper would you have to go??? We're not talking brain surgery. There may be some type of documentation required like a "born on date" but I think you're getting the intent. Step back and look at your business system, there is a logical flow to how things should be. ISO isn't asking you to do more than put it on paper so it can be verified. If you don't have anything documented it is abitrary. ISO, QS, TS standards do not prohibit the use of reason! I said reason not common sense - but that's another thread.
You don't have to have the big dog & pony show to get certified, if the company has been in business (especially mom & pops) for any time at all, they probably have about 95% of the things needed for certification. As you develop the system and document it remember to keep it simple. Float the evidence to the surface so it is easy to see, don't bury it under a bunch of bells and whistles. One thing I would suggest, get another set of eyes to look at what you've done. It doesn't have to be a consultant but should be someone with some experience. See if they can tell where you are going with your system. If it is a small shop sometimes you get to close and can't see the forest for the trees. Believe me, it's not that difficult.
:bonk:

kspurling

14th August 2002, 05:50 PM

I like the active link idea. A nice change to the restated standard manuals

Mike S.

14th August 2002, 06:11 PM

Stew got me to thinking...out loud here...

In the cross-reference table of 9001-2000, section 4.1 of 9001-2000 is equated to section 4.2.1 of 9001-1994 and that section applies to including or referencing your quality system procedures in the quality manual and outlining the structure of your documentation (the old doc. pyramid most people used). So, if you are currently 9001-1994 certified or compliant, and have good documentation of your processes via 2nd and 3rd tier docs (procedures, work instructions, SOP's, etc.), and this WORKS for your company (you produce good product and make customers happy), why can that not be considered a "proper and complete process description", Jim? Do I give my company more value by drawing that stuff out in a Visio flow diagram? Have I violated the word or intent of the standard? I'm not sure I have.

Mike S.

15th August 2002, 10:33 AM

I don’t mean to be argumentative, but I’m really trying to understand this part of the “standard” better and also understand why Jim is so against “procedures” as “process descriptions”.

Jim said: “One clue that I may be right is that ISO 9000 defines a procedure and a process as being two different things.”

Well, yeah, but I’m sure they define a “flow DIAGRAM” (diagram is your word) and a “process” as being two different things, but the former can be used to describe the latter (and many very detailed and fine examples have been posted in the Cove) just as a procedure (maybe?) can be used to describe a process. So, I guess I missed your point on this one.

Jim said: “It includes this diagram, which reminds us that a process description includes key factors not normally associated with documented procedures: inputs, outputs, resource requirements and performance measures”

Maybe I’m weird (go ahead, I left myself open on that one) but many of MY documented procedures (what I call Tier 2 and 3 docs under 9001-1994) do contain these factors, I think, but may not contain every spatula or measuring cup. For example, in greatly abbreviated fashion, back to the bakery example: “ Preheat the Maytag oven to 375 degrees. Mix the oil, eggs, and Pillsbury cake mix as per the instructions on the box using the Waring blender. Pour the cake mix into the 13” x 15” Chef’s Choice pan, making sure it is ¾ to 7/8 of the way full, Verify the oven is fully preheated; put the cake in the oven; set the timer for 35 minutes. After the timer goes off, put a toothpick in the center of the cake and pull it out – if it is dry remove the cake from the oven, if not dry bake for 3 more minutes and repeat. After the cake cools, remove and taste a small piece from the underside to verify moistness and flavor.” Didn’t this “work instruction” or “procedure” cover all the factors you mention?

Some folks, if I understood them correctly, feel reprinting a generic diagram like Figure 1 from section 0.2 in your QM serves the needs of 4.1 a and b when that doesn’t tell me a darn thing compared to a “procedure”, but it is a “diagram”. Stew says keep it simple, which fits me to a “T” in more ways than one, and use procedures. Some people do really fancy and exquisitely detailed Visio “diagrams”. Maybe they are ALL right as long as it: 1) Meets the company’s needs and allows them to make customers happy and 2) Meets the requirements of 9001-2000. ????

Help me here ya’ll, if there is any helping me. Any opinions welcome. And, I promise not to change the rules every time someone gives an answer!!!! ;)

Randy Stewart

15th August 2002, 04:23 PM

the fact that a company has been in business a while bears no relation at all to their ability to document their processes

I was referring to mom and pop shops being able to define how things worked.

significant distinction between a process description and a documented procedure

I may be throwing a wrench into the mix but your above quote is correct. However, it is not necessarily what 4.1 a & b is calling for (IMHO). Identify needed processes, identify their applicability to your organization and determine the interaction throughout. Personally I perfer process flow charts when I audit. It gives me a better feel for what is happening rather than reading a procedures. I won't say that I "require" one over the other.

The PDCA diagram gives us a process flow and shows interaction. I think we all will agree to applicability. Can you take it farther, sure. 4.1 a & b doesn't call for a process flow, nor does it call for a procedure. It calls out for them to be "documented".

I won't tell you that you are wrong Jim. But what you seem to be saying, if I understand you, is that only by deep documentation will you be able to satisfy this requirement. I just can't see it that way using the bakery example we have been using.

I have some very "deep" flow charts and process descriptions for some of our processes (digital scanning dies, cut package development for the NC Mills, etc.) but the operations that require training or acquired skills, have little. I'm not going to make a die designer to have a procedure that covers die design in detail. I'm paying him for his skill level and if he needs that in depth process description then he is in the wrong business or I'm paying him way too much.

That's my spin on it. I understand that we need to have defined processes, and that they have to make sense to our auditor/registrar in order for them to understand the system.

Mike S.

16th August 2002, 10:43 AM

Jim,

I know you like a challenge and you left yourself open to one. Let's test your ability to satisfy 4.1 a and b in clear, simple, "complete and extremely useful" AND ISO compliant format. (Sounds like another thread.....). The business is the hypothetical bakery we've discussed, the product lines are cakes on line 1 and pies on line 2 but you only need to do cakes.

You said you think you could describe all the processes of most businesses on just 1 page, so this Mom and Pop shop should be duck soup. I can't wait to see it. Maybe you will help hundreds of folks here. So, do you accept the challenge?

Mike S.

16th August 2002, 12:04 PM

Jim,

Sure, I'll play -- after all I issued the challenge.

From a previous post, here is how Mom and I run our business:

Let's say your small company bakes cakes. You send out flyers and have a web site for marketing but also get some word-of-mouth advertising; take orders by phone, internet, or occasionally someone stops by your shop to order; you purchase cake mixes, eggs, oil, and icing based on orders; mix-up the batter; bake the cake; icing the cake - sometimes adding special decorations or writing; and finally deliver the cake.

I guess I should add I either get paid on the spot or for big customers issue an invoice at delivery and give them net 15 terms.

Does that give you all the needed info?

P.S. -- Don't just facillitate here -- do the work! Consultants...jeesh.
:vfunny:

Mike S.

16th August 2002, 01:25 PM

I forgot -- I also test the cake during baking (toothpick test) and after cooling (taste-moistness test). Also, payment comes only after delivery. And, sometimes I order supplies after reciept of order ifI don't have any of that flavor mix in stock. Otherwise, your list is okay.

#1 is okay.

#2 is okay -- I have a spec. sheet that tells me how many cake mixes to use based on cake size

#3 -- how detailed do you want the resources to be -- every spatula, toothpick, and spoon I might use? Otherwise, a Waring blender, Maytag oven, timer, Super-Baker cake pans for the "bake cakes" step and, for "take orders" , well, I get them thru the internet (computer), phone calls (phone), and customer visits to my shop and I log them on a customer order sheet.

Enough info?

Mike S.

16th August 2002, 06:09 PM

Jeez -- you make a guy do lots of work! Running out of time but here is a quick addition. Your suppositions above are okay. If you have any other questions just make an assumption and go for it.

BTW -- Since Mom does some designs based on customer requests ("make me a clown-face cake") does this affect your diagram?

M Greenaway

17th August 2002, 06:12 PM

This is a great discussion.

Can I chip in please......

Jim, it appears you are taking Mike through a 'business modelling' lesson, which is all fine and dandy, and is what many of us are doing to satisfy this ISO9001 requirement.

But can I hark back to comments/questions posted a little while back, and re-itterated by Mike in that 'what purpose does this serve our business ?'

It appears again that perhaps we are merely going through a documentation exercise (the curse of ISO9001), and debating the format of this documentation.

Mike is quite correct in saying that a process can adequately be defined in written text, and many of us may well have what we traditionally called 'procedures' which actually adequately defined processes. To define them in your Quality Manual could well be, as suggested, a throw back to the 1994 requirement to contain in your Quality Manual all your operating procedures, or reference to them.

What is really key here is that the processes are adequately defined - not necessarily documented (ignoring ISO9001 for a second), i.e. what is actually fundemental is that those who work within the process, or interface with it know how the process is defined - and they may know this through training and/or experience. And if the guys who implement any new or changed process are the owners of the business, and the same guys who work inthe process (as in the case of Mom and Pops cake shop) then where is the benefit to the business.

Another thing I am in two minds on ..........

M Greenaway

18th August 2002, 11:56 AM

Jim

On the debate over the format of our process definitions I would agree that a diagramatic model has many advantages over written text in clearly identifying processes, their sequences and interactions. The standard doesnt mandate a format for our process definitions, hence anyone offering written text for this would be compliant with ISO9001. I would agree that a better way is to create such a model as that you are generating with Mike.

But lets ask ourselves again why we need such a model on such a broad high level ?

Will we find we are operating large chunks of business processes that we were unaware of, such as design ? I dont think so.

Will we find inefficiencies in our business ? On such a high level model I dont think so either, detailed process mapping may achieve this.

So regardless of the format what is the purpose of this requirement ?

M Greenaway

18th August 2002, 12:43 PM

Jim

I would have thought that most companies appoint departmental managers for departments which naturally tend to evolve around business processes. Maybe they would not know all the business processes, but I am sure they would know the ones they interact with - after all why would they need to know.

The guy who might like to know is the fella at the very top. Now if he doesnt already know until ISO9001 comes along and forces him to think about it then something is terribly wrong is it not ?

Mike S.

19th August 2002, 10:11 AM

In the attached file I added a few measures but otherwise it is pretty much how Mom and Pop run things. But, as I said, it doesn't show the design step Mom does on occasion when she gets a request she has not had before. If she has done a "clown face" before she would reference the old design info. from her records, but if it is a first-time request she needs to design it.

I'm glad Martin has chimed-in as I was hoping this would not just be the "Jim and Mike Show". He has asked some good questions. I think there must be many folks out there who have their own thoughts, suggestions, "better ideas", comments, etc. relating to this section of ISO. I think each organization should consider how much this step might (or might not) help them when deciding whether to spend lots of time on it or gloss over it with the fastest/easiest thing that will meet the requirement. Debate such as this should help their decision.

Generally Cove members aren't bashful with their thoughts, so...anyone else have any commnets?

Randy Stewart

30th August 2002, 12:00 PM

I'm back.

Mike it does address the new design. In the "take order" step you are addressing "Contract Review" and establishing Customer Requirements. In the design cake step you are putting the finishing touches on the design (drawing the clown face). Now Mom may go through some practice (Design Review), and may reference pictures from a magazine but these can all be part of a drill down in your process flow.

This is what I meant when I said don't go too far. It's not really a business model, it just shows how the processes interrelate.

I enjoyed getting back into the threads. I have 10 audits coming up between this now and the end of November. I'm gonna be busy.

Steve MacDonald

7th October 2002, 02:01 PM

Greetings;

We rolled our own. Small company. The system manaual is the quality manaul. Put the Policy in 5.3, objectives in 5.4.1 and tossed in the other stuff up front with an index, scope, exclusions, process sequences, etc.

Every department has a manual and every manual is the whole package. (The tree-huggers love me)

Steve

energy

14th October 2002, 11:47 AM

Doing charts in Word is like driving a farm tractor without power steering as opposed to a Lexus:eek: As a "Q" person, not enough study has gone into acceptance criteria and actions to correct deficiencies.:vfunny: While it is a Top Level Chart, the existance of a CA/PA System is impressive for a Mom & Pop Shop! Give them their certificate! :ko: :smokin:

M.,

This does nothing to enhance a Mom & Pop Shop. They are operating at maximum efficiency, or they would be out of business quick. Too much competition from Pop and Mom Shops and the big Pastry chains. This is all about getting the Certificate because more people will so impressed with that ISO Stamp on your marketing materials and on their register receipts that they will come in to buy and come back. Yea, right!:bonk:

M Greenaway

22nd November 2002, 09:38 AM

Energy

Although the mom and pop analogy does serve a purpose, and has certain merits I dont think most of us aspire to being a mom and pop cake shop - know what I mean ?

Marc

25th December 2002, 03:34 PM

One of the things I have noticed in recent posts is that there is a significant difference between posters based upon aspects such as company size and direction for the future. Many Mom & Pop operations are not out to conquor the world and become Micro$ofts. Many (most?) don't need complicated diagrams and business models. Most are already doing Corrective Actions and management review is a couple of people (sometimes family) who meet almost every day anyway. ISO pushes them into formal 'management reviews' and does nothing for the company. In many, many large companies management review is typically a sham to begin with.

I go along with what Randy and Mike are saying.

As far as the design review: The design review is unique and in the case of the Mom baker, it is probably in her head. I doubt she needs a documented procedure on what she goes through when someone calls and asks her to make something she has never made before. On the other hand, it's doubtful any of her customers give a flying pig whether they are ISO registered or not.

Jim, in your posts you are big business oriented with a level of 'pro ISO' which approaches religious blindness fervor. I was especially disappointed in the recent post regarding 'The Process Approach' as if it is something new and different. It isn't new - it is no more than a buzzword. Businesses have been using it for years. The positives you note I agree with. What I fail to find is a lack of 'The Process Approach' in almost all businesses. They may not have the diagrams you like and have come to expect, but that doesn't matter. In an earlier post you say:

The departmental view of the business is often quite different from the process view. The process view has to be IMO a team affair...

The only difference is to realize there can be many 'views' of a company. A departmental view (departmental team) is just that - a localized view. That does not discount what usually already exists which is the interaction of each department with regard to inputs and outputs at a higher level (higher level teams). You discount the fact that many times a process view is a local view and that another, higher level process view may (and typically does) tie everything together. There can be many process views at many levels. Your paradigm simply doesn't allow for this and appears to assume that if one defines a process at a lower level and it does not encompass the whole company it is not sufficient.

Thinking about - and managing - the business in process terms is relatively rare. Lots of great managers don't do it yet.

The sad thing is that ISO 9000, while posturing as being based on management principles which include Process approach, is applied in such a way that we can get a 9001 certificate without adoping the behaviors(**) that the principle implies. This is criminal!

Poppycock. I think this is overly simplistic, if not outright a totally a false premise not based upon fact. I do not believe managing from a 'process approach' is as rare as you apparently do. I remember a great Mac program named Stella from 1986 (It was a business simulator), which unfortunately is no longer, but there are a number of them out there now. In the 1980's I used process simulators which show interactions of processes at whatever level I wish to input. Heck, you should see the historical documents showing the use of the 'process approach' used by the US military in the Berlin airlift so many years ago, including how the 'process approach' allowed them to adjust for disruptions. It evolved by reacting to a 'corrective action' system whose outputs caused requisite systems changes and the airlift ended with an extremely fine tuned and efficient (given the circumstances and the amount of cargo which had to be moved) system.

For that matter, even we as individuals use a process approach in our every day lives if you think about it. Everything we do is, to some degree, a process. But I believe here you will depart on the basis of a definition of what a process approach is. I saw this in threads where you thoroughly defended a difference between a flow chart and a process diagram (if I remember correctly) based in part upon content (such as level of detail). Heck - they're both flow diagrams. Like with text procedures, there is no 'correct' content' or layout. Whatever works is fine for an individual or a company. One company has more detail than another but the one with less detail privides the details elsewhere or is significantly less complex. Too often strict definitions blurr what is important. Call it a flow diagram. Call it a process diagram. Call it whatever you like. If it represents what you are attempting to represent and has the appropriate detail for its function, whether within or without, you can call it a Strawberry Shortcake.

Sometimes I think there is an over emphasis on 'scholarly' thought - like over categorizing and over defining. Most consultants tend to do this but then most consultants are like preachers with a religious like fervor and an agenda. You tend to rigidity. I suggest flexibility. Where others attach documents in thread posts here, you put in a redirection to your site 'bin.co.uk' - your consultancy site (which I really do not particularly appreciate, by the way - you can share here as an attachment as others do with things like Mompop.doc) - for the 'hits' I suspect. Your rigidity would scare me off, but it probably sounds good to management of monolithic companies or companies in trouble.

Steve: Congrats on your manual. All that matters is that you can explain it and that your registrar approves it. Keep It Simple.

26th December 2002, 11:05 AM

If a process and a procedure are the same thing, how come ISO 9000 says they are not?

The way I handle this is the process is the activity that uses resources to tranform inputs into outputs. The procedure is the method used to perform the process. We can map the process, but we flowchart the procedure. That is why I usually have the flowchart in center of the process map.

Do we really believe that ISO 9000’s abandonment of an emphasis on procedures in favor of an emphasis on processes is merely playing with p-words, or is there – just possibly – a more significant meaning?

Looking at my previous definitions, we find that we should consider both the process and the procedure. Both the activity and the method must be understood.

...what would we learn if we found that different ‘top managers’ in the organization identified different processes in these categories?

This would be disturbing. I would think the difference would be in the procedure (method) as opposed to the process (activity). It is important for "top management" to have a unified vision of the processes. It is less important for them tho have a unified vision of the procedure.

. So is it not true that procedures are a [relatively] small part of a complete process description?

I would say the procedure is a large part of the process, but not necessarily a large part of the process description. If we look at procedures, based on my description, then all but 1 & 2 of your 16 requirements can be applied to the procedure, which is a sub-set of the process.

Process thinking takes us much deeper into our operations than procedures. I think that is why the shift in emphasis. Why emphasize only part of a process, when it is far more advantageous to truly understand the entire process.

Before we can undertake process thinking, we must first learn to think.

26th December 2002, 01:57 PM

First of all, let me say that I have no authority to say this. It just seems to make sense to me how the process and the procedure fit together. The process is the overall activity and the procedure is the method you use to enact the activity. You have process inputs and outputs, and you have procedure inputs and outputs (but they do not have to be the same)

I am attaching a simple process map to illustrate the differences. You will notice the procedure is flow-charted and the flow-chart is placed in the center of the process. It is not the process, but the means by which the process is accomplished. The process is not the procedure, but the reason for which the procedure exists.

Hope that helps.

Douglas E. Purdy

26th December 2002, 02:52 PM

db,

I did not get to see your attachment, for some reason (not given by Explorer) it would not open for me, but I have been contemplating just the opposite. I have drafted a Controls for Procurement (System Procedure) and plan to incorporate flows for Control of Purchase Orders, Control of Amendments, Customer Returns, and Rework & Repair Orders.

26th December 2002, 02:57 PM

Douglas,

I will try again. This time as a *.gif file. I'm not sure we are thinking differently. Your controls would be procedures, the activity (Procurement) would be the process.

Craig H.

26th December 2002, 04:03 PM

How about this angle:

You can have a process producing nonconforming output because the procedure was not followed.

In other words, a procedure tries to describe a process, to my understanding.

As with any type of model, a procedure is an incomplete view, and, depending on the user, may have a material impact on how effectively the process operates.

Douglas E. Purdy

26th December 2002, 04:05 PM

db,

Thanks, I got the gif okay. And yes I do use the procedure to control the process or processes.

26th December 2002, 04:06 PM

You are absolutely right Craig. If the procedure isn't followed, the process cannot work. Also, the inverse is true. If you follow the procedure to the "t", but the process has corrupt inputs, the output of the process will still be nonconforming product.

As with any type of model, a procedure is an incomplete view, and, depending on the user, may have a material impact on how effectively the process operates.

I like that, I might just quote you on that.....in fact, I just did! :smokin:

26th December 2002, 05:12 PM

Jim, I think you stole that stuff from me! :rolleyes: I've been saying much the same thing for years. A SIPOC is another method of describing the overall process. As far as your comment that procedures and work instructions sound like the same (in ISOspeak), I've seen them used interchangeably. My quick way to differentiate them is to look at procedures as multiple tasks performed by multiple people, and a work instruction is typically a single task performed by a single person. Procedures are process oriented and work instructions are task oriented.

A couple of other things, my ppt does not reflect the interaction too well, but it is a start.

Craig H.

26th December 2002, 05:33 PM

Jim Wade said:

Craig

You say "you can have a process producing nonconforming output because the procedure was not followed. In other words, a procedure tries to describe a process".

That’s true. But I’d extend what you say. You can get nonconforming output for other reasons (because the right resources are not available, or the process is measured incorrectly, or the procedure is followed but is flaky, and so on). So maybe those other factors also form part of a complete process description.

Jim, absolutely.

Dave, for what its worth, we have the full-blown, often 10 - 15 page procedures we call "procedures", and then the 1-page procedures describing the high points of the same process as "work instructions". Other than for training, the 1-page work instructions are what gets used on a daily basis, primarily because they are posted on the wall/control panel. Just semantics, I guess.

M Greenaway

28th December 2002, 04:36 PM

My current thinking is that there is no difference between the relationship Process>Procedure>Work Instruction and Process>Sub-Process>Sub-Sub-Process.

We all appreciate that everything we do is a process, and that all processes fall naturally into a hierachy where there may be parent processes, and where there may be child processes (or sub-processes).

The definition of procedure given by ISO9001, and the guidance document on processes given by TC176, to my mind show that a procedure is effectively the collection of sub-processes that make up a particular process.

Craig H.

30th December 2002, 09:19 AM

M Greenaway said:

My current thinking is that there is no difference between the relationship Process>Procedure>Work Instruction and Process>Sub-Process>Sub-Sub-Process.

We all appreciate that everything we do is a process, and that all processes fall naturally into a hierachy where there may be parent processes, and where there may be child processes (or sub-processes).

Martin:

I agree. Where the real trick, or art, lies is in deciding how to break up and compose the documentation so that there is enough information to effectively do the task, while there is not so much information that the document is difficult to use.

This is a real art, and reqiures that the audience and the use environment be thought of early and often in the process.

We call the division of tasks by different names because of differences in culture, education, and training. I agree that it really is just a matter of semantics.

Craig H.

30th December 2002, 10:24 AM

Oops, Jim, I'm afraid that maybe I have been less than clear. My "semantics" reference was to Martin's statement "...there is no difference between the relationship Process>Procedure>Work Instruction and Process>Sub-Process>Sub-Sub-Process."

To me, the procedure describes the process - they are related, but are not the same.

I am very flexible, though, when dealing with this type of discussion. Fact is, the Quality profession has so many people who started outside of quality that it's surprising that we don't have more confusion over the exact meaning of the words we use. Between engineers, management people, accountants, etc., not to mention the different nationalities involved, there are lots of chances for subtle differences of the meanings of words to exist among us. When there is confusion, we must try to figure out what each other is really trying to say.

Even here on the Cove, there have been some heated discussions that I have suspected were really based on confusion and misunderstanding of the words used by the parties involved. Agree?

30th December 2002, 11:08 AM

Even here on the Cove, there have been some heated discussions that I have suspected were really based on confusion and misunderstanding of the words used by the parties involved. Agree?

Craig, the way I approach this is that I must remember that most people here at the Cove is not as smart as me is. :biglaugh:

Craig H.

30th December 2002, 12:39 PM

Jim Wade said:

As I think you and I agreed a few posts back, a procedure is part of the description of a process. It is, of course, an optional part.

Other, non-optional, parts of a process description include its interactions, the criteria to ensure its control, the methods of its measurement and monitoring, information on its characteristics and trends, and so on.

Yes, Jim. You have reminded me that when I came to work here ~11 years ago, there were almost no written procedures, but there sure were processes.

Face to face interaction would help us greatly, although there have been some discussions that might have required the constables! Even between those of us in the USA and our friends the British, we can have misunderstandings about the language. How do you (mis)spell organization again??

:vfunny:

M Greenaway

31st December 2002, 06:01 AM

Jim

I assume you mean 'documented' procedures in your previous post ?

Procedures exist for everything, whether we document them or not is another matter.

Greg Mack

15th January 2003, 07:22 AM

Greg Mack

15th January 2003, 06:47 PM

Sure Jim,

I'd be happy to share my thoughts and actions. Can you help me out by pointing me to one of these threads?

Bob_M

18th July 2003, 05:59 PM

Hi Marc and everyone,

Been a while since I was here last! :bigwave:

Anyway, I use to try and re-write the Standard as our 'Quality Manual' but there is something that stands in the way of that - Copyright!

As it is now, my 'Quality Manual' is 4 pages long. It forms a part of my Procedures Manual and has
1) Table of Contents (Lists all procedures)
2) Control Information
3) System Flow Diagram
4) Business System information Scope/Exclusions/General

That's it - short and sweet.

I will take some time to look at all the other comments here over the next few days.

Cheers!

I haven't read this whole tread and probably won't but...

I'm about 90% done with our manual now and its mostly a cut and past of the iso standard. Is this really a problem?

At least if our auditor has a problem with it (during pre-assessment) I'll have 3 months to write a few paragraphs and leave in our:
Process Outline Map
Organization Chart
Procedure List and Cross-Reference
Scope, Policy, Objectives and the other bare essentials.

Actually based on auditors feedback this may be a future improvement project for the manual. *shrug* We'll have to wait and see for now...

Trolle

22nd July 2003, 11:21 AM

This great emphasis on a quality manual is down right silly. Who are these consultants and auditors who want to tell you where and how to define your systems?

For what it is worth Id like to see a company specific QM as an opportunity to define borders, to clarify and enhance whatever specifics that rule “your” business setting. This is your opportunity to define the Scwerpunkt of the QMS and the following “tiers” to the registrars. Yes sure this is only a theory, for now. But in a not to distant future Ill be the one who has to explain this to the registrar, AND I did not even write the one that I will have to defend!

Cheers!

Groo3

22nd August 2003, 04:45 PM

Claes Gefvenberg

27th August 2003, 08:57 AM

Good on you Groo,

As long as the layout fits you and you do it for your own sake... ...all is well. It's your manual, after all.

/Claes

Wes Bucey

23rd October 2003, 10:17 PM

We decided to use the standard as a guide / starting point when writing our manual. In this, we hoped to be able to systematically address all of the necessary standard requirements. We could have gone to a 4 page manual if we wanted, but we decided to incorporate a lot of details in the manual and clarify how our systems are set up... We probably could have incorporated all these details into our System Procedures and just had the QM reference those documents, but this method makes sense for us at this time. We also used several process overview flowcharts and an org-chart in our QM, the end result is about a 48 page QM, but it covers a lot of ground. Then again, our old QM used to be a lot larger than our current 48 pages...

Also, regardless of the preference of the auditors, I think each organization needs to do what makes sense for their organization. For us, this means having a 48 page QM which is structured along the lines of the standard.
I voted that my organization's QM follows the numbering of ISO9k2k.
I'm a plain language guy and I like LOTS of white space, with big headlines, so mine appears to have a lot of pages. I also had to incorporate the FAA "Fabrication Inspection System" in a seamless manner to placate the regulatory gods (devils?) This necessitated a redundant recap of some of the ISO9k2k sections because the FAA guy "with the ink" [to approve or deny our status as Certified Parts Approval Holder] wanted it "just like his chart."

I added an appendix which gave a capsule summary of each Procedure included in our QMS plus a glossary (an adjunct to Section 3 Definitions) which explained our usage of terms in our industry.

Here's our phrasing for Section 3.1:
3.1 Industry definitions and acronyms

Every industry uses terms (including acronyms) which have a particular meaning within the industry. We try to clarify the meaning of such terms by including a definition or a spelled out title of an acronym with its first usage in our manual. We have included these terms in our Glossary and Index for handy reference. By using the index, the reader can see how the term is used in context.

Our objective is to use simple technically accurate terms, and to the greatest extent possible, rely on common dictionary definitions. As with most technical subjects, some terms have a very specific meaning different from their commonly used dictionary definitions. In this case, the appropriate technical definition is provided in our Glossary.

We use the manual as part of our orientation of new hires. I am proud to say everyone in our organization has a copy and can answer any newbie or auditor's query about it and define any term in the glossary and describe where he fits in a Procedure which pertains to him or his job. Only the text and the glossary are a Controlled Document. The Appendix describing the Procedures is merely a "convenience" report - only the Procedures, themselves, are Controlled. I also included a copy of the FAA guy's "chart" in the Appendix as a "convenient" non-controlled exhibit. [he LOVED it!]

Greg B

9th December 2003, 07:31 PM

We use the manual as part of our orientation of new hires. I am proud to say everyone in our organization has a copy and can answer any newbie or auditor's query about it and define any term in the glossary and describe where he fits in a Procedure which pertains to him or his job.
Wes,

How do you test the knowledge and understanding of your organsiation in relation to the manual? We too give every one an induction into QA, including the manual (if we can keep them awake) but I could not guarantee that everyone could answer every 'Newbie's or Auditor's' query.
Why does everyone need a copy of the manual? Are these ALL controlled? We spend more time training our people on their Procedures and Work Instructions than the manual. IMHO our manual is nothing more than an auditors reference sheet. Our procedures are our bread and butter.
Sorry, I am not having a go at you or your company I just don't think that there (IMO) is a real need for quality manuals but I put up with them. I'm a less is more type of guy.

Greg B

Rob Nix

10th December 2003, 08:25 AM

Greg & Wes,

What we have for orientation is a five page summary of our QMS with a quiz at the end to test their comprehension, which is turned in to me within 10 days of hire.

We have only ONE hard copy Quality Policy Manual - and I keep that. The manual and all other documents (procedures, work instructions, forms) are available on a corporate intranet site available to everyone. If they print them out, it's their responsibility to make sure they're current.

Greg B

10th December 2003, 06:37 PM

dbzman

7th July 2004, 03:32 PM

7th July 2004, 03:38 PM

Everytime I try to simplify our manual the auditor or our coporate headquaters says that's wrong.

Why?

A large part of this might come from a misreading of ISO 10013 (I think that is the standard -- I don't have a copy in my immediate possession). If my memory serves me correctly it discussed things like company history, your "means of communication", etc.

You are correct in what 9K2K requires. Some auditors freak if you provide just what the standard requires.

SSwanson

11th July 2004, 10:59 AM

Edited by SSwanson

Laura M

11th July 2004, 01:15 PM

Because a "simple statement in the manual" is not enough.

By restating the requirement in your manual, everyone in the organization knows the requirement, and not just the QM who has a copy of the standard. It is the easiest way to ensure that all ISO requirements are indeed documented in your system. Otherwise, it is certain that you will not adequately document some requirement and that may result in some future error.

Why fight a losing battle? Just do it.

I have to respectfully disagree. While they meet the standard, I cringe at manuals that restate the standard. To me this emphasizes that a company requirements is in place "only to meet ISO" not because the company management has made an operating decision. You need to cover the requirements either IN the manual or reference to procedures. Restating the standard creates an unnecessarily lengthy manual....making employees less likely to read.

My last quality manual to ISO9001 was 5 pages long. A summary of how management establishes and reviews the quality system, explanations of how customer satisfaction is determined and is the focus, followed by a flow chart of the quality system referencing the various procedures. This makes sure the company "processes" are determined, that in the end meet the ISO standard. I was told by the registrar that this was "The best interpretation of the intent of ISO9001:2000 that he had seen." Another manual that I inherited at another company, which primarily restates the standard, then references procedures applicable to the section of the standard was recently audited and the auditor stated "You know, this works and meets the standard, but you can certainly make it shorter. Go back to the standard and look at the minimum requirements of a QM - since the procedures cover the detail, you may want to make the manual more user friendly."

I guess it comes down to personal preference of the company, but to say "just do it" doesn't work for me. The new standard gives companies the flexibility to write a quality manual in 'their language' and to be used by more than the auditor during the audit. I would take advantage of that flexibility and make you manual unique.

Laura

SSwanson

11th July 2004, 02:25 PM

Edited by SSwanson

Claes Gefvenberg

11th July 2004, 03:09 PM

:lmao: I guess someone should read ISO 10013. That norm is still valid I assume.There is ISO/TR 10013:2001 (http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26978&ICS1=3&ICS2=120&ICS3=10), of course: Guidelines...

I have to side with Laura here. The manual she describes should be quite adequate. Besides, the manual we had when I came here did in fact restate the standard to a large degree... It was also utterly useless. Nobody ever used it or asked for it with the sole exception of our registrar. They had to look at it, and they sighed every time they did so.

/Claes

SSwanson

11th July 2004, 03:52 PM

Edited by SSwanson

Laura M

11th July 2004, 10:27 PM

I know that manuals are useless. But they are a requirement. And they have a worth, or they wouldn't be required.I

Are they useless, or do they have a worth???? Using Microsoft Word, a synonym for "useless" was "worthless." :confused:

I think they are useless when they restate the standard. I think they have worth when they state the company quality policy, philosophy and procedures used to implement the above.

f I recieved a five page manual, I suppose I would have to request the remainder of the QMS documentation to determine if there really is a QMS documented. That means, the quality manual is indeed useless because the customer chose to document his system in lower level documents rather than the manual.

Are you an auditor? Then yes, you should require the procedures to adequately perform a documentation audit. The lower level procedures are easier to diseminate to appropriate departments. I suppose the procedures could be 'chapters' of a 'quality manual', or there can be separate documents. Either way, I will stand behind the fact that restating the standard in the manual is not value added. Would it surprise you to know that I wrote a 1 page QM that met the standard, passed an audit, and with the accompaning procedures was also deemed a valid QMS?

L

SSwanson

12th July 2004, 02:56 AM

Edited by SSwanson

SSwanson

12th July 2004, 08:31 AM

Edited by SSwanson

Marc

12th July 2004, 12:52 PM

The responses are getting a bit personal and emotional. Please - let's cool down.

Thanks!

Laura M

12th July 2004, 01:08 PM

I've only read the first and last few entries in this thread but I'm having a problem understanding what is going on.

I thought that the ISO9001:2000 requirements for a quality manual were to have:

1. the scope of the quality management system, including details of and justification for any exclusions

2. the documented procedures established for the quality management system, or reference to them

3. a description of the interaction between the processes of the quality management system (not the standard)

Everytime I try to simplify our manual the auditor or our coporate headquaters says that's wrong.

Why?

Why does an auditor look for a restatement of the standard in the quality manual? Why restate the standard when a simple statement in the manual that you will meet the standard is enough.

Confused and Abused :bonk:

This was the original question. I support the simple shorter manual. I do not appreciate the suggestion that my manuals are only acceptable to the types of registrars that will pass anybody that writes a check. In fact 5 different registrars have been used by the various companies I work with. I encourage
dbzman to continue to try and simplify the manual. If the auditor is insisting otherwise, than respectfully ask the auditor if its to be a document for the audit, or a document for the company. I had an auditor 'advise' one of my clients that they needed to re-index their manual and renumber their procedures so he could more easily correlate to requirements of the standard. I convinced them that it wasn't a requirement, and we didn't do it. :truce:

Wes Bucey

24th July 2004, 03:38 AM

This was the original question. I support the simple shorter manual. I do not appreciate the suggestion that my manuals are only acceptable to the types of registrars that will pass anybody that writes a check. In fact 5 different registrars have been used by the various companies I work with. I encourage
dbzman to continue to try and simplify the manual. If the auditor is insisting otherwise, than respectfully ask the auditor if its to be a document for the audit, or a document for the company. I had an auditor 'advise' one of my clients that they needed to re-index their manual and renumber their procedures so he could more easily correlate to requirements of the standard. I convinced them that it wasn't a requirement, and we didn't do it. http://elsmar.com/Forums/images/smilies/surrender.gifI agree with you, Laura.

Let me add this little bit for newbies and others who are struggling with interpretations of ISO9k2k:

The Quality manual (in an ISO9k2k QMS) is a top level document (often called tier one.) Except in small companies and other special circumstances, Procedures are NOT included in a tier one document because they are tier two documents. Similarly, Work instructions and forms for compiling records are tier three documents.

It is sufficient for most purposes to merely "refer" to Procedures by type, not by title or document number, in a Quality Manual. See this example Section (redacted to disguise company name.)
2 References

2.1 References to third party standards
[Our company] designed its quality policies and practices to achieve and maintain the status of Parts Approval Holder (PAH.)

We intend to achieve PAH status by complying with the procedures for Parts Manufacturer Approval (PMA) for Replacement and Modification Parts contained in the most recent edition of Order 8110.42 (Parts Manufacturer Approval Procedures issued by the Federal Aviation Administration of the United States Department of Transportation), including the establishment of a Fabrication Inspection System.

Where pertinent, all members of our organization will comply with all airworthiness directives from the FAA which may apply to any unsafe conditions in products, specifically in accord with FAR 39.3.

[Our] policies conform and comply with quality standards and practices described by, but not limited to, ANSI/ISO/ASQ Q9001-2000, MIL-Q-9858, MIL-I-45208, FAR (Federal Aviation Regulation) Part 21, 23, and 25, and FAA PMA (Parts Manufacturer Approval Procedures (Order 8110.42A)

2.1.1 Process approach (Plan-Do-Check-Act)
Q9001-2000 describes a methodology or system for managing the various processes within an organization. ISO uses the term “Plan-Do-Check-Act” for the system. The elements of the system are explained

> Plan – establish the objectives and processes needed to satisfy the customer’s (as well as our own) requirements.
> Do – put the processes in operation (‘implement’)
> Check – monitor, measure, and record the operation and output of the process and evaluate against the plan
> Act – to find and implement ways to improve the process

We use this methodology wherever possible to make our organization as a whole more efficient and to meet or exceed our customer’s expectations. Specific aspects of this system are contained in the various procedures we use in our organization.
Note this QM was written before I ever heard the concept of using flow charts and other graphics to give more clarity to the QM. I can assure you I will strongly consider using those features when I update or write another QM. Much of the language in our manual is there to satisfy the FAA folk who don't give a rat's tail about ISO9k2k or AS9100. The difference between dealing with FAA and a third party auditor is like night and day because of the immense power an FAA inspector wields.

Whereas a 3rd party auditor might say, "It will be easier and less expensive for me to do an audit if your QMS and QManual are numbered like the Standard."

The FAA inspector says, "You WILL do it this way or I will not allow you to build or sell parts." When ALL the power is in the hands of the inspector, it is economic suicide to try to try anything new.


	Web Elsmar.com