Hello Everyone!

If possible, please review my process map. It's intended to be the high level map for the QM. We're responsible for everything that ISO covers. I tried not to really use the "ISO format" but found that it provided organization.

I got the process owners together, got a mock flow together, and this is the organized version. So I think we're on the right track but you never know!

Any thoughts or recommendations would be greatly appreciated.

*The white boxes beneath the process will list the procedures.
**HV MFG is High volume Mfg. We do an evaluation after the first large batch to ensure it's ready for high volume production.

Thank you in advance! :thanx: :thanks:

It certainly works for me :agree1: Pretty neat, actually.

/Claes

It's really good.

Thanks for sharing. I think the mapping shown is good. My boss doesn't like the mapping in the ISO requirement. He said it is too simple for the reader (dept managers, supposed) to know what they should do actually to run the cycle. This one is clear and direct. I would like to adopt it with KPI added.

Hi hrrvett , its good and cover all points. :agree1:

One more, customer input shouldn't point to "Repair", right?

Hello Everyone!

If possible, please review my process map. It's intended to be the high level map for the QM. We're responsible for everything that ISO covers. I tried not to really use the "ISO format" but found that it provided organization.


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 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;


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

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!

One more, customer input shouldn't point to "Repair", right?

HI! The repairs are from customers. Perhaps I should state "customer repairs."
Thanks!

It certainly works for me :agree1: Pretty neat, actually.

/Claes

Thanks for everyones replies! I sincerely appreciate!

I think you've missed the point, similar to what Patricia is saying. I wouldn't have used a flowchart, since it's not actually showing processes - just a number of things that departments do or need to be done. You show, for example, your 'control of customer property' and it leads directly to corrective action etc. Really? You don't actually add vaue/process the stuff? I also would ask if your QMS always starts with Management review? Where are the actual business process inputs/outputs?

I rather doubt if you showed this to your management team they'd agree that this is the way you run a business and that's what ISO 9001 is asking you to describe in your QMS 'sequence and interaction' of processes. You've described what each department does, not how they work on your processes and, as such, your diagram is flawed.

:2cents:

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.


I think I have done just that. QMS processes are on the left with the specifics of the company in the center.

!

Hello Hrrvett,
The "critical processes" which you refer to appear to be the processes of "product realization", which I see as one of the Key Processes of your Business Operating System.

I may be mistaken, but it seems you're somehow segregating "The System" and Product Realization, as you've noted in your comment, "QMS processes are on the left with the specifics of the company in the center". In doing so, you have omited some processes which I believe are "key" to the Business Operating System, including:

1) Business Planning
2) Control of Documents and Records
3) Infrastructure and Service Support
(including Control of Building/Workspace, Machine Maintenance, Communication, and Work Environment)
4) Change Control

...sorry, I hadn't finished, and my comments somehow got posted!!...



Again, I believe that the standard is asking for your Business Operating System Processes sequence and interactions (which of course includes Product Realization), but I don't see it as a request for mapping our Product Realization in detail. Yes, it is a high level perspective, but where else are you going to define how the System Works, and not just Prod Realization?

Also...I don't think your sequence is quite right. Following Monitoring, measurement and Analysis, feedback should be fed to Management for Review and for the identification of appropriate Corrective/Preventive Action and/or Continual Improvement.

Actually, you've displayed very well that you understand the mechanism of the system...that is the Plan, Do, Monitor/Analyze, Check, Act cycle. I just think you've thrown Product Realization details in unnecessarily. You've created an excellent model (with a few omissions, as noted above), but you should save the center part for your "Product Realization Procedure".

I'll send you a model directly to demonstrate my perspective.

Patricia

I wouldn't have used a flowchart, since it's not actually showing processes - just a number of things that departments do or need to be done.

What would you have used if not a flowchart?

Isn't that what a process is? A number or flow of things that are done? With inputs and outputs?

You show, for example, your 'control of customer property' and it leads directly to corrective action etc. Really? You don't actually add vaue/process the stuff? I also would ask if your QMS always starts with Management review? Where are the actual business process inputs/outputs?

Really? Do I just have a mental block or what? :frust::frust: Of course there are many other processes that interact with "customer property" before it gets to CAPAs; however, those are at a lower level. And to list those would be to go against what Patricia is saying.

Of course the system doesn't always start with Mgmt review. It's very much circular. I don't think it's the starting point per se but something needs to be at the top or the "starting point" if you want to think of it in those terms.

I thought I had put in the business inputs and outputs. What else is there?

You've described what each department does, not how they work on your processes and, as such, your diagram is flawed.

:2cents:

I'm very much confused by this. How else can you show how mfg works on your processes besides showing that they schedule, mfg, test, track, and all that goes to mgmt for improvement?

I don't mean to come off defensive - I just don't know what I'm not doing or better, how you would show this. do you have an example?

Thank you!

Hello Hrrvett,
The "critical processes" which you refer to appear to be the processes of "product realization", which I see as one of the Key Processes of your Business Operating System.

I may be mistaken, but it seems you're somehow segregating "The System" and Product Realization, as you've noted in your comment, "QMS processes are on the left with the specifics of the company in the center". In doing so, you have omited some processes which I believe are "key" to the Business Operating System, including:

1) Business Planning
2) Control of Documents and Records
3) Infrastructure and Service Support
(including Control of Building/Workspace, Machine Maintenance, Communication, and Work Environment)
4) Change Control

...sorry, I hadn't finished, and my comments somehow got posted!!...



Again, I believe that the standard is asking for your Business Operating System Processes sequence and interactions (which of course includes Product Realization), but I don't see it as a request for mapping our Product Realization in detail. Yes, it is a high level perspective, but where else are you going to define how the System Works, and not just Prod Realization?

Also...I don't think your sequence is quite right. Following Monitoring, measurement and Analysis, feedback should be fed to Management for Review and for the identification of appropriate Corrective/Preventive Action and/or Continual Improvement.

