Poll: Should auditors promote the process approach?

[Helmut Jilling]

Once you understand the international language of the standard, however, the definitions seem quite good now that I think about it. It's really a matter of understanding the general idea first, which requires more than a simple presentation of definitions.

I agree. I think ISO assumes a certain degree of experience and exposure to systems, processes, practices, metrics, etc, which would provide a frame of reference to connect all the other things it adds.

 

[Helmut Jilling]

Re: What criterial do you use to identify a company using the "process approach"?

Please explain your definition of "define their documentation and organizations". Are you referring to organizational charts? Are you referring to documentation structure?

Their documented QMS, manual, procedures, diagrams, etc.

Please show or tell about an example of this and an example of one that does not follow this approach. Give me an example of what constitutes "...truly define and manage it as a series of processes...". You say it is a requirement. State the requirement and give an example of objective evidence that a company does, and of one that does not, "...truly define and manage it as a series of processes...". That is to say, objective evidence that a company does, or does not, comply with the requirement you are going to cite. (Key words: objective evidence)

In reading your post, I believe we see the process approach pretty much the same way. However, the ISO standard makes a fundamental error. The ISO 9001 standard fails to make a definitive SHALL statement requiring a QMS to be written and managed as a process approach.

ISO 9001 talks about the process approach. It promotes the concept, gives definitions. It provides clause 4.1. By the way, folks, ISO 9004 (2000) gives a lot more excellent discussion in cl 7 to 7.1.3.3. Further, the ABs and CBs hammer us to require it in our audits. But, the standard does not flat out say it is a nonconformity if the company only writes processes into the documentation to meet 4.1 and does not fully follow the concept. (After years, the TS Rules finally added an appendix to address this.) I know the intent is there, but they really failed the quality community by leaving it somewhat vague, except for cl 4.1. It makes for many interesting conversations during audits when I write nonconformities. It was introduced as a foundation to the standard, and could be more black and white. Just witness the amount of discussion and ink this topic has consumed over the years.

I have never been in a company that did not define and manage themselves as a series of processes. They really don't have a choice because a company *is* a series of processes/systems...

Give me an example of where Sales and Purchasing are identified as a single "process" (no sub-processes/systems).

Sales and Purchasing are functions/systems made up of sub-systems/processes relevant to how a specific company does things...

I have been in many companies where one person had multiple responsibilities. Sales and purchasing are broken up into sub-systems/processes necessarily simply because they are not the same thing. Whether or not one person has one or many responsibilities is not relevant.

What is a department approach? Are you referring to how the company structures its document naming conventions? So what if the same person has multiple responsibilities? Processes/systems (documented or undocumented) have to be followed, have to have inputs and outputs regardless of whether one person has to follow the processes/systems (documented or undocumented) or whether many do.

Actually, I agreed with most of your comments. But, I often see where companies define "processes," in their QMS without having a clear understanding of the process approach. I gave the example where a company combined Sales and Purchasing under one process. They titled it "Order Entry." As we looked at it, it became clear they addressed sales orders and purchase orders, but had neglected to define any processes to handle the whole Sales function, or Purchasing function. The order entry activities were merely subprocesses in their company, but were not defined that way in their system. One guy was in charge of both, so they lumped them together. I euphemistically refer to this as a "departmental approach" to help them see the difference between that and what cl 4.1 describes as a process approach.

Certainly companies are an ongoing series of activities and processes and subprocesses, but many do not see that. Many only see departments. Many people document their QMS to try to address the standard, but run their company by the existing departments. They feel that "d##n ISO" just creates another layer of nonvalue-added paperwork, when the real issue is they did not understand what ISO wanted them to achieve by the process approach.

It is usually evidenced by an incomplete implementation of cl 4.1. A few questions quickly confirm they don't really see the process flow in their organization, so what they documented is often a hodge-podge effort to try to satisfy the standard.

