Here I go again with another question.....
I am working on the process flow for ISO-9001:2000 and I just want to make sure I am doing this correctly. Something tells me that I am not....

My process map is not very detailed at all. We determined that all our "detailed" processes are actually our procedures. So why have them in two places (I can probably call out each procedure next to each process in the map, but I have not done that yet.

Our rough draft process map shows the customer giving us the order, us processing the order (not any detail there, literly it says "Receive Requirements from Customer via quote request, Sales w/ Mgmt perform contract review"). Then the map goes into basic Project Management, then Mech / Controls Design, etc.

Can a process map be this simple? We also have an old Process map the quality personnel before me did that is 36 pages long in VISIO. I think that is too detailed.

Looking on the cove I have seen every extreme. I guess, I am asking if just showing the "bare bones" process an order goes through our company, is that enough?

Everyone here has already provided me with valueable input on some other items I have going on. I appreciate it all! One day I am hoping to get to that Guru status :) too..... for now, I just need some solid help. :nopity:

are you doing a process map for Lean or trying to fulfill requirements for Interrelation of Processes

The short answer is "It depends." It depends on the purpose of the process map, and who are the users. If the map meets the needs of the users, then it works.

If its for the interelation of processes then you are doing it correct

Attach an example and some folks here will take a look at it. Print it out as a pdf or gif file or something. Some folks may have Visio - I don't and can't remember if SmartDraw will open Visio files.

are you doing a process map for Lean or trying to fulfill requirements for Interrelation of Processes

I am doing it for 9K2K, where it says "The organization shall establish , document, implement and maintain a quality management system and continually improve its effectiveness in accordance with the requirements of this International standard. The organization shall b) determine the sequence and interaction of these processes".

I don't have in my process map anything about continuous improvement, Management Commitment, Measuring & monitoring... Control of Customer product, nonconforming material......

So, I just have the "bare bones" of what our company does. But I figured all my procedures covered the above items.

I just have a feeling I am way off... Don't have much help here at my job. :thanx:

Attach an example and some folks here will take a look at it. Print it out as a pdf or gif file or something. Some folks may have Visio - I don't and can't remember if SmartDraw will open Visio files.

I pulled the VISIO Document into word. (Let me know if anyone is having a hard time opening this one.) I hope that this works! Please note that this is a VERY ROUGH Draft. I know that it does not follow much of any kind of set-up. It was us just getting our ideas out.

Thanks again for everyone's help! :agree1:

I don’t think you can have too many flow charts, but they can be too big and/or too detailed. Having several different flow charts with different levels of detail is the method we chose. Our QM has a high-level flow chart, like you’ve described, that references our procedures. Then, many of our procedures contain more detailed flow charts.

Your approach sounds like a good one and the idea of listing the procedure within the process symbol would be very helpful for someone trying to learn about your system. If you have an electronic system, try hyper-linking from the flow chart symbols to the related procedures or other flow charts.

I may have over-simpified...but here's what I did to meet the requirement (attached). I simply copied the process model out of the standard and placed our tier one document numbers in each section of the model.
I then placed the model in our Quality Manual, in a section titled "Process Relationships". I further supported it with a matrix that showed each document's relationship to the standard. Nothing wrong with the way you are doing it that I can see. Just another idea.

I may have over-simpified...but here's what I did to meet the requirement (attached). I simply copied the process model out of the standard and placed our tier one document numbers in each section of the model.
I then placed the model in our Quality Manual, in a section titled "Process Relationships". I further supported it with a matrix that showed each document's relationship to the standard. Nothing wrong with the way you are doing it that I can see. Just another idea.
Kimloree,

Welcome to the cove. This is an excellent idea and everyone could achieve it for their document map but does it truly show the processes?

Kimloree,

Welcome to the cove. This is an excellent idea and everyone could achieve it for their document map but does it truly show the processes?

It is a very good idea. We tried a variation of this idea by showing inputs and outputs. This gave a better understanding of how each process relates to all the others.

Jaime

Kimloree,

Welcome to the cove. This is an excellent idea and everyone could achieve it for their document map but does it truly show the processes?

Greg,
I don't know if it fully met the intent of the requirement...but I got away with it (AS9100 certified in Feb. 2004 by DNV).
I did support it with a matrix of each of the Tier 1 (process level) documents that showed the relationship between the individual documents and each area of the standard that they address. I also made it a requirement to include a process flow diagram in each of the documents themselves. And...I created a document tree that shows how the documents tier down for each element of the standard. But all in all, they only thing that I really had to show the "Interrelationship", was the model.

Wow, everyone has been very helpful. I feel better now that I am pretty much on the right track and not way off the track.

I would still love to hear more ways people have done their process maps, and if they feel that I am close with how I started my process map.

Although I have been in Quality for 7 years now, I never have been "in-charge" of implementation of the entire system. It just is nice to know that you aren't way, way off in how you are interpreting the standard :)

I would still love to hear more ways people have done their process maps, and if they feel that I am close with how I started my process map. Sure. Here is our process overview...

/Claes

I am going to revise ISO 13485 to 2003 version. I am thinking of having two flow charts. One is product or service related. It starts from customer requirements and leads up to the customer satisfaction survey.

The other flow chart is going to be system oriented. It starts from data inputs and through corrective actions it leads to continual improvement.

First I will complete all my processes and procedures and then I will integrate them into these flow charts. This will cover the requirements of the standard and it will let me organize and improve my processes as well.

What I did was create a process interaction diagram like a major overview - then I broke it down into more detail by creating the "Business Planning & Management Review" diagram and the "APQP and Product Realization" diagram.

All three diagrams are in the attachment; I also left the list of level II procedures so you can see what I referenced in the diagrams. Hope these are helpful.

Michelle, I know how you feel - just wanting to make sure you're not way off - I wish I had known of the cove when I first became "in-charge" of implementation. I'm sure you'll be great!! My Process Interaction Diagram is a modified version of one I found on-line google searching; the Business Planning and Management Review Diagram is a modified version of one I found here in the cove (thanks Garry :D ), and the APQP and Product Realization Diagram is one I created entirely from scratch.

Michelle, I know how you feel - just wanting to make sure you're not way off - I wish I had known of the cove when I first became "in-charge" of implementation. I'm sure you'll be great!!

Cari, thanks for the words of inspiration! These days, I sure can use it. Your process interaction map and supporting docs really are a excellent example for me too.

The cove has been great! and all the knowledge out here is outstanding. :bigwave:

I may have over-simpified...but here's what I did to meet the requirement (attached). I simply copied the process model out of the standard and placed our tier one document numbers in each section of the model.
I then placed the model in our Quality Manual, in a section titled "Process Relationships". I further supported it with a matrix that showed each document's relationship to the standard. Nothing wrong with the way you are doing it that I can see. Just another idea.Here is another approach. Start with what the business does. The attached has slight similarities to the ISO model but I wanted to write the system for my consultancy company around what we do and in words we use.

I haven't got to the stage of formalizing procedures - not sure under the new approach if there is any benefit. But if we need any more than the "6" I will link them from the process in the diagram - no reference to the clause of ISO they relate to but I may put a cross reference in place somewhere if we want to go for third party assessment.

HELLPP ... I've searched your site and perhaps some of you may be aware of where I might find this info or have some type of template that I can use as a starting point - although each company and process is different - I am trying to implement process auditing structure versus "standards" auditing to my internal audit procedure - is there something which would list for example "purchasing" and then if this process is audited what "standards" it will "hit" during the process ... I can do it manually but if I had something basic I can expand on it would save me time. Thanks, Karen

HELLPP ... I've searched your site and perhaps some of you may be aware of where I might find this info or have some type of template that I can use as a starting point - although each company and process is different - I am trying to implement process auditing structure versus "standards" auditing to my internal audit procedure - is there something which would list for example "purchasing" and then if this process is audited what "standards" it will "hit" during the process ... I can do it manually but if I had something basic I can expand on it would save me time. Thanks, KarenI attached one here ISO 13485 Process Matrix.doc (http://elsmar.com/Forums/attachment.php?attachmentid=4756) for ISO 13485. There are other variations attached in the files list (http://elsmar.com/Forums/fileslist.php). You will have to do some searching in the list. They may not match your processes, but you will have a starting point.