Actually, you've displayed very well that you understand the mechanism of the system...that is the Plan, Do, Monitor/Analyze, Check, Act cycle. I just think you've thrown Product Realization details in unnecessarily. You've created an excellent model (with a few omissions, as noted above), but you should save the center part for your "Product Realization Procedure".

I'll send you a model directly to demonstrate my perspective.

Patricia

Thank you Patricia for your help! I sincerely appreciate it. I look forward to your model. :D

What would you have used if not a flowchart?

Isn't that what a process is? A number or flow of things that are done? With inputs and outputs?



Really? Do I just have a mental block or what? :frust::frust: Of course there are many other processes that interact with "customer property" before it gets to CAPAs; however, those are at a lower level. And to list those would be to go against what Patricia is saying.

Of course the system doesn't always start with Mgmt review. It's very much circular. I don't think it's the starting point per se but something needs to be at the top or the "starting point" if you want to think of it in those terms.

I thought I had put in the business inputs and outputs. What else is there?



I'm very much confused by this. How else can you show how mfg works on your processes besides showing that they schedule, mfg, test, track, and all that goes to mgmt for improvement?

I don't mean to come off defensive - I just don't know what I'm not doing or better, how you would show this. do you have an example?

Thank you!

I would have used a process map. It doesn't deal with binary decisions like you've shown, since business isn't a binary decision making process.

It appears to me that you've simply matrixed the top level requirements of the ISO standard (left hand side) to the departments of the organization across the top, then overlaid the things the departments do. I can't provide any further details without running into a long-winded description. It would be simpler to have a copy and mark it up.

Again, I have to ask - what does your management think of this? If they can't describe what you've got here, then there's little point to us providing a review. There are many other examples posted in other similar threads here.

One key point for me is that you've shown everything being done before anything is sent for Management Review. Everything's analyzed, corrective action, etc taken before reporting up to Management. This isn't what should happen. It's management's responsibility to use the data from the processes etc. to decide on what to improve, reset objectives, policy etc.

Hrrvett,

Here is a copy of the business process map I used in our company's QM. Don't know if it is the best but it is example of another type you could use.
Good luck.

Hrrvett,

Here is a copy of the business process map I used in our company's QM. Don't know if it is the best but it is example of another type you could use.
Good luck.

Nothing personal Andy, but this is one of the worst process maps I've ever seen. It doesn't even begin to explain or elude to how the "Management System" works. Your "Support Functions" appear to be Department names, and not processes. The requirement is to identify the "management processes".

Conspicuously absent from your Model are:
Business Planning
Monitoring Measurement and Analysis
Management Review
Corrective Action
Preventive Action
Continual Improvement
Control of Monitoring and Measuring Devices
Internal Audit
Control of Documents and Records
Change Control
Control of Non-conforming Product and Materials
Materials Management
Infrastructure Support
Employee Competence and Empowerment


I think you need to go back to the drawing board, and focus on the "System" and not on Product Realization. (I won't even get into what's missing from your Product Realization process since it's not pertinent to the discussion).

I can't imagine that you can use this model to train employees or to help them understand how the system works.

I apologize for my candor if it offends you, but my intentions are noble.

Patricia

...I apologize for my candor if it offends you, but my intentions are noble.
Patricia
No offense taken. I enjoy the candor.

Nothing personal Andy, but this is one of the worst process maps I've ever seen... I think you need to go back to the drawing board, and focus on the "System" and not on Product Realization.
Patricia
Ooh, I think you are very close. But I perfer to say we should focus on the "System" and not the process map. And by focusing on the system we should really start with the metrics and use those to focus efforts and drive improvement.

I quite agree that my process map, or flowchart, or whatever you want to call it is lacking and over-simplified. But this is also intentional. You see I've been where Hrrvett has been. I've spent months mapping out entire business processes and in the end they really never contributed much value. Processes continually changed and it became a paperwork exercise to keep up, all the while we were losing focus on the quality of the product being shipped.

I don't want to minimize the importance of process maps and they can be useful tools in root cause analysis. But when it comes to outlining the quality system, I guess my advice would be to keep it simple, make it a page in your QM, but don't spend too much time on it and focus more efforts on measuring and improving.

No offense taken. I enjoy the candor.

...I don't want to minimize the importance of process maps and they can be useful tools in root cause analysis. But when it comes to outlining the quality system, I guess my advice would be to keep it simple, make it a page in your QM, but don't spend too much time on it and focus more efforts on measuring and improving.


Well, what can I add to that? There really is no point in persisting in this rhetoric if your approach satisfies you, your company and your registrar. I just think that it's a loss for your company that you don't have a well-mapped out Business Operating System, and at the same time, I can understand your predilection for the product and the customer.

If done properly, your Business/Management Operating System is relatively static. I created mine 4 years ago, and have yet to change it. The high level documents don't change. Perhaps the subordinate Work Instructions change with increased frequency, but that would not be evidenced in the System Model anyway.

Enough said...I don't give up too easily.

Thanks for putting up with me,
Patricia

Patrica, you woulnt care to share the model you mentioned earlier would you?

I'm particlulary interested in how it has stayed constant for 4 years

I'm currently looking at this for my boss.

Thank you everyone for your comments - they have helped tremendously.

I would like to take the time to discuss Patricia's flow. (I would have done this sooner but I have been quite ill and am just now catching up with things.)

First let me say that I hate to post comments on the board knowing that I cannot share the document and that overall, I may not answer your question. However, I respect Patricia and her property and will try my best to offer what I can.

Second, I've tried writing this post multiple times to include as much detail as possible and to ensure that it is as clear as possible. So please bear with me if it's still not clear - just ask me for clarification. :notme:

Patricia, if I write anything that is contradictory to your model, please correct me.

Patricia's "flow" was quite helpful and gave me a clear global understanding of the quality management system (I hadn't thought of it in those terms previously). She has both a static version (for posting) and an animated version (great for training) that are very professional, both in appearance and meaning.

