Quality System Process Map - Is this too detailed or not enough detail?

[josecortez]

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?

 

[josecortez]

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.

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?

 

[Patricia Ravanello]

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!

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

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

 

[jerzki]

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.

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.

jerzki ( im back!!!! )

 

[Patricia Ravanello]

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

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!!!! )

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

 

[jerzki]

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

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?

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

P.S.

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

 

[wessamsheta2000]

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.

 

[Patricia Ravanello]

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

 

[Gary E MacLean]

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

 

[JohnCTB]

Well said Mr. MacLean.

JohnCTB