Hi - i am new to ISO 9001 and am having difficulties organizing what I need to do - there is so much info out there, it's a bit overwhelming, but so far this site has been a Godsend!

I do not have a background in this and we are a small company of about 7 employees - essentially we sell a cost-savings program to OEMs for purchasing semiconductors, therefore, we also physically buy an sell the product for them.

I have a question about processes:

My understanding is I do not have to document my entire company's way of doing business, but only areas that affect quality, such as supplier verification, purchasing, inspecting, inventory holds, ESD, shipping, invoicing, etc. I am assuming I do not need to layout processes and procedures for landing accounts or contract signing, etc. Is this true?

What I am currently beginning with is analyzing our processes as it relates to the customer - it essentially goes from quoting to procurement to inspection to shipping etc. Then laying out the procedures that support them, and so on. Please let me know if this seems to be on the right track. Much appreciated!

I may have over-simpified...but here's what I did to meet the requirement (attached). I simply copied the process model out of the standard and placed our tier one document numbers in each section of the model.
I then placed the model in our Quality Manual, in a section titled "Process Relationships". I further supported it with a matrix that showed each document's relationship to the standard. Nothing wrong with the way you are doing it that I can see. Just another idea.


That's a nice diagram of your documented system, but what does it do to define your processes, sequences, interactions, criteria for effectiveness, and metrics? That would be what the process approach in 4.1 calls for? Confused...

Some free samples from ISO site.

So above and beyond the overall QMS process map to satisfy 4.1. Are there other process maps REQUIRED by the ISO/TS 16949 standard? 8.2.3.1 Mentions a process flow diagram is implemented.
I ask this because we are being in the process of prepping for certification. We have a nice overall process map of the QMS, but some people feel that standard requires COP, MOP and SOP should have one! What is the minimum requirement?

Thanks!!!

...
I have a question about processes:

My understanding is I do not have to document my entire company's way of doing business, but only areas that affect quality, such as supplier verification, purchasing, inspecting, inventory holds, ESD, shipping, invoicing, etc. I am assuming I do not need to layout processes and procedures for landing accounts or contract signing, etc. Is this true?

What I am currently beginning with is analyzing our processes as it relates to the customer - it essentially goes from quoting to procurement to inspection to shipping etc. Then laying out the procedures that support them, and so on. Please let me know if this seems to be on the right track. Much appreciated!

Well I am of the opinion that if you are doing something in your business it should be governed by quality principles. A quality management system is not just for product or services but for the whole system with in your company. If you have things that happen in your company that are not in some way related to your product or service why are you doing it?
You should have and do have procedures for landing accounts and contract signing, they just might not be formalized as of yet.
Many of the issues you face down the road are directly related to how the original contract and accounts have been understood and setup. You and the customer need to be clear as to what the agreements are.

IMHO,
Mark

My understanding is I do not have to document my entire company's way of doing business, but only areas that affect quality, such as supplier verification, purchasing, inspecting, inventory holds, ESD, shipping, invoicing, etc. I am assuming I do not need to layout processes and procedures for landing accounts or contract signing, etc. Is this true?

What I am currently beginning with is analyzing our processes as it relates to the customer - it essentially goes from quoting to procurement to inspection to shipping etc. Then laying out the procedures that support them, and so on. Please let me know if this seems to be on the right track. Much appreciated!

Do you need to document these things? No. But there should be standardized processes and procedures for such activities. Read 4.2.1 (d) "...documents needed by the organization to ensure the effective planning, operation and control of its processes..."

If the lack of documentation would adversely impact the these three items, you might wish to consider developing a document.

But if you can demonstrate that there are consistent results of a process, you don't need to go all document-happy. :) It all boils down to having a standardized method...if Person A and Person B perform the same way and acheive the same results, you've standardized the process.

So above and beyond the overall QMS process map to satisfy 4.1. Are there other process maps REQUIRED by the ISO/TS 16949 standard? 8.2.3.1 Mentions a process flow diagram is implemented.
I ask this because we are being in the process of prepping for certification. We have a nice overall process map of the QMS, but some people feel that standard requires COP, MOP and SOP should have one! What is the minimum requirement?

Thanks!!!


TS or ISO do not REQUIRE any process maps. To my knowledge, the term does not appear in the standard. It DOES require you to define your processes, their sequences and interactions (defined in the Rules as inputs and outputs). This is found in clause 4.1.

Process maps, flow charts, illustrations or Turtles are all acceptable formats to attempt to describe these items.

Cl 8.2.3.1 does not deal with process maps, it discusses process performance. In QS, it was element 4.9.2.

Cl 8.2.3.1 does not deal with process maps, it discusses process performance. In QS, it was element 4.9.2.

I do see the line in the second paragraph that states in 8.2.3.1 "The organisation shall ensure that the control plan and process flow diagram are implemented, including adherence to the specified..."
We haved never paid much attention to it and have never gotten written up for it either. But it is a shall requirement... I can see where the confusion stands because even though the standard does not mention process maps, everyone is sure posting them like crazy to meet 4.1

Good luck!

I ended up redoing ours last year, because our auditor, correctly, thought it was way too generalized for our business. I ended up using two circles. The outer circle started with the customer and ended with the customer. As it goes around (clockwise), it picks up the processes involved in what our business/qms does in its everyday life of supplying a product to the customer. The inner circle picks up MA and I with continual improvement activity also. The departments/processes in the business/qms are shown in a key on the map, and each one is shown in the proper sequence of the flow. All together, it shows how our business/qms flows and how each department/process fits in to that, from customer order to customer feedback after receipt of order.

I like doing this with a chart, as it gets the message across pretty well, and I tend to get pretty verbose when doing written descriptions of anything :lol: .

Do you need to document these things? No. But there should be standardized processes and procedures for such activities. Read 4.2.1 (d) "...documents needed by the organization to ensure the effective planning, operation and control of its processes..."

If the lack of documentation would adversely impact the these three items, you might wish to consider developing a document.

But if you can demonstrate that there are consistent results of a process, you don't need to go all document-happy. :) It all boils down to having a standardized method...if Person A and Person B perform the same way and acheive the same results, you've standardized the process.
:thanx: Thank you for your help! I had already begun the process of documenting everything from start to finish, then just wanted to make sure. I have included a copy of my overall process map if anyone cares to critique (be kind!). From here I have started to breakdown each area to include more detailed processes and then procedures to follow. I just want to know if this is heading in the right direction....

I do see the line in the second paragraph that states in 8.2.3.1 "The organisation shall ensure that the control plan and process flow diagram are implemented, including adherence to the specified..."
We haved never paid much attention to it and have never gotten written up for it either. But it is a shall requirement... I can see where the confusion stands because even though the standard does not mention process maps, everyone is sure posting them like crazy to meet 4.1

Good luck!


As I mentioned in the previous reply, Cl 8.2.3.1 discusses mfg. process performance. The reference to control plan and process flow diagram refers to the flow diagrams required by QS as part of APQP. Just note the context - 8.2.3 and 8.2.4 deal with monitoring and measuring processes and products.

The many different approaches to process maps, process flowcharts and such derives more directly from the requirement in cl 4.1.a and cl 4.1.b, where we are required to define the processes in our QMS, along with the sequence and interactions.

To most Engineers, that phrase "sequence and interactions" automatically connotes flowcharts and process maps. It is certainly a good approach, but the standard leaves it to each organization to decide what format to take.

This is really funny. Our organisation went on a process map rampage. We had them coming out of our ears, we had corporate training on business process model notation and Visio....and you know what, the only maps people look at is the overall quality systems flow, and the people that look at them are 3rd party auditors or SQE's doing 2nd party audits.
My suggestion is to go with the overall systems map and then let people draw them up as they see fit. Don't make it requirement for all departments to do a process map, rather leave it up to the individual departments otherwise you will soon have food for external findings.

This is really funny. Our organisation went on a process map rampage. We had them coming out of our ears, we had corporate training on business process model notation and Visio....and you know what, the only maps people look at is the overall quality systems flow, and the people that look at them are 3rd party auditors or SQE's doing 2nd party audits.
My suggestion is to go with the overall systems map and then let people draw them up as they see fit. Don't make it requirement for all departments to do a process map, rather leave it up to the individual departments otherwise you will soon have food for external findings.