Let's take organizational charts: ...in many companies they change frequently, sometimes monthly. Just because the organizational chart changes frequently it does not mean that the process/systems the company have in place necessarily change. ...next month (after another round of downsizing) the Engineering Department Manager may take on additional responsibilities for systems/procedures someone who is let go used to be responsible for. Org charts assign responsibilities/authorities for processes/systems but that's about it.

...organizational charts must be up to date and must be controlled documents, and that changes are appropriately communicated throughout the organization. Then again, I have been in small companies that didn't need an organization chart. You could ask any employee who was responsible for what systems/processes and they could tell you....

I generally don't have problems with org charts. Yes, assignments change, but that rarely changes the underlying processes.

So - You are saying a company has to have something like diagrams of some sort to show linkages between processes when linkages (inputs and outputs) are already within the documents? Can you cite the specific requirement...

All that I can see is you are trying to say companies must adopt a specific documentation structure ...The *content* (importantly inputs and outputs) of a document/procedure is what is important.

Now we're getting into subjective territory. Who is to decide how much process documentation is necessary? An auditor? Who is to decide what metrics are enough as long as data/inputs/outputs required by the standard are there? An auditor?

Sorry, not sure where you drew that inference. I agree and often state, the processes and items in cl 4.1 can be documented in anyway they choose. It just has to make sense, address all their activities, plus meet all the requirements in 4.1.

But to me, ISO 9004 is 'basic business 101' (as is ISO 9001)...

ISO 9004 is a good document. I'd call it a basic business primer ...

I agree. I call it "Common Sense Codified" (into a standard). It is a good document. In fact, if everyone at the Cove read 9004, there would be a lot less debate. It actually clarifies a lot of the unclear content of 9001.

On this we agree. I usually advise companies to write their Quality Manual based on the clauses because it helps them learn the structure of the standard, how it all fits together and promotes a better understanding of it. One might even call it a reference, especially in small companies that already do 'every thing right'. It helps wean a company off their dependence upon me for understanding of the standard because its in their face all the time (at least in the face of people who have to understand the requirements, which is always a small sub-set of employees in any given company).

I find that is the easiest way to get everyone up to speed. And it gets the requirements into their QMS. Although I do use 9004 (2000) as the model and not 9001. I find 9004 has much more meaningful content and explanation.

ISO 9001 and related standards only require that a company have certain systems/processes (e.g.: document control) and that certain systems/processes have certain inputs and outputs. Well, yes, the systems must be *effective*, but again we digress into a degree of subjectivism when we discuss what is 'effective' from the view of the auditor vs. the view of the company. In some cases it *is* quite apparent that a system/process is or isn't effective, but many times we end up in the old 'gray area' of opinion.

ISO only requires certain "documents." The standard requires all of a company's processes be defined and dissected (cl 4.1). Not just certain ones.

In all the years that I've been involved in this, almost all companies I have worked with had *most*, if not all, of the systems/processes the standard... requires. A lot of what I did was look at how they operated and then explain the standard and its requirements. Most of the problems were understanding the 'language'...

...Now, let's step through your procedure here and see if it contains all the requirements of the standard, and let's look through your documents and forms and ensure we know how they work together." I've been called 'the teacher' in a couple of companies. Obviously it was because I was teaching them how to interpret the standard and how they complied (or didn't comply) with the requirements of the standard.

Agreed. I follow the same approach. The primary disconnect I find is what I described above - many companies run in a certain way, but the documentation does not describe it that way. Upon investigation, the root cause is always related to not understanding the standard or the process approach, but trying to write something to "meet the standard." Whenever we have explained the process approach, they always see there is benefit to that approach. Usually, inevitably, during the time onsite, we discover good examples where the attempt missed the intent. That further reinforces the point.

Good talking with you.

 

[Big Jim]

Re: What criterial do you use to identify a company using the "process approach"?

ISO only requires certain "documents." The standard requires all of a company's processes be defined and dissected (cl 4.1). Not just certain ones.

I'm not sure how you got that from 4.1 a or just how you apply it.