It is not like most models or flows that you see. (that's a good thing in my mind) So I don't want you to think that you're going to get a "first we have sales, then purch, etc." You won't get that type of a model. Those processes are included in the model but are grouped into higher level processes (i.e., instead of "shipping" or "packaging", you might have "product realization"). It organizes the processes into MOPs, COPs, SOPs and shows how they interact at a very high level. It basically shows how inputs from the organization are fed into management and how they are then fed back into the organization but with more bells and whistles.

In regards to not changing for 4 years, I understand and believe it. The reason is because her model does not go into detail with the lower level processes such as "obtain part #" or "request quote" but rather keeps it high level and refers to processes as "product realization" for example. However, her model does specify the steps for product realization in this instance but generically (this is where some specifics to your company can easily be entered and this may require some minimal change over the years - however, I doubt it unless your company changes operations completely). An example is she may specify "mfg process validation" under product realization as a sub-process but she doesn't go into detail about you first obtain parts, build, test, review, approve, etc. So, a company that does not manufacture would not have "mfg process validation" under product realization but 5 years down the road, they may begin manufacturing and would have to modify the model. Does that make sense?

:topic:just a side note, since her model is very accurate, I am concerned with the fact that many models may technically be an infringement strictly because there are only so many ways one can model the ISO system at a top level. So I'm not sure if I agree with it just like I don't understand why ISO copyrights their info. The fact that most QMs border on infringement does not seem right - honestly, if we're following the system who cares if we used the same terminology. ...in fact, most auditors flip out if you don't use practically the same wording...not the best auditors but many of them... A very black and white view and I know that most QMs shouldn't model the ISO but their company processes but the principle is the same IMO. :2cents: But at the same time, this is Patricia's hard work of many many years so I do not mean to disrespect her at all. I am very thankful that she provided me another way to view the QMS.

Her model does demonstrate sequence as well. I think the animated version demonstrates this more effectively but the static version does as well. Many people have discussed that some flows do not show sequence effectively. I tend to disagree slightly only because it is hard to demonstrate sequence with businesses. Many processes seem to happen interchangeably - one not really coming first or last all the time, sometimes it's even hard to say which one really came first...chicken and egg. However, it is clear in Patricia's model.

I am torn between including a high level model or a mixed level model. I believe I will include both in our QM or integrate them. I believe my company needs to see both how the QMS runs at a system level and at a lower level (sales, then purch, then receiving, etc). I don't really see ISO requiring one or the either just the processes to run an effective QMS. (Sorry Pat, you may disagree with me.) I think the higher level is definitely needed and Pat's model shows this beautifully and the lower level is needed at least at the procedure level and perhaps at the QM briefly. A lot of times, it is hard for employees to look at a high level model and determine what "box" they fit into...that's primarily why I think we might need a mixed level model. (I'm running my version over with Pat to ensure it doesn't infringe on her copyright out of respect but I can't imagine it does - then I will post it.)

Further, I created a model that I felt was a bit more simplistic (doesn't have the whistles) and slightly easier to understand visually; at least for me. I forwarded it to Patricia because it may be infringement of the copyright and I thought I could offer some visual modifications. Perhaps she will allow that one to be shared but that is not up to me.

The bottom line is that I understand Patricia's model and believe that it applies to all companies. It is probably one of if not the best models that I have seen. (I would say the best but I like the one I modified for her better :notme::lol:) It is very valuable information that any company could use.
Is it required for your Quality System to work effectively? Probably not.
Could it help in the understanding of the system and ensuring that it runs correctly? Most likely than not, most definitely. (unless you already share this mentality and then it's just a great visual tool)
Would I adopt it if you're operating an up and running system that is working for your company? No only for the idea of "if it's not broke don't fix it."
Would I adopt it if you're beginning a system or updating it? Definitely.

I apologize for the lengthy post and hope that I have helped.:)

I just wanted to add my mgmt model. (This is not the modified version that I sent to Patricia so please forgive as it is not as visually appealing as I would like.)

There are some changes that I need to make (adding control of NC product, adding change control, moving design and repair to product realization, moving the requirements box out of the customer area, etc) but I wanted to post something sooner than later so that you can see my ideas. I'll post the modified one when its complete after the holidays.

I hope everyone has a great holiday!

I quite agree that my process map, or flowchart, or whatever you want to call it is lacking and over-simplified. But this is also intentional. You see I've been where Hrrvett has been. I've spent months mapping out entire business processes and in the end they really never contributed much value. Processes continually changed and it became a paperwork exercise to keep up, all the while we were losing focus on the quality of the product being shipped.

Andy, I tend to agree with you. I've also spent one heck of a lot of time trying to work on maps & diagrams of a whole system... and seriously questioned the value. These days, I don't waste much a lot of time on it.

Yes, Andy's is a simplified version. But it shows quite smoothly the main flow through to the customer, & what are core business & what are supporting processes (though yes, I'd add in planning & the NC/CA etc as well!). Frankly, I'd rather use simplified diagrams than the ones that try to put the whole kit & caboodle in & become very hard to follow. Any diagram that needs a lot of description to interpret it tends not to be very useful.

I found hrrvet's busy and complicated - I found Andy's refreshingly clear.

Let's not lose sight of the fact that nowhere in 9001 does it actually have a requirement for a process map or a system diagram. Neither of those phrases appear in it anywhere.

There are many ways to meet the requirements for sequence & interaction of processes - eg, references in individual procedures, interlinked IT systems, hyperlinked web docs, etc etc.

Patricia, it is not fair or reasonable IMO to criticise Andy's auditor for accepting this - his auditor is in a position to audit the whole system. We aren't.

I found hrrvet's busy and complicated


I'm not sure what you found complicated - perhaps the whole thing. But I think it's pretty straight forward, ultimately which is all that matters. If you could elaborate, I would appreciate it.

