On another thread (or several) there has been some disagreement about what a process is. Perhaps covers could take part in a poll as to which of the "processes" listed is significant and their justification. I'll let the voting start and then give my vote.

I voted that they all were processes, thay all have INPUTS and OUTPUTS.

Some are - but then some are controls on a process (SPC) and some are activities. I know that there are long and painful debates about processes, but IMHO, there are some things in ISO 9001 (for example) which are called 'procedures' which I don't believe need to be treated (nor was it the intention, hence the name) as the 'value adding' processes of the organization. I know, I know, you can make anything into a process if you want, but, really, is Records Control a process?

Now, let the fun (or pain) begin.........thanks Paul, you may not know what you've started.........

Business planning
Contract review
Document control
Change management
Management responsibility
Managing design changes


These are the processes I would single out as "significant" enough to be in my process map. I eliminated satisfying customer orders because I felt it was addressed by contract review and improvement processes. I also eliminated a few other less significant processes on the basis that they are singular activities or fall under the scope of more significant processes, i.e. annual budget is under business planning.

SPC and Calibration I felt were sub-processes, meaning they should fall under something along the lines of "Instrument control" and "Inspection" which engulf a broader spectrum of activities.

It's funny, I recall reading a post that mentioned COPs, MOPs, and SOPs recently, someone questioning whether their process map was robust and correct. There is a reason for grouping the processes in this manner as it allows you to better visualize where your core processes are and how they function together.

I almost always see a process listed as "Continual Improvement" or somethign similar to this as well....typically defined as encompassing inspection, spc, client feedback, surveys, etc...these kind of activities. ;)

I would change the title to "which of these processes are significant and why" to avoid confusion, because as stated before, all of them are processes.

Business planning
Contract review
Document control
Change management
Management responsibility
Managing design changes


These are the processes I would single out as "significant" enough to be in my process map. I eliminated satisfying customer orders because I felt it was addressed by contract review and improvement processes. I also eliminated a few other less significant processes on the basis that they are singular activities or fall under the scope of more significant processes, i.e. annual budget is under business planning.

SPC and Calibration I felt were sub-processes, meaning they should fall under something along the lines of "Instrument control" and "Inspection" which engulf a broader spectrum of activities.

It's funny, I recall reading a post that mentioned COPs, MOPs, and SOPs recently, someone questioning whether their process map was robust and correct. There is a reason for grouping the processes in this manner as it allows you to better visualize where your core processes are and how they function together.

I almost always see a process listed as "Continual Improvement" or somethign similar to this as well....typically defined as encompassing inspection, spc, client feedback, surveys, etc...these kind of activities. ;)

I would change the title to "which of these processes are significant and why" to avoid confusion, because as stated before, all of them are processes.

They are all processes. The easy definition of a Process is:

Anything that has an input and creates an output is a process.

Yes they are all processes, I said that. His question is which do you consider significant , not whether or not they are actually processes...

Everyone that I see are worthy of process flows. Each of the process can have impact on the Bottom Line ($$$$) and Customer's expectations, at least in my opinion.

Well, all work is a process, so....

Anyway, my votes were for which should appear on an overall process map. Each could be flowcharted on their own, though.

They all are...every one of them requires input - something done with those inputs - and there is an output that serves a purpose of has "value".

If one is "open minded" he/she can see that evey clause of ISO 9001 is in fact a "process", linked to other "processes" coverting inputs into a desired output (customer requirements into customer satisfaction)

They are all processes. The easy definition of a Process is:

Anything that has an input and creates an output is a process.

ISO 9000:2000 provides the definitions used in the standard. Clause 3,4,1 defines a process as - "set ofinterrelated or interacting activities which transforms inputs to outputs"

ISO 9000:2000 provides the definitions used in the standard. Clause 3,4,1 defines a process as - "set ofinterrelated or interacting activities which transforms inputs to outputs"


You're behind the power curve by 3 years there pardner, it's ISO 9000:2005 now.

3.4.1
process
set of interrelated or interacting activities which transforms inputs into outputs

NOTE 1 Inputs to a process are generally outputs of other processes.

NOTE 2 Processes in an organization (3.3.1) are generally planned and carried out under controlled conditions to add value.

NOTE 3 A process where the conformity (3.6.1) of the resulting product (3.4.2) cannot be readily or economically verified is frequently referred to as a “special process”.

I voted that they all were processes, thay all have INPUTS and OUTPUTS.


They all could be, but this poll was designed to include some activities which probably should be better considered sub-processes. Those would not need to be fully developed with flow-maps and all the things called out in 4.1. Otherwise, your company map would show 80-100 process maps and the whole thing bogs down. What would be different, is some things become more or less important, depending on what the company does.

Nice poll, Paul...;)

I voted for the "significant" processes we use. We include manage design changes in change management so I didn't vote for that one specifically. Our change management process includes changes in design, process and product.

I looked at this from the point of view of what do I consider necessary to include in my ISO 9001 documentation.

The significant process is "satisfying customer orders" which includes the topics of contract review, change management, introducing new products, design change and customer satisfaction (the latter very reluctantly).

Document control and calibration can be covered with simple procedures and I see no benefit in generating process maps for these topics.

Management responsibility is just a heading in other documentation, not worth a process flow diagram on its own.

SPC is controlled by training, charts and reference in the control plan, again not worth a separate process flow diagram.

IT can get on with their work without my interference. I reference their activity only in the records procedure for their daily records back-up activity.

Budgeting is obviously important to the business but outside the scope of ISo 9001.

Anyone who expends the effort to write a process flow for e-mailing brochures clearly has too much time on their hands.

I looked at this from the point of view of what do I consider necessary to include in my ISO 9001 documentation.

The significant process is "satisfying customer orders" which includes the topics of contract review, change management, introducing new products, design change and customer satisfaction (the latter very reluctantly).

Document control and calibration can be covered with simple procedures and I see no benefit in generating process maps for these topics.

Management responsibility is just a heading in other documentation, not worth a process flow diagram on its own.

SPC is controlled by training, charts and reference in the control plan, again not worth a separate process flow diagram.

IT can get on with their work without my interference. I reference their activity only in the records procedure for their daily records back-up activity.

Budgeting is obviously important to the business but outside the scope of ISo 9001.

Anyone who expends the effort to write a process flow for e-mailing brochures clearly has too much time on their hands.

Thanks, Tyker for articulating what I wanted to say.:agree1:

It is too easy to 'fit' these into a QMS and justify them as processes, but it really isn't accurate to treat everything in such a manner. There are so many things which are simply activities and we often fall into a trap by being a little too 'evangelical' about process - IMHO. It becomes simply un-manageable, literally, to treat everything as a process.

ISO 9000:2000 provides the definitions used in the standard. Clause 3,4,1 defines a process as - "set ofinterrelated or interacting activities which transforms inputs to outputs"

Thanks for the definition via ISO 9000, but I wanted to put it into simple terms, and that is how I train.

Is there a point to all this ?

I don't think so, it's purely opinion...

Is there a point to all this ?

I think we're trying to resolve an argument between Paul and Helmut.

Or between Paul and the rest of the world.

Or something.:cool:

Let's get back on the topic at hand.

On another thread (or several) there has been some disagreement about what a process is. Perhaps covers could take part in a poll as to which of the "processes" listed is significant and their justification. I'll let the voting start and then give my vote.

On another thread (or several) there has been some disagreement about what a process is. Perhaps covers could take part in a poll as to which of the "processes" listed is significant and their justification. I'll let the voting start and then give my vote.

Paul,
If your talking about the processes which need to be identified in response to 4.1 a and b, then those processes, for most companies, are as follows :

1 - System-oriented Processes

a) SOP-0001 Internal Audit
b) SOP-0002 Control of Documents and Records

2 - Management-oriented Processes

a) SOP-0003 Business Planning and Management Review
b) SOP-0004 Monitoring, Measurement and Analysis
c) SOP-0005 Corrective & Preventive Action and Continual Improvement

3 - Support-oriented Processes

a) SOP-0006 Employee Competence, Empowerment and Motivation
b) SOP-0007 Control of Monitoring and Measuring Devices
c) SOP-0008 Purchasing and Materials Management
d) SOP-0009 Infrastructure & Production Support

4 - Customer-oriented Processes

a) SOP-0010 Product Realization
b) SOP-0011 Change Control
c) SOP-0012 Control of Non-Conforming Product & Materials

These may be referred to as the Key Business or Management Operating SYSTEM processes.. (They represent the "Procedural" level of your Operating System Documentation). The way you vizualize their sequence and interaction could be referred to as your Business/Management Operating System MODEL.

The sequence of events in any of these SOPs is captured in the FLOW CHART of that SOP, as in the attached Flow Chart of SOP-0001 Internal Audits. The subordinate processes identified within the Procedural Flow Chart are detailed in Work Instructions (which may or may not be flow charted also, depending on your preference and resources).

The difference is that the Procedure is a MACRO Process and the Work Instruction is a MICRO process. Every Work Instruction in your System should have a parent "Procedure" to which it belongs, and where it is referenced.