"identify the processes needed for the quality managment system and their application throughout the organization"

Why would you need to get down to the minutea of "be defined and dissected" out of that?

 

[Helmut Jilling]

Re: What criterial do you use to identify a company using the "process approach"?

I'm not sure how you got that from 4.1 a or just how you apply it.

"identify the processes needed for the quality managment system and their application throughout the organization"

Why would you need to get down to the minutea of "be defined and dissected" out of that?

Cl 4.1 requires all the processes to be identified. (The Note adds that it applies to support processes also). It requires that sequences and process interactions (inputs/outputs) be identified. Criteria for how each process is to be evaluated must be determined (that one is critical and many people miss it). Resources must be determined, and lastly, how to measure or monitor effectiveness and performance must be determined. There is a lot of detailed pieces parts there. I euphemistically refer to that as dissecting the processes. Mapping them or defining on turtles would be two ways to approach doing that.

 

[Big Jim]

Re: What criterial do you use to identify a company using the "process approach"?

Cl 4.1 requires all the processes to be identified. (The Note adds that it applies to support processes also). It requires that sequences and process interactions (inputs/outputs) be identified. Criteria for how each process is to be evaluated must be determined (that one is critical and many people miss it). Resources must be determined, and lastly, how to measure or monitor effectiveness and performance must be determined. There is a lot of detailed pieces parts there. I euphemistically refer to that as dissecting the processes. Mapping them or defining on turtles would be two ways to approach doing that.

Determining criteria and methods needed to ensure that both the operation and control of these processes does not necessarily equate to "criterial for how each process is to be evaluated must be determined". You are drilling down deeper than the standard requires.

Ensure the availibility of resources and information necessary to support the operation of these processes does not necessarily equate to "resources must be determined" Again, you are attempting to add more to the standard than is there.

A few years ago, I had an assignment to help with an internal audit for a company that was behind on their internal audit activity. Their management representative had been on sick leave for nearly six months and they were approaching a certification body audit. They had so detailed their processes that they had over 250 processes. Without their chart, no one in the company other than the management representative had any idea what the processes were. That was certainly a good example of too much minutia. However, it was their choice and that is how they chose to do it.

In the end, it is the organizations choice on how they want to break down the titles to their processes and what subprocesses and activities are in them. There is no requirement to over document them.

 

[Marc]

Re: What criterial do you use to identify a company using the "process approach"?

Helmut - I think your approach is what you expect to see and want rather than the requirement as Jim has pointed out. It is what you would do if you were running the business. You agree that most of your issues are with documentation structures rather than the actual processes. You do say:

In reading your post, I believe we see the process approach pretty much the same way. However, the ISO standard makes a fundamental error. The ISO 9001 standard fails to make a definitive SHALL statement requiring a QMS to be written and managed as a process approach.

My emphasis in red. I can only take this to mean you believe ISO 9001 should define and require a format for documents including 'Quality Manuals'. Maybe it will some day, but I seriously doubt it.

And what is a Quality Manual and it's associated procedures? What format would be a 'process approach' format? Flow charts (aka process maps, etc.)? Would it make a 'significant' difference?

You call it an 'error'. I don't consider it an 'error' (which brings up "What is the purpose of ISO 9001?"). This is something you would do if you ran a company. Now, I can emphasize with you. I have been working with companies for a long time and as I have posted here many times over the years I have pushed flow charting of as many procedures/systems as possible (get rid of as much text as possible) since the early 1990's. The first company I got to do this was in 1994. That's 16 years ago. ISO 9001 was 7 years old at the time. Here are some of their flow charts from back around 1996 when they asked me to take a look at revisions they made. I got permission to put copies here because I was as enthusiastic about my approach back then as you and the ISO 9001 Guy are now. I was a biologist looking at a business system and wanted business people to see the benefits of flow charting (process mapping, etc.) rather than "...writing big honking binders..." full of text procedures. I felt, and still feel, that flow charts do help a company better understand their processes and their interactions, but I base that upon my belief that people better able to understand pictures vs. text. Not to mention, I think it better helps people understand system/procedure inputs and outputs (aka process interactions).