That's a pretty good observation, IMO. We HAVE done process maps for a couple of departments, but these are made by the people who run the department/process, with some limited guidance from me. I think this CAN be a nice tool for getting the managers to look at what they are doing on a daily basis, when they have to actually map it out. It CAN be an educational exercise. But no one else but me and the registrar auditors actually look at it afterwards. So we don't make everyone do it for their department/process.

Michelle,
Looks fine to me. Can it be too simple? No, not in my opinion. Quantity does *not* equal quality. Dont' let the fact that the previous version was umpty pages long get in your way. It's harder (believe it or not!) to simplify than to complicate.
Only some minor suggestions: you could make it clearer & simpler by removing some of the word repetition in boxes (eg, within scope over & over). Also, you might *consider* only, 'greying' out boxes done by customer, to make clear what happens in your company & outside it.
Final point: you might consider replacing specific titles with broad functions. That way , if titles change, the flowchart doesn't have to.
Looks like you're well on the right track.
Cheers
Jane

here i would like to share our process flow & interaction.

maybe help you....

jhoniegudel

We all appreciate your sharing it with us! Thanks!

here i would like to share our process flow & interaction. maybe help you.... jhoniegudel

jhoniegudel

Our sister plant tried something like this, and they failed a TS Stage I.

This is essentially Figure 1 from ISO/TS Introduction.

Our registrar would not accept this as a process map. Did yours?

Over to others - is this OK?

Recently I’ve changed the way I’ve been doing the process approach to fulfill the standards requirement.
I started to pay more attention on Michael Porter’s Generic value chain, in order to identify my processes. It’s business we have to create, and not just processes to be according to a standard requirement.
It’s an old theory (from the 85 book Competitive advantage), but the difference Porter showed between value processes and support processes, can be very useful to QMS. :)

If I may, I strongly suggest the reading of the book.
What he proposes is a little different from what the standard shows in it’s classic diagram “Model of a process-based Quality Management System”.

jhoniegudel

Our sister plant tried something like this, and they failed a TS Stage I.

This is essentially Figure 1 from ISO/TS Introduction.

Our registrar would not accept this as a process map. Did yours?

Over to others - is this OK?


I am not a big fan of the PDCA Circle, I don't think it says much. However, as an auditor, I don't have a problem with clients who use this format. However, this example does not answer all the questions, it just shows an overview.

Since Caster asks, if this is all the client has, I could not accept it either. However, if there are other maps or documents which describe the inputs and outputs, criteria for effectiveness, metrics, objectives, etc., then it might be acceptable. All the requirements outlined in cl 4.1 must be addressed.

jhoniegudel

Our sister plant tried something like this, and they failed a TS Stage I.

This is essentially Figure 1 from ISO/TS Introduction.

Our registrar would not accept this as a process map. Did yours?

Over to others - is this OK?

One of our sister plant use this 'process map' and it is OK.

but if you failed you can use this one....

it maybe hel you...

Well, I thought I'd share mine also for grins/criticism. I don't really care for mine too much - it was suggested by someone who had great influence at the time that it was a necessity in our implementation process. It passed the audit.

What does anyone think?
Thanks,
Lee

I deleted the word doc and replaced with a pdf file since the word doc wouldn't open properly.

Well, I thought I'd share mine also for grins/criticism. I don't really care for mine too much - it was suggested by someone who had great influence at the time that it was a necessity in our implementation process. It passed the audit. What does anyone think? Thanks, Lee
.

Lee

Since you asked....

1) The key words are "it passed the audit", so nothing else really matters

2) Is this format called swim lanes? I like it a lot, it shows how processes cut across departments....I feel this style is one of the more successful ones.

3) And this format just proves my favorite gripe....look at how much the Quality department is responsible for <by inspection about 20%>....so why is this a called Quality management system...it is a business management system, just look at all the stuff those other departments are responsible for...

4) Second favorite gripe "product realization". Does any one use that term in yor company? Bet you have a design department.

Every time I see a Quality manual with "real eye zay she own" it tells me quality system is grafted on, not a day to day part of the system

You say you don't like it, what would you do instead?

So, I guess now I better post my map so it can be critiqued.

You say you don't like it, what would you do instead?

I do not know. I have been searching to see what everyone else has done. I just do not see the value in having this map. I never look at it or refer to it. No one does. The registrar said we had to have it but what good is it? I don't get it. :confused:

1) The key words are "it passed the audit", so nothing else really matters
To rely on "Well, it passed the last audit" could get a person in trouble. Different auditors, etc.

You MUST rely on your knowledge and ability to explain how and why your company / location complies. If a company had an 'easy' auditor last time and a 'by the book' auditor comes next audit, a shock could follow.

1) The key words are "it passed the audit", so nothing else really matters




Please don't make that the primary criteria! Sure, it has to pass the audit, but first and foremost, it has to provide a benefit. It has to be right for the business. If it is right for the business, we'll make it work for the audit too.

In my opinion, it was a bit complicated. That tends to make it intimidating to the average person at a company. That tends to render it as "not beneficial" to the company. There is nothing wrong with putting some of this info in a secondary document, and keep the primary flow clean and clear.

But, more important, is that it suit your needs, not your auditor's needs.

I do not know. I have been searching to see what everyone else has done. I just do not see the value in having this map. I never look at it or refer to it. No one does. The registrar said we had to have it but what good is it? I don't get it. :confused:


There is NO requirement to make flowcharts, process maps, or turtles! The requirement is that we define the sequence and interactions. ANY format that accomplishes that can meet the requirement. So, if YOU want to have flowcharts, process maps, or turtles, that is great. But, don't make it for the auditor. Make it to be what you need! If you understand the standard, you will make it in such a way that it also meets the requirements.

Lee, we are in the process of developing very similiar maps, however, ours not only show the departments but how the actions align with PDCA (the overall foundation of our Management System).

Departments along the top axis...PDCA along the vertical. We also include a "how" column and "frequency" column on the right side so that each step shows how often it is done and what actions are done/resources are needed.

To rely on "Well, it passed the last audit" could get a person in trouble. Different auditors, etc.

You MUST rely on your knowledge and ability to explain how and why your company / location complies. If a company had an 'easy' auditor last time and a 'by the book' auditor comes next audit, a shock could follow.

Re: Complies with what? With section 4.1 General requirements?
Re: "by the book" auditor.....Oh, I am well aware of that potential situation!

Please don't make that the primary criteria! Sure, it has to pass the audit, but first and foremost, it has to provide a benefit. It has to be right for the business. If it is right for the business, we'll make it work for the audit too.

In my opinion, it was a bit complicated. That tends to make it intimidating to the average person at a company. That tends to render it as "not beneficial" to the company. There is nothing wrong with putting some of this info in a secondary document, and keep the primary flow clean and clear.

But, more important, is that it suit your needs, not your auditor's needs.

Re: benefit...I do not see the benefit of the document. Why is it needed?
We're getting off-topic. :topic: I am not the original poster. I just wanted to share my process map and at the same time, get some feedback. Sounds like it is a bit complicated. Big Thanks!

Lee, we are in the process of developing very similiar maps, however, ours not only show the departments but how the actions align with PDCA (the overall foundation of our Management System).

Departments along the top axis...PDCA along the vertical. We also include a "how" column and "frequency" column on the right side so that each step shows how often it is done and what actions are done/resources are needed.

I am not real familiar with PDCA. I have asked about it in a separate thread and there I learned something about it. But, I am interested in seeing what you come up with....eventually. :)

There is NO requirement to make flowcharts, process maps, or turtles! The requirement is that we define the sequence and interactions. ANY format that accomplishes that can meet the requirement. So, if YOU want to have flowcharts, process maps, or turtles, that is great. But, don't make it for the auditor. Make it to be what you need! If you understand the standard, you will make it in such a way that it also meets the requirements.

You've stated it perfectly and I did not realize that "maps" were not "the format" to use. It seems that most people create that type of document so it must be the best? Hey, this could be a poll. What does everyone use? Anyone want to start a poll here too?

Re: benefit...I do not see the benefit of the document. Why is it needed?
...Sounds like it is a bit complicated. Big Thanks!


The fact that you have come to this conclusion is good, it sets you on a course where you can tune the document(s) to a stage where they actually do provide value. I'll try to offer a couple steps:

1. Sequences (cl 4.1.b) The value of a sequential diagram is to see if there are bottlenecks, redundancies, or wasted steps. Is the process unclear, or obvious and straightforward. Can we simplify the steps. It is also a useful tool for internal auditors to use.

2. Inputs and Outputs (Interactions cl 4.1.b) are useful to define what is actually adding value and what is merely paperwork. It also helps show the sequences discussed above.

3. Criteria for Effectiveness (cl 4.1.c) helps establish what the team agrees are the important criteria of the process. These become the focal point. Note: These are not the same thing as the process outputs, except in some cases. There are like the key dimensions on a blueprint that we inspect parts to.

4. The Measurables (cl 4.1.e) are how we track whether those Criteria are being met.

These four steps are requirements, as indicated, but the format is left to you. A process map is an attempt to evaluate these variables. Some folks find the turtles are an easier format to do this.

Hope that helps.

Lee,
I looked at the process map.

I guess my main question would be: can you put this in front of someone new to the organisation, and can they glean anything useful out of it? (NO cheating now... no having someone steeped in ISO and quality terminology to sit next to 'em and explain it).

If not... what's the value? And why bother?

If not... what's the value? And why bother?

My question exactly. That is why I am looking to change it to something that means something to someone. Thanks.

The probem is that many folks don't have a methology on how to execute and use process maps to improve their process. For those who believe it is just flow charting then I would say that is like comparing elementry arithmetic with advanced accounting.
Let me just give you a few hints at what we are doing, keep in mind we are a complex international organization with many sites around the globe. Pick an important process to map, say training. Now training occurs through many departments in most companies so you need to get together the head people from all the different training groups, those would be the process owners. Now have them discuss what the high level training processes are, then break down each of the high level processes to a second level to get the most benefit. You would be surprised to find out that those managers cannot even agree on what those process steps are and they live eat and breathe training...anyway after many hours of deliberation the final output is an "as is" process definition which includes maps from a high level 1 to a second level as well as a supporting document that outlines process measures/monitors, controls, chronic obstacles, and improvement opportunities. I can honestly as an internal auditor that we have had more process improvements from this process mapping activity in the last 3 months than we have ever had from internal audits for the past 5 years. The activity has served as a trigger and thread to show connection between all of the veritcally siloed department controlled planning processes and give a meaningful horizontal view of the a consolidated planning process. An extra plus is that we are able to show top management in a complex organization the issues of silo management and now truly do process oriented audits.
The next step is to develop a "to be" process that will close the gaps in the current horizontal process. I am currently in process of documenting this process definition methodology in order to capture the intellectual capital gained. It may be a while before I can share it here but once it is done I will share it. :)

The probem is that many folks don't have a methology on how to execute and use process maps to improve their process. For those who believe it is just flow charting then I would say that is like comparing elementry arithmetic with advanced accounting.
Let me just give you a few hints at what we are doing, keep in mind we are a complex international organization with many sites around the globe. Pick an important process to map, say training. Now training occurs through many departments in most companies so you need to get together the head people from all the different training groups, those would be the process owners. Now have them discuss what the high level training processes are, then break down each of the high level processes to a second level to get the most benefit. You would be surprised to find out that those managers cannot even agree on what those process steps are and they live eat and breathe training...anyway after many hours of deliberation the final output is an "as is" process definition which includes maps from a high level 1 to a second level as well as a supporting document that outlines process measures/monitors, controls, chronic obstacles, and improvement opportunities. I can honestly as an internal auditor that we have had more process improvements from this process mapping activity in the last 3 months than we have ever had from internal audits for the past 5 years. The activity has served as a trigger and thread to show connection between all of the veritcally siloed department controlled planning processes and give a meaningful horizontal view of the a consolidated planning process. An extra plus is that we are able to show top management in a complex organization the issues of silo management and now truly do process oriented audits.
The next step is to develop a "to be" process that will close the gaps in the current horizontal process. I am currently in process of documenting this process definition methodology in order to capture the intellectual capital gained. It may be a while before I can share it here but once it is done I will share it. :)


Excellent stuff, qualitiboi...

I would add, there is turbocharge power in defining the Criteria for Effectiveness (cl 4.1.c)

This helps establish what the team agrees are the important criteria of the process. These become the focal point. (Note: These are not the same thing as the process outputs, except in some cases.)

An example. I had a training situation where I asked a Maintenance Mgr. to describe the top 4 things (criteria) whereby he judges whether he is doing a good job for the Production Mgr. (his internal customer). He rattled off four good things. I next asked his customer, the Production Mgr., what 4 things HE felt were important criteria to judge the performance of Maintenance. He also mentioned 4 good things.

However, only one of the four things the Maintenance Mgr. mentioned as important, were mentioned as important be the Production Mgr!

In other words, 75% of the focus of the Maintenance Mgr. was misplaced, and of secondary importance to the Production Mgr. Just understanding this discrepancy allowed these two managers to better align their efforts for the maximum benefit.

This stuff works, if we do it right!

I agree with the last few posts that the process map must be of some value other than showing the auditor that you have them. I have made a training package that some of you may have seen called "Process Mapping" (http://elsmar.com/Forums/attachment.php?attachmentid=2420&d=1090893917) .
It is very basic but I get everyone to do it before I get them to look at their processes. There is an exercise where they have to map 'making a cup of coffee'. It sounds easy until you let them loose with it:) . I emphasis at the end of it that they must do the following:
1. Check if the process is effective
2. Explain how they monitor the process
3. Explain how they measure the process
4. Explain how they can improve the process

We lead them thru to another project where they have to explain how they monitor the transition of their process thru to the customer...be it the next process in line, transport, storage or the final customer. We look at the gaps between the processes!!!

It is a very interesting exercise and it has broken down some departmental barriers that people had established as they felt that their responsibility ended with their process.

You would be surprised to find out that those managers cannot even agree on what those process steps are and they live eat and breathe training...
Jim
I agree entirely. After finding it is so common, it no longer surprises me - how difficult it is for competent, experienced people to explain to someone else what they do! It makes it all the more important that an organisation has a very simple, clear method of describing how they operate, so that new staff don't have to rely on these same people to tell them (although it is always useful to have someone to refer to if in doubt).