That's what this "process mapping" is all about.
All other organizational processes are subordinate to these 12 (or 15, or whatever) , and would be captured in or referred to in the Flow Charts of these 12 KEY OPERATING SYSTEM processes.

The secret to a successful system is in the initial identification and differentiation of the System Document levels.

I think that the question that you pose is ambiguous.

Patricia Ravanello

Paul,
If your talking about the processes which need to be identified in response to 4.1 a and b, then those processes, for most companies, are as follows :

1 - System-oriented Processes

a) SOP-0001 Internal Audit
b) SOP-0002 Control of Documents and Records

2 - Management-oriented Processes

a) SOP-0003 Business Planning and Management Review
b) SOP-0004 Monitoring, Measurement and Analysis
c) SOP-0005 Corrective & Preventive Action and Continual Improvement

3 - Support-oriented Processes

a) SOP-0006 Employee Competence, Empowerment and Motivation
b) SOP-0007 Control of Monitoring and Measuring Devices
c) SOP-0008 Purchasing and Materials Management
d) SOP-0009 Infrastructure & Production Support

4 - Customer-oriented Processes

a) SOP-0010 Product Realization
b) SOP-0011 Change Control
c) SOP-0012 Control of Non-Conforming Product & Materials

These may be referred to as the Key Business or Management Operating SYSTEM processes.. (They represent the "Procedural" level of your Operating System Documentation). The way you vizualize their sequence and interaction could be referred to as your Business/Management Operating System MODEL.

The sequence of events in any of these SOPs is captured in the FLOW CHART of that SOP, as in the attached Flow Chart of SOP-0001 Internal Audits. The subordinate processes identified within the Procedural Flow Chart are detailed in Work Instructions (which may or may not be flow charted also, depending on your preference and resources).

The difference is that the Procedure is a MACRO Process and the Work Instruction is a MICRO process. Every Work Instruction in your System should have a parent "Procedure" to which it belongs, and where it is referenced.

That's what this "process mapping" is all about.
All other organizational processes are subordinate to these 12 (or 15, or whatever) , and would be captured in or referred to in the Flow Charts of these 12 KEY OPERATING SYSTEM processes.

The secret to a successful system is in the initial identification and differentiation of the System Document levels.

I think that the question that you pose is ambiguous.

Patricia Ravanello

Thank you Patricia, well said !!
I'm curious to hear/read you comment about how one should deal with the communication process. Although it is seldom portrayed as a "formal" process, if it is not effective it can wreak havoc in a QMS and/or organization.

Thanks to all who have voted so far. Having kept my head down for a day I have now posted my votes (available for all to see). As promised here is my significant processes list and reasoning:
Business planning - probably the most difficult to describe (and map)
Satisfying customer orders - this is the end - to - end core process describing how an organization captures customer orders and plans, produces and fulfils those orders
Change management - this covers the setting up of new systems either because the organization has started doing something new or has changed its way of doing something
Introducing new products - a customer comes along with a new need or the design people have an idea for a new product this is the process for dfelivering these products / services

and the ones that didn't make it into the top 4:

Contract review - part of the "satisfying customer orders" process
IT support - part of a number of bigger processes for a) maintaining existing equipment, b) managing data, c) change management
Document control - part of change management
Calibration - part of maintenance of existing equipment and purchasing
The annual budget - part of business planning
Customer satisfaction survey - part of monitoring and measuring of current performance
Management responsibility - doesn't exist outside ISO. Responsibility & authority is all part of a process for human resources, particularly competence
SPC - another part of monitoring and measuring of current performance and may form part of introducing new products / change management
E-mailing our brochures - part of customer communications, part of obtaining new customers, part of external communications
Managing design changes - part of change management


To the questions:

This isn't me against Helmut. It may be me against the rest of the world :lol:
There is a point. ISO 9001 is supposed to be a quality standard. We are the key users of ISO. If we don't understand whether a process is a process or whether it is worthy of recording / flowcharting / measuring then who else will?
This is a dialogue. I may be abrupt but I want understanding to be better - if that is mine or everyone else's
To go back to the ISO definition of "transform inputs into outputs" is to miss the point. There are some things that are significant and important to control and need highlighting on a "process map" there are others that need less management

Thanks to all who have voted so far. Having kept my head down for a day I have now posted my votes (available for all to see). As promised here is my significant processes list and reasoning:

Business planning - probably the most difficult to describe (and map) <SNIP>


Paul,
I want to thank you for starting a thought provoking thread. I think change from flow chart and activity management mind set that overlaps check list mentality/conformance monitoring to process management through performance management has not been fully embraced.

My question is why do you say business planning is difficult to describe and map?

Making a pot of Tea is a process

Boiling an egg is a process

Driving a car is a process

Drinking a glass of water is a process

Going potty is a process

Developing a procedure is a process


Everything we do or that gets done can be defined as a process....

Making a pot of Tea is a process

Boiling an egg is a process

Driving a car is a process

Drinking a glass of water is a process

Going potty is a process

Developing a procedure is a process


Everything we do or that gets done can be defined as a process....

Randy, it can, agreed..................but should it? I don't agree, for example, with your list. Without promulgating bathroom humo(u)r, 'going potty' isn't a process!:notme:

Andy,

Either you have forgotten or never have experienced a small child having trouble going to the bathroom. Trust me...it is a process!

Input - electrical impulses telling brain that muscular contraction required
things happen
Output - happy kid.

:)

On another thread (or several) there has been some disagreement about what a process is. Perhaps covers could take part in a poll as to which of the "processes" listed is significant and their justification. I'll let the voting start and then give my vote.

Paul,

I don't think people know what "Process Map" you're talking about, hence the debate about what is "significant".

A process which is significant at a Work Instruction level, may not be significant or even referenced at the Procedural level.

This discussion is going nowhere.

Patricia Ravanello

....This isn't me against Helmut. It may be me against the rest of the world :lol:



Oh, c'mon, Paul. You and I haven't had a good go 'round for a long time ...:D


Actually, I think the comments in your reply make some good points. I agree with all the comments, and agree all the things in the poll are important activities. But, how you slice and categorize some of them is different than I. So, there were a lot of items on the list that I did not vote for, because I would class them as sub-processes rather than full processes. Another company might slice them along different lines.

I really like the fact that ISO allows that tailored approach this time, rather than the one-size-fits-all approach of the 20 elements. We outgrew that.

However, with the freedom comes the responsibility to actually understand the concept of what process approach is. Which of course is your main point. I agree with that. But, we have to leave room for different folks to slice it along different lines, as long as it is still effective.

However, since there is so much confusion, I do suggest understanding which are the main, core, key, customer-oriented processes, as opposed to the supporting and administrative processes, helps newbies to do cleaner implementations.

A lot of the examples we are asked to review clearly show the team got bogged down in the exercise of flowcharting, and lost sight of the processes themselves.

Also, I think people need to remember that processes have a hierarchy, almost like chemistry. The standards do not require it, but it helps to understand it:

Processes contain significant subroutines, (subprocesses).
Subprocesses contain sub-subprocesses.
This drills down to individual interactions (transactions).Failures occur when one of these transactions fail to connect. When someone misses one of these steps, it can lead to a failure. The process didn't actually fail, one of the transactions failed.

Watching a sports game helps to model how process interactions and transactions work. Lots of interactions and transactions - and they frequently fail and recover, in realtime.

Understanding how processes work goes a long way toward defining them in a manner that is beneficial to improving the organization.

Andy,

Either you have forgotten or never have experienced a small child having trouble going to the bathroom. Trust me...it is a process!

Input - electrical impulses telling brain that muscular contraction required
things happen
Output - happy kid.

:)


Cute point, but in the overall scheme of how your House (organization) operates, would you class that as a full process? Or is it better defined as a sub-process, under something like a "Bathroom Process?" Do you really want to elevate it to a full process spot on the household [high level] process map?

It helps to understand there are different levels in processes, just like in an outline. Defining the right level to place it at helps the process maps flow cleaner.

Making a pot of Tea is a process

Boiling an egg is a process

Driving a car is a process

Drinking a glass of water is a process

Going potty is a process

Developing a procedure is a process


Everything we do or that gets done can be defined as a process....


I agree with your point, but in an organization of 50 - 200 people, these would all fall down to subprocess or even sub-subprocess levels. Otherwise, it would choke the quality systems to a point of gridlock.

Some of the examples submitted to this forum for review frequently get bogged down precisely on this point. They get processes and sub-subprocesses all mixed together, then they don't flow.

Thus, it is the responsibility of each management team to get a good understanding of the process approach to management, and evaluate how to apply that paradigm to their particular organization.

I agree with your point, but in an organization of 50 - 200 people, these would all fall down to subprocess or even sub-subprocess levels. Otherwise, it would choke the quality systems to a point of gridlock.

Some of the examples submitted to this forum for review frequently get bogged down precisely on this point. They get processes and sub-subprocesses all mixed together, then they don't flow.

Thus, it is the responsibility of each management team to get a good understanding of the process approach to management, and evaluate how to apply that paradigm to their particular organization.