The flow charts I got companies to do going back 15+ years are primitive compared to the detailed ones many companies do today (particularly with respect to inputs and outputs), but for their time they did work pretty well. Harley-Davidson in York even gave flow charting (process mapping) classes to managers (guess who did the training....) when I started the H-D implementation there back around 1996.

I remember well my first registration audit where the company I was working with had used my flow charting approach to procedures. It took a couple of hours (including a phone call to his boss and a few faxes back and forth) just to convince the auditor that a flow chart could be a procedure. He was very upset, as well I can imagine never having come across anyone before anything like it before. That a procedure could be something other than a text document did not fit in his paradigm.

During the early days of my consulting career I saw that many companies had things like quality manuals, but usually they had them because a customer required them to have one. As I think you are saying, the companies didn't really use them. Like an ISO 9001 implementation, a customer (this was mainly in automotive at the time) requirement kicked off a compliance 'project' where certain procedures were written, a quality manual was written (etc.) and then, after the customer audit and their 'OK' the documents were not used. They sat there and as 'actual' systems changed the related documentation often didn't. Thus, as I think is part of your issue, the procedures/documentation did not reflect what the company was really doing. When I came into the picture everything had to be looked at again. That's why I stress Document Mapping and 'Sweeps' in an implementation. Until a company knows what they have they can't act.