I have made a training package that some of you may have seen called "Process Mapping" (http://elsmar.com/Forums/attachment.php?attachmentid=2420&d=1090893917) .
It is very basic but I get everyone to do it before I get them to look at their processes. There is an exercise where they have to map 'making a cup of coffee'. It sounds easy until you let them loose with it.
Greg
Thanks for the package - it is very clearly set out. Do you mind if I use it to illustrate what I think is a major obstacle for folk who are still trying to get their heads round "processes"?

First of all, I am pleased that Jim (above) used "Training" for his example, and that you use "Making a cup of tea". In both cases, each "instance" of the process will be different, and the staff need to manage the differences (between customers, their demands, the other orders being processed at the same time etc). Neither is a "continuous production line" type of process, which is where I feel much of the confusion comes from.

Quoting the accepted definitions (which I believe are production line based, and so at the root of the problem!) you say "Inputs ... may include equipment". You say that a process "... transforms inputs into outputs". You say that "a cup" and "a spoon" are two of the inputs required to make a cup of coffee. So what do you use to make the second cup, now that the cup you used for the first customer has been "transformed" (into a pumpkin?)

You ask "What are your inputs from the customer?" Why just "from the customer"? You have listed many more "inputs" (or are they resources?!) Your question suggests that you are closer to my definition of a process - which has something "triggering" the process to start. So the order from the customer triggers the "Make a cup of coffee" process, whose objective is to deliver a cup of coffee, in a clean cup, without undue delay, and with a smile... How well you can do it depends (a) on the resources you have available, and also (b) on the other factors that can influence the process (such as the attitude of the staff, the length of the queue...).

I like your "What now" section. Often, just defining the process is a challenge - but the real benefit comes after that, when managers (and staff) can think about what the process is trying to achieve, what the organisation's overall objectives are and how they affect how the process is designed and delivered. For example, do you want the customers to tell their friends how friendly the staff are, and how clean the premises are? Then encourage the staff to smile when they take the order, and to clean the table as soon as it is vacated. It's all part of the process.

How many staff in a coffee shop go to work to "do" transformations? They go to serve customers / deliver a service / keep the boss happy enough to get paid.... After all, the staff are "resources" as well - I bet they don't want to be "transformed" by their shift either!

Sorry for having a go (not at you, but at the definitions), but your example was so clearly set out...!

Greg
Thanks for the package - it is very clearly set out. Do you mind if I use it to illustrate what I think is a major obstacle for folk who are still trying to get their heads round "processes"?

First of all, I am pleased that Jim used "Training" for his example, and that you use "Making a cup of tea". In both cases, each "instance" of the process will be different, and the staff needs to manage the differences (between customers, their demands, the other orders being processed at the same time etc). Neither is a "continuous production line" type of process, which is where I feel much of the confusion comes from.

Making cups of coffee can be a production line and our company does not have a production line. It is an example only to get them thinking and works well.

Quoting the accepted definitions (which I believe are production line based, and so at the root of the problem!) you say "Inputs ... may include equipment". You say that a process "... transforms inputs into outputs". You say that "a cup" and "a spoon" are two of the inputs required to make a cup of coffee. So what do you use to make the second cup, now that the cup you used for the first customer has been "transformed" (into a pumpkin?)

These are questions that are posed as they go about their process mapping. They actually have all the resources (we do this in the common room) and individuals get up and make coffee with others mapping away. I don't like to pre-empt their thought process so a lot of this they discover during their own 'process' of coffee making. People ask them what do you do with the spoon? What happens to the dirty cup? What temp is the water? is the customer satisfied? Who placed the order? etc they often have to be roped back to the process or they go off at tangents….especially the accountants and engineers :D

You ask "What are your inputs from the customer?" Why just "from the customer"? You have listed many more "inputs" (or are they resources?!) Your question suggests that you are closer to my definition of a process - which has something "triggering" the process to start. So the order from the customer triggers the "Make a cup of coffee" process, whose objective is to deliver a cup of coffee, in a clean cup, without undue delay, and with a smile... How well you can do it depends (a) on the resources you have available, and also (b) on the other factors that can influence the process (such as the attitude of the staff, the length of the queue...).
I don't tell them who the customer is! They have to work this out and usually get it wrong. In our company the process operators don't usually know who the final customer will be….they only know up and down stream from their area of responsibility. I ask them about their manager being a customer etc. 'resources' can be and are 'inputs' to the physical process but I also get them to think about Training, paperwork, instructions, maintenance etc because these all have to be ticked off.

I like your "What now" section. Often, just defining the process is a challenge - but the real benefit comes after that, when managers (and staff) can think about what the process is trying to achieve, what the organisation's overall objectives are and how they affect how the process is designed and delivered. For example, do you want the customers to tell their friends how friendly the staff are, and how clean the premises are? Then encourage the staff to smile when they take the order, and to clean the table as soon as it is vacated. It's all part of the process.
I get them to realise that their are two parts of the mapping. The 'physical' that will be documented in work instructions and the flow charts etc and the 'business map' of where and how their process fits into the organisation.

How many staff in a coffee shop go to work to "do" transformations? They go to serve customers / deliver a service / keep the boss happy enough to get paid.... After all, the staff are "resources" as well - I bet they don't want to be "transformed" by their shift either!

Sorry for having a go (not at you, but at the definitions), but your example was so clearly set out...!
Peter, I am not taking offence but I need to clarify that this is more than the physical process during the class.... it is a thinking lesson and I don't want to impart my bias or kill them with PowerPoint slides :). Cups of coffee were easier than walking thru a noisy plant with people that had 'their' opinion of how 'their' process operates. I take them away from that environment and give them something relatively easy that turns out to be not so easy when documenting it. We also have people form different sections in the class.
I too not always agree with the 'terms' as it used in the various standards but I use them in name only and do not get stuck down with semantics as many in the cove do.. Just look at the 'Shall' people or those that have conniptions over 'preventative' versus 'corrective’ :D
PS: If you want this presentation then you may do with at you please. I put all of my presentations on the cove for everyone to use. I just like the recognition if they are re-used on this site, which has happened.:)

Greg

That all sounds brilliant - much more to it than you can see from the slides, and covering all the things I would have thought about (and more!)

You are right that many people just don't know that they are part of a process - all they are doing is taking the next piece of paper out of the in tray, or doing what they did last week, or doing what they think will keep the boss happy. Customer - what customer?

Many thanks.

...
Quoting the accepted definitions (which I believe are production line based, and so at the root of the problem!) you say "Inputs ... may include equipment". You say that a process "... transforms inputs into outputs". You say that "a cup" and "a spoon" are two of the inputs required to make a cup of coffee. So what do you use to make the second cup, now that the cup you used for the first customer has been "transformed" (into a pumpkin?)
...!


I think there is a simpler method to teach inputs and outputs. If we call all the items inputs, it gets too clumsy.

It is cleaner to define the spoon, coffemaker, measuring cup, recipe, etc. as the tools of the process. (This is where a turtle diagram would help make the discussion clearer).

The easier method is to ask what is the direct item(s) being taken from the previous process, upon which I will take further action.

The actual input would be the coffee beeans (an output of Purchasing) and water (is it distilled, tap, filtered, bottled, etc).

The actual output is the brewed coffee, which will probablt be packaged in a cup. The other output, invoice, used grounds, etc. are not "outputs. They are byproducts of the process.

I sometimes ask folks, what are you putting in the bucket which you are handing to the next process? What is the actual product of that process? Who do they "sell" it to (the next process)? This helps bring a simpler clarity to this exercise.

I think there is a simpler method to teach inputs and outputs. If we call all the items inputs, it gets too clumsy.

It is cleaner to define the spoon, coffemaker, measuring cup, recipe, etc. as the tools of the process. (This is where a turtle diagram would help make the discussion clearer).

The easier method is to ask what is the direct item(s) being taken from the previous process, upon which I will take further action.

The actual input would be the coffee beeans (an output of Purchasing) and water (is it distilled, tap, filtered, bottled, etc).

The actual output is the brewed coffee, which will probablt be packaged in a cup. The other output, invoice, used grounds, etc. are not "outputs. They are byproducts of the process.

I sometimes ask folks, what are you putting in the bucket which you are handing to the next process? What is the actual product of that process? Who do they "sell" it to (the next process)? This helps bring a simpler clarity to this exercise.
Helmut

This also makes much more sense to me. It sounds as though you don't like the "transformation" definition either - or at least you don't try to justify it. It is interesting that your choice for the "input" is different from what I have seen others define as the input, ie the "customer need" or the "customer order".

I like the idea of "tools" ("resources"?), and of treating them as "things you need to have available for the process to work". Staff would also belong in this category (a product of the Recruitment and Training processes?).

But the bottom line is that I believe that all this would be unnecessary if we used a more intuitive definition, such as "a sequence of activities triggered by an event and designed to achieve an objective. It uses resources and is subject to influences." The "product" is the achieved objective. This works for a higher level process and also scales down to the individual task level. So the receipt of a customer order triggers the order processing process, and a New Customer form arriving in someone's Intray triggers the task to set up a new customer on the computer. Focussing on objectives is one of the key concepts which the ISO definition misses, and is vital for seeing how the business processes help to achieve the overall business strategy.

And we wouldn't need to debate what is an input, what is or isn't "transformed"...

Going back to the original theme of this thread - the way the processes interact is to do with how you make the required resources available, and how you manage the factors that can influence a process (such as compliance with external standards). I have never seen the point on drawing a picture to say that "we sell something then we make it then we check it then we deliver it then we invoice it" - everyone knows that!

Peter, your thoughts are very insightful. However, I don't think I fully agree with every approach you sited.

The "process approach" under ISO should not be any different than process mapping without ISO. The principles are the same. I just think we make it too complicated, and lose sight of the purpose in the first place - ummm...to bring clarity to an activity (process).


Helmut

This also makes much more sense to me. It sounds as though you don't like the "transformation" definition either - or at least you don't try to justify it. It is interesting that your choice for the "input" is different from what I have seen others define as the input, ie the "customer need" or the "customer order".


I think subscribe to a "transformation" definition, though maybe we have different connotations of that word. A simpler definition is "A core process takes "something," and does something to it, and the resulting output has more value than before.

The coffee example takes coffee beans and water, and makes a tasty beverage which sells for $1.00. The next operation make take that nice basic beverage and add a bunch of extra silly ingredients, resulting (output) in a highly over developed designer beverage, and sell it to the customer for $4.50. If the customer has extra specifications, they have a more expensive product, but it meets their perceived needs.

