I think you've failed to isolate your "High level" processes from the lower level ones, and as a result, you have too many processes to be able to map out sequence and interaction successfully. Also, your map only demonstrates "sequence" and not "interaction".
The standard states:
The standard asks you to identify the processes for the "Management System"....not for "Product Realization". You probably only have about a dozen high level processes (often referred to as Procedures) which need to be in the map. Then you need to determine the sequence and interaction of only those processes. No one could be expected to describe the "sequence and interaction" of ALL system processes (that is all Procedures and all Work Instructions).
But then again, almost every sample on this site only shows sequence and rarely interaction, and apparently they're widely accepted by auditors, so, it will probably be passed. The fact remains, that it simply doesn't comply with the requirement.
Patricia Ravanello
Thanks for your feedback. If you don't mind, I'd like to discuss this with you and get some more feedback.
This was my thought - if I just keep it VERY high level, I'd be pretty much re-writing the ISO continuous improvement map with one or two additions. Also, I wanted to ensure to capture critical processes such as our "Engineering value run, HV Mfg, and Final acceptance test." I do agree that there are quite a number of processes on the flow; however, I do think they are all pertinent.
The organization shall:
a) identify the processes needed for the quality management system and their application throughout the organization (see 1.2)
b) determine the sequence and interaction of these processes;
I think I have done just that. QMS processes are on the left with the specifics of the company in the center.
As far as sequence and interaction, I think it most definitely shows that. But perhaps you are thinking further than me and might have an example of what you mean. Otherwise, I think one could follow the process at the beginning of the flow all the way down to the design, mfg, shipping, customer, analysis, and then back to mgmt, starting it all over.
Further, take "purchase & verify parts." It shows that multiple process teams have input/interaction because the box spans all those teams. Whereas with "repair," only the technical support team is represented. And yes, one could say that "repair" ultimately involves others (feeding back into design and mfg) and that is where the analysis being fed into CAPAs and back into Mgmt would come into play. Those vehicles would ensure pertinent information would flow back into the system and areas of improvement addressed. Does that speak to what you were addressing?
Patricia, if you have an example that you could share, I would really appreciate it. I'm sure everyone else would too.
Perhaps if others could chime in, that would be great too. I want to ensure that we are as compliant as possible.
THANKS!