Could I get some professional opinions on my Process map draft? Is this too detailed? or not enough detail?
Thanks in advance.
Regards,
Jose

Welcome to the cove!

Since you asked, here's my (admittedly biased) $.02. Technically I don't believe it's a process map. It looks like functional group responsibilities superimposed on the ISO process model with a flow of product realization.

Some of your processes may have the same names as the functional groups, but I dont' think you're really identifying your processes (or why would you have two processes named purchasing?). Also, I believe that you may be missing some of your processes that aren't in product realization.

I would start by identifying the processes of your system and make sure that each is really a process (transforms inputs into outputs). For example, look at the "Management" block in product realization. The process is probably really something like "Order Review." The primary inputs are sales orders and the outputs are approved orders.

Once you've identified the processes, connect the outputs of processes with the inputs of other processes, and you'll have a process map. There is no need to try to force it onto the ISO process model.

I'd be interested to hear other opinions...

Sure, I agree with Howste.

The names inside the product realization are all department names. You would have to determine what process each department does, what are the inputs, what are the outputs, what resources are needed, what controls are in place, etc.

For example warehousing could be called "ship product" with inputs (received product, shipping order), outputs (shipped product), activities (inspect product, package product), controls (inspection criteria, packaging standard), monitor/measuring (customer complaints, ontime shipping).

Another option is to look at product realization as one process. This would probably work if your process is not too complex.

Thanks for the feedback!
I think I might have to go with product realization as being 1 process. Does the new draft appear to be quality system process map now to comply with 4.1?

I believe it should look more like your company, not like the ISO process model. I've attached an example of one that I think is pretty good.

...and here's the one I use...just without the ISO bridgework.

Thank you all for the constructive feedback. I have made some more adjustments to my Process Map. Do you think its conforming now to the ISO requirements?
I appreciate all your opinions.

Thank you all for the constructive feedback. I have made some more adjustments to my Process Map. Do you think its conforming now to the ISO requirements?
I appreciate all your opinions.

Many people fail to remember that it should first conform to what your company actually does, then it must conform to ISO. It's supposed to be a view of what you do from 30,000 ft.

Personally, although it makes sense I still agree with Howste in that it looks too similar to the ISO model from the standard.

Also, I'm not entirely sure of what you do? If I read the map correctly (and assuming I haven't overlooked anything) you seem to be a merchandising company. A request comes in, purchasing calls the vendors, product comes in and you recieve it, then you ship it to the customer. Is this correct or do you do anything with the product?

Many people fail to remember that it should first conform to what your company actually does, then it must conform to ISO. It's supposed to be a view of what you do from 30,000 ft.

Personally, although it makes sense I still agree with Howste in that it looks to similar to the ISO model from the standard.

Also, I'm not entirely sure of what you do? If I read the map correctly (and assuming I haven't overlooked anything) you seem to be a merchandising company. A request comes in, purchasing calls the vendors, product comes in and you recieve it, then you ship it to the customer. Is this correct or do you do anything with the product?

Yes. We are simply brokering. We get Request for quotes, source our vendor availabilities, quote our vendors stock with a mark up, get an order from our customer, buy it fro our vendor, receive and inspect it, then ship it to customer.

We are simply brokering. We get Request for quotes, source our vendor availabilities, quote our vendors stock with a mark up, get an order from our customer, buy it fro our vendor, receive and inspect it, then ship it to customer.

I think you've encapsulated your core business processes in this statement! Why not try & map it like that?

I think you've encapsulated your core business processes in this statement! Why not try & map it like that?

:cool: That was my directive...just had to push it a weird way.

Thank you all for the constructive feedback. I have made some more adjustments to my Process Map. Do you think its conforming now to the ISO requirements?
I appreciate all your opinions.


I would have difficulty accepting this if I were auditing you. Only the bottom (Cl 7) seems to actually mention the "processes you folks do. The rest of the verbiage appears to be reciting the clause numbers.

You need to make a list of the primary, core, processes that describe what you actually do for your customers.

Also, list the supporting or administrative processes you do to support those core processes (training, auditing, corrective action, etc.).

These two lists then have to be developed as discussed in clause 4.1.

My problem is not with your diagram, I have a problem with the fact it does not address your processes.

I would have difficulty accepting this if I were auditing you. Only the bottom (Cl 7) seems to actually mention the "processes you folks do. The rest of the verbiage appears to be reciting the clause numbers.

You need to make a list of the primary, core, processes that describe what you actually do for your customers.

Also, list the supporting or administrative processes you do to support those core processes (training, auditing, corrective action, etc.).

These two lists then have to be developed as discussed in clause 4.1.

My problem is not with your diagram, I have a problem with the fact it does not address your processes.


Thanks alot for your professional input. I took it to heart and made some changes. What is your opinion now?

Thanks alot for your professional input. I took it to heart and made some changes. What is your opinion now?


I think it is clearly better. It might work for one of my audits, though I would need to review it more. But, definitely better. I personally, prefer a simpler approach. I have seen a straight line of core processes, going from Sales through Engineering, Purchasing, Scheduling, Manufacturing to Shipping. These are the "core" Customer Oriented Processes. Then, put an oval around it. All the support processes would be on this oval. (Sorry, I don't have a diagram to post). The inputs and outputs can be described on a matrix or some turtle diagrams.

The benefit of this approach is it is very simple and easy for everyone to understand. If they understand it easier, then it would be more likely to actually be used.

Just my personal approach.:2cents:

Does anyboday else have any feedback regarding my Process map?

I'm with hjilling, I prefer a simpler approach.

Look, taking a purely design & usability focus, my first reaction when I opened your map was that I literally didn't know where to look. It appeared rather cluttered & very busy.

I found it odd to have such a heavy amount of 'action' on the right hand side of the map and such a big empty space on the top left. Western readers generally start at the left side of a page and read across - but you've got a blank there. And an extremely large yellow rectangle on the right, which is very dominant.

I don't doubt you've got a lot of info on the page - but do you really need it all? I'd be inclined to put it in front of some people and ask them: what's your first impression (ie, can they understand it fairly easily or not?). My guess is not. And (unless it's not a good idea) try some people at work - if they can't follow it, then you've got a problem, & I'm guessing they probably can't. I'd like to see you end up with something that's kind of quickly 'obvious' & clear.

I'd be much more inclined to start with the beginning (eg, requests for quotes, etc) & put that at the left side (assuming your flow is left to right), then move through the main activities actually associated with core business - ie, getting & selling stuff & ending with delivery to customer at right. Keep them similar sizes and evenly distributed.

Then make the rest of the processes subordinate, which they are. Sorry to be so critical - but as is, it's not really easy to read.

I'm with hjilling, I prefer a simpler approach.


I'd be much more inclined to start with the beginning (eg, requests for quotes, etc)

Is RFQ the begining???

How about strategic planning? (ISO 9004:2000)

Does anyboday else have any feedback regarding my Process map?

If you've read my previous posts on this subject, you'll know that I'm a bit of a maverick when it comes to the System Process Map. I don't agree with most of what I've seen posted.

The standard says:

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 believe that you have combined and confused "Key" processes with "Secondary" processes. I don't believe that you have to include the secondary processes of Product Realization - it's far too complex, and it's captured in your "Product Realization" flow chart, you don't have to duplicate it here. That's not what the standard is requesting. It's asking for the processes which define your Management System, not Product Realization.

What you have to do is:
1) Define your KEY PROCESSES (most organizations don't have more than 12 or 15). For the purposes of the "Map" it helps to group them together into System-, Management-, Support-, or Customer-oriented classifications.
2) Demonstrate their "Sequence" and "Interaction".


If it's done properly, it will demonstrate how Senior Management steer the organization toward its goals and objectives, for all processes: customer-, support, management-, and system-oriented.

In the attached "corner" of a "System Process Model", you see, I've grouped together 4 "support-oriented" processes (SOP-0006,7,8, & 9). These processes interface and provide input to the "Business Planning & Management Review" process (per SOP-0003). How?...these support processes produce output which are monitored, measured & analysed (per SOP-0005) and reported to Management. Management reviews the results (per SOP-0003), and feeds back Corrective or Preventive Action or Continual Improvement (per SOP-0005) into the respective process.

The same dynamics happen for the customer-oriented processes. You plan, implement, monitor, measure, analyse, review, correct/prevent improve...etc.

I believe they're asking for how the system works...not how Product Realization happens.

Also, I can't remember all the details in your map, but I don't recall seeing the "Control of Monitoring & Measuring Devices", or "Control of Documents and Records", or "Change Control"...

I hope this is helpful, and not confusing...I know it's a bit of a deviation from the popular approach.

Patricia Ravanello

P.S. Putting arrows between processes to connect them, does not explain the interaction. I think this Map needs to communicate to employees what the dynamics are between the processes. Example: Your Infrastructure link to Management doesn't explain the dynamics. It is not accurate and doesn't explain how the Management Review process impacts on the performance of Infrastructure processes.

Could I get some professional opinions on my Process map draft? Is this too detailed? or not enough detail?
Thanks in advance.
Regards,
Jose

Hello Jose,

Allow me to come back to your original post. By now you have seen many examples of process maps. Good intentions and great suggestions from all Covers. But......in the end, you must do what makes most sense to your company and its employees. If your process map works for you and it meets the intent of the Standard...go at it! If you decide to incorporate all suggestions, you may end up with something you may not like at all. Remember that a camel is a horse designed by a committee.

Good Luck Jose!

Stijloor.

It looks to be thorough, but it is too busy in my opinion. Better use of fonts (larger, cleaner - I prefer arial and Tahoma), colors and layout would help. I would use more decision points as opposed to just arrows.

But the bigger question is "Does it work for you?" and secondarily "Does it work for your auditors, suppliers and customers?

If you've read my previous posts on this subject, you'll know that I'm a bit of a maverick when it comes to the System Process Map. I don't agree with most of what I've seen posted.

The standard says:

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 believe that you have combined and confused "Key" processes with "Secondary" processes. I don't believe that you have to include the secondary processes of Product Realization - it's far too complex, and it's captured in your "Product Realization" flow chart, you don't have to duplicate it here. That's not what the standard is requesting. It's asking for the processes which define your Management System, not Product Realization.

What you have to do is:
1) Define your KEY PROCESSES (most organizations don't have more than 12 or 15). For the purposes of the "Map" it helps to group them together into System-, Management-, Support-, or Customer-oriented classifications.
2) Demonstrate their "Sequence" and "Interaction".