Thanks for bringing a sense of reality to this, Helmut. I believe that sometimes, in our posts here, we forget that many times the subject matter has to make sense to business leaders who don't frequent this forum. We can debate all day/week/year long, what's a process, what isn't - however, it's got to make sense and be value added to the management of the organization.

Their frustration is palpable when they are told (often by quality professionals) that to comply; "We have to map all our processes and show their interaction and everything we do is considered a process".

Helmut,

I would consider it a significant process....my daughter is still very young (3 next month) so yes at this point in time the situation I described can stop the household and prevent it from operates efficiently (or at all ;))

However, I do agree with your point as it all depends on the size and maturity of the house (organization) as to how many subprocesses exist and the significance of said processes (re: as she gets older it becomes much less significant and becomes more of a subprocess (re: work instruction level) than at this time).

John

Andy,

Either you have forgotten or never have experienced a small child having trouble going to the bathroom. Trust me...it is a process!

Input - electrical impulses telling brain that muscular contraction required
things happen
Output - happy kid.

:)

Actually I've had this experience more than once - I have two sons and I was that small child, myself. It might seem like a process to a parent, but it's actually the 'end' (pardon the euphemism) of the bodily process......

Agreed it is the "end" but a very significant step in the overall process! The impact of the last step on working can be extreme! ;)

This also holds true in the business world! I am currently dealing with a situation where the planners were "unaware" of the number of steps needed to meet customer requirements. As a result, the process is very much undefined, inefficient, and we are having trouble meeting deadlines (we have met them but not in a profitable manner!).

Why? The "menial" steps were overlooked results in a lack of understanding of the total process.

Yes, I get stuck "wiping up" again (yes, I had to go there) due to the lack of review of ALL of the processes. All of the processes must work in unison to ensure success. Doesn't this make all "sub-processes" significant to the overall process?

John

Helmut,

I would consider it a significant process....my daughter is still very young (3 next month) so yes at this point in time the situation I described can stop the household and prevent it from operates efficiently (or at all ;))

However, I do agree with your point as it all depends on the size and maturity of the house (organization) as to how many subprocesses exist and the significance of said processes (re: as she gets older it becomes much less significant and becomes more of a subprocess (re: work instruction level) than at this time).

John


OK...well, to keep with the theme expressed in the last few comments, each organization can define their processes in a manner that suits their current needs..and potty training is clearly a current need. The organization can also redefine processes over time, as situations change...and you may eventually decide it is in fact better described as one of many sub-subprocesses on the road to training and raising your young daughter. Thus, it would perhaps be better defined as your organization's "Child Rearing Process," and "potty training" would simply be a subprocess thereunder (with some very notable "OUTPUTS)." :notme:

In fact, if this is your first child, you will find that list of subprocesses will become LONG, indeed, over the next 20 years...

However, to your important point, it would be the organization's prerogative to define it as they wish, as long as it results in a viable and effective Quality Management System.

...I am currently dealing with a situation where the planners were "unaware" of the number of steps needed to meet customer requirements. As a result, the process is very much undefined, inefficient, and we are having trouble meeting deadlines (we have met them but not in a profitable manner!).

Why? The "menial" steps were overlooked results in a lack of understanding of the total process.

Yes, I get stuck "wiping up" again (yes, I had to go there) due to the lack of review of ALL of the processes. All of the processes must work in unison to ensure success. Doesn't this make all "sub-processes" significant to the overall process?

John

I agree with your premise. But, I believe your position would be more correct to say:

... the problem occurred due to the lack of review of ALL of the menial steps in the planning process. They may also have failed to understand all the processes, but your complaint was they did not consider all the menial steps. That is the classic breakdown in management - not managing the process.

And yes, subprocesses are VERY important to the overall process. In fact, I argue the Subprocesses ARE the Process. You don't actually do a process, you do all the subprocesses and activities within that process.

For example, grocery shopping is a process, but is actually a basket of many subprocesses:
selecting the store, (vendor selection)
driving to the store, (transportation)
selection and comparison of products, (inspection)
paying the bill, (procurement) and,
driving back home, (transportation or shipping)
and putting it all away (storage and inventory management)

All together, we call that "Grocery Shopping." But to improve that process, you actually have to understand all the subprocesses within the process. At the sub and lower levels is where the activity, failure and improvements occur. So, yes, subprocesses are VERY important, and frequently overlooked.

Thanks again to all. It seems a useful debate. I'm afraid I have to duck out of it for a week - holiday / vacation in the Austrian Alps.

Have fun!

Thanks again to all. It seems a useful debate. I'm afraid I have to duck out of it for a week - holiday / vacation in the Austrian Alps.

Have fun!

Nice one, Paul! "Let's you and him fight. Oh, by the way, I have to step outside for a bit." :lol:
Seriously, though, this is a great thread.:applause:

I see it pretty much like Andy and Helmut, I think. While every activity that actually affects a transformation can be described as a process, some processes are far more important than others.

One thing I've learned from clients and employers over the years is that the important (key, core, value stream, whatever you call it) processes are the ones that bring money into the organization. Those are the ones that deserve the most attention.

All the other processes deserve attention in proportion to their impact on the stream of key processes. This will be different for different organizations; it will be different for the same organization over time.

So there is no effective cookie cutter approach, no one-size-fits-all list of processes or process categories. But there is a principle to apply: pay attention to what's important.

Randy, it can, agreed..................but should it? I don't agree, for example, with your list. Without promulgating bathroom humo(u)r, 'going potty' isn't a process!:notme:


Yes it is...

There is an input called food

There is a value added activity called digestion

And there is definitely an output (which to the body adds value as well)

The measurement comes from satisfaction and relief of discomfort;)


As for some things being "sub-processes" remember, even a "subprocess" is a process, it's just part of a larger one. In fact everything going on in any organization can be called a "sub-process"

Ya gotta take it from a different perspective.

Yes it is...

There is an input called food

There is a value added activity called digestion

And there is definitely an output (which to the body adds value as well)

The measurement comes from satisfaction and relief of discomfort;)


As for some things being "sub-processes" remember, even a "subprocess" is a process, it's just part of a larger one. In fact everything going on in any organization can be called a "sub-process"

Ya gotta take it from a different perspective.

How would a doctor use this process model to diagnose system failure?

How would a doctor use this process model to diagnose system failure?

Problem with food to include fluids

Problem with upper digestive system

Problem with lower tract

A problem in any one or combination could be a cause of breakdown....

Either the above or a bad case of nerves can stsrt or stop the process abruptly:lol:

Yes it is...

There is an input called food

There is a value added activity called digestion

And there is definitely an output (which to the body adds value as well)

The measurement comes from satisfaction and relief of discomfort;)


As for some things being "sub-processes" remember, even a "subprocess" is a process, it's just part of a larger one. In fact everything going on in any organization can be called a "sub-process"

Ya gotta take it from a different perspective.

Randy:
You've given a great response which identifies the problem which is at the heart of much of why implementors get in trouble. They define their organization's processes in isolation of their management. By way of explanation:

The inputs to the body are, indeed food, however the output which is meaningful and measurable is energy - heat, work, nervous (electrical) etc. The waste is processed and expelled, yes, but it's not the desired output which is important to the process - and before you run off with the old joke about no output being bad, we're not using a good analogy anyway!

If we had used the guidance of a knowledgable person (in this case a doctor) we wouldn't have made assumptions about what the output was etc.

The danger, IMHO, is very real that when people start off by creating all kinds of documentation, nice looking graphics of process flows etc., they are often missing a vital point - it is an accurate description of the business?

The waste is processed and expelled, yes, but it's not the desired output Andy, I think you just triggered an epiphany for a few Covers....:lol:

I was trying to keep it really simple Andy.

Too many times people equate process to a manufacturing focus only and that is not the case.

Sorry I have arrived late. I voted for all of them.

I consider all of them important (significant) processes, to some group within the organization. The days of simple input/output, stimulus/ response have passed; too many things happening in the middle.

Sorry I have arrived late. I voted for all of them.

I consider all of them important (significant) processes, to some group within the organization. The days of simple input/output, stimulus/ response have passed; too many things happening in the middle.

Yay for Brad:applause:

Sorry I have arrived late. I voted for all of them.

I consider all of them important (significant) processes, to some group within the organization. The days of simple input/output, stimulus/ response have passed; too many things happening in the middle.

Brad,

I see your point. I'm not sure we can conclude that they all contribute equally to the success of the organization, though.

I'm pretty sure we can say they don't all merit the same level of attention, especially at any given point in time.

Yes it is...

There is an input called food...
I didn't vote because of the "...worthy of inclusion on your process map.", since I see no requirement for a process map.

But Randy, you are only partially correct.

What other inputs do you need?
Toilet?
Toilet Paper?
Reading Material?
Water for the Toilet?
Instructions?
Lighting?

When looking at the inputs, you really should consider all of the inputs.

Thanks to all who have contributed to the thread .... and before you ask the skiing was magnificent! :D

Just to clear up a couple of things:

Yes, they are all processes
They are all important in their own way


I didn't vote because of the "...worthy of inclusion on your process map.", since I see no requirement for a process map.

