Search the Elsmar Cove!
**Search ALL of** with DuckDuckGo Especially for content not in the forum
Such as files in the Cove "Members" Directory

Quality Manual Organization and Structure including Numbering

Is Your Company's 'Quality' Manual....

  • Organized and numbered like ISO 9001.

    Votes: 39 60.0%
  • Organized, but NOT numbered like ISO 9001

    Votes: 17 26.2%
  • We 'Rolled Our Own' (Please comment how so in a Reply)

    Votes: 9 13.8%

  • Total voters


Captain Nice
Staff member
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 '' - 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.
Process vs procedure

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.
Simple stuff

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

Quite Involved in Discussions

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.

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.

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.
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 fact, I just did! :smokin:
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.

Jim Wade said:


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.
Top Bottom