If it's done properly, it will demonstrate how Senior Management steer the organization toward its goals and objectives, for all processes: customer-, support, management-, and system-oriented.

In the attached "corner" of a "System Process Model", you see, I've grouped together 4 "support-oriented" processes (SOP-0006,7,8, & 9). These processes interface and provide input to the "Business Planning & Management Review" process (per SOP-0003). How?...these support processes produce output which are monitored, measured & analysed (per SOP-0005) and reported to Management. Management reviews the results (per SOP-0003), and feeds back Corrective or Preventive Action or Continual Improvement (per SOP-0005) into the respective process.

The same dynamics happen for the customer-oriented processes. You plan, implement, monitor, measure, analyse, review, correct/prevent improve...etc.

I believe they're asking for how the system works...not how Product Realization happens.

Also, I can't remember all the details in your map, but I don't recall seeing the "Control of Monitoring & Measuring Devices", or "Control of Documents and Records", or "Change Control"...

I hope this is helpful, and not confusing...I know it's a bit of a deviation from the popular approach.

Patricia Ravanello

P.S. Putting arrows between processes to connect them, does not explain the interaction. I think this Map needs to communicate to employees what the dynamics are between the processes. Example: Your Infrastructure link to Management doesn't explain the dynamics. It is not accurate and doesn't explain how the Management Review process impacts on the performance of Infrastructure processes.

Thanks Patricia/Maverick. I want to make clear that the map is in its drafting stage. Iam having trouble I guess in identifying my key processes. What is the best way to identify them? I didnt even know I was supposed to have a seperate product realization flow chart! Control of Monitoring & Measuring Devices is an exclusion of ours. But control of docs would be in my QMS maintainance. Patricia, in the end does my map meet the standard?

I think it is clearly better. It might work for one of my audits, though I would need to review it more. But, definitely better. I personally, prefer a simpler approach. I have seen a straight line of core processes, going from Sales through Engineering, Purchasing, Scheduling, Manufacturing to Shipping. These are the "core" Customer Oriented Processes. Then, put an oval around it. All the support processes would be on this oval. (Sorry, I don't have a diagram to post). The inputs and outputs can be described on a matrix or some turtle diagrams.

The benefit of this approach is it is very simple and easy for everyone to understand. If they understand it easier, then it would be more likely to actually be used.

Just my personal approach.:2cents:

hjilling,
I did a some formating and tweeks. Though I highly appreciate all the members input I value your opinion hjilling and want your feedback. I have read some of your other posts on process maping and I found it to be enlighting. I think this map should be conforming to ISO and internal purposes. I also did some color coding on this one to reflect QM/ISO clauses. I also referenced my QS procedures for each process. Though I could be wrong, I believe the process maps should be more detailed and not too simple or general for small companies. Almost like a flowchart. Wouldnt it be easier to identify detailed improvements with having detailed processes for smaller companies instead of having 2 or 3 sets of processes? :thanks:

Thanks Patricia/Maverick. I want to make clear that the map is in its drafting stage. Iam having trouble I guess in identifying my key processes. What is the best way to identify them? I didnt even know I was supposed to have a seperate product realization flow chart! Control of Monitoring & Measuring Devices is an exclusion of ours. But control of docs would be in my QMS maintainance. Patricia, in the end does my map meet the standard?

Originally Posted by josecortez

Hi Jose...
I applaud your tenacity!:applause:

Re: Flow Chart of Product Realization:
There are no mandatory Flow Charts...it's simply the preferred approach, since long, and verbose narratives are of limited appeal and efficacy.

Re: Identifying Key Processes:
I know it's difficult to sort through everything and create neat little piles of documents, but essentially that's what you have to do to identify your Key Processes. Key Processes are the "Parent" activities, and the rest of sub-processes are the "kids." In going through this exercise ask yourself, "Is this a Parent process, or is it a sub-process, or is it a member of another family of activities?'

Your Key processes will then become more evident.

Here's a couple of examples (these are from automotive-associated organizations):

Parent process:
Purchasing and Materials ManagementAssociated subordinate processes:
1) Purchase Order Requisition Process
2) Competitive Quotation Process
3) Potential Supplier Selection Process
4) Supplier Performance Evaluation Process
5) Incoming Product Receipt Verification
6) Qualification of Incoming Materials
7) Handling and Storage of Materials
8) Supplier Issue Resolution
9) Supplier Performance Tracking


Parent Process:

Product Realization

Associated Subordinate Processes:
1) Contract Review and Program Approval
2) Quotation
3) Concept Development
4) Product Design, Development and Verification
5) Process Design, Development and Verificaiton
6) Product Design Validation
7) Process Design Validation
8) Production Part Approval Process
9) Part Production
10) Product Identification, Packaging, Storage
11) Product Delivery...
12) Etc.............

So when you create your "Key Processes Map", you don't have to include all the subordinate processes.

To answer your question, "Does my map meet the Standard?", I believe the only answer I can provide is, "It depends on who's looking at it"...I'm quite certain that most Auditors would accept it, so I guess that might be an indication that it "meets the standard".

If you're asking me personally, the answer is no, it does not satisfy the requirements of 4.1.a and b., but you're definitely heading in the right direction.

No one said it was going to be easy.
Hang in there...
Patricia Ravanello

Re: Identifying Key Processes:
I know it's difficult to sort through everything and create neat little piles of documents, but essentially that's what you have to do to identify your Key Processes. Key Processes are the "Parent" activities, and the rest of sub-processes are the "kids." In going through this exercise ask yourself, "Is this a Parent process, or is it a sub-process, or is it a member of another family of activities?'

Your Key processes will then become more evident.

Here's a couple of examples (these are from automotive-associated organizations):

Parent process:
Purchasing and Materials Management
Associated subordinate processes:

1) Purchase Order Requisition Process
2) Competitive Quotation Process
3) Potential Supplier Selection Process
4) Supplier Performance Evaluation Process
5) Incoming Product Receipt Verification
6) Qualification of Incoming Materials
7) Handling and Storage of Materials
8) Supplier Issue Resolution
9) Supplier Performance Tracking



Parent Process:

Product Realization
Associated Subordinate Processes:

1) Contract Review and Program Approval
2) Quotation
3) Concept Development
4) Product Design, Development and Verification
5) Process Design, Development and Verificaiton
6) Product Design Validation
7) Process Design Validation
8) Production Part Approval Process
9) Part Production
10) Product Identification, Packaging, Storage
11) Product Delivery...
12) Etc.............


So when you create your "Key Processes Map", you don't have to include all the subordinate processes.



hello guyz , im back and quite in the mood to post mine. I like this guy who continuosly posting his map. :applause:

Am also an apprentice about this process mapping and this cove have had scrutinize my postings before and it has handed me a lot of things.

As for ms. patricia is saying, identifying the key processes is all you have to show in your process map, am a big fan of her coz of her straight forward approach. hope my post helps.

am still in the process of studying it for some possible improvements as i've told you am still an aprrentice and this cove has given something to look at on the brighter side. Thanks to all.:bigwave::bigwave::bigwave:

jerzki ( im back!!!! ) :biglaugh:

hello guyz , im back and quite in the mood to post mine. I like this guy who continuosly posting his map. :applause:

Am also an apprentice about this process mapping and this cove have had scrutinize my postings before and it has handed me a lot of things.

jerzki ( im back!!!! ) :biglaugh:

Hi Jerzki,

Thanks for your kind words...Sorry, I don't have much time to critique your work, but would like to offer a suggestion on your Flow Chart for the Contracts Bidding Process.

You could greatly simplify your Flow Chart by eliminating all the arrows to the left and right of the process.

1) Rather than have a "responsibility" column, just identify the person responsible in the Process box (see attached example). You won't have such a tangle of lines, and won't have to jump around from box to box to get the complete picture. It also allows more flexibility for the twist and turns of the "layout" of the flowchart. Few flowcharts are "straight line" processes.

2) Always start the activity with the title of the person performing the activity, that way employees become conditioned to looking in a specific place for that information. Bold-face and color the "Job Title", for prompt and easy recognition.

3) Put your output (evidence) right next to the process, and always on the "right side", so again, users will know where to find the 'Output", and again, eliminate the line and arrow. Color code for prompt recognition (as you did).

4) You don't seem to have any input to any processes. Using the same principle as "2" above, put all your input to the left of the "process box", and color code it too.

Also, I have a question for you...Where is all the rest of the information that tells a person what they have to do, or tells the internal auditors what they are supposed to be confirming? Do you have separate narrative Work Instructions? How are people trained from such "cryptic" flow charts?

...Or perhaps anyone else out there who is using a similar format could answer these questions.

Thanks again,
Patricia Ravanello

Also, I have a question for you...Where is all the rest of the information that tells a person what they have to do, or tells the internal auditors what they are supposed to be confirming? Do you have separate narrative Work Instructions? How are people trained from such "cryptic" flow charts?


Again, please accept my sicncerest appreciateion for the comments you are suggesting. I belive this is one improvement i have to made to my documents as I can see it, my documents are really tangled with lines :yes:

Where is all the rest of the information that tells a person what they have to do, or tells the internal auditors what they are supposed to be confirming?

... yes , we have a defined work instructions necessary to perform definite tasks, however this WI's are made if it is deemed necessary for the complexity or sensivity of that activity or process.

How are people trained from such "cryptic" flow charts?


....:biglaugh: unfortunately our people are not yet trained for this for we are in the process of developing.

I personally loved your straighforward approach and I would like to apply it to the system we are currently developing. Again, a big THANK YOU for your continous support and share of knowledge.

jerzki:biglaugh:

P.S.

about the inputs and outputs , that thing I will add.:thanks:

Hello all,
great discussion
very interesting subject

first I would like to take your opinion about our company process model. (still draft)

I hope, I make it right
and ofcourse welcome to any advise for any one

another thing, I don't know but some how I got confused between the difference between process model and Quality plan

my understanding is that Quality plan is the Document specifying which procedures and associated resources shall be applied by whom and when to a specific project, product, process or contract.

so it is very close to the process model, in another word we can say Quality Plan for the company can be called Process Model

so please correct me if I was wrong

Thanks.

[QUOTE=wessamsheta2000;203176]Hello all,
first I would like to take your opinion about our company process model. (still draft)
QUOTE]

If your "Process Model" is in response to the following,

4.1 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:
4.1.a) identify the processes needed for the quality management system and their application throughout the organization (see 1.2)
4.1.b) determine the sequence and interaction of these processes;
then, I believe you have failed to isolate your "Management System" processes. What you have created is more like an overview flow chart of Product Realization with links to other system processes.

This type of model does not demonstrate that you understand how the system is supposed to work. Also, for the most part, this model only demonstrates sequence and not interaction.

Re: Quality Plan:

The Quality Plan can mean different things to difference companies, and the standard allows for some latitude in its definition. As seen in the "Notes" under 7.1 in ISO/TS 16949:

NOTE 1: A document specifying the processes of the quality management system (including the product realization processes) and the resources to be applied to a specific product, project or contract, can be referred to as a quality plan.

NOTE 2: The organization may also apply the requirements given in 7.3 to the development of product realization processes.
NOTE: Some customers refer to project management or advance quality planning as a means to achieve product realization. Advanced product quality planning embodies the concepts of error prevention and continual improvement as contrasted with error detection, and is based on a multidisciplinary approach


In some companies, the Control Plan might actually encompass all these requirements. In other companies, there may be a series of documents which together cover all the bases, such as APQP. What is important is that the intent is met, that is, that the Quality Plan identifies:

Per the requirements of 7.1...
a) quality objectives and requirements for the product
b) the need to establish processes, documents, and provide resources specific to the product
c) required verification, validation, monitoring, inspection and test activities specific to the product and the criteria for product acceptance
d) records needed to provide evidence that the realization processes and resulting product meet requirements (see 4.2.4)
The output of this planning shall be in a form suitable for the organization's method of operations.

Again, the standard offers latitude in that the Quality Plan can be in a "form suitable for the organization's method of operations". However, the Quality Plan is definitely more than a "Flow Chart", or a one page document. It has to encompass all of the above-listed requirements.

Hope this helps.
Patricia Ravanello

You know...this whole thing about having to develop a process map is 100% non-value added anyway. What will we do with it when it is done? Who does do something with it right now? Who is to decide what is a process or is not? Is management review a process? Some registrars do not think so and some do. If the selected process does not lie in the "Line of Sight" it has been said to not be a process in ISO terms.

So what. Do we simply keep arguing about what is and what isn't a process? What is a good map and what isn't? Which comes first and which comes last? Does it really make sense? We probably know how our system flows, why not a simple flow chart with no real assignments or designations on it just how product gets through our facility?

I don't know, I just sort of feel that just when we thought we were getting ISO and QS (TS) in our blood and just getting used to it, someone made a change that now has us all filling up forums and questioning our own abilities and developing all sorts of roadmaps that will be folded up and put away.

Are we helping ourselves?

GMAC49

Well said Mr. MacLean.

JohnCTB

We probably know how our system flows, why not a simple flow chart with no real assignments or designations on it just how product gets through our facility?

I think that is one of the reasons Process Maps do provide real value. I have worked at a number of places, and at each one there were management and technical people that thought they knew how the system flowed. They were floored to find out how it really flowed when looking at a process map.

Process Maps also allow one to find redundancies, illogical loops and unnecessary work.

You know...this whole thing about having to develop a process map is 100% non-value added anyway. What will we do with it when it is done? Who does do something with it right now? Who is to decide what is a process or is not? Is management review a process? Some registrars do not think so and some do. If the selected process does not lie in the "Line of Sight" it has been said to not be a process in ISO terms.

So what. Do we simply keep arguing about what is and what isn't a process? What is a good map and what isn't? Which comes first and which comes last? Does it really make sense? We probably know how our system flows, why not a simple flow chart with no real assignments or designations on it just how product gets through our facility?



I am more than mildly appalled at your attitude, and your admission of failure to understand the role and significance of a "Key Process Map". I sympathize with the frustration people have expressed herein, in trying to create such a Map, and am not surprised that your conclusion is that they are "non-value added". I would have to agree with you on that point, based on most of the sample models that I have seen posted here on this site. They don't offer any value, because they aren't what the standard is asking for. They are "process cocktails", mixing and interfacing major and minor processes from various levels of the "System" without distinction.

Which comes first and which comes last?....that's a question which each organization needs to address and to answer, it's not just a masochistic exercise. It's a reality for which Senior Management must take ownership. The answer to that question will guide Sr. Mgmt in how to steer their ship....how to keep it on course, and how to make it turn left or right, how to stop or go, and how to accelerate or to decelerate. It's how the "SYSTEM" works.

We probably know how our system flows, why not a simple flow chart with no real assignments or designations on it just how product gets through our facility?

...I agree...a simple flow chart should do, however, it should be of your "Management System Processes"....not one of "how the product gets through the facility". That's not what the Standard is asking. The question of "How the product gets through the facility", should be answered in your "Product Realization" Flow Chart.


Do we simply keep arguing about what is and what isn't a process?

I don't think we have to argue about what is and what isn't a process. Each organization just has to decide what their "Key Management System Processes" are, and everything else should fall into place.

Respectfully,
Patricia Ravanello

Well, Patricia, did I hit a button? I didn't mean to, believe me. But I have been a part of so many different audits on what different organizations have identified as their processes and then on how those same organizations have portrayed their process sequence and interaction that I have become hardened to the subject.

I know from first hand experience that if the organization does what the registrar wants them to they will be applauded. However, if they use imagination and creativity and end up with something other than the auditor has in his mind as acceptble - they will be chastised.

The standard doesn't give us any guidance on what to do or how to do it. In fact the standard doesn't even ask for a map or a process flow of any kind. The standard simply wants us to;

4.1.a "identify the processes needed for the quality management system..."

and

4.1.b "determine the sequence and interaction of these processes."

No requirements as to how it is to be done. Whatever requirements are floating aroud regarding format or structure or purely registrar bred. As with all other requirements, we should be able to do what we want to to satisfy this requirement. It doesn't matter what we do as long as we can show which processes are needed, their sequence and how they interact.

That is certainly not the way registrars see it and that is what is forcing this process map discussion. We, as the general public, have allowed registrars to stake their requirements claim however and now it will be difficult to get out from under it.

I have seen many totaloly acceptable approaches used and have accepted most of them when I audit. But, I can tell you this, they were not all process flows as we have been seeing from the examples.

I really don't like K.I.S.S., nor do I use it but my Gawd, isn't it about time we started thinking about the content of the system itself before the method of presentation? Shouldn't we at least try to simplify things?

GMAC49

I hear ya' Gary, and I think your observations are shared by many auditors out there, however, just because everyone else is jumping off the cliff...doesn't give me any comfort. By the way, based on the companies I've seen certified, I don't have a whole lot of respect for what many auditors pass. However, having said that, I wouldn't want to be in the position of jeopardizing an organization's livelihood, due to failure to meet the requirements. It's just unfortunate that "marginal systems", get the same recognition as "exceptional systems", with no distinction. What a shame!

By the way, you didn't hit a button...I'm just passionate about this stuff, and very confident about my approach.

Re: Management System Processes:

The standard doesn't give us any guidance on what to do or how to do it. In fact the standard doesn't even ask for a map or a process flow of any kind. The standard simply wants us to;

4.1.a "identify the processes needed for the quality management system..."

and

4.1.b "determine the sequence and interaction of these processes."


I agree...but who needs guidance? Just do it!! (but Not to be confused with the Product Realization process)


RE: Registrars:

Some registrars are better than others...some are just regurgitating what they've learned in training, without offering any significant guidance or insight to their customers (which they're not supposed to do anyway).

I think the use, abuse and/or misuse of the "Turtle Diagram" is an example of this. I'm tired of hearing myself talk about this, so I'm not going to bore everyone to tears with that discussion yet another time.

Re: Flow Charts/Maps:
Again, I agree, there's no mandate for "flow charts" (in ISO 9000), however, they have become the acceptable and preferred methodology for defining a complex process, including all the twists and turns, and what ifs...?? It's all about "best practice". If you don't see this as "best practice", don't use it. Communicate in a language and methodology that your organization understands.

Re: Content vs. Presentation:

... isn't it about time we started thinking about the content of the system itself before the method of presentation? Shouldn't we at least try to simplify things?

That's what it's all about for me...Content & Simplicity ...it's each person for themselves when it comes to presentation. I'm definitely not preaching presentation (but you can bet your booty that I have some pretty strong preferences in that area).
I hope our dialogue inspires some readers to consider these ideas as they pursue "continual improvements" for their systems.

Patricia Ravanello

