Which of these are Processes and should have Process Maps and why?

[Marc]

I have been involved in application of process approach since 1983. All my project plans have been based on process approach. I guess you can call me a seasoned practitioner of process approach.

I understand, believe me. I have argued many times over the years that the 'Process Approach' is nothing new, and is how I have worked with companies in implementation over the last 17 plus years (since I've done consulting).

In my case the 'Process Approach' it goes back to college. As a biologist, everything was (is) a system. Period. Interaction of bio-chemical processes was 'where it is at'. How do you do this? Via flow charts, of course.

Hearing Process Approach when ISO 9001:2000 was being hyped made me laugh. It still makes me chuckle... Everything is a process. Nothing new here. Nothing to see. Move along, now.

These are flow charts from around 1994 (revised in 1996): Flow Charts from circa 1994 - 1996. There are no 'Inputs' and 'Outputs' as we typically do today in linear flow charts, but...

Everything is a system or series of interacting systems. People are a series of interacting 'systems'. Businesses are, like humans, a series of interacting systems. The 'Process Approach' is a systems approach.

 

[chaosweary]

In fact, the standard does not require a process maps. One of my friends (a CEO) obtained ISO certification for his organization from DNV without a single process map or turtle chart.

If the objective of constructing process map is to obtain certification or pleasing the auditors, then the whole thing is a waste of time... Auditor does not have to satisfy your stakeholder....

They all become generic at a high level... Why not modify ISO's model? And just because a company has ISO certification and randomly identified inputs, processes, and outputs does not mean they understand the application of process approach.

Paul’s question was: Which of these are Processes and should have Process Maps and why?

I think it is worth while reviewing TS176...

It seems ironic that the TS176 link provided describes the process approach with...process maps!
At first I didn't like process maps, but then when I found out I would get a free visio license out of the deal I was in like flynn!
Oh yeah, I also use process maps to fulfil section 4.1 b, and I love making them really colorful and exciting to captivate the managers attention during boring ISO implementation meetings. I even have one process map with their faces embedded on pictures of monopoly peices, they loved it!

In reality, there are companies whose reason for getting 9001 or 16949 are purely market driven that said, I think its corporate suicide to tell customers that you will not get certified just for the sake of getting their business (Go tell Sony, Dell and HP they are so wrong for making us get OHSAS 18001 certified)! For myself, making money beats the heck out self actualization everytime, it's just a matter of opportunity cost...I will repent once I have a golden parachute

 

[michellemmm]

Auditors 'expect' a high level map to show the 'Interaction of Processes'. You don't need a 'Process map' (flow charts or what every you want to call it), and you are right there is no written requirement for a high level process map, but if you want to 'make it easy' for an auditor, a map helps.

Personally, I would want one because it makes it easy to see how an organization (or system) works because I'm more of a 'visual' person than I am a 'text' person. They're relatively easy to make.

Marc,

I am not against process map. I don't like the idea of setting a QMS to suit an auditor's fancy. Simple road maps are great if you are passing through a town. But, if you have a house and want to add second floor, you need more than...here is the front door...here is the living room...and here is the bedroom description. An auditor should not dictate his/her preference.

 

[michellemmm]

I agree with Marc.

Think about driving directions. I do much better with a simple hand-drawn map and landmarks as opposed to written directions.
I found that the MapQuests and the Googles provide too much detail which confuses me.

Stijloor.

I am sure you would ask for more detail if you were city planning or analyzing traffic flow.

 

[Helmut Jilling]

Michelle the original poster wrote "should"..."Which of these are Processes and should have Process Maps and why?"

But I'll bite anyway, let's not call it a shall but a "truism". Tell me the name of your 3rd party registrar that lets you get ISO TS 16949 certified without having at least one process map, I want their number! I think its universally understood that having a process map is the easiest way to show the sequence and interactions of your processes and I would think that you "should" have at least one to meet minimum requirements if one was going to meet that requirement using a process map.

I know this is a fundamentally wrong approach but we asked our consultant who is a 3rd party TS 16949 lead auditor typically how many process maps does he come across when auditing in our industry he stated anywhere from 20 to 30 and stated that we wouldn't get through an audit without at least one at a high level and he had worked for our registrar in a prior life.

Technically, you can get certified without any flowcharts, process maps, or diagrams...but it defeats the purpose of a good process approach. Somehow, you have to describe the sequence and interactions. I suppose it is possible to describe it with a diagram of some sort, but is it really worthwhile?

PS: I agree with Marc. ISO did not invent the process approach. I suggest it merely adopted the methods that some of the more progressive companies were already using. But, it is useful, nonetheless.

 

[Stijloor]

I am sure you would ask for more detail if you were city planning or analyzing traffic flow.

Michelle,

Absolutely! It all depends on its intended purpose. The right tool for the right application.

Stijloor.

 

[Colin]

Can you direct me to the ISO "Shall" section that says you need one high level process map?

As pointed out by others, you are quite right Michelle that ISO does not demand a high level process map but clause 4.2.2 c) does require a description of the interaction between the processes of the quality management system and a process map is a pretty easy way to fulfill that requirement - as well as being useful.

 