There is no requirement for a process map, please excuse my shorthand, if I have to explain every word and phrase the flow gets lost. A bit like reading a dictionary as a novel - not much of a plot but at least every word is explained as you go along! :lol:
If we take the ISO wording for the requirement in the quality manual:c) a description of the interaction between the processes of the quality management system. then I presume in this high level document you wouldn't (taking the least popular option) include a reference to "E-mailing our brochures." Or have I misjudged you all totally?

Yay for Brad:applause:Yay for Randy and your usual non partisan contribution to intelligent debate. As you can see I have returned from my vacation full of the joys of spring! :lmao:

I had hoped people would be moving the thread on to some assessment of significance and business risk.

We are the people who are supposedly driving quality forward and talking to senior managers about strategic approaches to quality.

It seems we can't even grasp the pareto principle. :nope:

...I had hoped people would be moving the thread on to some assessment of significance and business risk.

We are the people who are supposedly driving quality forward and talking to senior managers about strategic approaches to quality.

It seems we can't even grasp the pareto principle. :nope:

Hi Paul - you got to go skiing, and in the US, many of us were sliding along the roads in snowstorms...I think you had more fun.

More than half of the posts addressed some degree of separating your list into higher level processes and lower level sub-activities, but I agree, it would have been nice if everyone got that understanding from your stated exercise.

I got two things from your exercise:

The poll results do show a reasonable degree of understanding higher and lower level processes.

It does point out that different companies will choose to define their system into different processes, and we auditors need to be open to various approaches, as long as they are reasonable.

Hi Paul - you got to go skiing, and in the US, many of us were sliding along the roads in snowstorms...I think you had more fun.

More than half of the posts addressed some degree of separating your list into higher level processes and lower level sub-activities, but I agree, it would have been nice if everyone got that understanding from your stated exercise.

I got two or three things from your exercise:


The poll results do show a reasonable degree of understanding higher and lower level processes.
It does point out that different companies will choose to define their system into different processes, and we auditors need to be open to various approaches, as long as they are reasonable.
44% agree that IT Support is a viable "suport process."Thanks for putting the exercise up. I think it was worthwhile. Some of the items, Change Management, for example, could be defined as a process by some, and others would put it under their Design or Engineering process. So that would show differences in the poll.

Yay for Randy and your usual non partisan contribution to intelligent debate. As you can see I have returned from my vacation full of the joys of spring! :lmao:


:topic:

Thank you Paul............

I will be in the UK in early April, possibly Milton Keynes, attending AS9110 Train-the-Trainer. I don't know the particulars yet.

Just to clear up a couple of things:

Yes, they are all processes
They are all important in their own way


There is no requirement for a process map, please excuse my shorthand, if I have to explain every word and phrase the flow gets lost. A bit like reading a dictionary as a novel - not much of a plot but at least every word is explained as you go along! :lol:
If we take the ISO wording for the requirement in the quality manual: then I presume in this high level document you wouldn't (taking the least popular option) include a reference to "E-mailing our brochures." Or have I misjudged you all totally?

Paul

Welcome back! As you might expect(!), I have one or two observations which might well be at variance with your comments:

"Which of the following is a process worthy of inclusion on your process map"?

What do you imagine "my process map" might be? I ain't got one, and never will...

To me, a "process map" is a description of a process. Drawing a picture (a "system map"?) to define the "sequence and interaction of processes" is very often an incomplete, relatively worthless and pointless exercise, which may do the drawer some good, but is unlikely to tell the workers little more than "we win work, we do work, and then send an invoice, and we need to control a few things as we do it". And so what if an external assessor wants to see a picture?

"Yes, they are all processes":

"Management responsibility" is a process? Never! It is a heading in a standard - that doesn't make it a process.

"The annual budget" is a piece of information - no "transformation" in sight (if we use the "traditional" definition of a process (not that I would recommend it...))

And "Contract review" is very often just a task in the tendering process - it doesn't even mean "the review of a contract" (it happens before there is any agreement to review), but it has got into people's mindsets because of the old version of 9001 and the fact that folk didn't read the words and think what they meant.

"I have to explain every word and phrase" - sometimes it may be necessary - assumptions are dangerous things (maybe even processes...?)!

:topic:

Thank you Paul............

I will be in the UK in early April, possibly Milton Keynes, attending AS9110 Train-the-Trainer. I don't know the particulars yet.

Randy - I know one or two good pubs (well they were when I lived there!) in the area and some around and about.......

Will you get a chance for a few days vacation, while over there?

I'm going to have a day or two on both sides of the training because of travel costs and I hope to get around a bit to endanger US-UK relations:lol:

My wife is really upset. Judi lived in the UK a couple of years with her 1st husband and our oldest was born there. Judi still has a good friend she has remained in touch with and is frothing at the bit because of a previous engagement she can't get out of, so she can't go.

I'm actually more interested in the "historical" stuff and will be mapping out an intinerary once I know the dates and all that. Being a history buff of sorts I appreciate the common history we share.

This is my 1st trip and maybe my only trip so I need to make the most of it.

Randy:
It's all history - you won't have to go far............:lmao:

Don't waste your time going to Stonehenge.......there's a lot more interesting stuff than a bunch of bricks sticking out of the grass:lol:

I voted that they all were processes, thay all have INPUTS and OUTPUTS. Same here.

Don't waste your time going to Stonehenge.......there's a lot more interesting stuff than a bunch of bricks sticking out of the grass:lol:

http://elsmar.com/jpg/stonehenge.jpg

Stonehenge

I was there in 1965. No fences or anything. In fact, the day we were there we were the only people there, at least while we were there for a couple of hours. It was *neat*. I was 15 at the time. My parents and my little sister and I went there (we were living in Wimbledon and did a lot of weekend trips). I'm sorta a history nut (as was my father), and I was even back then. History and anthropology are neat!

Same here.

They are all processes, of some sort of importance...but would you actually define them as full processes in the QMS, at a flowchart level?

Thanks to all who have contributed to the thread .... and before you ask the skiing was magnificent! :D

Just to clear up a couple of things:

Yes, they are all processes
They are all important in their own way


......There is no requirement for a process map, please excuse my shorthand, if I have to explain every word and phrase the flow gets lost. A bit like reading a dictionary as a novel - not much of a plot but at least every word is explained as you go along! :lol:
................ :nope:


Hi Paul, and welcome back.