P.S. By the way, Flow Charts are mandatory for the processes of Product Realization in ISO/TS 16949, per the requirements of the APQP Manual.

You know what Patricia? The biggest reason I even come on forums such as this one is for discussions like the one we are having or have had. Either I am involved or I just read and learn. Whatever the case, a little more information never hurt anybody and that is just what I get from challenging dialogue and contrasting opinions.

I too, never having a failure, am very confident in my approach, and that is what it really takes. Establish it, write it down, put it in place, keep it up to date and believe in it!

Thanks for your healthy passion Patricia.

GMAC49

[QUOTE=Patricia Ravanello;203227][QUOTE=wessamsheta2000;203176]Hello

first, I would really thank you about your really justification about the difference between the Quality plan and process model (it was really helpful)
I got it

second, in my process model I try to make it clear to my organization to try to apply, so that it doesnot be like the standard (little bit rough)

may be you are right, it needs some modification but I don't know how
cause we still beginners in implementation of QMS

I just want to show the whole process of 2 main things:
1- the action of the company towards getting new projects and how we get them.
2- the action of the company towards the already running projects and how we deal wth them.

so a little bit hard to present, if any one has the same case
it will be very good

third, about your process model
it is some how not clear to me, a little bit difficult to understand
so many info in small areas, small fonts after printout

and the "as applicable" statment gives the idea that these activities may happen or not while I see it is very important like Product assurance planning manual.

any way it is new look to the process model, never see it before, but I think need more modification, keep on

Hi Wessamsheta

You wrote:
second, in my process model I try to make it clear to my organization to try to apply, so that it doesnot be like the standard (little bit rough)

I just want to show the whole process of 2 main things:
1- the action of the company towards getting new projects and how we get them.
2- the action of the company towards the already running projects and how we deal wth them.

Wessam, your Key Process Map should only show your KEY MANAGEMENT SYSTEM Processes. What you are describing are the Phases of Product Realization.
Take a step further back and describe how all the KEY SYSTEM Processes sequence and interface. I don't think you've made a distinction yet between your Key System Processes, and all the subordinate processes.

third, about your process model
it is some how not clear to me, a little bit difficult to understand
so many info in small areas, small fonts after printout

Sorry Wessam, it appears clearly on my screen and in my printouts...I can only suggest that you set your printer to print at 150% or something suitable.

and the "as applicable" statment gives the idea that these activities may happen or not while I see it is very important like Product assurance planning manual.

The reason why "As applicable" sometimes appears in "Input", or "Output" is because the activity serves two purposes, as in this case, it can be either the receipt of a new Request for Quotation (which can take many forms...RFQ for some customers, SOW...or SOR for others, etc.), OR, the Review may not be for a new request, it could be for a "Change" to an existing Program or product, hence, it would be a "Program Change" and the input and output documentation would vary. Those details would be delineated in the associated "Work Instruction" possibly called...WI-0001 Review of Incoming Request for Quote or Program Changes.

As a general rule, in my documentation, I place an asterisk "*", next to input and output documents which are MANDATORY*.

Patricia Ravanello

Interesting topic, thanks you lot!

I am in the process of reviewing our Management system and probably revamping our whole manual.

We currently do not have a Flow Chart, we just have a line in the front of our manual saying:

The Key processes arising from our companies business are as follows.......

We also have a diagram loosely showing the departmental interactions that take place.

I think I have two confusing elements when approaching this:


How do you define a KEY/CORE Process. If you look at any process long enough it becomes key! That's my problem anyway!

How are interactions defined on the diagram, if they are not simply lines?


I would like to develop a good diagram to improve upon the current content of our QM manual, which is just slapped in to fulfill ISO requirements.

FYI, the manual I want to develop will be electronically based and hopefully be fully interactive.

Here is an interesting observation;:cool:

"Wessam, your Key Process Map should only show your KEY MANAGEMENT SYSTEM Processes. What you are describing are the Phases of Product Realization."

I know of at least two registrars who have publicly stated and published exactly the opposite of what you have just suggested. I would have thought all the KEY MANAGEMENT SYSTEM Processes as well but these two registrars phrase it "the line of sight" approach. They include only those activities that result in product realization.:confused:

And still we negotiate, we barter, we discuss and we banter. We have collectively been reduced to a group of bunco gals disecting the latest love novel, and it is not of our own design.

Believe me if there is any organization that has no knowledge of how their system produces product then that organization has jumped the train to oblivion. I just cannot see the value in juggling back and forth on whether a certain activity is a process or not just for the purpose of having a document.

If we do it - it's a process - include it.

This quasi - requirement for a process map has initiated far too many confused participants and confusing dialogue. Though I respect your clearly educated and experienced opinion Patricia I think it is only one of so many hundreds available. We, as a group again, seem to not be able to bring ourselves together under one standardized explanation for anything we do. When we get close (ISO 9001:1994) Someone outside steps in and upsets the cart.

If I speak with 20 professionals I will get some agreement and I will get some disagreement but I will get 20 totally indpendent ideas of how this quasi-requirement should be handled. It's sad, just plain depressing.:(

GMAC49

We have collectively been reduced to a group of bunco gals disecting the latest love novel, and it is not of our own design.

:topic:This is one of those occasions when I laughed, but then realized that I had no idea what I was laughing at. :truce: Maybe some of us like being bunco gals. :tg:

:topic:This is one of those occasions when I laughed, but then realized that I had no idea what I was laughing at. :truce: Maybe some of us like being bunco gals. :tg:

Hi Gary and Jim,

:topic: To avoid cultural confusion among our Cove friends in the rest of the world, here is an explanation: http://en.wikipedia.org/wiki/Bunco

Stijloor.

Of course we like being bunco gals but what we like and what we are steered into believing or herded into doing are two different things indeed. If I could just take the standard for what it says and go on about my business I could afford to be a bunco gal. :biglaugh:

Well, I'm glad you laughed anyway, doesn't matter why we laugh, as long as we can laugh things are bound to be alright.

GMAC49

Manix, you've stated...

I think I have two confusing elements when approaching this:

How do you define a KEY/CORE Process. If you look at any process long enough it becomes key! That's my problem anyway!

How are interactions defined on the diagram, if they are not simply lines?


You might want to look at the thread entitled: Linking Business Process Map with Sub-Process Process Map . In addition, I've posted an attachment here that might help clear your thinking. It lists what I believe to be the minimal "Key Processes" of a Management Operating System (I say minimal because there are many organizations that have other key processes, but they are not mandated by the ISO standard).

It's an animated Powerpoint presentation, but it will advance on it's own...don't click anything after it starts.

The second and third attachments are a partial representation of a "Key Processes Map". It demonstrates how the 4 support-oriented processes (SOPs-0006 through -0009) interface with the Business Planning & Management Review process (SOP-0003), which is through the Monitoring, Measurement & Analysis Process (SOP-0004). You can see how output from one becomes input to the other.

Then, the Business Planning & Management Review process considers the input, identifies appropriate Corrective or Preventive Action, or Continual Improvement (SOP-0005), and outputs it back to the Support Processes.

This is the essence of the dynamics of your Management System...of everyone's (ISO-compliant) Management System. When you think about it, the sequence and interface should be identical for each company, if you are compliant with ISO. It is very generic, and really applies to everyone, because the Standard has mandated the dynamics. How you illustrate it is up to you.

Gary MacLean, you've said...

I know of at least two registrars who have publicly stated and published exactly the opposite of what you have just suggested. I would have thought all the KEY MANAGEMENT SYSTEM Processes as well but these two registrars phrase it "the line of sight" approach. They include only those activities that result in product realization.

You can add dozens more registrars to the two you mention...I really feel like a voice in the wilderness. I think I've said and given samples enough on the subject to make my point. I really don't care to further belabor my seemingly unique perspective. At this point, this thread is becoming redundant...I'm not giving in, or giving up...I just can't provide any further guidance without releasing "copyrighted" materials..
I hope that at least this thread has provoked some thought and re-assessment of how we each have met this challenge. It should not be taken lightly, because if executed properly, it becomes a critical tool for training, and a powerful representation of the organization's dynamics and operational methodology. I hope my input has been helpful, thought-provoking, and inspiring, and not just indiscriminate bantering and posturing.

Patricia Ravanello

Patricia

I too feel we have come to the end of this one - we are at our last thread so to speak. However, one of your last statements just demanded a response. You said you feel like a voice in the wilderness. I can scarcely believe it - I heard your voice several years ago. I too interpret the whole situation in the same manner you do, I believe, at least in the big picture. Details may get messy but I really balked at the "line of sight" thing. It is management processes that ISO is looking for and that is how I have practiced since inception of the "process approach."

Your voice has been heard :applause:

and acknowledged :agree1:

GMAC49

Could I get some professional opinions on my Process map draft? Is this too detailed? or not enough detail?
Thanks in advance.
Regards,
Jose

Hello Covers,

I've been following this thread for the last few days. Thank you Patricia and Gary! What a determination and energy!

I think the OP (josecortez) got his "money's worth"....:tg:

Well done:applause:

Stijloor.

Could I get some professional opinions on my Process map draft? Is this too detailed? or not enough detail?
Thanks in advance.
Regards,
Jose

I apologize. Sometimes it is easier just to get on the bandwagon and start spouting off about what we know or what we think we know than it is to stop and take a look at what the poster's real question is. I missed that first rule.

I should have looked at your map some time ago Jose. Very clean, very direct and clearly, related to the requirements of the standard yet addresses the lne of sight. I like it. Were I to audit your system I would ask for a copy so I could "Benchmark" it on my own time.

Well I just went back and read every post on your orignal query Jose. I wish I had time to read them at the time of posting but I don't always. In my mind you have just crippled your original process map. If you still have the original one compare your very latest with it. Which one can you read? Get the point. The only ones making the rules about how your map will look are the registrars. You need to find a registrar who will accept what you present and say "Good Job." Your system is indeed your system. Not even ISO trys to tell you what to do with it.