When we discuss "core" or "Customer Oriented" processes, this relationship between inputs and outputs should be pretty clear and obvious. The rest of the details fall into the various Tools categories you mentioned.

However, when we discuss "non-core" or "Supporting" processes, like Training, Calibration, etc., the input/output conversation can be less clear. When working with a team of folks, I add another question to clarify the output concept.

For Training, the discussion would be as follows. OK, Training is an internal support process. In other words, Training is a service (product) provided b the HR Dept. OK, what is the result we expect to get? What is the product of that activity? What is the output? The answer is usually "trained, competent, people with proficient skills." OK, then "trained, competent, people with proficient skills" is the output of that Training process. Then it stands to reason the input was "UN-trained, NOT-competent, people with certain undeveloped skills."

I find groups of managers and regular folks have a much easier time developing it when this approach is clear.



I like the idea of "tools" ("resources"?), and of treating them as "things you need to have available for the process to work". Staff would also belong in this category (a product of the Recruitment and Training processes?).


Yes, but bear in mind, these tools probably were the result of an earlier process (Training, Purchasing, Process Designing, etc.)



But the bottom line is that I believe that all this would be unnecessary if we used a more intuitive definition, such as "a sequence of activities triggered by an event and designed to achieve an objective. It uses resources and is subject to influences." The "product" is the achieved objective. This works for a higher level process and also scales down to the individual task level. So the receipt of a customer order triggers the order processing process, and a New Customer form arriving in someone's Intray triggers the task to set up a new customer on the computer.

You may add and modify the "official" definition all you want internally. A good teacher always adds insight to the material, and tailors it to the needs of the student. But, don't lose the link to the original definition, because I don't think it is so far off. It just can be phrased better.

In the examples I sited above, the customer order "trigger" would be the input to the Sales/Contract Review/CSR Process (whatever the heck we are calling it nowadays). The output would be the processed order information on the form or ERP database. This information and order is the product we pay the Sales people for. And the effectiveness (cl 4.1.c) is judged by whether the information is complete and accurate, and in my opinion, whether they get enough of these transactions. Then, the next process - Engineering/APQP - takes this information and fashions a product and process to meet these needs/requirements.

It is very easy to "map" this just scribbling a half dozen circles on the whiteboard. The class sees the concept, then they begin to develop each one. All the rest of the activities tend to fall into the "Support Process" categories.


Focussing on objectives is one of the key concepts which the ISO definition misses, and is vital for seeing how the business processes help to achieve the overall business strategy.


No, not at all. in my view, ISO is very focused on effective results from each process. In other words, effective outputs from each process, which then become effective inputs for the next INTERNAL customer - the next process in the chain. The failure is that everyone steps right over 4.1.c and jumps right to 4.1.e. They measure "stuff (4.1.e)," when they haven't even defined and documented what "stuff" is important (4.1.c).

Imagine inspecting a part to a blueprint that does not define what the acceptance criteria shall be. Well, why do we evaluate (inspect) processes to criteria that has not been defined (4.1.c).


And we wouldn't need to debate what is an input, what is or isn't "transformed"...

I think my approach reduces much of this to a comfortable discussion.



Going back to the original theme of this thread - the way the processes interact is to do with how you make the required resources available, and how you manage the factors that can influence a process (such as compliance with external standards). I have never seen the point on drawing a picture to say that "we sell something then we make it then we check it then we deliver it then we invoice it" - everyone knows that!



Oh, contraire, my friend. Everyone THINKS they know this, but they only know it in part! And the parts they don't know as clearly as they thought, costs us millions of dollars, euros, etc.

The magic of the Process Approach is when we take what everyone "knows," and we plug it into maps, all sorts of small cracks and gaps appear. If we do this well, and give it its due, we see where internal suppliers have a completely different opinion of what their product is than their internal customer's perception. And we see where internal customer's are judging the effectiveness of a process or output completely differently than the supplier did. It is in seeing these gaps and glitches, that we are able to connect the wires. This proper review allows an alignment and optimizing that can supercharge a company. I find this is a 12-36 month exercise of evolution, depending on the skills of the people leading the effort. It is also this exercise that makes a good consultant worth his weight in gold...

"a sequence of activities triggered by an event and designed to achieve an objective. It uses resources and is subject to influences." The "product" is the achieved objective.


Mate I love IT!!!!! Great explanation:applause:

...I also think Helmut might be over complicating the issue about my coffee process. The aim of the lesson is to keep it simple as I aim at the lowest common denominator "The operator". They (IMO) don't really care about the flowery words and phrases they want to know what to do and how it interacts. Many of OUR processes are merely steps between other processes and in most the operator doesn't see an order, a customer or a finished product (read, Final product). So while my lesson, as it stands, works very well for MY company it would need to be structured differently to someone that made cct boards, isntalled dashboards, manufactured matchsticks or whatever but hopefully I get the concept across. The sad thing is that while we discuss this others, in most cases, will read only this page and not understand what we are talking about. So for those not familiar or can't backpage here is my presentation...Process mapping 101 (http://elsmar.com/Forums/attachment.php?attachmentid=2420&d=1090893917) :D