Not that I care to be redundant (Item #21 in this thread), or to extend this discussion further, but as Helmet has repeatedly pointed out in this thread, it depends what "level" Process Map you are referring to in your Question.

The discussion thread starter identifies the question as:

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

But then, your Poll question is:

Which of the following is a process worthy of inclusion on your process map?"
These are two totally different questions, and now I'm wondering exactly which one people are answering. I originally thought you were speaking about the "QMS" sequence and interaction Map (which I believe only captures how the QMS works, and not how you build thingamajigs). The Poll question refers to "Process Map", in the singular, so I guessed you were speaking of the Map that defines the QMS.

Or....perhaps you really were asking: "What processes warrant inclusion in your Product Realization Process?"

Sorry, this is rather late in the discussion, but it might help to get everyone on the same page.

Thanks,
Patricia

P.S. I think this distinction demonstrates, at least in part, the importance and justification for having a Model that defines the workings of the QMS at a Macro Level. I know I won't find much agreement here on the Cove, since many have expressed their distinct disdain for this "requirement", calling it useless, of no consequence to anyone...not understood by employees, non-value added, or simply non-existent and unnecessary". I still contend that the QMS (sequence & interface) Model is Sr. Management's roadmap for managing the company, and should be familiar to, and understood by all employees. Rest assured, it is not my intention to revisit that discussion here. Patricia

:topic:

Thank you Paul............

I will be in the UK in early April, possibly Milton Keynes, attending AS9110 Train-the-Trainer. I don't know the particulars yet.
Thanks, Randy. I'd love to meet you. I am based in Northampton (c 20 miles) and work just outside Milton Keynes. Let me know your schedule and we could meet up - how will I recognize you? :lol:

Hi Paul, and welcome back.Thanks, Patricia. I'd love to say I'm glad to be back. :bonk:

It's only visiting the cove that keeps me sane!:lol:

Not that I care to be redundant (Item #21 in this thread), or to extend this discussion further, but as Helmet has repeatedly pointed out in this thread, it depends what "level" Process Map you are referring to in your Question.

The discussion thread starter identifies the question as:

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

But then, your Poll question is:

Which of the following is a process worthy of inclusion on your process map?"

Thanks for pointing this out. When I originally put together the poll it was under the ISO 9001 sub forum and the title wasn't the one that now heads this thread. Perhaps the moderator who moved it can remember what the original title was - I've skiied since then - and drunk schnapps! :lol:

These are two totally different questions, and now I'm wondering exactly which one people are answering. I originally thought you were speaking about the "QMS" sequence and interaction Map (which I believe only captures how the QMS works, and not how you build thingamajigs). The Poll question refers to "Process Map", in the singular, so I guessed you were speaking of the Map that defines the QMS.Agreed. The point of the poll was to invite covers to identify which of these processes is significant enough to be listed in your quality manual (sequence and interaction).

Or....perhaps you really were asking: "What processes warrant inclusion in your Product Realization Process?"Nope! A lot of the "significant" processes are support processes rather than core process (Product realization) - e.g. business planning.

Sorry, this is rather late in the discussion, but it might help to get everyone on the same page.

Thanks,
Patricia

P.S. I think this distinction demonstrates, at least in part, the importance and justification for having a Model that defines the workings of the QMS at a Macro Level. I know I won't find much agreement here on the Cove, since many have expressed their distinct disdain for this "requirement", calling it useless, of no consequence to anyone...not understood by employees, non-value added, or simply non-existent and unnecessary". I still contend that the QMS (sequence & interface) Model is Sr. Management's roadmap for managing the company, and should be familiar to, and understood by all employees. Rest assured, it is not my intention to revisit that discussion here. Patricia Exactly. The significance test was introduced to try and weed out the "IT support" and "document control" processes and get Covers to focus on the significant few rather than the insignificant many.

44% agree that IT Support is a viable "suport process."

But is it worthy of inclusion in the description of sequence and interaction?

Popularity doesn't mean it is right.

:topic:

It is interesting how progress is made in management field....3R rules...


Turtle chart was adopted from Phillip Crosby's "Process Analysis Work Sheet." I am sure Crosby also adopted it from someone else...
Phillip Crosby also made a distinction between a "Process" and a "Program".
For example: Quality Improvement is a process and not a program.


Crosby defined a process as being "on going" and never ending and a program to have a beginning and an end.
In one of seminars, he did not speak kindly of ISO and found the principles in contradiction modern management principles!!!
Now, all work is process.

I wonder what QMS is headed?

Turtle chart was adopted from Phillip Crosby's "Process Analysis Work Sheet." I am sure Crosby also adopted it from someone else...
Phillip Crosby also made a distinction between a "Process" and a "Program".
For example: Quality Improvement is a process and not a program.
Crosby defined a process as being "on going" and never ending and a program to have a beginning and an end.

Michelle

Thanks for making me think!

I'm not sure about "Quality Improvement" being a process. Could it be an "Objective", or even a "Policy", which is achieved in a variety of ways, perhaps by individual "projects"?

And I reckon that the "Procurement" process, and the "Tendering" process, are just that - ways of doing something which may be (is) repeated as required. To me, a "Program" is more like a collection of projects - which by definition is time-limited.

I can see that a "continuous" production line could fit the "process" definition (at least until someone turns the power off), but I'm not convinced otherwise.

It all adds to the challenge of deciding "what is a process"!

Michelle

Thanks for making me think!

I'm not sure about "Quality Improvement" being a process. Could it be an "Objective", or even a "Policy", which is achieved in a variety of ways, perhaps by individual "projects"? Think about it Peter....Quality Improvement has to have inputs, something done with them, and outputs (primarily improved Quality)


And I reckon that the "Procurement" process, and the "Tendering" process, are just that - ways of doing something which may be (is) repeated as required. To me, a "Program" is more like a collection of projects - which by definition is time-limited.

I can see that a "continuous" production line could fit the "process" definition (at least until someone turns the power off), but I'm not convinced otherwise.

It all adds to the challenge of deciding "what is a process"!


Process is so easy that the tendency is to complicate it to make it more acceptable

INPUT - - ACTIVITY (Doing something to or with the Input) - OUTPUT (The result of something being done to or with the Input)

Process is so easy that the tendency is to complicate it to make it more acceptable

INPUT - - ACTIVITY (Doing something to or with the Input) - OUTPUT (The result of something being done to or with the Input)

As you may guess I take a different view. :D

A process may be simple but it is rarely easy.

The difference is:
You can easily identify all the inputs and outputs, the resources and controls - that is the easy bit.
The difficult bit is to identify and manage all the interactions of the elements of the process - particularly the humans involved.


Take implementing a new procedure for example - simple.

Then why:
does it take so long
is it difficult to get all stakeholders to agree what it should contain
once issued despite how much you communicate requirements and train people they don't follow it?


It's called systems thinking and says you can't break a complicated organization like a company down and micro manage small bits of it and expect the whole to work as well as you would like.

Michelle

Thanks for making me think!

I'm not sure about "Quality Improvement" being a process. Could it be an "Objective", or even a "Policy", which is achieved in a variety of ways, perhaps by individual "projects"?

And I reckon that the "Procurement" process, and the "Tendering" process, are just that - ways of doing something which may be (is) repeated as required. To me, a "Program" is more like a collection of projects - which by definition is time-limited.

I can see that a "continuous" production line could fit the "process" definition (at least until someone turns the power off), but I'm not convinced otherwise.

It all adds to the challenge of deciding "what is a process"!


I don't think we should debate whether IS a process. Pretty much most activities can be classed as a process. In systems thinking, I think the relevant question is which processes should be defined at the QMS system level, and the rest should be subprocesses and even subactivities below that.

As you may guess I take a different view. :D

A process may be simple but it is rarely easy.

The difference is:
You can easily identify all the inputs and outputs, the resources and controls - that is the easy bit.
The difficult bit is to identify and manage all the interactions of the elements of the process - particularly the humans involved.


Take implementing a new procedure for example - simple.

Then why:
does it take so long
is it difficult to get all stakeholders to agree what it should contain
once issued despite how much you communicate requirements and train people they don't follow it?


It's called systems thinking and says you can't break a complicated organization like a company down and micro manage small bits of it and expect the whole to work as well as you would like.


It's all very simple....Humans are resistant to change no matter how beneficial it may be. We like contiuity...sameness so to speak. If it is different, we aren't gonna do it.

Just look at the old Roman Republic and the later Empire....it conquered, but did not require those conquered to change anything other than where the taxes were sent, and to whom ultimate alliegence was to be given (always to Rome and later to Ceasar (sitting Emperor). Those conqured were allowed to keep their identity, religion and internal culture pretty much intact. Rome recognized early on that with less change there is greater potential for stability, acceptance and peace (Pax Romana). It was only after more aggressive Roman rule came down that we see the internal strife (like in Judea).

New procedure = Change = Resistance

I don't think we should debate whether IS a process. Pretty much most activities can be classed as a process. In systems thinking, I think the relevant question is which processes should be defined at the QMS system level, and the rest should be subprocesses and even subactivities below that.

Absolutely right.

I would only add that some of these processes are critical to the health of the organization, and others are not so critical.

Hence, I think, Paul Simpson's earlier invocation of the Pareto principle.

It's all very simple....Humans are resistant to change no matter how beneficial it may be. We like contiuity...sameness so to speak. If it is different, we aren't gonna do it.

New procedure = Change = Resistance

Thanks for the history lesson, Randy. :)

Applying your logic then nobody would ever want to change anything?

There are some of us who welcome beneficial change - like the need to move a debate forward! :D

It's all very simple....Humans are resistant to change no matter how beneficial it may be. We like contiuity...sameness so to speak. If it is different, we aren't gonna do it.


Humans resist imposed change.

Humans resist change when there's no good answer to "What's In It For Me?" The change that benefits the company (shorter cycle time! yay!) may injure the employee (less overtime! boo!)

Humans readily adopt changes when they see a benefit; as in this whole Internet thing.

Humans resist imposed change.

Humans resist change when there's no good answer to "What's In It For Me?" The change that benefits the company (shorter cycle time! yay!) may injure the employee (less overtime! boo!)

Humans readily adopt changes when they see a benefit; as in this whole Internet thing.

The degree of resistance is proportional to culture and environment...

Sometimes it is negligible where absolute obedience is considered a positive attribute and virtue or "we/us" is used more considered than "I/me"...

Just my opinion.

The degree of resistance is proportional to culture and environment...

Sometimes it is negligible where absolute obedience is considered a positive attribute and virtue or "we/us" is used more considered than "I/me"...

Just my opinion.

Good point. My cultural frame of reference for that post was Western.

Think about it Peter....Quality Improvement has to have inputs, something done with them, and outputs (primarily improved Quality)

Process is so easy that the tendency is to complicate it to make it more acceptable

INPUT - - ACTIVITY (Doing something to or with the Input) - OUTPUT (The result of something being done to or with the Input)

Randy

I assure you that I have thought about it(!) - which is why I am suggesting that "Quality Improvement" / "A safer working environment" / "Less damage to the environment" / "Learning lessons" are all "objectives". All of which can be achieved by lots of small (possibly unrelated) projects and activities.

Mind you, I don't find that the "Inputs - Transformation - Outputs" definition is always helpful (maybe because folk complicate it as you say). I prefer "a sequence of related tasks triggered by an event and intended to achieve an objective" - which recognises that there is a reason or aim in starting to do something, and so ties processes and objectives together.

Mind you, I don't find that the "Inputs - Transformation - Outputs" definition is always helpful (maybe because folk complicate it as you say). I prefer "a sequence of related tasks triggered by an event and intended to achieve an objective" - which recognises that there is a reason or aim in starting to do something, and so ties processes and objectives together.
Peter,

I prefer the other definition because it makes it easy to see how the process adds value. If the output is not much changed from the input, then the process doesn't add much value.

Prime example: I recently encountered a process called "warehousing" that consisted of hauling big bags of stuff from place to place. I guess the assumption was that the stuff in one place was more valuable than stuff in another place.

Fortunately the organization has dropped warehousing as a process and quit hauling the stuff from place to place for no apparent reason.

Peter,

I prefer the other definition because it makes it easy to see how the process adds value. If the output is not much changed from the input, then the process doesn't add much value.

Prime example: I recently encountered a process called "warehousing" that consisted of hauling big bags of stuff from place to place. I guess the assumption was that the stuff in one place was more valuable than stuff in another place.

Fortunately the organization has dropped warehousing as a process and quit hauling the stuff from place to place for no apparent reason.

Cliff

That is exactly why "my" definition works for me! What is the objective in "hauling big bags of stuff from place to place"? If you asked the person involved: "why are you doing this, mate?", I bet he won't say "I am trying to transform an input" - if he has thought about it at all(?), he might be trying to keep it dry / keep it tidy / get it ready for despatch (or even "keep the boss off my back"...?)

Cliff

That is exactly why "my" definition works for me! What is the objective in "hauling big bags of stuff from place to place"? If you asked the person involved: "why are you doing this, mate?", I bet he won't say "I am trying to transform an input" - if he has thought about it at all(?), he might be trying to keep it dry / keep it tidy / get it ready for despatch (or even "keep the boss off my back"...?)

What I don't get out of your version of the conversation is a way to show the boss that the movement is a waste of time.

With the input-transformation-output model I can show the labor vs. results very easily.

I am quite confused exactly which constructs are we referring to.:)

First, the title of the poll has been changed. It started as:


original 'Which of these are processes and why?


And is currently:


Which of the following is a process worthy of inclusion on your process map?


Just saying, that is two totally different things. I would vote differently for each.

Now, the word process is very general and vague. My definition is:

Process is so easy that the tendency is to complicate it to make it more acceptable

INPUT - - ACTIVITY (Doing something to or with the Input) - OUTPUT (The result of something being done to or with the Input)

Exactly what Randy has. Thus, every entity within the organization has a process. That process is important to them.

However, if you are using the business process definition, it is a bit more open, and I think may coincide with some of Paul's current thoughts:
http://en.wikipedia.org/wiki/Business_process (http://en.wikipedia.org/wiki/Business_process)

Within the business process definition above, yes, I would limit some of them as more impacting than others.
****
Consider the group of us taking a Cove cruise. Most of us hopefully are enjoying ourselves too much to be worrying about the operations management of the ship.:tg:

To the people who work on the ship, every operation has a process. Can anyone enlighten me which of the process on that cruise ship is not significant? It's significant to some group of stakeholders, one way or another.

As you may guess I take a different view. :D

A process may be simple but it is rarely easy.

The difference is:

You can easily identify all the inputs and outputs, the resources and controls - that is the easy bit.
The difficult bit is to identify and manage all the interactions of the elements of the process - particularly the humans involved.Take implementing a new procedure for example - simple.

Then why:

does it take so long
is it difficult to get all stakeholders to agree what it should contain
once issued despite how much you communicate requirements and train people they don't follow it?It's called systems thinking and says you can't break a complicated organization like a company down and micro manage small bits of it and expect the whole to work as well as you would like.

I agree with systems thinking. However, when eating an elephant, one must take one bite at a time. Even with operations, there must be tiered levels. I envision one big system, with several systems encompassed in that.

Even with operations, there must be tiered levels. I envision one big system, with several systems encompassed in that.

Ahhhh, a part of the definition of "process approach to management"............

Peter,

I prefer the other definition because it makes it easy to see how the process adds value. If the output is not much changed from the input, then the process doesn't add much value.

Prime example: I recently encountered a process called "warehousing" that consisted of hauling big bags of stuff from place to place. I guess the assumption was that the stuff in one place was more valuable than stuff in another place.

Fortunately the organization has dropped warehousing as a process and quit hauling the stuff from place to place for no apparent reason.

Perhaps the warehousing process is actually "Inventory Management." If so, there is a lot involved in a company that buys batches of material, makes batches of product, and needs to have a robust method of storing this product until it can sell smaller quantities to various customers.

All of a sudden, it does not seem so silly, especially when one thinks of the vast amounts of money wrapped up in these inventories.

Randy

I assure you that I have thought about it(!) - which is why I am suggesting that "Quality Improvement" / "A safer working environment" / "Less damage to the environment" / "Learning lessons" are all "objectives". All of which can be achieved by lots of small (possibly unrelated) projects and activities.

Mind you, I don't find that the "Inputs - Transformation - Outputs" definition is always helpful (maybe because folk complicate it as you say). I prefer "a sequence of related tasks triggered by an event and intended to achieve an objective" - which recognises that there is a reason or aim in starting to do something, and so ties processes and objectives together.


I think there is little to be gained from debating whether your processes are better than my processes.
ISO clearly allows/requires each organization to "define its processes." This collection of processes must cover all the activities of the organization.
The organization may name them in any approrpiate manner, as long as it is an appropriate manner.
The auditor does not define what may be a process, as long as they are reasonably appropriate.
The key is how we improve and optimize the performance of those processes, the results, outputs, and interactions.
It is not important whether we agree on process names, because we each approach this exercise from different perspectives.Let's move on to the important things - results, not names.

What I don't get out of your version of the conversation is a way to show the boss that the movement is a waste of time.

With the input-transformation-output model I can show the labor vs. results very easily.

So if you take an "effective" warehousing process (one which keeps the inventory in good condition until ready for despatch) what is the "input", what is the "output" and what was "transformed"? I would imagine that the worst possible outcome from that process would be for the goods to be “transformed” – you want them to come out looking and working exactly the way they did when they went in.

I think there is little to be gained from debating whether your processes are better than my processes.Actually there is lots to be gained from debating understanding of processes. As covered in much detail elsewhere and my opening for this thread was:
On another thread (or several) there has been some disagreement about what a process is. Perhaps covers could take part in a poll as to which of the "processes" listed is significant and their justification.
And then later when I explained my votes, I added:


There is a point. ISO 9001 is supposed to be a quality standard. We are the key users of ISO. If we don't understand whether a process is a process or whether it is worthy of recording / flowcharting / measuring then who else will?
This is a dialogue. I may be abrupt but I want understanding to be better - if that is mine or everyone else's
To go back to the ISO definition of "transform inputs into outputs" is to miss the point. There are some things that are significant and important to control and need highlighting on a "process map" there are others that need less management

I am not going to argue with the Input -> Process -> Output people any more - life is too short. :bonk:

What I will say as a parting shot is that if we are to rid ourselves of the image that others have of us as micro managers and the "document guys / gals" then we have to see big picture and concentrate on the business critical processes (significant) and let all the others go without significant monitoring or measuring.
ISO clearly allows/requires each organization to "define its processes." This collection of processes must cover all the activities of the organization.ISO doesn't allow anything. It does require the organization to identify its processes, the interrelationships and measures necessary to control (my ISO shorthand, you can look it up as well as I).

If you are spending time on the insignificant many then the whole purpose of the process approach is lost.
The organization may name them in any approrpiate manner, as long as it is an appropriate manner.
The auditor does not define what may be a process, as long as they are reasonably appropriate.As we have discussed endlessly the point of an assessment is to take a judgement as to whether the organization has satisfied the requirements (in this case in clause 4.1) and if they haven't to raise a finding. So if someone has listed a process of IT support (:))I would have to take issue. I'm not going to fail them just for that but it is part of the process of improving process understanding when I tell them that IT support is part of a series of other processes (see earlier).
The key is how we improve and optimize the performance of those processes, the results, outputs, and interactions.Starting with the important ones - the significant processes. On many other threads I have seen covers asking what kind of measures they should have for the calibration, document control etc., etc. systems. Concentrate on the big stuff and the little stuff sorts itself out.
It is not important whether we agree on process names, because we each approach this exercise from different perspectives.
Yes, and my contention is the "process" of "identifying processes" is too variable across organizations and quality professionals. My concern is that it is a bureaucratic / check box approach without any deep understanding of what processes are (apart from I/P -> O/P) and how they should be managed.

Let's move on to the important things - results, not names.Please explain how you think results are identifiable if processes are not adequately defined.

Paul

I agree! Well said.

Paul

I agree! Well said.
Now I'm in trouble. :mg:

If you're agreeing with me Peter .... :lol:

Now I'm in trouble. :mg:

If you're agreeing with me Peter .... :lol:

Paul

You are bound to be right at least some of the time...!

:topic:

Paul, I'm going to be fairly close to you April 1-6. I have some training to attend just outside Birmingham in Hampton-in-Arden, Solihull with Tec Transnational.

Perhaps the warehousing process is actually "Inventory Management." If so, there is a lot involved in a company that buys batches of material, makes batches of product, and needs to have a robust method of storing this product until it can sell smaller quantities to various customers.

All of a sudden, it does not seem so silly, especially when one thinks of the vast amounts of money wrapped up in these inventories.

Helmut,

No disagreement. Just in the cited example, it wasn't really what we would call inventory management. It was movement to no real purpose.

:topic:Randy, I may be passing quite close by there on 3rd April - would like to call in if you are available.

So if you take an "effective" warehousing process (one which keeps the inventory in good condition until ready for despatch) what is the "input", what is the "output" and what was "transformed"? I would imagine that the worst possible outcome from that process would be for the goods to be “transformed” – you want them to come out looking and working exactly the way they did when they went in.

Actually, that is my point. Warehousing does not add value to the product. (transformation <> deterioration)

So if we have a manufacturing situation where warehousing of finished goods constitutes twenty percent of the labor time for a product, it is easy to demonstrate to management that they are spending too much money on warehousing.

Some companies work very hard to eliminate warehousing activity, because it does not make the product more valuable.

If we ask how much value any process adds to the product, I believe we get better answers than if we ask what is the objective of a process.

So if we have a manufacturing situation where warehousing of finished goods constitutes twenty percent of the labor time for a product, it is easy to demonstrate to management that they are spending too much money on warehousing.

Some companies work very hard to eliminate warehousing activity, because it does not make the product more valuable.That is correct in a large number of cases, but some organizations have a business model which by they do inventory management for their customers. If the customer is not sophisticated enough to provide information on their demand planning, the suppliers have to build an inventory buffer to support "unexpected" product demand. That creates a value to the customer and they normally pay for it.

:topic:

Paul, I'm going to be fairly close to you April 1-6. I have some training to attend just outside Birmingham in Hampton-in-Arden, Solihull with Tec Transnational. Great!

I live between Birmingham and Milton Keynes (about 60 miles total).

Are you going in to the office to see the UK based guys? Let me know your travel arrangements and I will arrange to drop by and meet up.

If Colin is available the drinks are on him!

That is correct in a large number of cases, but some organizations have a business model which by they do inventory management for their customers. If the customer is not sophisticated enough to provide information on their demand planning, the suppliers have to build an inventory buffer to support "unexpected" product demand. That creates a value to the customer and they normally pay for it.

I agree.
Even if the customer is sophisticated enough on their demand planning, the customer's customer may not be.... I have seen "magic multipliers" added to compensate for demand fluctuations. Sometimes they work....

Have you ever seen an optimal model demand forecasting with an acceptable confidence level?

I think in any business model, the scope of inventory management should be defined as related to customer requirements and satisfaction in general terms.

Some customers claim to have JIT...If you examine the system closely, you will notice many pay excessive carrying cost to their suppliers for their practice of JIC.

Let's Consider a small organization business:

Factors such as low inventory turn over rate, safety stock, obsolete/excess inventory, inaccurate inventory, etc...can affect organization financially... to purchase raw material on-time and ship final product on-time. They need to establish a true JIT system.

That is correct in a large number of cases, but some organizations have a business model which by they do inventory management for their customers. If the customer is not sophisticated enough to provide information on their demand planning, the suppliers have to build an inventory buffer to support "unexpected" product demand. That creates a value to the customer and they normally pay for it.

Sidney,

Quite true. Your example supports the idea that activities (processes, tasks, whatever) are better measured by the value they add.

In this case, the customer pays for inventory management. The extra expense is easy to justify.

Actually, that is my point. Warehousing does not add value to the product. (transformation <> deterioration)

If we ask how much value any process adds to the product, I believe we get better answers than if we ask what is the objective of a process.

Clif

But that is not what I asked(!). I wanted to know what is the "input", what is the "output" and what was "transformed"? I have no problem with the idea of value being added, it is the "traditional" definition of a process that I find difficult to apply in some of these situations.

Just hoping to follow the process through until I see the light (that's my objective, and it should result in value being added as well...)

Clif

But that is not what I asked(!). I wanted to know what is the "input", what is the "output" and what was "transformed"? I have no problem with the idea of value being added, it is the "traditional" definition of a process that I find difficult to apply in some of these situations.

Just hoping to follow the process through until I see the light (that's my objective, and it should result in value being added as well...)

Peter,

Maybe the attached process map will help in outlining of input and output....

This map shows one way of describing the process. It is not the optimum...

M

Clif

But that is not what I asked(!). I wanted to know what is the "input", what is the "output" and what was "transformed"? I have no problem with the idea of value being added, it is the "traditional" definition of a process that I find difficult to apply in some of these situations.

Just hoping to follow the process through until I see the light (that's my objective, and it should result in value being added as well...)

Many companies define Inv. Mgt. and Shipping as one process. Generally has the same process owner. If so:

Input = finished goods.
Value added activity = hold product in bulk, pull, package and ship to customers' immediate order.
Output = packaged and shipped goods.

It would be silly to try to make the case to top management that this process adds no benefit to the company, so we have to define it in terms they can be comfortable with.

Then, develop improvement projects to reduce carrying costs.

Actually, that is my point. Warehousing does not add value to the product. (transformation <> deterioration)

So if we have a manufacturing situation where warehousing of finished goods constitutes twenty percent of the labor time for a product, it is easy to demonstrate to management that they are spending too much money on warehousing.

Some companies work very hard to eliminate warehousing activity, because it does not make the product more valuable.

If we ask how much value any process adds to the product, I believe we get better answers than if we ask what is the objective of a process.


The value comes from facilitating customer's inability to forecast effectively.

Peter,

Maybe the attached process map will help in outlining of input and output....

This map shows one way of describing the process. It is not the optimum...

M

Michelle

Thanks. Rather than helping me to understand the "input - transformation- output" definition of a process, it confirms what I think is important:

The objective of the process (ie "why you do it") is:
1 "to ensure customer properties are identified, verified, stored and maintained for incorporation into products
2 to maintain optimal inventory level."

That is clear, understandable and concise, and anyone involved in the process will know why they are doing it.

And taking your first "Input/Output" example, I don't see how an "Inventory Report" etc is "transformed" to create "Excess or Obsolete Inventory". The report doesn't change (although it is needed for the process to work), and Excess or Obsolete Inventory isn't created by the process (although it is identified by it).

To my mind, the "Drawing, Documentation, CTQ list, Sampling Plan and Promised Delivery Date" etc aren't "transformed" either.

But this does help me understand the reasoning behind your earlier quote about a process being ongoing.

Michelle

Thanks. Rather than helping me to understand the "input - transformation- output" definition of a process, it confirms what I think is important:

The objective of the process (ie "why you do it") is:
1 "to ensure customer properties are identified, verified, stored and maintained for incorporation into products
2 to maintain optimal inventory level."

That is clear, understandable and concise, and anyone involved in the process will know why they are doing it.

And taking your first "Input/Output" example, I don't see how an "Inventory Report" etc is "transformed" to create "Excess or Obsolete Inventory". The report doesn't change (although it is needed for the process to work), and Excess or Obsolete Inventory isn't created by the process (although it is identified by it).

To my mind, the "Drawing, Documentation, CTQ list, Sampling Plan and Promised Delivery Date" etc aren't "transformed" either.

But this does help me understand the reasoning behind your earlier quote about a process being ongoing.


I think this discussion is somewhat hobbled by the fact that the examples being discussed are at sub-subprocess levels.

The whole input - transformation - output concept is pretty clear at the high level, full process level of view.

Purchasing - Manufacturing - Shipping.

But when you get down into the sub-activities, these transformations are not always so clearly defined. That is why it is useful to specify what are processes, and what are really subprocesses or smaller activities.

While the principle is the same, at the transaction level, the diagram becomes awfully fuzzy.

peter, I agree that understanding "why" a process is done is important, and knowing what the actual steps are is important too. The details of inputs and outputs are just a natural part of that process. Soemtimes we overthink it.

Where it becomes important is when you try to align and improve processes, typically at a manager or supervisor level. Then, flowcharts and such become useful tools to see bottlenecks and waste.

And taking your first "Input/Output" example, I don't see how an "Inventory Report" etc is "transformed" to create "Excess or Obsolete Inventory". The report doesn't change (although it is needed for the process to work), and Excess or Obsolete Inventory isn't created by the process (although it is identified by it).




The report you mentioned is the result of process of evaluation / analysis / segregation of inventory items, physically or virtually.

This process may not directly affect product quality every time...When you look at big Q (quality of management system) as opposed to little q (product quality), material management affects all aspects of the business and their ability to deliver what customer wants on time...

I think this discussion is somewhat hobbled by the fact that the examples being discussed are at sub-subprocess levels.

The whole input - transformation - output concept is pretty clear at the high level, full process level of view.

Purchasing - Manufacturing - Shipping.

But when you get down into the sub-activities, these transformations are not always so clearly defined. That is why it is useful to specify what are processes, and what are really subprocesses or smaller activities.

While the principle is the same, at the transaction level, the diagram becomes awfully fuzzy.

peter, I agree that understanding "why" a process is done is important, and knowing what the actual steps are is important too. The details of inputs and outputs are just a natural part of that process. Soemtimes we overthink it.

Where it becomes important is when you try to align and improve processes, typically at a manager or supervisor level. Then, flowcharts and such become useful tools to see bottlenecks and waste.

Have you ever used "process approach" outside of auditing?

If yes,.....Can you give an example?

You only need one high level process map to show the sequence and interactions of processes to meet minimum ISO requirements. (However just having process maps alone no matter how many you have is not really evidence that you understand the interactions, just the sequences of processes and subprocesses).

Other than the high level map, you can pick and choose what to process map according to what adds the most value to your companies business/quality system.

You only need one high level process map to show the sequence and interactions of processes to meet minimum ISO requirements. (However just having process maps alone no matter how many you have is not really evidence that you understand the interactions, just the sequences of processes and subprocesses).

Other than the high level map, you can pick and choose what to process map according to what adds the most value to your companies business/quality system.

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

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

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.

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.

In fact, the standard does not require a process map. 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...

http://isotc.iso.org/livelink/livelink/3554880/Process.doc?func=doc.Fetch&nodeid=3554880 (http://isotc.iso.org/livelink/livelink/3554880/Process.doc?func=doc.Fetch&nodeid=3554880)

Every organization is unique with different system and needs. Sales purchasing Manufacturing Shipping is a useless process map for any organization. Didn't they know this order before ISO require them to identify/define processes?

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.

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

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.

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 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... :rolleyes: 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 (http://elsmar.com/pdf_files/flowcharts/). 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.

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! :lmao:
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!:agree1:
:topic:
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:lol:

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.

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.

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.

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.

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.

Michelle,

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

Stijloor.

Stijloor,

EXACTLY!!:agree1:

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.

ISO was never in my responses.:nope:

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

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:D), 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)

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.

“Things which matter most must never be at the mercy of things which matter least.” Goethe

I like it!

Thank you:thanx:

I was looking for some quotes by Theodore Roosevelt and found this website.... www.quotationspage.com It's a pretty good resource.

It is implicit that the OP has decided to do them based on the poll they put together. I think its unwise to try and convince the OP that process maps are not useful.

Although I've only been in the business for 14 yrs I don't think anyone here could convince me that process maps or flow charts don't add value.

Friends,

Great thread, excellent and very passionate posts. Respectful and thoughtful responses. Wow! :applause:

I am impressed with all my Fellow Covers that participate in this thread.

Proud to be part of this Forum!

Stijloor.

Thank you:thanx:

I was looking for some quotes by Theodore Rosevelt and found this website.... www.quotationspage.com It's a pretty good resource.

:topic: Here is another quote from Theodore Rosevelt:

“It is not the critic who counts, not the man who points out how the strong man stumbled, or when the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena; whose face is marred by dust and sweet blood; who strives valiantly; who errs and comes short again and again; who knows the enthusiasms, the great devotions and spends himself in worth cause; who, at best, knows in the end the triumph of high achievement; and who, at worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who knows neither victory nor defeat.”

Does this not stand true for most of us.

Identifying which processes are significant or key from a list of processes makes no sense. We are given no information about the business, its customers or its objectives. First analyze the system to identify the key processes.

One way to do this is to map the core process (at 30,000ft) from end to end (needs to cash) to show the interactions between the organization, its customers and its suppliers. This identifies to sequence and interaction of the key processes in the core process. These are the processes that add value. Then identify the key processes that support the core process. These are the processes that sustain and improve the core process. Support key processes come from the system standard and your common sense. For example, we know that competence requires the ability to apply skills and knowledge; that means that the recruiting and hiring process is key as well as the training process.

They are all processes, some multi-step and some fairly basic. They all have inputs and outputs and added together create one big process, Quality Management.

Jo

Can someone help me to understand what "Key Processes" are? Do most companies generally have the same key processes? Does anyone have examples that they are willing to share?

Can someone help me to understand what "Key Processes" are? Do most companies generally have the same key processes? Does anyone have examples that they are willing to share?

Some organizations define a Key Process as a process of which results (output) have a direct/immediate impact on the customer (and satisfaction).

Examples:

RFQ handling
Order reviews and confirmations
Product design and development
Manufacturing processes
Shipping
Invoicing
Etc.
In automotive, the term "Customer Oriented Process" (COP) is used.

Stijloor.

Can someone help me to understand what "Key Processes" are? Do most companies generally have the same key processes? Does anyone have examples that they are willing to share?

Nicole,

You're going to find as many answers to this as there are contributors on this website...so here's at least, one of possibly thousands of opinions...

There are two ways of approaching this question. Are we defining the Key processes of the Business Operating System, or the Key Processes of Product Realization? The answers to either will vary considerably.

My answer to "What are the Key Processes of the Business Operating System?" are as follows:

1 - System-oriented Processes

a) SOP-0001 Internal Audit
b) SOP-0002 Control of Documents and Records

2 - Management-oriented Processes

a) SOP-0003 Business Planning and Management Review
b) SOP-0004 Monitoring, Measurement and Analysis
c) SOP-0005 Corrective & Preventive Action and Continual Improvement