In all this we have to consider the evolution of companies and how they were run. We also have to look at the people who were/are 'Quality Gurus' like:
1. Dr. Walter Shewhart - PDCA cycle as well as well as theories of process control and the Shewart transformation process.
2. Dr. W. Edwards Deming - “Fourteen Points” and the “Seven Deadly Diseases of Management” -
3. Dr. Joseph M. Juran - The Quality Trilogy - Quality Planning, Quality Improvement, and Quality Control, not to mention the Juran Handbook (at 5 pounds or so... .
4. Armand V. Feigenbaum - The idea of total quality control based on three steps to quality consisting of quality leadership, modern quality technology, and an organizational commitment to quality.
5. Dr. Kaoru Ishikawa - The Ishikawa diagram known for popularizing the seven basic tools of quality and the philosophy of total quality.
6. Dr. Genichi Taguchi - The Taguchi Loss Function - The “Taguchi methodology” of robust design, also known as “designing in quality”, which focused on making the design less sensitive to variation in the manufacturing process instead of trying to control manufacturing variation.
7. Shigeo Shingo - Lean concepts such as Single Minute Exchange of Die (SMED) or reduced set-up times instead of increased batch sizes as well as Poka-Yoke (mistake proofing) to eliminate obvious opportunities for mistakes. He also worked with Taiichi Ohno to refine Just-In-Time (JIT) manufacturing into an integrated manufacturing strategy, which is widely used to define the lean manufacturing used in the Toyota production system (TPS).
8. Philip B. Crosby - Developed the idea of “quality is free” which asserts that implementing quality improvement pays for itself through the savings from the improvement, increased revenue from greater customer satisfaction, and the improved competitive advantage that results. His popularized “zero defects” to define the goal of a quality program as the elimination of all defects and not the reduction of defects to an acceptable quality level.
9. Dr. Eliyahu M. Goldratt - Developed the Theory of Constraints which focuses on a single element in a process chain as having the greatest leverage for improvement (i.e., “1% can have a 99% impact”). This compares to the Pareto principle which states that 20% of the factors have an 80% effect on the process.
10. Taiichi Ohno - Developed the seven wastes (muda), which are used in lean to describe non-value-added activity. He developed various manufacturing improvements with Shigeo Shingo that evolved into the Toyota Production System.

I mention the Gurus because the technological changes since about 1985 have allowed medium sized and smaller companies to use the tools, to keep documentation up to date, and so many things more. For all the tools the Gurus gave business, the computer has revolutionized what companies can do including the use of tools. Home computers started in the 1970s as toys for hackers, became business office tools in the 1980s, design and educational tools in the 1990s, and home-entertainment/communications centers in the 2000s (and destroying the previous industry giants in each field in the process). Over the years I have watched as computers and the internet have made it possible for small and medium sized companies to many things they could not do 20 years ago.

My point is there is a continuing evolution in business and how they are run. Not so many years ago communication was a significant issue. People started businesses and most didn't depend upon something like ISO 9001, nor could they hop on the internet and come somewhere like this site to learn about business systems and processes. I can see some of you points, but again they are what *you* would do/expect, not what the standard requires. A 'process approach' is not new. It is being more widely accepted just as tools and methods the 'Quality Gurus' we all know and love continue to be more widely accepted and used even today.

The primary disconnect I find is what I described above - many companies run in a certain way, but the documentation does not describe it that way.

Now let's think about that. If the documentation does not reflect how a company is run, you can only be saying people are not following procedures. If the company doesn't use (follow) their procedures they couldn't begin to pass an audit, so that's a moot issue.

Well, what I've written are just some of my thoughts. As I've said, I think there is a big difference between what an auditor would like to see as often is the case vs. what the standard requires.

 

[Helmut Jilling]

Re: What criterial do you use to identify a company using the "process approach"?

Helmut - I think your approach is what you expect to see and want rather than the requirement as Jim has pointed out. It is what you would do if you were running the business. You agree that most of your issues are with documentation structures rather than the actual processes. You do say: My emphasis in red. I can only take this to mean you believe ISO 9001 should define and require a format for documents including 'Quality Manuals'. Maybe it will some day, but I seriously doubt it.

And what is a Quality Manual and it's associated procedures? What format would be a 'process approach' format? Flow charts (aka process maps, etc.)? Would it make a 'significant' difference?

You call it an 'error'. I don't consider it an 'error' (which brings up "What is the purpose of ISO 9001?"). This is something you would do if you ran a company. Now, I can emphasize with you. I have been working with companies for a long time and as I have posted here many times over the years I have pushed flow charting of as many procedures/systems as possible (get rid of as much text as possible) since the early 1990's. The first company I got to do this was in 1994. That's 16 years ago. ISO 9001 was 7 years old at the time. Here are some of their flow charts from back around 1996 when they asked me to take a look at revisions they made. I got permission to put copies here because I was as enthusiastic about my approach back then as you and the ISO 9001 Guy are now. I was a biologist looking at a business system and wanted business people to see the benefits of flow charting (process mapping, etc.) rather than "...writing big honking binders..." full of text procedures. I felt, and still feel, that flow charts do help a company better understand their processes and their interactions, but I base that upon my belief that people better able to understand pictures vs. text. Not to mention, I think it better helps people understand system/procedure inputs and outputs (aka process interactions).

The flow charts I got companies to do going back 15+ years are primitive compared to the detailed ones many companies do today (particularly with respect to inputs and outputs), but for their time they did work pretty well. Harley-Davidson in York even gave flow charting (process mapping) classes to managers (guess who did the training....) when I started the H-D implementation there back around 1996.

I remember well my first registration audit where the company I was working with had used my flow charting approach to procedures. It took a couple of hours (including a phone call to his boss and a few faxes back and forth) just to convince the auditor that a flow chart could be a procedure. He was very upset, as well I can imagine never having come across anyone before anything like it before. That a procedure could be something other than a text document did not fit in his paradigm.

During the early days of my consulting career I saw that many companies had things like quality manuals, but usually they had them because a customer required them to have one. As I think you are saying, the companies didn't really use them. Like an ISO 9001 implementation, a customer (this was mainly in automotive at the time) requirement kicked off a compliance 'project' where certain procedures were written, a quality manual was written (etc.) and then, after the customer audit and their 'OK' the documents were not used. They sat there and as 'actual' systems changed the related documentation often didn't. Thus, as I think is part of your issue, the procedures/documentation did not reflect what the company was really doing. When I came into the picture everything had to be looked at again. That's why I stress Document Mapping and 'Sweeps' in an implementation. Until a company knows what they have they can't act.

In all this we have to consider the evolution of companies and how they were run. We also have to look at the people who were/are 'Quality Gurus' like:
1. Dr. Walter Shewhart - PDCA cycle as well as well as theories of process control and the Shewart transformation process.
2. Dr. W. Edwards Deming - “Fourteen Points” and the “Seven Deadly Diseases of Management” -
3. Dr. Joseph M. Juran - The Quality Trilogy - Quality Planning, Quality Improvement, and Quality Control, not to mention the Juran Handbook (at 5 pounds or so... .
4. Armand V. Feigenbaum - The idea of total quality control based on three steps to quality consisting of quality leadership, modern quality technology, and an organizational commitment to quality.
5. Dr. Kaoru Ishikawa - The Ishikawa diagram known for popularizing the seven basic tools of quality and the philosophy of total quality.
6. Dr. Genichi Taguchi - The Taguchi Loss Function - The “Taguchi methodology” of robust design, also known as “designing in quality”, which focused on making the design less sensitive to variation in the manufacturing process instead of trying to control manufacturing variation.
7. Shigeo Shingo - Lean concepts such as Single Minute Exchange of Die (SMED) or reduced set-up times instead of increased batch sizes as well as Poka-Yoke (mistake proofing) to eliminate obvious opportunities for mistakes. He also worked with Taiichi Ohno to refine Just-In-Time (JIT) manufacturing into an integrated manufacturing strategy, which is widely used to define the lean manufacturing used in the Toyota production system (TPS).
8. Philip B. Crosby - Developed the idea of “quality is free” which asserts that implementing quality improvement pays for itself through the savings from the improvement, increased revenue from greater customer satisfaction, and the improved competitive advantage that results. His popularized “zero defects” to define the goal of a quality program as the elimination of all defects and not the reduction of defects to an acceptable quality level.
9. Dr. Eliyahu M. Goldratt - Developed the Theory of Constraints which focuses on a single element in a process chain as having the greatest leverage for improvement (i.e., “1% can have a 99% impact”). This compares to the Pareto principle which states that 20% of the factors have an 80% effect on the process.
10. Taiichi Ohno - Developed the seven wastes (muda), which are used in lean to describe non-value-added activity. He developed various manufacturing improvements with Shigeo Shingo that evolved into the Toyota Production System.

I mention the Gurus because the technological changes since about 1985 have allowed medium sized and smaller companies to use the tools, to keep documentation up to date, and so many things more. For all the tools the Gurus gave business, the computer has revolutionized what companies can do including the use of tools. Home computers started in the 1970s as toys for hackers, became business office tools in the 1980s, design and educational tools in the 1990s, and home-entertainment/communications centers in the 2000s (and destroying the previous industry giants in each field in the process). Over the years I have watched as computers and the internet have made it possible for small and medium sized companies to many things they could not do 20 years ago.

My point is there is a continuing evolution in business and how they are run. Not so many years ago communication was a significant issue. People started businesses and most didn't depend upon something like ISO 9001, nor could they hop on the internet and come somewhere like this site to learn about business systems and processes. I can see some of you points, but again they are what *you* would do/expect, not what the standard requires. A 'process approach' is not new. It is being more widely accepted just as tools and methods the 'Quality Gurus' we all know and love continue to be more widely accepted and used even today.

Now let's think about that. If the documentation does not reflect how a company is run, you can only be saying people are not following procedures. If the company doesn't use (follow) their procedures they couldn't begin to pass an audit, so that's a moot issue.

Well, what I've written are just some of my thoughts. As I've said, I think there is a big difference between what an auditor would like to see as often is the case vs. what the standard requires.

I'm not sure why we are not connecting here. I agree with most of your statements. But somehow what I am trying to say gets lost.

I DO wish the standard would make a specific statement saying it requires a "process approach," instead of alluding to it. The CBs and ABs state that to us auditors, but it is harder to persuade some people without the standard making it explicit.

I DO NOT want the standard to require any particular document format. (Read all my posts, I have been consistent on that point for years). I am very flexible that companies can document their QMS in a manner that is appropriate to their needs. I do ask that it be appropriate, however.

I DO NOT believe overdocumenting provides any value. I call it "Goldilocks." Not too much, not too little, but just right. And that target will be different with each company. I appreciate that the standard allows for that.

I DO see many examples on my first visits where companies have documented a list of processes, but that list does not reflect how the company actually functions. The lsit was an attempt to meet ISO. Whether that means they are not following their procedures or not, it clearly tells me they do not get it when it comes to the process approach. When we take them to the standard, and show them the flow in 4.1, you can see the light bulb in their eyes go on.

Hope that clarifies my views.

 

[Helmut Jilling]

Re: What criterial do you use to identify a company using the "process approach"?

Determining criteria and methods needed to ensure that both the operation and control of these processes does not necessarily equate to "criterial for how each process is to be evaluated must be determined". You are drilling down deeper than the standard requires.

Ensure the availibility of resources and information necessary to support the operation of these processes does not necessarily equate to "resources must be determined" Again, you are attempting to add more to the standard than is there.

A few years ago, I had an assignment to help with an internal audit for a company that was behind on their internal audit activity. Their management representative had been on sick leave for nearly six months and they were approaching a certification body audit. They had so detailed their processes that they had over 250 processes. Without their chart, no one in the company other than the management representative had any idea what the processes were. That was certainly a good example of too much minutia. However, it was their choice and that is how they chose to do it.

In the end, it is the organizations choice on how they want to break down the titles to their processes and what subprocesses and activities are in them. There is no requirement to over document them.

Sorry, I was paraphrasing the standard, but I do not feel I was adding additional requirements.

I was emphasizing the criteria for effectiveness in cl 4.1.c is a vital link that many companies overlook. It is the shadow to the process approach, just like the misunderstandings about Preventive Actions.

I do not believe in overdocumenting a QMS or over defining the processes in a company.

A company with 250 defined processes is an example of what I have been saying. The clearly did not understand the intent of the process approach, and I am sorry they went to that mauch effort. Just about any system with more than a couple dozen processes has probably elevated a lot of subprocesses to the level of a full process, and that rarely adds clarity. It usually bogs things down.

As to your specific example of resources, obviously "resources must be determined," before the company can make available the "resources and information necessary to support the operation of these processes." I was really not adding requirements to the standard. I don't do that.

 

[dknox4]

Re: What criterial do you use to identify a company using the "process approach"?

Given the endless possible business operating systems and equally endless ways of implementing and documenting QMS's within these BOS's, it is in all probability impossible to come to an agreement on what is definitively a documented "process approach" in a forum like this. Everyone is talking theoretically and has their own mental picture of what this is. In order to get anywhere near definite agreement/disagreement, you would most likely need to reveiw a system together against the standard. This is in fact, what an auditor is supposed to do and nothing more.

Back to the original poll question, my issue is with the "promote" objective. As a recipient of audits/audit outputs, I am looking for my system to be evaluated against the standard. I am not interested in auditor opinions and theories about how my system should be set-up and a good auditor will not audit to their paradigm only. Beyond the meddling/tinkering that I would not want an auditor to be doing to my system, I cannot see how a CB or auditor could go down this "promote" path without crossing into the consulting realm.

 

[Big Jim]

From Marc:

"As I've said, I think there is a big difference between what an auditor would like to see as often is the case vs. what the standard requires."

Very well put Marc. This is an easy trap to fall into. My habit to try to minimize this is to actually refer to the standard very frequently. I always refer to it before writing any nonconformance to ensure I have not accidently altered the meaning. It should be refered to anyway when you write the citation (the part of the standard that was violated) so why not start there in the first place?