Jim,
Yeah - I replied because of my agreement with you.
The "
Process Approach" becomes a discussion of what is essentially a war of words just like Six Sigma "debates" (aka discussions).
I said it before, and I'll say it once again: "The Process Approach" as seen (advertised) today is a sales pitch. Any business owner that doesn't understand that their business is a series of interrelated processes (aka systems) with inputs and outputs won't be in business very long. It's so basic that it amazes me that the discussions keep surfacing.
It surely doesn't take an MBA to understand that businesses are a series of
inter-related processes,
process interactions are important, and that these processes have to be effective (for lack of a better word off hand).
I'd say more, but I put my thoughts about this into my post above (Post 19).
Here's an example of the difference between the process approach and the more common elemental approach. A little case study. And I agree Marc, organizations understood process just fine and were managing them accordingly (if informally) before ISO 9000 professionals came along to confuse everyone!
Let's assume a small manufacturing company (not design responsible) making widgets to customer specification. So, this company is a contract manufacturer. 4 realization processes affecting quality are in operation: Sales, Purchasing, Production, and Shipping and Receiving. (Although shipping and receiving are two distinct processes, they operate in the same department, as is common in smaller companies.)
Let's assume our little company was seeking certification to the old 20-element version of 1994. So, the company is pursuing certification to ISO 9002:1994, which omits 4.4 Design. And since service agreements are not offered, 4.19, Servicing is excluded. So 18 requirements are applicable to the company.
Using the elemental approach, the organization will "develop" (cut-and-paste) 18 procedures, one for each of the elements of the standard (ISO 9002:1994):
4.1
Management responsibility
4.2
Quality System
4.3
Contract Review
4.5
Document Control
4.6
Purchasing
4.7
Customer-supplied Product
4.8
Product Identification and Traceability
4.9
Process Control
4.10
Inspection and Test
4.11
Control of Inspection, Measuring and Test Equipment
4.12
Inspection and Test Status
4.13
Control of Nonconforming Product
4.14
Corrective and Preventive Action
4.15
Handling, Storage, Packaging, Preservation, and Delivery
4.16
Quality Records
4.17
Internal Quality Audits
4.18
Training
4.20
Statistical Techniques
These procedures were often purportedly required of the standard (due to poor interpretation).
Using this approach, an organization's processes are not even taken into consideration in the architecture of it's QMS! The structure and to some degree the content of the procedures are based upon the standard's requirements. That's what's wrong.
Regardless of organization structure and the existing processes affecting quality, QMS documentation is developed to answer the requirements of the standard, without regard regard for the processes. This confounds a basic purpose of QA--to control processes. In fact, this approach mistakenly raises many requirements to the level of being QMS processes.
Since QA is about controlling processes, these documents are not helpful to anyone trying to manage a process nor to those trying to understand processes, in fact they confuse processes. How? By using procedures that slice and dice the description of these processes according to the requirements of the standard.
While the "contract review" procedure covers the sales process, and the "purchasing" procedure covers the purchasing process, the remaining realization requirements--eight of them--do not describe the remaining processes: production and shipping/receiving. Again, they reflect requirements that pertain to these processes instead of reflecting a process that complies with the applicable requirements.
A guy in receiving that is expected to follow procedure while accepting the next shipment would have 8 procedures to read and become confused by, none of which tell him how to receive the shipment--they don't describe the receiving process. They slice it into 8 procedures (unless another layer of documentation pertains, such as a receiving work instruction):
- Customer Supplied Product
- Product Identification
- Process Control
- Inspection and Test
- Inspection and Test Status
- Handling, Storage, Packaging, Preservation, and Delivery
- Control of Nonconforming Product
- Statistical Techniques
Using the process approach, the organization will develop only ten procedures. Why? Because they have only 4 realization processes: sales, purchasing, production, and shipping/receiving. The titles of the procedures describing these processes?
- Sales,
- Purchasing,
- Production, and
- Shipping and Receiving.
The remaining 6 procedures describe support processes. For example, just as they combine shipping and receiving, they also combine document control and record control, corrective and preventive action, etc.
It is the 4 realization processes that are important in the first place, yet using the elemental approach, these processes are lost among the procedures.
The Shipping and Receiving procedure describes the shipping process and the receiving process so that the processes are clear and conformity with the applicable requirements can be plainly seen. So, not only does it tell the guy in receiving how to accept the shipment, by following the procedure, it also ensures that the shipment is received in conformity with applicable ISO requirements.
Do you see the difference between an elemental approach (18 procedures dedicated to requirements) an a process approach (10 procedures dedicated to processes)?