3 - Support-oriented Processes

a) SOP-0006 Employee Competence, Empowerment and Motivation
b) SOP-0007 Control of Monitoring and Measuring Devices
c) SOP-0008 Purchasing and Materials Management
d) SOP-0009 Infrastructure & Production Support

4 - Customer-oriented Processes

a) SOP-0010 Product Realization
b) SOP-0011 Change Control - Product, Process and Sourcing
c) SOP-0012 Control of Non-Conforming Product & Materials

In my opinion, all ISO-compliant companies should have these 12 key processes. They may not be mandatory in the standard, but they just make sense. I'm not going to defend or rationalize my choices in this post.

If you ask me, "What are the Key Processes of Product Realization?", my answer would be the following (for a typical automotive-parts supplier), but this list could easily be edited to comply with any service or manufacturing entity's processes:

I call them the Phases of Product Realization (SOP-0010 above):
Phase 1: Program Feasibility
Phase 2: Quotation and Approval
Phase 3: Concept Development
Phase 4: Product Design, Development and Verification
Phase 5: Production Process Design, Development and Verification
Phase 6: Product Design Validation
Phase 7: Production Process Design Validation
Phase 8: Production Process Part Approval
Phase 9: Product Launch, Production and Delivery
Phase 10: Product Close-Out