I mentioned that I would repost my tentative "finished product" and here it is. There is some explanation that is probably needed which makes it not so "straight forward" as some but much more comprehensive IMO.

Layout:
The requirements for the QS come in at the top. There are four "key processes": system (SOP2s), mgmt (MOPs), support (SOPs), and customer (COPs). The "system (SOP2s)" encapsulates everything as internal audits and control of doc/records touch everything.

Explanation:
There are sort of two models here. The first is the mgmt level processes, which are the arrows stemming out of the MOPs (blue square). Essentially, data from the SOPs, COPs, and SOP2s (green, pink, and yellow) is fed into the MOPs (mgmt - blue) and then CAPAs are fed back for correction and improvement.

Then, you have the other key processes for the company, not just mgmt. This is shown by the dotted black line. The MOPs and SOPs feed into the COPs which ultimately feed into the customer.

That's sort of the explanation in a nut shell. If you have feedback, I'd love to discuss and improve my model. If you'd like to use it, please do so.

Thanks!

I'm not sure what you found complicated - perhaps the whole thing. But I think it's pretty straight forward, ultimately which is all that matters. If you could elaborate, I would appreciate it.

I mentioned that I would repost my tentative "finished product" and here it is. There is some explanation that is probably needed which makes it not so "straight forward" as some but much more comprehensive IMO.

Layout:
The requirements for the QS come in at the top. There are four "key processes": system (SOP2s), mgmt (MOPs), support (SOPs), and customer (COPs). The "system (SOP2s)" encapsulates everything as internal audits and control of doc/records touch everything.

Explanation:
There are sort of two models here. The first is the mgmt level processes, which are the arrows stemming out of the MOPs (blue square). Essentially, data from the SOPs, COPs, and SOP2s (green, pink, and yellow) is fed into the MOPs (mgmt - blue) and then CAPAs are fed back for correction and improvement.

Then, you have the other key processes for the company, not just mgmt. This is shown by the dotted black line. The MOPs and SOPs feed into the COPs which ultimately feed into the customer.

That's sort of the explanation in a nut shell. If you have feedback, I'd love to discuss and improve my model. If you'd like to use it, please do so.

Thanks!

I think your map is absolutely beautiful...This is one of the best ones I have ever seen....:applause:

Since you asked for feedback.....:2cents:

If I was doing this map, I would reposition the "Management Review" process.

To me, Management Review is one of the most important processes in QMS. I hate Management Reviews that mimic "Staff Meetings." Management Review should align business processes with QMS. MR should align business objectives with quality objectives. It should deepen management commitment and deliver direction and blood flow to the heart of a QMS. Management review is not just an event. The result of MR is synchronized approach to the future of QMS....

This may not be an expressed requirements, but I think of MR as a forum for implanting the continual improvement ...

Fantastic!! Thank You.

hrrvett, two quick questions:

1. Why is "Customer its own input and in with Requirements?

I'd suggest listing them all as inputs...equal to each other.

2. Why is Purchasing a support process?

Even before I accepted the transfer into Procurement, I deemed them a core process. If they don't acquire products as necessary, an organization will have a difficult time finishing the product. And considering how some vendors are key to the process, I'd move Procurement over to a the customer process section. Granted, this may be more of a philosophical discussion.

I found hrrvet's busy and complicated - I found Andy's refreshingly clear.



Many consultants and auditors cannot distinguish between "Flow Charts" and "Process Maps".... Many prefer to read long "how to" procedures than analyze a map...Makes their conformance auditing easy...

Process maps are supposed to be complicated and portray complex management system structure and interactions. Relationships are not always linear...

I found hrrvet's chart refreshingly informative.

hrrvett, two quick questions:

1. Why is "Customer its own input and in with Requirements?

I'd suggest listing them all as inputs...equal to each other.

Good suggestion - THANKS!!


2. Why is Purchasing a support process?

Even before I accepted the transfer into Procurement, I deemed them a core process. If they don't acquire products as necessary, an organization will have a difficult time finishing the product. And considering how some vendors are key to the process, I'd move Procurement over to a the customer process section. Granted, this may be more of a philosophical discussion.

I went back and forth with this one and since our QS is new, we might change it. The ultimate reason why I put in the SOPs is because I think of SOPs as something that is triggered by Mfg, which purchasing would be in my company. The customer doesn't trigger the purchasing process but they do trigger the MFG process.

But you're absolutely right - sort of philosophical. We may change it to a COP but at least you know why I put it where I did. :)

Have a good one!

I think your map is absolutely beautiful...This is one of the best ones I have ever seen....:applause:

THANKS!!

If I was doing this map, I would reposition the "Management Review" process.

To me, Management Review is one of the most important processes in QMS. I hate Management Reviews that mimic "Staff Meetings." Management Review should align business processes with QMS. MR should align business objectives with quality objectives. It should deepen management commitment and deliver direction and blood flow to the heart of a QMS. Management review is not just an event. The result of MR is synchronized approach to the future of QMS....

Fantastic!! Thank You.

I agree. Do you have any specific thoughts where you would put MR or are you just thinking that you would make it more apparent or its own "box?" Just curious to what you think.

Thanks for your feedback!!

THANKS!!



I agree. Do you have any specific thoughts where you would put MR or are you just thinking that you would make it more apparent or its own "box?" Just curious to what you think.

Thanks for your feedback!!

My Pleasure...

I hate to create additional work for you...Your map is so beautiful...Believe me, I also do beautiful maps. My format is different....

I also agree with Roxane and always place Purchasing as a core process on mine.

Please review the input and output of your management review and frame it the way you have framed Internal Audit. I am not familiar with your management review procedure.

Here are input-output to my MR:

MR Input:

Results of Internal Audit and Self Assessments

Results of previous Internal Audit

Follow up Actions from Previous Management Review

Customer Feedback

Customer Requirements

NCMR Performance/Product Conformity Report

Preventive and Corrective Action Status

Potential Changes that could affect the QMS

Improvement Recommendations