I still like your very first one. I have never been one for all those arrows and turn arounds and backing up on one another and duplications and on and on and on. Just flow it and keep it related to ISO. You did that very well in your very first version.



Good Job.

GMAC49

I....The only ones making the rules about how your map will look are the registrars. You need to find a registrar who will accept what you present and say "Good Job." Your system is indeed your system. Not even ISO trys to tell you what to do with it.




Whoa...I would like to strongly disagree. A registrar auditor most definitely should not MAKE rules about your process map. As a registrar auditor, I am only supposed to assess whether your map is appropriate and meets the requirements in cl 4.1.

I have seen many maps which I did not care for personally, but they met the requirements. At that point, we might discuss improvement ideas, but I cannot make "rules" about it.

On the other hand, frequently the maps are not compliant. Then, I still don't make the rules, but I might have to point out where it does not meet the requirements. (Remember, there is no requirement to make process maps.)

There is a big difference between meeting requirements vs. opinions about how process maps should look. Therefore, make your maps to meet the requirements, and provide value to your company, and select good auditors and registrars. But please don't base your selection on whether they like your style of process map.

Manix, you've stated...



You might want to look at the thread entitled: Linking Business Process Map with Sub-Process Process Map . In addition, I've posted an attachment here that might help clear your thinking. It lists what I believe to be the minimal "Key Processes" of a Management Operating System (I say minimal because there are many organizations that have other key processes, but they are not mandated by the ISO standard).


It's an animated Powerpoint presentation, but it will advance on it's own...don't click anything after it starts.


The second and third attachments are a partial representation of a "Key Processes Map". It demonstrates how the 4 support-oriented processes (SOPs-0006 through -0009) interface with the Business Planning & Management Review process (SOP-0003), which is through the Monitoring, Measurement & Analysis Process (SOP-0004). You can see how output from one becomes input to the other.


Then, the Business Planning & Management Review process considers the input, identifies appropriate Corrective or Preventive Action, or Continual Improvement (SOP-0005), and outputs it back to the Support Processes.


This is the essence of the dynamics of your Management System...of everyone's (ISO-compliant) Management System. When you think about it, the sequence and interface should be identical for each company, if you are compliant with ISO. It is very generic, and really applies to everyone, because the Standard has mandated the dynamics. How you illustrate it is up to you.


Gary MacLean, you've said...



You can add dozens more registrars to the two you mention...I really feel like a voice in the wilderness. I think I've said and given samples enough on the subject to make my point. I really don't care to further belabor my seemingly unique perspective. At this point, this thread is becoming redundant...I'm not giving in, or giving up...I just can't provide any further guidance without releasing "copyrighted" materials..
I hope that at least this thread has provoked some thought and re-assessment of how we each have met this challenge. It should not be taken lightly, because if executed properly, it becomes a critical tool for training, and a powerful representation of the organization's dynamics and operational methodology. I hope my input has been helpful, thought-provoking, and inspiring, and not just indiscriminate bantering and posturing.

Patricia Ravanello


There are a numbe rof different ways to diagram a company's processes. I happen to like the Core (COP) vs Supporting (SOP) process approach because it is simple and easy to understand.

Others like a very complex map showing every possible interaction.

Others take other approaches. There is no single correct approach, or everyone would do it my way.

The important things is whether it is accurate, complaint, addresses the required items, and MOST IMPORTANTLY, is it in fact useful to the organization.

Please, define your processes for your needs, not for an auditor.

...If we do it - it's a process - include it.

:applause: GOT to love that idea!!!!! That ought to at least reduce some of the debate!

[quote=Gary E MacLean;203653]

:applause: GOT to love that idea!!!!! That ought to at least reduce some of the debate!

Yeah it will reduce the debate, but it will increase the complexity of the process map!

Again, more out of frustration than anything else, where does it say we need to have a process map - other than in the registrar's mind?:confused: What is said goes something like;

1) Identify the processes: What activities will be your processes, sub-processes and so on?
2) Identify their application througout the organization: What discipine will be affected by or will use what process?
3) Determine the sequence: Which one comes first, second and so on?
4) Determine the interaction: What other processes does the output of each process feed into? Where does each process get their input?
5) Determine criteria: What is the decisive factor of the process? The measure or the standard. Like 100% delivery, or 25PPM. What will you use to decide whether this process is working or not?
6) Determine methods: What do you need to have in place to make certain this process can be utilized and will stay under control. How will you monitor, measure and analyze this process?
7) and so on and so on

The process map or table we are talking about is a creation of someone's imagination. It's like an organization chart. None of the standards ever asks for one but the registrars sure do; of course, we all have one. I regularly promote ideas other than the process map. There are many other methods to clearly and easily satisfy every one of the statements above.

Seriously, is it just me? Are my clients the only ones who do not understand this concept? Are my clients the only ones who, once they have this table or map, never read it or use it anyway? Are my clients the only ones who look at me in amazement and ask me "Now what?"

I can remember at the roll-out of TS when automotive said something like "If this doesn't work this time then it's back to us managing the supplier audit function." Can't they see "IT ISN'T WORKING!" :mad: Registrar's have a blank check. They write what they want and they ignore what they want. They create an approach they like then expect everyone to follow that approach --- before the standards. In general, they stifle creativity and promote registrar dependence. They are creating the system they want to audit and they are pushing it down to the uneducated organization.

The idea that your process map would be too complex if you were to include everything you actually thought was a process seems to me to be self-defeating. "I want to define my system but if I do it will be too confusing. So I had better just do what the registar wants." Doesn't that sort of tell us maybe we should look for a different way to depict our processes?

I worked with a client once who had ten processes. They were all color coded and related with a certain ICON; a sun, a moon, a star and so on. I suggested a couple more processes due to their operation but the Management Quality Rep (MQR) balked. Several times we went through negotiations and debates about whether they needed these additional processes or not. Finally she admitted to me. "I stopped at ten because that is all the ICONS I have."

Not much of an effective control is it? Should we allow the number of ICONS, or the complexity of a process map to stop us from working our system?:confused:

Registrar's have no jurisdiction when it comes to how you satisfy any requirement in the standard. Process map, list of processes, process table, it doesn't matter. The objective, and the only deciding factor, is "Does it work?" I only wish the registrars would realize that.

Again, more out of frustration than anything else, where does it say we need to have a process map - other than in the registrar's mind?

This illustrates the difference between a QMS that defines/controls/measure/improves the business AND satisfying a particular QMS standard.

The process map may help to simply visualise the process, and, sometimes it highlights that the mapped process does not, in fact, fully match the process as performed, especially if this has not been done before. The process map can also provide an opportunity to ID process/activity owners, internal customers, risks, control process costs etc.

Amongst the best quality advice I've been given was from a well known certification/insurance body to design my QMS to describe/control the business first, THEN assess against the relevent QMS standard and make any required changes eg. linkage documents to demonstrate compliance.

I'm inclined to agree with Jane. IMHO this still looks like a set of requirements of ISO shown as an attempt to link them. I rather doubt if your management could 'talk to' this and that's a key consideration. One item that jumps out, by way of explaining myself, is the control of non-conforming product - it doesn't link to anything! It should link to data analysis and then to corrective action and on to management review etc.

Rather than pull your work apart, (and it's too difficult to list all the considerations of what you're trying to do) - have you looked at any other posts here, which have covered the same question?

Again, more out of frustration than anything else, where does it say we need to have a process map - other than in the registrar's mind?:confused: What is said goes something like;

1) Identify the processes: What activities will be your processes, sub-processes and so on?
2) Identify their application througout the organization: What discipine will be affected by or will use what process?
3) Determine the sequence: Which one comes first, second and so on?
4) Determine the interaction: What other processes does the output of each process feed into? Where does each process get their input?
5) Determine criteria: What is the decisive factor of the process? The measure or the standard. Like 100% delivery, or 25PPM. What will you use to decide whether this process is working or not?
6) Determine methods: What do you need to have in place to make certain this process can be utilized and will stay under control. How will you monitor, measure and analyze this process?
7) and so on and so on

The process map or table we are talking about is a creation of someone's imagination. It's like an organization chart. None of the standards ever asks for one but the registrars sure do; of course, we all have one. I regularly promote ideas other than the process map. There are many other methods to clearly and easily satisfy every one of the statements above.

Seriously, is it just me? Are my clients the only ones who do not understand this concept? Are my clients the only ones who, once they have this table or map, never read it or use it anyway? Are my clients the only ones who look at me in amazement and ask me "Now what?"


My main interest in this topic is that I am looking for a starting block to get our management system away from a paper based booklet and into an interactive, electronic format, whilst continuing to meet the objectives of TS.

I see this requirement to define your processes, define the interactions etc.... as a great interactive opening to a Management System, used by everyone within my organisation. SO not only will we meet with the requirements of the spec, but that it will be used by current personnel and provide a fantastic means of training for new personnel.

Using an electronic interactive approach, I see no reason why you can't include - "Everything you do", but perhaps not all in one place (I.e. all on the same map, table, graph........ whatever method used)

Am I right to start here? It is after all the very foundation of the Process Approach, to define processes and there interactions as well as measure and improve..........

Like I have mentioned before, we have never had a process map and always pass our audits, we just have a paragraph saying what our core processes are and how departments interact. This is not enough as far as I am concerned and would like to develop something better. This thread has been enlightening but also a bit confusing because of course there is differing opinions.

PS. Something I have also learned, and maybe this is a very negative thing, but thinking out of the box is great, trouble is, most people (especially some auditors) don't like being outside the box. It's comfortable in the box and stepping outside of it is not a good thing! But hey, how do things move on and become better? I take your points Gary!