The magic of the Process Approach is when we take what everyone "knows," and we plug it into maps, all sorts of small cracks and gaps appear. If we do this well, and give it its due, we see where internal suppliers have a completely different opinion of what their product is than their internal customer's perception. And we see where internal customer's are judging the effectiveness of a process or output completely differently than the supplier did. It is in seeing these gaps and glitches, that we are able to connect the wires. This proper review allows an alignment and optimizing that can supercharge a company. I find this is a 12-36 month exercise of evolution, depending on the skills of the people leading the effort. It is also this exercise that makes a good consultant worth his weight in gold...
:applause:
This is exactly why I have people from different areas in each class. We need to find the gaps between the processes. I usually have people up and down stream of a main process (including ancillary process' such as supply, maintenance and even accounts) and after the lesson we discuss how everything interacts. It is valuable lesson and a real eyeopener to most.

This is exactly why I have people from different areas in each class. We need to find the gaps between the processes. I usually have people up and down stream of a main process (including ancillary process' such as supply, maintenance and even accounts) and after the lesson we discuss how everything interacts. It is valuable lesson and a real eyeopener to most.

So I reckon that we agree (?!) - what is important is for folk to understand why they are doing something, how it fits into the overall plan, what else needs to happen for them to achieve success, and to be able to describe it all clearly and concisely.

And ... it is surprisingly difficult for many people to see how activities all fit together, but using simple examples and simple terminology to focus on the key steps makes life easier for everyone.

So why is it such a struggle?!

So I reckon that we agree (?!) - what is important is for folk to understand why they are doing something, how it fits into the overall plan, what else needs to happen for them to achieve success, and to be able to describe it all clearly and concisely.

And ... it is surprisingly difficult for many people to see how activities all fit together, but using simple examples and simple terminology to focus on the key steps makes life easier for everyone.

So why is it such a struggle?!


Because

1. it takes someone who clearly understands how this works to lead the exercise.

2. And, it takes the clear support of Top Management to participate and drive the process to ensure it is completed at all levels.

3. And finally, management then must take the results and carefully build continual improvement based on the resulting information.

This takes understanding, time, committment and leadership...

I came across this link which shows the "ISO 9001:2000 - A Process Interaction Matrix "

http://www.quality-works.com/download/270%2001%20Process%20interaction%20matrix%20article,%20Fig.1.pdf

sathis

Your process map is in a microview.First start with a bussiness process map, then a process map( for example purchasing,QA,Manufacturing,Warehousing,and distribution process), then in the warehouse process you have the receiving,staging, issuance procedure after that if it still needs further explanation come up with a work instruction.

I just thought I would throw in another example for your comments. This is the 'top level' process map I have put in a quality manual for a client. I am trying to show a brief overview of their main (core) processes plus the fact that there are other processes which impact on the core processes.

I have more detailed flowcharts for many of the boxes on this map which serve as procedures for how the activity is controlled.

I finally got a chance to re-visit this thread and I just wanted to say Thank You for your input and attachments. It's been awhile since the last post and if you have any new / updated info to attach, please do! :thanks:

Working on getting up to speed on ISO9000. Does it require that we have process flow charts? Or is this a best management practice. Our Quality manual states we have supporting documentation for each section that includes maps. I have found a few, notg sure I want to generate all the remaining ones (training map, sales order map, etc..) if it is not a requirement. The actual processes we do for our customers are included on a flowchart. I have attached a blank copy.

Here is an sample deployment flowchart that describes what an organization does to develop its process-based management system:

Our management manual contains the high level overview process map of the entire process company wide. Our SOP section of the QM breaks each process down into a seperate process maps by the process outlined in the management manual. For instance the overview process map says "design development, 3.0", but turn to the section 3.0 of the SOP and you will find that our process for design/development is 3.0 thru 3.17. which shows greater detail of inputs and outputs. And no the processes our not written out that much, At the end of each process we state "refer to the associated work instruction," which is the spelled out, detailed instructions or third level document located at the point of use.

Hi all, is it possible for you to take a look at my Interaction of Processes map? I find alot of the diagrams over - complicated and wanted to keep mine as simple as possible. Without referencing individual procedures, I have just used terms e.g Management, or New Business. Is this okay. Any advice would be appreciated

Stephen:
I'm having a problem with the way a couple of things are shown, like the line connecting 'management' to 'customer requirements/satisfaction'. I don't see a clear definition of 'processes' and their interaction, just a set of boxes with lines running between them.
You're correct to keep it simple, but I'd be interested to know what your management would describe if you asked them to talk me through the diagram. It's a challenge for sure, trying to keep from making a parody of the ISO requirements but at the same time defining a 'real' picture of how the business functions.

I'd suggest you get your management in a room, lock the door, use a whiteboard or flip chart and ask them - "How do we operate?" and have them draw it......... Trust me it'll be interesting!

Just to add to AndyN's comments. If the identification of processes (4.1) and the process interrelationship (4.2.2) are to be meaningful they are written in terms of what the organization does. So if you make widgets then there should be a box "Make widgets" and if part of the top management activity includes an annual budget setting process then there should be a box "Set budgets."

Only after you have gone through Andy's "locked room" exercise :lol: should you start to document all of this and map it against clauses of the standard.

:confused:

Thanks for your comments guys. I'm not far away from cracking this but not quite got my head around it yet.


Paul Simpson - I had intended the middle operational box to detail what the organisation does. We do CRB checks, we do Media and Production, we do events, we do administration.

In terms of 'what management does, I had intended to use the broad box of Management to show that management links to other aspects of the company, and then management procedures would include -set budgets, HR etc.

The business development box would show that the Business Devlopment dept relate to customers/analysis etc but again the flowcharted procedures would detail eg. QP/1 Targetting New Business, QP/2 Tender process, QP/3Customer Percetion Monitoring.

If I replaced the box for New Business with the titles of all the flowcharted procedures for that department would that be more like it?

Thanks again for your help, i'm going to search around some more and hopefully nail this tomorrow.

Hi Paul.

When I look at the process map. I can see inputs and outputs right up to Measurement/Analysis & Improvements. Then the process flow goes to Management? Management involvement is continous flow and I hate to be the third wheel here and agree with the other two informed posters, but the connection line with Management to Cust. Satisfaction,doesn't work. If you lump all the other processes in operational, wouldn't be best to lump in training?

Mikey in the OC. :bigwave:

Frustrated Quality Managers make for lousy conversationist

:confused:

Thanks for your comments guys. I'm not far away from cracking this but not quite got my head around it yet.

Paul Simpson - I had intended the middle operational box to detail what the organisation does. We do CRB checks, we do Media and Production, we do events, we do administration. OK. But do you do all of these together or can one process follow another.

For example do you ever get an administration contract after a CRB check contract. This interrelationship could be covered in your map.

Also you have listed below a range of processes that make up business development. Some of them may apply to all of the operational processes, some may not. For example if you have a series of standing contracts for (for example) CRB checks then you may not choose to have "Targetting new business" as a preceding process.

Similarly "Customer perception monitoring" will rely on outputs from the operational processes going into it and then feeding back into the management process and then back into the operational processes again (as resource requirements, process controls (for example) are changed.... following so far? :)

In terms of 'what management does, I had intended to use the broad box of Management to show that management links to other aspects of the company, and then management procedures would include -set budgets, HR etc.OK. The difficult thing is to show where these support processes interface with core (operational and business development) processes. As mentioned earlier if you don't have anything called "Management" that anyone else in the company recognizes then it is difficult to see how the process map helps.

The business development box would show that the Business Devlopment dept relate to customers/analysis etc but again the flowcharted procedures would detail eg. QP/1 Targetting New Business, QP/2 Tender process, QP/3Customer Percetion Monitoring. As above, not all of these would necessarily apply as inputs to all operational processes.

If I replaced the box for New Business with the titles of all the flowcharted procedures for that department would that be more like it?Yes. If the processes are separate then they should be listed separately. There may be ways of simplifying the diagram afterwards but, without knowing exactly how your business operates it is impossible to judge.

Thanks again for your help, i'm going to search around some more and hopefully nail this tomorrow.Thanks for taking the advice in the right spirit. As AndyN suggested a locked (darkened :lol: ) room and perhaps some sticky notes would be time well spent!

I think identification of processes means, detailing all the processes involved in QMS including design and development and production.

However since process flow chart for production may be big (depending on the product), a interaction of all other processes can be developed refering details of production as annexure (which can be called from interaction of processes).

A simple one is attached for reference.

Regards

Ajay

I have posted one query on calibration today, kindly give your suggestions.

Hi all, is it possible for you to take a look at my Interaction of Processes map? I find alot of the diagrams over - complicated and wanted to keep mine as simple as possible. Without referencing individual procedures, I have just used terms e.g Management, or New Business. Is this okay. Any advice would be appreciated


I'm a little late in reviewing this one, but it does not appear to address all the activities of your organization. Somewhere, all your processes must address all activities, including Purchasing, Calibration, etc.

It might be easier for you to show the sequence of your main processes first, as a stright pipeline. Then plug in all the supporting processes around that, perhaps in a circle surrounding the main process line.

There is NO requirement to make flowcharts, process maps, or turtles! The requirement is that we define the sequence and interactions. ANY format that accomplishes that can meet the requirement. So, if YOU want to have flowcharts, process maps, or turtles, that is great. But, don't make it for the auditor. Make it to be what you need! If you understand the standard, you will make it in such a way that it also meets the requirements.

Good point, hjilling! It seems to me that the standards are often looked at 'as something we must do' rather than 'a way to improve upon our business'. In the case of the former, people seem to misinterpret the standard and then scramble to appease the 'all powerful, all knowing auditor'.

It also seems that a lot of people jump straight to Point 1 of the ISO 9001:2000 standard - Requirements, and don't (or forget to) read the Introduction, especially the first sentence of 0.2.

This International Standard promotes the adoption of a process approach when developing, implementing and
improving the effectiveness of a quality management system, to enhance customer satisfaction by meeting customer
requirements.

To enhance customer satisfaction by meeting customer requirements...that is my mantra. And I ask myself every working day if my organisation has evidence to show that it is doing just that.

Yes, we need an understanding of how our business operates and interacts with each component (dept, section, whatever), but there certainly isn't any requirement to map it out.

When I conduct inductions of new staff into the QMS, I explain our company processes and how they interact. Explaining how each person contributes to a process and the flow on effect from one process to another certainly helps to make our staff understand the purpose of our QMS.

When I am audited on this point, I show my training material which has been reviewed by Management, approved and notated in their minutes. That is one way that I am able to evidence that the organisation has determined the sequence and interaction.

Rather long-winded, but I just wanted to point out that there are other ways to approach this without 'process mapping' and to challange any auditor who says that it is required.

It seems to me that the standards are often looked at 'as something we must do' rather than 'a way to improve upon our business'. In the case of the former, people seem to misinterpret the standard and then scramble to appease the 'all powerful, all knowing auditor'.

It also seems that a lot of people jump straight to Point 1 of the ISO 9001:2000 standard - Requirements, and don't (or forget to) read the Introduction, especially the first sentence of 0.2.

To enhance customer satisfaction by meeting customer requirements...that is my mantra. And I ask myself every working day if my organisation has evidence to show that it is doing just that.

Yes, indeed! You make excellent points, with which I could not agree more.

I just wanted to point out that there are other ways to approach this without 'process mapping' and to challange any auditor who says that it is required.

Again, yes. Auditors are there to test the system against the relevant Standard, & all the good ones I've come across are willing to discuss and debate & consider alternative ways of meeting requirements.

And one of the best ways to challenge any auditor is to know the Standard very well indeed, and keep debate to what the Standard itself says - which effectively undercuts personal interpretations.

To enhance customer satisfaction by meeting customer requirements...that is my mantra. And I ask myself every working day if my organisation has evidence to show that it is doing just that.

An interesting view! This is one of (several) terms in ISO9001 that confuse me. I would have thought that to "enhance customer satisfaction" you would need to go beyond "just" meeting customer requirements by "exceeding" them in some way, or perhaps by meeting their expectations (if these go beyond basic or stated requirements). Perhaps the words ‘to ensure’ would be more accurate...?

An interesting view! This is one of (several) terms in ISO9001 that confuse me. I would have thought that to "enhance customer satisfaction" you would need to go beyond "just" meeting customer requirements by "exceeding" them in some way, or perhaps by meeting their expectations (if these go beyond basic or stated requirements). Perhaps the words ‘to ensure’ would be more accurate...?

Good point, Peter, however, the idea behind the 'model' of a QMS in ISO 9000 is based on the premise that the organization has to consider its position in the market place and if the customer base actually wants to have their expectations exceeded! Or indeed, if expectations can be identified. I believe that it's very difficult in many situations for a company to do either and the customer doesn't require it anyway.

Good point, Peter, however, the idea behind the 'madel of a QMS in ISO 9000is based on the premise that the organization has to consider its position in the market place and if the customer base actually wants to have their expectations exceeded! Or indeed, if expectactions can be identified. I belive that it's very difficult in many situations for a company to do either and the customer doesn't require it anyway.

Yes. :agree1: If most or many of a customer's suppliers don't meet expectations, you can exceed their expectations just by consistently meeting the requirements.

An interesting view! This is one of (several) terms in ISO9001 that confuse me. I would have thought that to "enhance customer satisfaction" you would need to go beyond "just" meeting customer requirements by "exceeding" them in some way,

Possibly. Certainly Sony's Walkman exceeded the requirements of the pocket transistor radio buying public. Enhanced satisfaction with Sony products resulted, as evidenced by the death of the pocket transistor radio.

or perhaps by meeting their expectations
Many customers have a hierarchy of requirements, from must-haves though nice-to-haves and up to life-would-be-perfect-if's. If you are operating on the must-have level and move up to the nice-to-have level, you have enhanced customer satisfaction.

At the same time, you have improved your chances of retaining their business.

if these go beyond basic or stated requirements.It's up to you - and to your benefit - to learn these unstated requirements. 7.2.1(d) mentions "any other requirements determined by the organization."

Knowing these requirements can help you stand out from the pack.


Perhaps the words ‘to ensure’ would be more accurate...?Nah. No change necessary.

Your flow diagram looks okay. One thing we have done with our flow diagrams to make them even more useful is that we associate the implementing procedure to the steps and hyperlink to the procedure itself. Users can then use the flow diagram to understand where in the process they are; what procedures they need to use; and can actually go to the procedure all from one place.
Hope this helps.

One thing we have done with our flow diagrams to make them even more useful is that we associate the implementing procedure to the steps and hyperlink to the procedure itself. Users can then use the flow diagram to understand where in the process they are; what procedures they need to use; and can actually go to the procedure all from one place.
Hope this helps.

That can be a very handy thing.

You can incur a maintenance burden as procedures get deleted from the system and new ones added.

Another reason to be lean in your documentation.

Hello everyone,

Please can you view/critique my latest attempt to get this right.

Thanks in advance,

Stephen

Hello everyone,

Please can you view/critique my latest attempt to get this right.

Thanks in advance,

Stephen

Stephen,
Stare real hard at the process map in 0.2 of ISO 9001:2000. Start with that as your model.

The top box inside the PDCA circle is management responsibility. ISO 9001 identifies the elements of management responsibility. What processes does your management use to fulfill its responsibilities? What are the inputs to, for example, provision of resources? What are the outputs from provision of resources? What is the sequence of steps in the process that leads from an identified need for a resource to the resource itself?

Follow the same thought process for resource management, product realization, and, measurement, analysis and improvement.

This is not going to fit on one page. Sorry. If you must have a one pager, cop the one from clause 0.2 and add pointers to your other charts to it.

I've added a little tutorial attachment. I hope it helps.

See also post #82 in this thread for another point of view.

Cliff Kachinske

Thanks for your comments Cliff. I have pinched this idea from someone else and adapted it to suit my company. Is this more like it?

I'm at the stage where I just want any old diagram to scrape through the assessment.

Thanks again,

Stephen

Thanks for your comments Cliff. I have pinched this idea from someone else and adapted it to suit my company. Is this more like it?
Seems better, assuming the department names across the top are actually understandable in terms of your company's departments.

I notice production does production planning, but doesn't actually produce anything. How does that work?

It seems like some of your supporting processes aren't accounted for. How about calibration, for example?


I'm at the stage where I just want any old diagram to scrape through the assessment.
I have felt your pain and I understand it. Therefore I'm going to pad my cluebat with a pillow :tg:, but you still get a resounding WHAP from the cluebat.

These diagrams can be a good learning tool. Creating, or seeing them for the first time, often surprises management who might be a wee bit insulated from what's actually going on. That's why some call it a voyage of discovery.

Thanks for your comments Cliff. I have pinched this idea from someone else and adapted it to suit my company. Is this more like it?

I'm at the stage where I just want any old diagram to scrape through the assessment.

Thanks again,

Stephen

Hi Stephen,

To add to Cliff K's notes above...there are a few other Management System processes which are conspicuously absent from your System Model, namely:

Control of Documents
Control of Records
Infrastructure and Service Support
Control of Non-conforming Products and Materials
Change Control
Control of Monitoring and Measuring Devices.
Also, your sequence of processes is not quite right; it should be:

1) Implement process (which ever you choose)
2) Monitor, Measure and analyze performance
3) Conduct Management Review
4) Implement Corrective/Preventive/Improvement Action
5) Repeat cycle