Quality Policy and Quality Objectives

Technology Updates

Supplier Performance


MR Output:

Performance Objectives for products and processes

Performance improvement objectives

Organization structure optimization

Plans for Improvement of QMS

Infrastructure Improvement Plan

Environmental and Quality Objectives

Customer Satisfaction Improvement Plan

Improvement Plan for Financial Strength.
I would nest it in the same level or inside of Quality Manual frame.

Thanks for sharing!! As you can see, a well constructed process map is an aid for analysis of QMS effectiveness...

Good Luck

I'm not sure what you found complicated - perhaps the whole thing.

We seem to be talking of 2 different things. My comment was on the High Level QM (Quality Management) Process Map attached to your first post. I don't know that I can 'elaborate' any more - it was simply my reaction to the whole thing.

But you're right - ultimately that you like it is all that matters. But then, if you're already quite happy with it, I don't see really understand why you seek 'review'.

A truely beautiful presentation (and you folks make great product, BTW!)

However, I think there's something fundamentally missing - it's not the way you actually operate! The interaction is not through the management processes from the support processes to the customer processes!

A truely beautiful presentation (and you folks make great product, BTW!)

However, I think there's something fundamentally missing - it's not the way you actually operate! The interaction is not through the management processes from the support processes to the customer processes!

Thanks!

Well, I think perhaps you're looking at it in a slightly different angle than it is meant. The position of the MOPs SOPs and COPs really isn't significant - they just seemed to fit there with all the connections. The MOPs and COPs provide support and input into COPs. Perhaps the sequence isn't defined as well as it could be but this is supposed to be the sequence: (there are really two process models here)
General:
The company operates with the requirements which are integrated into the SOP2s (yellow), which sort of pull the entire system together through the QM, audits, docs/records, etc
Process 1:
Looking in on a company level and not mgmt, that is where the customer processes come in - starts with the customer as the input, goes through the COPs, and then ends with the customer with product output.
Process 2:
Looking at it from the mgmt perspective, the yellow, green, and pink feed into the MOPs basically through Mgmt review and then CAPA/improvements are fed back into the system.

I hope that sort of clarifies it but let me know if you still disagree. ...I want to ensure that this flow is understandable and purposeful.

We seem to be talking of 2 different things. My comment was on the High Level QM (Quality Management) Process Map attached to your first post. I don't know that I can 'elaborate' any more - it was simply my reaction to the whole thing.

But you're right - ultimately that you like it is all that matters. But then, if you're already quite happy with it, I don't see really understand why you seek 'review'.

My mistake. I apologize. I am seeking review because even if you are happy with something, it doesn't mean that it cannot be improved upon.

I guess your document in post #26 is the latest and greatest version.

Thank you for posting it in pdf format. You are very considerate to use an open format for document interchange. I wish more people would do it.

Having said that, I have to say I don't see the value in this process map.

I thought you were trying to show the sequence and interaction of processes. I don't really see a clear link between, let's say, training and repair, for example.

Which process is supplier? Which is customer? What's the feedback loop? If the supplier provides defective product, what's the impact on the customer? Is training a lob-it-into-the-silo effort by HR, or is there collaboration between those who repair and those who provide training?

Perhaps you can explain it, but can you truly call it successful if it requires an explanation? If you explain that there's a connection via the monitoring, measurement and analysis highway, through the land of CAPA and improvement, to the house of training and so on, it's an interesting intellectual exercise, but it doesn't tell me anything about what actually goes on in your organization. In that sense it's way too generic.

Maybe you have lower level graphics or other documents that depict those things. If so, what value does this thing provide?

Sorry to be such a curmudgeon. Perhaps in your environment charts like this have value. If so, be happy with it.

Thank you for posting it in pdf format. You are very considerate to use an open format for document interchange. I wish more people would do it.
No problem!

I thought you were trying to show the sequence and interaction of processes. I don't really see a clear link between, let's say, training and repair, for example.
Well, it's not a high level process. There is a relationship but there are numerous relationships that aren't presented here. I was just trying to capture the high level main ones. Besides, if I were to draw relationships from training to everything in touched, there would be lines to everything. That's why I put it in the support processes which support the COPs, specifically repair in your example. (you do see the little white arrow that feeds into the pink box, right?)


Which process is supplier? Which is customer? What's the feedback loop? If the supplier provides defective product, what's the impact on the customer? Is training a lob-it-into-the-silo effort by HR, or is there collaboration between those who repair and those who provide training?
Well, the supplier is within the "purchasing" process - it's just a lower process, not a high level process, so it's not depicted here. The customer is on the left and right with the huge pink box to support it. The training tid-bit I mentioned above.

Perhaps you can explain it, but can you truly call it successful if it requires an explanation? If you explain that there's a connection via the monitoring, measurement and analysis highway, through the land of CAPA and improvement, to the house of training and so on, it's an interesting intellectual exercise, but it doesn't tell me anything about what actually goes on in your organization. In that sense it's way too generic.
Well this is the process map in the Quality Manual to comply with 4.2.2 c. It's sort of got to be a bit generic, otherwise, you get into too much detail which should really be housed in procedures. The MMA / CAPA is really Management Review. How do you show how mgmt interacts with your system in your QM? And the COPs are where the specifics come in - not really generic - but they are commoningly found in other companies just because they do perform the same high level functions. Does that make sense?

I appreciate your feedback and perhaps I've clarified some things. ???

Do others feel that this is a waste? If so, how do you comply with 4.2.2 c?

No problem!

Well, it's not a high level process. There is a relationship but there are numerous relationships that aren't presented here. I was just trying to capture the high level main ones. Besides, if I were to draw relationships from training to everything in touched, there would be lines to everything. That's why I put it in the support processes which support the COPs, specifically repair in your example. (you do see the little white arrow that feeds into the pink box, right?)
Exactly my point about this chart being too generic.