I must agree with you Manix about the differing opinions; I don't believe we will ever get away from it though. However, that is what makes ISO exactly what it is - a standard that does not dictate but invites. Yours is a very apropo reply. Your organization has done it the way they have wanted to for some time which does not include a process map. They have gotten registered. As long as you can satisfy the intent (does it work?) there should be no problem.

Now, your looking at either making it more complex or simplifying it. According to ISO you should have the freedom to do so. All you want to do is to make it work for your organization and satisfy the requirements of the standard. We may not want to admit it but there is always a third participant and that is the auditor. At this point your auditor is accepting the approach your company has presented.

I don't know, should you fix something that isn't broken? That's the primary definition of continual improvement but should you? If you are uncomfortable with it and it doesn't seem to do what you think it should, then by all means make it do what you need it to.

About your question "Am I right to start here?" Why did ISO put this requiremet first in the standard? Think about it. You are right on the money. Design it to work for your objectives and for your organization. Make it inviting for the entire organization but make it complete. Don't sacrifice clarity for the sake of brevity. Don't cut out words or any text simply because it seems "too long."

Good comment Manix.

Good Luck

I must agree with you Manix about the differing opinions; I don't believe we will ever get away from it though. However, that is what makes ISO exactly what it is - a standard that does not dictate but invites. Yours is a very apropo reply. Your organization has done it the way they have wanted to for some time which does not include a process map. They have gotten registered. As long as you can satisfy the intent (does it work?) there should be no problem.

Now, your looking at either making it more complex or simplifying it. According to ISO you should have the freedom to do so. All you want to do is to make it work for your organization and satisfy the requirements of the standard. We may not want to admit it but there is always a third participant and that is the auditor. At this point your auditor is accepting the approach your company has presented.

I don't know, should you fix something that isn't broken? That's the primary definition of continual improvement but should you? If you are uncomfortable with it and it doesn't seem to do what you think it should, then by all means make it do what you need it to.

About your question "Am I right to start here?" Why did ISO put this requiremet first in the standard? Think about it. You are right on the money. Design it to work for your objectives and for your organization. Make it inviting for the entire organization but make it complete. Don't sacrifice clarity for the sake of brevity. Don't cut out words or any text simply because it seems "too long."

Good comment Manix.

Good Luck

I hear what you are saying about the "ain't broke..." thing, but although the auditor walks away happy each time, I don't think it serves any purpose whatsoever! 90% of our team don't even refer to the QM from the day they walk through the door, there just shown what it looks like! So although there is a fundamental problem with the use and understanding of our management system that needs addressing, this will have to be the starting point of addressing it!

Thanks for the reassurance on the fact that this is a good starting point! I thought it was, but with so many ideas flowing at once, I was becoming confused as to where to start with all this. To clarify:

- I am going to be taking over as QM in the near future and have been tasked with bringing all of our Management system up to date and more accessible to everyone.

Thanks Gary for your valued opinion. I can take what I have learned here and try and make sense of it all and then make it make sense to everyone else!

where does it say we need to have a process map

.... Registrars have no jurisdiction when it comes to how you satisfy any requirement in the standard. Process map, list of processes, process table, it doesn't matter. The objective, and the only deciding factor, is "Does it work?" I only wish the registrars would realize that.

Utterly true.

ISO 9001 does not (contrary to very strong and widespread belief to the contrary) dictate the existence of one. That said, it's very hard to argue with a dogmatic auditor who is utterly determined to have one.

But just the sheer volume of different approaches to it, and the various models, and the passionate arguments about the merits of one versus the other indicates how widely varied they can be. One person's 'clear' is another's 'mud map'.

My alternative solution? Discuss, debate the Standard & what it actually requires. And if necessary, ultimately seek out & switch certifiers to one with a more intelligent approach. They ARE out there, and switching is infinitely easier than most people know.

You must meet the requirements. Of course. But as Gary says, there's many different ways of doing that. Spending a huge amount of time drawing up a map/diagram/whatever that the business never uses and becomes just a quality manager's millstone ain't worth it. Yeah, it may look pretty. Maybe. Or it may look damned detailed and complex. Or whatever. Acid test: is it really valuable to the organisation? Seriously? (Beyond just something an auditor wants?) If it was, they'd use it.

Yes, I know, I've done it too, for various clients. And in all honesty, I've yet to come across one who found it worthwhile or used it much if at all. In fact, I found many mediocre auditors demanded it in the early days of the new millennium, right when they started auditing to the 2000 version. I figure it was all new to everyone. And the 'audit by the clauses only' auditors were flat out themselves struggling with the 'what is a process' question. Whereas the good certifiers/auditors who'd long been process-savvy were fine.

But I stopped doing it when I just couldn't see the value. And welcomed discussion with auditors & particularly intelligent, educated & enlightened auditors. They were all happy when they could see evidence of all the points you list Gary (all highly valid), but who did not insist on a particular way of it being done.

