Re: Cl. 4.2.2 - Quality Manual includes a description of the interaction between the
I agree. Viewing processes from the 30,000-foot view, as you say, is useful in laying out QMS processes and their sequence and interaction. When diagrams are requested by clients or auditors, I like block diagrams because they define processes at an appropriate level: 30,000 feet. Defined at this level, I see no reason why QMS processes should be omitted. A QMS IS a system of processes--management processes.
ISO 9001:2008 4.1a requires the organization to determine the processes needed for the QMS, while 4.1b requires the organization to determine the sequence and interaction of these processes. (Italics mine.) It seems that in defining a QMS, an organization should determine all of the processes impacting quality, shouldn't it? Isn't that kind of the point?
By requiring the sequence and interaction of processes to be described somehow, it's a good idea to include all processes comprising the system--assuming the processes are sensibly defined. Those who allow the standard to identify their processes surely have a mess to deal with. But that very well might have been part of the intention of the requirement to define seq and int. Those who have allowed the standard to identify their realization processes should recognize by going through the seq and int exercise that there IS no seq between standard-based "procedures," and their interaction will always be confusing at any level. I don't think the idea is to omit procedures that don't fit into a description of the sequence and interaction of QMS processes; delete them instead.
The attached is a hybrid between my previous two posted examples. Again, diagrams aren't necessary, but sometimes a picture is helpful. This one depicts the four primary processes of a small machine shop, in order of appearance. I like the icons showing the support processes, simply because they show precisely which support processes support which primary processes--to demonstrate a fairly clear interaction between the processes. It also shows an example of how the requirements of ISO 9001 are addressed in process fashion.
Many make the mistake of looking to the standard to identify their processes (e.g., "Product Identification" or "Inspection and Test Status"), which results in a confusing smattering of "procedures" describing (or failing to describe) real processes--the ones that were being operated and managed before ISO 9000 came along. Like the requirements they reflect, there is no particular sequence or interaction between the requirements, thus there is no particular sequence or interaction between procedures based upon these requirements.
But there is definitely a very real sequence and interaction between real processes affecting quality (e.g., sales, purchasing, receiving, production, shipping). These are the processes to which procedures should have been dedicated in the first place, rather than to the disparate requirements of the standard. Properly defined, the sequence and interaction of these processes is not difficult to convey in a variety of formats, such as the above sequenced list. A block diagram such as the attached shows all of the QMS processes and how they relate. In this particular case, with the exception of "calibration", the support structure is very similar for each realization process; the "calibration" process only supports two realization processes: Shipping and Receiving, and Production. In more sophisticated organizations, the interaction of the support structure might be slightly different.
At any rate, once (real) QMS processes have been determined, the standard requires their sequence and interaction to be determined as well. If you say you have a QMS process--a management process affecting quality--then the standard reasonably requires you to determine how it fits into the quality management system. Although this is terribly difficult to do if a bad approach was used to define and document the system, that doesn't mean the principle should be abandoned. In the case of a standard-based system, a block diagram showing real processes while also identifying which requirements (and thus which procedures) apply to each QMS process might help clarify the confusion (sic).
To define a QMS as a system of processes affecting quality--which is what a QMS is--it seems a description of those processes and their sequence and interaction is common sense, doesn't it?
Sorry to ramble . . .