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.
Quality Manual Organization and Structure including Numbering
- Thread starter Marc
- Start date
K
km2red
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!!!
M
M Greenaway
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).
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
M Greenaway
Or even more harmful, not spelling out the requirements to understand processes (and causes of variation).
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.
M
M Greenaway
Mike
Probably none.
But real process mapping is a useful tool.
Probably none.
But real process mapping is a useful tool.
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.
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.
Last edited:
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...
R
Randy Stewart
Don't go overboard!!!!!
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.
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.
Similar threads