If organisations continue to accept being held hostage by mediocre auditors/certifiers, then nothing changes. Demand & insist on better. I know it's possible - I get it for my clients, & I refuse to believe it's only here down under. (Or maybe we're right, and we really are top of the world if you reverse the globe).:biglaugh:

Well said Jane. Great, now there are two of us!:biglaugh:

This whole thing is only a game if we decide to play. If we quit playing it becomes serious - like it should be. The stories are many that would proove out what both Jane and I are saying. ISO and TS are both very worthwhile and very valuable business tools but we need to be allowed to interpret them on our own and to make our own approach work.

Thanks again Jane - Kudos

Utterly true.

ISO 9001 does not (contrary to very strong and widespread belief to the contrary) dictate the existence of one. That said, it's very hard to argue with a dogmatic auditor who is utterly determined to have one.

But just the sheer volume of different approaches to it, and the various models, and the passionate arguments about the merits of one versus the other indicates how widely varied they can be. One person's 'clear' is another's 'mud map'.

My alternative solution? Discuss, debate the Standard & what it actually requires. And if necessary, ultimately seek out & switch certifiers to one with a more intelligent approach. They ARE out there, and switching is infinitely easier than most people know.

You must meet the requirements. Of course. But as Gary says, there's many different ways of doing that. Spending a huge amount of time drawing up a map/diagram/whatever that the business never uses and becomes just a quality manager's millstone ain't worth it. Yeah, it may look pretty. Maybe. Or it may look damned detailed and complex. Or whatever. Acid test: is it really valuable to the organisation? Seriously? (Beyond just something an auditor wants?) If it was, they'd use it.

Yes, I know, I've done it too, for various clients. And in all honesty, I've yet to come across one who found it worthwhile or used it much if at all. In fact, I found many mediocre auditors demanded it in the early days of the new millennium, right when they started auditing to the 2000 version. I figure it was all new to everyone. And the 'audit by the clauses only' auditors were flat out themselves struggling with the 'what is a process' question. Whereas the good certifiers/auditors who'd long been process-savvy were fine.

But I stopped doing it when I just couldn't see the value. And welcomed discussion with auditors & particularly intelligent, educated & enlightened auditors. They were all happy when they could see evidence of all the points you list Gary (all highly valid), but who did not insist on a particular way of it being done.

If organisations continue to accept being held hostage by mediocre auditors/certifiers, then nothing changes. Demand & insist on better. I know it's possible - I get it for my clients, & I refuse to believe it's only here down under. (Or maybe we're right, and we really are top of the world if you reverse the globe).:biglaugh:


Sometimes I think we spend more time arguing this stuff, than it takes to just do it.

It is true, ISO and TS do not require process maps, turtles, flowcharts, or diagrams of any kind, per se. HOWEVER, they do require you to define the sequence and interaction of your processes (cl 4.1.b). You may do that in any way you wish, but you do have to do it. So, we can't really say just do whatever you feel like doing. It has to meet cl 4.1.

It just so happens, a few diagrams work pretty simply for most organizations.

I have often heard people say no one uses this stuff. HOWEVER, I have NEVER heard that said at companies whose systems are well developed and well documented...so, I'll let folks draw their own conclusions as to what that means. Perhaps, if we develop it in a meaningful way, our personnel will find meaningful benefit in what we develop.

There is a lot of value in doing this stuff. But, we need to understand what and why we are doing it.

Sometimes I think we spend more time arguing this stuff, than it takes to just do it.

Yeah, me too. But then, not everyone has the wealth of experience - for some, it's an entirely novel idea that one doesn't (just for example) have to have a process map. Gary and you are consultants too - so you've seen many different systems & implementations, as I have. Not everyone has.

It is true, ISO and TS do not require process maps, turtles, flowcharts, or diagrams of any kind, per se. HOWEVER, they do require you to define the sequence and interaction of your processes (cl 4.1.b). You may do that in any way you wish, but you do have to do it.

Yes, of course.

So, we can't really say just do whatever you feel like doing.

Again, of course not. If you are inferring that meaning from anything I have written, it is an incorrect one.

It has to meet cl 4.1.

But of course. Not open to debate.

All I was debating - the sole point I intended to make - was whether one had to have a process map or diagram. Nothing more, nothing less.

But, we need to understand what and why we are doing it.

Hell yeah. Ain't that the truth! (That's one reason why we debate & discuss, I think. To clarify understanding & share info.) :tg:

Although by this time, we've probably confused the hell out of the OP, for which I'm sorry, if so. Trouble is, such interesting conversations begin...

...and here's the one I use...just without the ISO bridgework.

Hi Pazuzu,

I really liked your process map because it is very close to what we do. However on closer examination I feel there maybe a a missing link:

Your management Processes seem to be totally isolated from your customer input. How can this be? Surely the managements planning and objectives should consider the voice of the customer? I see one of your customer inputs is market research. What if this research shows that your customer wants something completely different from you. This diversification would require management review and a degree of planning so this link should be there should it not?

Also, it would be useful to measure how many quotes we actually do turn into business, as this might tell us something about our pricing and the other elements of our quotes that we might be getting wrong (or right).

I might have missed something but it just seems your management review of measurement data is centred around Internal product and process data and not external customer requirements. Just an observation!

Acid test: is it really valuable to the organisation? Seriously? (Beyond just something an auditor wants?) If it was, they'd use it.

Whoa, that's a HUGE ASSUMPTION! Many organisations (trust me I work in one) don't make use of such things for a huge amount of reasons, not just because it's not useful to the organisation. Our quality manual and our quality procedures would probably be useful if they were used, but the fact is in my organisation, it has become a bad habit not to refer to our manual and do it your way!

The same could probably be applied to many organisations with redundant process maps. OK I accept that MAYBE a reflection of the process not working for the organisation, but what about the flip side? An organisation refusing to work in a more efficient manner and everyone having a better understanding of the whole rather than just their individual piece.

Like I have said earlier, people like being in the box, stepping outside is scary. I think it is the same with many organisations, people don't use these maps because it's not their area, they have to step out of their box! IMO!

Because something is redundant, does not mean it is not useful. The people who made it rendundant might just be incompentent!

PS: I wish my organisation had implemented process maps for our key processes, so I would be having an easier time understanding what they are and how they interact. Instead I am having to try and create them myself! (I am taking over the QM in the near future and I am trying to get my head around the management system.

There are many underlying threads throughout this discussion. One of them is "The use of the process map." On one hand some of us would proclaim that "No one uses it anyway." then on the other hand there is a group that says "If they are serious - they will use it."

After careful thought I have to ask "Use it for what?" I mean we, as quality professionals, spend umpteen hours in the development, discussion and revision of our Process Maps but then what do we actually do with it? Please don't respond with a bunch of pretty statements about what COULD be done with it. Really, what is really done with this map? How does anyone really use it? What is the activity you actually require this map for? What do you do today that you could not accomplish without this map?

What comes to mind right away for me is "Show it to the auditor!" Am I wrong? I believe it is something like many people's FMEAs; "Build it at PPAP then file it." Or like we used to be accused of regarding the Quality Manual; "Write it then let it sit on a shelf gathering dust."

If you are really honest with yourself and with your organization I really think you are going to have to say the biggest use of this map is as evidence for the auditor that you have built one. Reminds me of the WPA. You know, one group of guys digs the ditches while the other group fills them up, but at least they all have work.:bonk:

A common remark we get from the QMS & EMS auditors is that our plant and processes are good, the process maps are excellent (as they describe what happens well), but that the employees are not familiar with the ISO process procedures. Even the forms they use, which are controlled and have a form number, etc., the employees do not recognize them as being ISO. They say we have well integrated the ISO into the operations - just it is not recognized as ISO. Sometimes we get an embarrassing comment about ISO from an employee during an audit interview showing that they do not fully understand what ISO is about. We have training sessions for all employees once a year, and part of the training is ISO, but they seem to forget it once they leave the training session.

We are working closely with many of the employees now as we review the process maps, and getting them involved. Ths is the result of Lean Mnaufacturing Implementation, and the few involved are getting a good understanding of what ISO is, and we are hoping that it will be contagious, especially as more and more employees get involved with Lean. I work both ISO and Lean, along with plant engineering (many hats:cfingers:).

There are many underlying threads throughout this discussion. One of them is "The use of the process map." On one hand some of us would proclaim that "No one uses it anyway." then on the other hand there is a group that says "If they are serious - they will use it."

After careful thought I have to ask "Use it for what?" I mean we, as quality professionals, spend umpteen hours in the development, discussion and revision of our Process Maps but then what do we actually do with it? Please don't respond with a bunch of pretty statements about what COULD be done with it. Really, what is really done with this map? How does anyone really use it? What is the activity you actually require this map for? What do you do today that you could not accomplish without this map?

What comes to mind right away for me is "Show it to the auditor!" Am I wrong? I believe it is something like many people's FMEAs; "Build it at PPAP then file it." Or like we used to be accused of regarding the Quality Manual; "Write it then let it sit on a shelf gathering dust."

If you are really honest with yourself and with your organization I really think you are going to have to say the biggest use of this map is as evidence for the auditor that you have built one. Reminds me of the WPA. You know, one group of guys digs the ditches while the other group fills them up, but at least they all have work.:bonk:

We, being intimately involved with the ISO interpretation and implementation, can sometimes forget that those who are reminded of it only once or twice a year or those who have very little to do with it or for it, need to know as well. But how do you transfer the level of involvement a few people have, like yourself, over to the bulk of the employees. You simply can't make a Management Qualty Rep out of everybody in your organization so there must be other measures applied.

Everybody has that same problem; every organization I have ever worked with. From the smallest organization to the largest. It doesn't matter; if you have a group of employees who are not intimately involved with the standards you have a group of people who simply do not understand it to your personal depth. Being a consultant for over ten years and working with upwards of 75 different organizations during that time I have seen many attempts and many different ideas used to try to keep ISO in front of and within the employees daily thinking. A list follows; some of them are the more obvious but some are a bit different. May be worth reading.

1) Of course, Dr Demings favorite (:rolleyes:); posters, banners, and placards proclaiming your registration success. But a twist to this is that the posters and such get changed every so often. I have a client who posts a clause of ISO with an interpretation right below it and changes it once a month. It could take forever to go through the whole standard this way but this client has four posting locations in the same plant and each one has a different clause. At the end of every month there is a public quiz on the four postings with an economical, however attractive, prize for those with a perfect score.

2) Internal auditors need to know the standards. I have seen organizations use their internal auditors to hold training sessions on certain aspects of ISO; particularly those areas that directly affect employees. All employees are invited. Keep it short and pay the employees for the time they are in training.

3) Lunch and Learns: Hold 30 minute discussions on certain parts of ISO during lunch. Buy lunch for everyone who attends. Of course have a quiz at the end of the session. You can claim "effectiveness" and you can find out who is comprehending what. I have a client who has a L&L every Friday.

4) I personally know a Management Quality Rep (MQR) who walks around watching for someone who is particularly successful at applying any aspect of their internally documented ISO Quality System. Upon his discretion he awards outstanding practitioners with a silver dollar. Not a great expense but something very worthwhile.

5) Tie knowledge of the standards to an employees Performance Review. Actually establish an increase schedule, however small, to their ability to respond effectively and accurately to a series of example ISO questions.

6) Establish career tracks for the average employee to work themselves into a premium ISO related position. Require knowledge and uderstanding of the standards at certain points along the path.

7) I know an MQR who holds weekly ISO meetings simply to talk about the standards and any changes or developments; internationally, nationally, locally, corporate wide and internally. Of course, at the end there is always a quiz.

There really are many more ways to influence the average employee to take an interest. You need to make it worthwhile for anyone to undertake somethng that is extra to their job description though; always keep compensation and time off in the equation.

No matter what I do or what I recommend an organization do I always say give a pre-quiz and a post-quiz. I don't care what the topic is if you want anyone to get anything out of what you are subjecting them to then quiz them before you present your material (ISO meeting, department meeting, plant meeting, benefits meeting, training, L&L, whatever) then after you present it. Compare the grades.

You do several things for yourself;
1) You help support the effectiveness requirement
2) People begin to expect quizzes so they may start listening better
3) You get info on your students ability to comprehend and retain knowledge.
4) You also get input as to the ability of your instrucftor to transfer information effectively.

Bottom line is you must get people involved. You can't afford those embarrasing questions or statements during an audit. Get creative - just do it.

Greetings Gary,
You mean the employees are supposed to be involved with ISO? I thought that is why we have a Management Quality Representative. The MQR should be able to take care of the entire QMS without any help. My goodness, is it not enough that the employees show up for work? There is really no need to hold them responsible for anything.

( only slightly tongue in cheek !! )

JCTB

There are many underlying threads throughout this discussion. One of them is "The use of the process map." On one hand some of us would proclaim that "No one uses it anyway." then on the other hand there is a group that says "If they are serious - they will use it."

After careful thought I have to ask "Use it for what?" I mean we, as quality professionals, spend umpteen hours in the development, discussion and revision of our Process Maps but then what do we actually do with it? Please don't respond with a bunch of pretty statements about what COULD be done with it. Really, what is really done with this map? How does anyone really use it? What is the activity you actually require this map for? What do you do today that you could not accomplish without this map?

What comes to mind right away for me is "Show it to the auditor!" Am I wrong? I believe it is something like many people's FMEAs; "Build it at PPAP then file it." Or like we used to be accused of regarding the Quality Manual; "Write it then let it sit on a shelf gathering dust."

If you are really honest with yourself and with your organization I really think you are going to have to say the biggest use of this map is as evidence for the auditor that you have built one. Reminds me of the WPA. You know, one group of guys digs the ditches while the other group fills them up, but at least they all have work.:bonk:

Sometimes the utility is in the process of making the document, and not in the document itself. There are lots of records in lots of companies that are never "used," but are highly useful when someone (an auditor, for example) does want to see them. The process of drawing a process map, if it's done effectively, forces thought about processes and their relationships. Sometimes we only "see" all of this as we're in the process of drawing the map. The old derisive question, "Do I need to draw you a picture?" comes to mind. Sometimes you do need to have a picture drawn in order to understand the sequence and relationships of processes.

FMEA is pretty much the same thing; as I've often said here, FMEA is a process, not a document. The document is a record of the process, and nothing more. As such, it's not surprising that the document itself might not be particularly "useful." Let's not confuse containers for the things contained. If a process map serves its prime purpose (facilitating the visualization of key processes and relationships) we shouldn't necessarily expect it to be anything more. It's worth retaining for a number of reasons, though, not the least of which is to serve as a record of the execution of a process required by the standard.