These Phases are the sub-components of my SOP-0010 Product Realization (above). I do not consider them Key Processes of the Business Operating System, but sub-processes of Product Realization.

While this list can vary from one organization to the next, the Key Processes of the Business Operating System could, in fact, be identical for each company. I've used this same model for everything from educational, to automotive manufacturing, health care, composite pole-winding, and printing organizations. It's a perfect fit for any one of them.

The variations you will see proposed in this Forum, from company to company are the bi-product of the system owner's perspective on the "Big Picture" of their company, their understanding and interpretation of ISO, and their interpretation of the individual processes and their roles, sequences and interfaces.

In my experience, the Sequence and Interfaces of the B.O.S. processes should be the same for each company, since they are dictated by ISO, and so, it would make sense that they are the same from company to company.

However, Product Realization is really a list of "sequential" activities that are performed in the realization of the product, and hence can vary from one organization to another.

IMHO there's no need to re-invent the wheel with regard to KEY B.O.S. processes...but to each his/her own.

Patricia Ravanello

Can someone help me to understand what "Key Processes" are? Do most companies generally have the same key processes? Does anyone have examples that they are willing to share?

Nichole,

All work is process and some processes you can safely ignore/eliminate from your system (starting with work that adds or enables no value for customers).

Key processes are important enough to the system to be analyzed and documented to the extent necessary for effective planning, operation and control.