Also, if you follow your flow...subsequent to Dispatch of goods, you identify Analysis of Customer Feedback/Supplier Performance/Competency Data...but you do not input this information into Management Review...your sequencing is in need of some repair.

Your organizational structure is also questionable...no Quality Department? Purchasing and Materials Management?? Machine Maintenance?

Back to the drawing board....

Patricia Ravanello

Food for Thought: An Organization as an Extended System (http://elsmar.com/Imp/sld037.htm)

Thanks for your comments Cliff. I have pinched this idea from someone else and adapted it to suit my company. Is this more like it?
I'm at the stage where I just want any old diagram to scrape through the assessment.
Thanks again,
Stephen

Hi
For achieving your process mapping, you can follow the following stages:

1: Identify all processes
Note:
-In this step, you can't mix procedures and processes
-Start with the general approach.

2: Classify all processes in these 3 levels:
--Level 1_process of realization: creating the value directly for customers, employee, and investor (i.e: process of production)
--Level 2_process of support: providing resources to permit the execution of the processes of realization, these processes don't create the value directly (i.e: processes of quality)
--Level 3: processes of direction: create the vision of the enterprise, influencing the environment in which processes of level 1 and 2 are going to take place (i.e: processes of internal communication)

3: Identify all interactions


I tried to remake your process mapping (I hope that is going to help you) but I am sorry for my English writing.
I try to improve my skills in English

Best regards

Just reviving an old topic on Process Mapping / Sequence of Interaction...hoping to get newbies to submit their examples or us experienced folks to submit any changes that we may have done.

I personally have not upgraded / changed mine other than adding new process references (procedure #'s) since we have a new facility. Right now, best to leave "what works for us" alone and not change/improve until later.

I actually use the process flow diagram right out of the ISO 9001:2000 spec in my QM. No problem with the auditor on it. The auditor mentioned that everyone uses diagrams now which I thought was interesting. I was a QM for a automotive company and changed their system from QS to TS and I made turtle diagrams. A different company I worked at was AS 9100 and I didn't need process diagrams at that job either when I wrote their manual. I pulled together 2 process maps showing the relationship of the flow. :D