Added in edit: As has been mentioned here already, the standard doesn't require graphic illustrations of any kind, and a written summation of key processes and relationships is sufficient. If you have an auditor who disagrees after having been asked for the specific "shall," politely show the auditor to the door, and talk to his supervisors.

John - John - John

I KNOW I sense a certain degree of "levity" in your post - I sure hope so anyway.:cfingers: Yeah, it's quite a concept isn't it? I really have seen it work though:)

Jim,

Very good explanation, you know, the value is not in the document but in the making of that document. I know, I have experienced that very thing many times. I fully agree. Perhaps the document is not used but whoever built it has most certainly expanded their own knowledge of the subject at hand simply by researching enough to build the document.

Thanks

I didn't feel like I was being lectured to, Gary, honestly. Your reply was very thought provoking and had some very good ideas in it. I agree that the quality policy and quality objectives should be clearly communicated by management, and staff should be aware of thier ISO certification and how their job contributes to maintaining that, but knowing more about the standard? I've replied to your numbered points below, but this is meant in the best possible taste:

1) Management certainly need to be aware of their responsibilities wrt ISO, but does anybody else need the detail? They need to know how to do their job. I thought poster campaigns were useless without the continual verbal re-inforcement?
2) Train within normal working hours surely?
3) Now you've lost your essential break time - how can you stay fresh?
4) How can he tell? Isn't everyones' contribution essential to success?
5) Only if they're interested - does this fit with company objectives?
6) as in 5)

If something is extra to your job description that's a goal or objective aint it, so you don't get paid for it, but you may get a rise at the end of the year.

I have to prepare an annual refresher training course for all staff in GMP/GCP/GCLP/GLP so I'm planning on using the theme of one of those reality game shows that seem to be on the tv a lot, maybe using small teams to answer quiz questions or vote on answers or vote on truth/lies. What do you think?

Cheers:D

As I continue to read this thread I become more and more lost. Is process mapping so political? :argue:I dont know much about it but then again I guess no else does either due to the various "opinions." Based upon my reading about it, if applied correctly can be a benefit to a company. As the Quality Mgr, I have the responsibility in applying ISO requirements effectively in order to produce results. Even if my company does not use a map that is done correctly wouldnt the Quality Manager still benefit from it? Is not the Quality Manager the driver of the companies quality system? If so wouldnt he need a process map to drive it? This is why Iam trying hard to do it correctly. Even if only the auditor benefits from it he could use it to give advice for our system which would make the process map beneficial for everyone in the end. :agree:

THE BIG ISSUE:confused:
I still am having trouble in determining at what point does the interelated activities become a "core process"? What Iam finding is that there are many levels of this. How detailed should i go? Should I make a few process maps with detailed levels?
What if I use both of these maps? (see attachments)

As I continue to read this thread I become more and more lost. Is process mapping so political? :argue:I dont know much about it but then again I guess no else does either due to the various "opinions." Based upon my reading about it, if applied correctly can be a benefit to a company. As the Quality Mgr, I have the responsibility in applying ISO requirements effectively in order to produce results. Even if my company does not use a map that is done correctly wouldnt the Quality Manager still benefit from it? Is not the Quality Manager the driver of the companies quality system? If so wouldnt he need a process map to drive it? This is why Iam trying hard to do it correctly. Even if only the auditor benefits from it he could use it to give advice for our system which would make the process map beneficial for everyone in the end. :agree:

THE BIG ISSUE:confused:
I still am having trouble in determining at what point does the interelated activities become a "core process"? What Iam finding is that there are many levels of this. How detailed should i go? Should I make a few process maps with detailed levels?
What if I use both of these maps? (see attachments)

You have heard from many wise and learned Q practitioners in this thread. :applause: Now, for the viewpoint from someone who has about 1 year total in QA.

Make it work for YOU. Now that may mean make it work for your auditors also, but that has to be your call. Reviewing the maps, I like the detailed one better. The simpler one simply looks to be a restatement of the five main clauses.

Regarding the more detailed map, I would suggest that you use the terms, titles, buzzwords that YOUR company uses and not the terms that ISO uses.

As I continue to read this thread I become more and more lost.

Jose, I'm sorry. As you can see, there are many different viewpoints and opinions. It isn't a simple topic and there just is no B&W simple answer.

Is process mapping political? No. But there are different points of view.

You see, when you ask for advice in a free public forum, you get what you pay for. :) In this case, lots and lots of it. :) You can't expect from a whole bunch of different people a single, common answer. Hope perhaps, but not expect. :D And you raised a topic which is interesting to various people for different reasons.

OK, back to your question:

Even if my company does not use a map that is done correctly wouldnt the Quality Manager still benefit from it?
Yes, very much so, as Jim points out.

Is not the Quality Manager the driver of the companies quality system?

Ooohh - another thorny question & potential discussion topic! (My answer is no, the QM should not be the 'driver' and trying to assume that role is fraught with danger. Everyone needs to own quality and the quality system - if you see 'em as carriages being towed by you, where you want them to go, you'll make it hard for yourself. The QM's role includes overseeing it, ensuring it meets requirements, coordinating, coaching, inspiring, etc. But 'driving'? I wouldn't.)

If so wouldnt he need a process map to drive it? This is why Iam trying hard to do it correctly.

Re. your process maps: I think both of your maps are fine for this point in time. I wouldn't worry about trying to do it 'correctly' - there's no single right/wrong version. Quality improvement is a process - you may well change/upgrade/improve one or more of these later.

But do, do, do, take this good advice already given: Make it work for you.

I'd keep both at this point - the one structured around the ISO clauses may help you keep the clauses in your mind, and the other, more business-centred one helps you understand more clearly the overall business processes.

I still am having trouble in determining at what point does the interelated activities become a "core process"?

Try using this rule of thumb: If it makes you money, then it's a core process. If it cost you money to do it, then it's not (it's a supporting/enabling process.


Way back in this thread , you said this about your business:

We are simply brokering. We get Request for quotes, source our vendor availabilities, quote our vendors stock with a mark up, get an order from our customer, buy it fro our vendor, receive and inspect it, then ship it to customer.

Great - that's your core business, right there. Perhaps 3 core processes:

Procuring goods (or perhaps more accurately, sourcing vendors)
Taking Orders
Order fulfilment (includes buy, receive, ship)

Getting & selling goods is a core process. (No goods = no sales = no $$). But things like recruiting, for example, or controlling docs isn't. You have to recruit (unless you can replace people with robots :) and you must control docs or things go awry. But neither of those things actually directly make you money.

Hope this helps.

Thanks for summing it up, Jane.

I hope the OP (Jose) find these discussions beneficial - much better than attending a course where you listen and get the views & ideas of only one person.

Very nicely put Jane. Even keeled, calm and balanced and full of logic and information. Thank You.

Incidentally:topic: how do you show a quote of an individual part of a persons post like you just did with Jose's? Can you help? or can you point me in the right direction. I try to use the forum help forum but it to is a forum. I have to know how to use it before I can use it to find out how to use it??:confused:

Very nicely put Jane. Even keeled, calm and balanced and full of logic and information. Thank You.

Incidentally:topic: how do you show a quote of an individual part of a persons post like you just did with Jose's? Can you help? or can you point me in the right direction. I try to use the forum help forum but it to is a forum. I have to know how to use it before I can use it to find out how to use it??:confused:

:topic:

Thanks Gary. Yes, it isn't always very easy to find info around this place.

Re. quoting, this is one of many tags in HTML that are paired - one tag opens it, the other closes it.

It's too hard to write about HTML in something that uses them, so see attached how to do it.

Incidentally:topic: how do you show a quote of an individual part of a persons post like you just did with Jose's? Can you help? or can you point me in the right direction. I try to use the forum help forum but it to is a forum. I have to know how to use it before I can use it to find out how to use it??:confused:

If you want to include only part of someone else's post, just hit the "Quote" button, and then delete everything except the part you want to quote, making sure that the quote tags remain in place. If you want to quote more than one post, hit the "multiquote" button under each post you want to quote, then hit the "Quote" button under the final post you want to quote. The multi-quote button looks like this:
http://elsmar.com/jpg/screenshot001cf9.jpg

and it turns red when you select it. After all of the quotes are in place in your post, you can edit them as you see fit.

Whoa, that's a HUGE ASSUMPTION! Many organisations (trust me I work in one) don't make use of such things for a huge amount of reasons, not just because it's not useful to the organisation. Our quality manual and our quality procedures would probably be useful if they were used, but the fact is in my organisation, it has become a bad habit not to refer to our manual and do it your way!

The same could probably be applied to many organisations with redundant process maps. OK I accept that MAYBE a reflection of the process not working for the organisation, but what about the flip side? An organisation refusing to work in a more efficient manner and everyone having a better understanding of the whole rather than just their individual piece.



Actually, your quote below may answer your own comment.


PS: I wish my organisation had implemented process maps for our key processes, so I would be having an easier time understanding what they are and how they interact. Instead I am having to try and create them myself!



If a company does not write useful things, people won't read them much.

What I find is most manuals and procedures don't provide much information...therefore they don't get used much. Why would you refer to a document which you believe does not provide relevant information?

Most procedures I read provide less relevant information than the standard itself. Often, only work instructions begin to contain meaningful information.

Let's write meaningful stuff, and maybe more people would begin to read it.

Let's write meaningful stuff, and maybe more people would begin to read it.

So true Helmut. Indeed, so very true.

I've lost count of the so-called 'quality procedures' or so-called 'quality manuals' that were just a bunch of verbiage, that actually said nothing. Or perhaps contained a very small fragment of useful information, ooh, say perhaps around 5%. No one can be bothered to spend that much time sifting through the dross panning for the useful info.

Indeed, let us strive to write meaningful stuff.