You organization has key processes that add value for customers (from the core process) and key processes that sustain and improve the core process.

Here (http://www.aworldofquality.com/content/consulting/KeyProcesses.aspx) you will find two tests for a process to see if it is key to your system. For example, the process "Monitoring and Measuring Processes" may or may not need to be classified "key" depending on the outcome of these two tests.

You can determine your system's key processes by analyzing your system starting with the core process(es). The core process for each type of product runs from customer needs to cash in the bank.

For example, key processes from the core process may include:


Strategic planning
Innovating (R&D)
Marketing and Selling
Planning and designing
Purchasing
Fulfilling service specifications (includes learning from service failures)
Invoicing and controlling credit

...and key processes from the support processes may include:


Managing risks (beneficial and adverse)
Recruiting and training
Controlling documents
Filing and archiving
Analzying data for preventing problems
Solving problems
Investing in continual improvement
Maintaining facilities and equpment
Maintaining the computer network
Auditing for future effectivenesss

You should determine your system's key processes by analyzing your system.

You can determine your system's support key processes from your student of the system standard and by the work of your cross-functional system development team.

Obviously, you can prioritize the inclusion of these processes in your system depending on its objectives and scope.

Each of the key processes should be owned by a subject matter expert who can determine its objectives, supporting documents and how it really works before, during and after your process analysis sessions with each of them.

I hope this helps you in your work,

John

Can someone help me with the meaning of: "Some organizations "map" quality management system processes to show the linkages between processes and the responsibilities associated with activities to be performed." What is a process map?

Can someone help me with the meaning of: "Some organizations "map" quality management system processes to show the linkages between processes and the responsibilities associated with activities to be performed." What is a process map?

Welcome to The Cove Forums! :bigwave: :bigwave:

Process Map (http://elsmar.com/Forums/fileslist.php?mode=allfiles&sortby=filename&pageamt=2&criteria=process+map).

Stijloor.