Well, the supplier is within the "purchasing" process - it's just a lower process, not a high level process, so it's not depicted here. The customer is on the left and right with the huge pink box to support it. The training tid-bit I mentioned above.
Perhaps I was a bit unclear. What I meant was, between the training process and repair process, which is the supplier and which is the customer? And so on. All these questions apply to the relationship between these two processes.

Well this is the process map in the Quality Manual to comply with 4.2.2 c. It's sort of got to be a bit generic, otherwise, you get into too much detail which should really be housed in procedures. The MMA / CAPA is really Management Review. How do you show how mgmt interacts with your system in your QM? And the COPs are where the specifics come in - not really generic - but they are commoningly found in other companies just because they do perform the same high level functions. Does that make sense?
How about Old Fashioned Text (OFT)? You could easily capture the level of detail in this chart in one or two well-chosen paragraphs. I would venture to say you could hone those paragraphs to perfection in far less time than you have spent on this chart so far.

Or if you want to have charts that say something meaningful and specific to your organization, create them and incorporate them into your manual by reference.

Graphical depictions work best where there is a true sequence of events. Product realization is a good example.

Relationships between support processes and the value stream are often not sequential. Calibration is a good example, because calibration usually occurs on a schedule, regardless of events in the process that uses the instruments. In these cases, a narrative or tabular approach may better describe the interaction between processes and probably entail less effort.

Someone will no doubt point out that an instrument failure should trigger a reaction in the process for control of measuring devices, thereby creating a sequence of events. While acknowledging the truth of this statement, I would claim that it would be a lot less work to describe this kind of process interaction using OFT rather than a chart.


I appreciate your feedback and perhaps I've clarified some things. ???

Do others feel that this is a waste? If so, how do you comply with 4.2.2 c?Waste is perhaps too strong a word, but I don't think you're getting much value for the time you have spent on this graphic.

If you want a lesson in graphical depiction of information, check out this link.
http://en.wikipedia.org/wiki/Wikipedia:Featured_picture_candidates/Napoleon's_Invasion_of_Russia (http://en.wikipedia.org/wiki/Wikipedia:Featured_picture_candidates/Napoleon%27s_Invasion_of_Russia)

Waste is perhaps too strong a word, but I don't think you're getting much value for the time you have spent on this graphic.

If you want a lesson in graphical depiction of information, check out this link.
http://en.wikipedia.org/wiki/Wikipedia:Featured_picture_candidates/Napoleon's_Invasion_of_Russia (http://en.wikipedia.org/wiki/Wikipedia:Featured_picture_candidates/Napoleon%27s_Invasion_of_Russia)