[michellemmm]

Michelle,

Absolutely! It all depends on its intended purpose. The right tool for the right application.

Stijloor.

Stijloor,

EXACTLY!!

The key word as you stated is intended purpose.

The title of this thread is: Which of these are Processes and should have Process Maps and why?

There has been 116 replies and majority focus on ISO requirements and not the intended purpose of process map.

If I did not believe in process approach, I would not be practicing it for so long. It is a very powerful tool.

Organizations develop process maps or flow charts to satisfy ISO and then store it in documentation vault.

How many companies review/ reexamine the processes and their interactions when they are reorganizing, expanding, or contracting? Many don't know how to use them...

Let's take ISO out of this equation and focus on why we should map out those processes....

Goldilocks (the auditor) should not dictate to Three Bears how to prepare their porridge.

 

[Randy]

ISO was never in my responses.

As for the process approach, control and all that other "stuff", I'll contribute this piece. There ain't nuttin new about it and it ain't that difficult to understand, it's the "professionals" that make it more complex than it really is.

The process approach, process management and process control have been used for thousands of years as has "risk management"....."What do I need and what do I have to do with it to get what I want?" and then controlling the output (the "what I want") by juggling what goes in and what is done. It is that simple. Every bit of it could be mapped out if necessary (Claes does an excellant job of it with his "Spiders")

The real problem is, that it is such a basic and simple activity we want to make it complicated, and we do that very effectively.

Every human or natural activity, regardless of what it is, can be defined as Input-Action-Output (Cause & Effect), and it can all be mapped.

Now getting back to the OP's thing about mapping process's in a system....As a 3rd party type I really couldn't care less. All I need to know and all you need to show (I'm a poet), is that you understand and can demonstrate how "A" gets to "B". I've seen systems where the evidence shows that more time was spent on making Eyewash, Dog & Pony Show maps than there was on actually doing "stuff". Please, whip me, beat me or starve me, but don't bore me! (GySgt Highway - Heartbreak Ridge)

 

[Peter Fraser]

Stijloor,

EXACTLY!!

The key word as you stated is intended purpose.

The title of this thread is: Which of these are Processes and should have Process Maps and why?

There has been 116 replies and majority focus on ISO requirements and not the intended purpose of process map.

If I did not believe in process approach, I would not be practicing it for so long. It is a very powerful tool.

Organizations develop process maps or flow charts to satisfy ISO and then store it in documentation vault.

How many companies review/ reexamine the processes and their interactions when they are reorganizing, expanding, or contracting? Many don't know how to use them...

Let's take ISO out of this equation and focus on why we should map out those processes....

Goldilocks (the auditor) should not dictate to Three Bears how to prepare their porridge.

Michelle

Well said! I agree entirely with your opinion on the benefits of "mapping" a process - and also with what I think you think about a "system" map (also, confusingly, called a process map by many!) I don't think that I have ever seen one which shows the true sequence and interaction of processes in any meaningful way. And the "picture" in ISO9001 is the main culprit.

The exercise of defining a process can raise all sorts of issues about lack of clarity, duplication, lack of added value, risks etc. The end result should provide a way to communicate how things should be done to all staff.

But drawing a picture with a few boxes and some arrows linking some of them together, mentioning "Customer requirements" and "Customer satisfaction" and labelling it "sequence and interaction of processes" doesn't do anyone much good.