Well I still don't understand half of the processes with supplier and repair and training, etc you are referring to. That does not need to be depicted here. However, I noticed that you didn't post any of the ways in which you are complying to ISO. (not to say that I don't want feedback)

I think you are too concerned with showing lower level processes and their sequence which should not be displayed in the QM. Those flows will be represented in procedures or work instructions but not the manual. I think your theory is incorrect.

Well I still don't understand half of the processes with supplier and repair and training, etc you are referring to. That does not need to be depicted here. However, I noticed that you didn't post any of the ways in which you are complying to ISO. (not to say that I don't want feedback)

I think you are too concerned with showing lower level processes and their sequence which should not be displayed in the QM. Those flows will be represented in procedures or work instructions but not the manual. I think your theory is incorrect.

:yes:

Let me share one of early experiences in my career that changed the way I think and approach situations...

Picture this :evidence: ...1982...Oil Crisis...Layoffs... business contraction...I ended up reporting to Sr. VP after 2 years of experience (became the acting Manager of Manufacturing Engineering :cool: ). I was at the same level as the directors and VP of manufacturing. One day, the VP of Quality walks to my bosses' office and hands him a 50+ page quality report (we did not use PC or emails back then..all charts were done by hand). My boss says "Thank You." He then places the report in his trash can. The Quality director objected to his action. My boss told him:"I know what this report is...Get back with me when you can shrink this in 1/2 page."

My point is: Higher level reports and maps do not need details. Details belong to lower level...

When I design my QMS, my first map aligns business processes with QMS and ISO. My starting point is "Business Planning." The ending point is "Continual Improvement." I then choose critical processes and map them out, identifying the details to a certain level. For third level, I zoom and construct a turtle....

A CEO does not need to see how non conforming material process or RMA ties to CAR or document control.

The first map I ever posted, portrayed high level sales strategy and was butchered by auditors in this forum...They questioned the accuracy and usefulness...That particular map was praised by my mentor and is being used and proved effective...

I personally think you have too many details for top level map (unless they are micro/nano managers)... Your map should be used by top management and customers (top management) and they simply need a city map and not turn by turn map.

When you are approaching top management, try to shrink/contract your conversation/report/material to less than 2 minutes...For those 2 minutes need to cover what normally takes place in one/two hours management meeting...

Good Luck!!!!!!:agree1:

Well I still don't understand half of the processes with supplier and repair and training, etc you are referring to.
Okay. Does it help if I say:
Upstream process instead of internal supplier
Downstream process instead of internal customerOr --
Process that provides inputs instead of internal supplier
Process that uses outputs instead of internal customerHowever, I noticed that you didn't post any of the ways in which you are complying to ISO. (not to say that I don't want feedback)
How about these two paragraphs that I wrote in the middle of my post:How about Old Fashioned Text (OFT)? You could easily capture the level of detail in this chart in one or two well-chosen paragraphs. I would venture to say you could hone those paragraphs to perfection in far less time than you have spent on this chart so far.

Or if you want to have charts that say something meaningful and specific to your organization, create them and incorporate them into your manual by reference.

I think you are too concerned with showing lower level processes and their sequence I hate to see people waste time on generic fluff when they can spend time on something of actual value.
which should not be displayed in the QM. Why not? If you were run over by a beer truck, which charts would be of more value to your successor? Cookie-cutter charts that could fit any organization or charts that describe what actually goes on in your organization?

Those flows will be represented in procedures or work instructions but not the manual. I think your theory is incorrect.I think you don't know my theories about quality manuals. One is the beer truck theory. It goes like this: if the management rep gets run over by a beer truck, the quality manual should contain enough information so the new management rep can get up to speed quickly.

Another is the KISS theory.

According to my theories, the quality manual adds value in terms of continuity. It can also help the management rep should he forget some detail about the QMS. A simple quality manual costs the organization less because it's easy to understand. People may actually read a simple quality manual.

:yes:

Let me share one of early experiences in my career that changed the way I think and approach situations...

<big snip>

When you are approaching top management, try to shrink/contract your conversation/report/material to less than 2 minutes...For those 2 minutes need to cover what normally takes place in one/two hours management meeting...

Good Luck!!!!!!:agree1:

Good post. No disagreement here.

Here's my problem with the chart in question: all of the information on it could be conveyed in three short sentences along with two bulleted lists and one numbered list.

The result would be less work to create, occupy less space on the page and be easier to understand.

When Lou Gerstner became president of IBM, he refused to allow Powerpoint presentations into his meetings because people were spending too much time on eye candy and not enough time on content. That's how the chart in question makes me feel.

Good post. No disagreement here.

Here's my problem with the chart in question: all of the information on it could be conveyed in three short sentences along with two bulleted lists and one numbered list.

The result would be less work to create, occupy less space on the page and be easier to understand.

When Lou Gerstner became president of IBM, he refused to allow Powerpoint presentations into his meetings because people were spending too much time on eye candy and not enough time on content. That's how the chart in question makes me feel.

Cliff,
If you think eye candy is bad, please consider necessity of balancing right brain and left side of brain. I use eye candy because I am an artist and an analytical scientist. Without color, I doze off....
:paint:
Let me share one of my maps....
:cool:You may need your sun glasses...:lmao:

I am attaching a simple one I call them IPOMs (Input-Process-Output Maps)... This is MY FORMAT...It is not a flow chart. In my IPOMs, you rarely see a decision box branching, unless it is a MAJOR one...Horizantal sections represent a simplified "turtle".
My IPOMs are gated and structured based on PDCA...I may change them later to DMAICR...

This map was constructed to depict "Continual Improvement" road map of RMA process.

Do others feel that this is a waste? If so, how do you comply with 4.2.2 c?

Yes. (And I bet that raises a storm of protest).

4.2.2c does NOT mandate any diagram nor a process map.

These days I very rarely bother with a 'process map' or a 'system diagram'. Unless my client has a preference for graphic representation, I rarely find that the time & effort involved is worth it.

Plus, people have different ways of 'modelling' or representing things. Your model suits you but you may loathe one of mine, and vice versa. I hate the fact that the customer turns up in 2 separate places in the classic ISO 9001 model, for example.

It's possible at times that the process of doing it is a valuable activity in itself. Again, I have very rarely found that with the clients I've worked with - but that may also be associated with the types of clients, systems and fields I've had.

I've now pretty well stopped doing 'process maps' or 'system diagrams' - the clients rarely see the point and don't get value from them. So they're not worth the time (& thus my cost). I most often these days use either words (eg, short description of management processes, specific references within procedures to other procedures) or a very simple generic type of diagram. And if I came across an auditor absolutely insisting on a 'process map'... I'd find another auditor (or certifier), frankly.

The strength of the debate on this topic is interesting - some people express strong preference for a particular posted diagram/map/representation, while others express strong criticisms. You certainly can't make everyone happy!

[QUOTE=michellemmm;230024]Cliff,
If you think eye candy is bad, please consider necessity of balancing right brain and left side of brain. I use eye candy because I am an artist and an analytical scientist. Without color, I doze off....
:paint:
Let me share one of my maps....
:cool:You may need your sun glasses...:lmao:


:bigwave: That's my sort of visuals!

I work in a community services area and some of the process or procedure documentation I help our staff with needs to be visual or colorful. Some staff are fantastic in delivery of service to our "customers" but often are not big on the technical detail like paperwork or documents so this sort of visual works for them.

Also some of our "customers" may be disadvantage youth or people with a disability. Putting the "eye candy" in documents that they need to read or understand really helps.

Our high level QMS "map" doesn't have any pics but is a colorful visio diagram. Our board and management team find it easy to understand how everything fits and connects within the whole organisation with this type of visual. We are a diverse organisation with a number of quality standard requirements not just ISO so I find this helps piece it all together.

So to echo some other comments, what works for our organisation may not be suitable in another environment but I don't think that makes any one type more "right" (or wrong for that matter), it just means you need to take into account your audience as well.

cheers

<snip>
So to echo some other comments, what works for our organisation may not be suitable in another environment but I don't think that makes any one type more "right" (or wrong for that matter), it just means you need to take into account your audience as well.

cheers

Quite right. I'm glad you found a solution that works for the organization.

That said, I would add some considerations:

First, graphics cost more than text to deliver any given payload of information. They take more time to polish and get right. An excellent example is the graphic that launched this thread. It's on its third iteration, and you can see the huge amounts of labor that have gone into getting it into its current state. The same information could have been conveyed in three short sentences, two bulleted lists and one numbered list. The text could have been written in much less time than needed to revise the chart.

Given that, it doesn't make sense (to me at least) to jump into a lot of diagramming when creating QMS documents, unless there's a compelling reason, such as yours.

Second, not everyone has the talent that allows you to create great charts. In fact, I would that your talent is very rare. I've seen plenty of examples and most are, well, just wretched. Most other Covers with broad exposure to lots of organizations (auditors, consultants, trainers) share my opinion, if the comments that I have read are any indication (and I think they are.)

What does that mean? Well, let's say you've created a great set of flow charts for your organization and you move on because you win the lottery or get run over by a beer truck. Who will maintain these charts? Chances are very good that the organization does not have someone with your talent and the charts will not be well maintained.

Second, not everyone has the talent that allows you to create great charts. In fact, I would that your talent is very rare. I've seen plenty of examples and most are, well, just wretched. Most other Covers with broad exposure to lots of organizations (auditors, consultants, trainers) share my opinion, if the comments that I have read are any indication (and I think they are.)

What does that mean? Well, let's say you've created a great set of flow charts for your organization and you move on because you win the lottery or get run over by a beer truck. Who will maintain these charts? Chances are very good that the organization does not have someone with your talent and the charts will not be well maintained.


Good points Cliff,

I think we often spend too much time recreating things our predecessors have done "their way" (sometimes the written docs you inherit too) and I acknowledge I am adding to the problem for whoever follows me.

I suppose as a lone quality support person within the organisation I do what works for me and delivers for my internal customers. Many only have documented procedures the good old way and that suits them.

I would be happy if things were just documented using Plain English but there's a whole other topic that's dear to my heart :D

again thanks for posing your questions :agree1:

Cheers
Wendy

I'm not sure what you found complicated - perhaps the whole thing. But I think it's pretty straight forward, ultimately which is all that matters. If you could elaborate, I would appreciate it.

I mentioned that I would repost my tentative "finished product" and here it is. There is some explanation that is probably needed which makes it not so "straight forward" as some but much more comprehensive IMO.

Layout:
The requirements for the QS come in at the top. There are four "key processes": system (SOP2s), mgmt (MOPs), support (SOPs), and customer (COPs). The "system (SOP2s)" encapsulates everything as internal audits and control of doc/records touch everything.

Explanation:
There are sort of two models here. The first is the mgmt level processes, which are the arrows stemming out of the MOPs (blue square). Essentially, data from the SOPs, COPs, and SOP2s (green, pink, and yellow) is fed into the MOPs (mgmt - blue) and then CAPAs are fed back for correction and improvement.

Then, you have the other key processes for the company, not just mgmt. This is shown by the dotted black line. The MOPs and SOPs feed into the COPs which ultimately feed into the customer.

That's sort of the explanation in a nut shell. If you have feedback, I'd love to discuss and improve my model. If you'd like to use it, please do so.

Thanks!

Just one question, I see that Internal Audits are in the yellow system area, I can't see where Corrective & Preventive Action and Cont Imp "flows" from Internal Audits to delivery areas. If audits pick up on C&PA or identify how things could be improved how does that interact??

To me it looks like C&PA is moving from the inside out to the audit area??? or have I misunderstood this altogether :confused:

Thank you for posting this, I have enjoyed the discussion and following your thought and the responses.

Having been fortunate to see Patricia's model and how she lays out a process I think we all need t otake a step back and remember that the QMS is not about making widgets, its about managing a business which delivers what a customer wants at a price which means they'll keep buying and we'll still be around!

The broad overview of Patricia's model shows clearly the interaction of the key process that enable a busienss to function.

I would change the "customer oriented process" name to Product or Service depending on the client as imho all processes are be customer facing. also perhaps change control should be more a system oriented process as the change relates to the documentation/controls the output of which is the correctwidget/service.

The clear information flow and the use of colour in the process layouts - there is one posted on another thread - clearly show how a top level process works.

ISO9000 is about the system and processes that create a satisfied customer - not about making correct widgets. The correct widgets are a consequence of the management decisons in using the information around them - fro mthe results of the 12 process Patricia has in her model.

I have a lot of work to do to move from over 200 documents in a 80person company to 12 key process and a few more below...whilst maintaining the output and quality..:rolleyes:

Having been fortunate to see Patricia's model and how she lays out a process I think we all need t otake a step back and remember that the QMS is not about making widgets, its about managing a business which delivers what a customer wants at a price which means they'll keep buying and we'll still be around!

The broad overview of Patricia's model shows clearly the interaction of the key process that enable a busienss to function.

I would change the "customer oriented process" name to Product or Service depending on the client as imho all processes are be customer facing. also perhaps change control should be more a system oriented process as the change relates to the documentation/controls the output of which is the correctwidget/service.

The clear information flow and the use of colour in the process layouts - there is one posted on another thread - clearly show how a top level process works.

ISO9000 is about the system and processes that create a satisfied customer - not about making correct widgets. The correct widgets are a consequence of the management decisons in using the information around them - fro mthe results of the 12 process Patricia has in her model.

I have a lot of work to do to move from over 200 documents in a 80person company to 12 key process and a few more below...whilst maintaining the output and quality..:rolleyes:

Hello Cdagnan,
I appreciate your comments and feedback regarding my Management Operating System Model. Input from others is a wonderful stimulus for Continual Improvements.

Re: "Customer-oriented" vs "Product-oriented" Processes

I agree with you...I've just tried to stay, (somewhat) within the confines of the COP, SOP, and MOP groupings recommended by the ISO guidance documents.

Re: Change Control

...without seeing the Procedure, I too might have thought it was about Changes relating to the Operating System, and therefore should be grouped with the "System-oriented Processes". Actually my procedure on system document management (SOP-0002 Control of Documents and Records") includes document changes within its scope.

The "Change Control" in the "Customer-oriented Processes" in my model actually relates to changes in the product, as initiated internally or externally by customers and suppliers, and so relates to the process of review, approval and implementation (including PPAP for automotive companies), of product changes. In the interest of clarity, it should perhaps be renamed "Product Change Control". Thanks for pointing that out.

(I've been planning to add a narrative to the Powerpoint presentation to remove that type of ambiguity. Typically people don't see it without a narration from me).

If I might suggest, the process of "restructuring" your system doesn't have to happen over night. You might begin by assigning each of your existing documents to a "Parent" procedure, and you'll probably find that most of them are subordinate "Work Instructions", which may need little editing...just appropriate linking to other documents.

Thanks again for the feedback.
Patricia Ravanello

Hi Hrrvett,
looks good to me, maybe a link to KPIs ??
Cheers

hrrvett ,

Would it be possible to get a .doc copy of your process?

Normma