posted 08 April 2001 12:23 PM               

Just before that 'explaination' is 3.4.1 which describes a process as "...set of inter-related or interacting activities which transforms inputs into outputs..."

Then you say: "...Processes · are carried out under controlled conditions to add value..." which is close, but read closely and you will see note 2 in fact qualifies the note with the term '...generally..'. Thus, a process does not always 'add value'.

posted 09 April 2001 04:42 AM               

I understand the word "...generally..." to refer to "...value added...", not '"...under controlled conditions..." but I suppose it can refer to both.

My interpretation is that a way of doing something is essentially a process. I do not even necessarily relate it to a physical output. For eaxmple, in 3.4.4 it says: "...set of proceses (3.4.1) that transforms requirements (3.1.2) into specified characteristics (3.5.1) or into the speification (3.7.3) of a product (3.4.2), process (3.4.1) or system 3.2.1). Above I said:
->Design Engineering is a functional classification while
->design is done by a process.
and this pretty well confirms my interpretation.

My opinion is you are trying too hard to restrict the definition of process. You are trying to restrict the word process to apply only to operational processes and restricting the words "inputs" and "outputs" to physical items. There are inputs into the design process and outputs from it. There are inputs into the purchasing process and outputs from it. They're not physical, per se (e.g.: a design requirement is an input to the design process, is arguably not value added, and the design output is typically paper or computer file [design drawing and such]).

I stand my my statement that:
->Management responsibility is a 'topic', if you will. The
->things management does (e.g.: management review) are processes.

You say:
->So, if I say "process", I consider only production process
->which adds value to input, transforms it and resulted in
->final product

I believe my example of 3.4.4 makes clear that your statement is not correct.

posted 09 April 2001 05:14 AM               

Yup - lots of people trying to sell you something. This is not that complicated. I stand by my assertion that if you do what I have recommended to clients since 1994 - flow chart your systems - you will see every system is a process or processes each of which has inputs and outputs -- and inter-relationships are well defined - that's all this is about. Your internal audit system is a process or a set of processes. Purchasing is a process or a series of processes. You have a nonconformance system which is made up of processes. Taken to the extreme, almost everything can be looked at as a process.

I took a course in the mid-1980's called "Business as a Process". None of this is new. It is more 'Good Business Practices' which is all ISO 9001 is. When you reach the point where you can understand everything you do in terms of inter-relating processes, you can then go on to evaluate each in terms of cycle time, effectiveness of interaction, etc. The course goal was, by the way, how to ensure continuous improvement -- a relatively 'new' concept to the ISO standards folks -- and stressed the use of experiments to generate knowledge as well as process feedback for learning.

posted 09 April 2001 12:50 PM               

Products arenât necessarily tangible items. A consulting firm produces IDEAS as the Product. Any process delivers an output. It might be of value, it might be waste, or a mix of both.

There are many processes in an organization. I classify them two ways: Primary and Support. Primary processes are those that traditionally feed the Gemba. Support processes are non-Gemba processes, but important contributors to the Gemba processes. Now, which do you document?

For me, you must document the Primary Processes (reference Marc Smithâs contributions above, i.e. Design). Then, do some type of risk analysis to determine where else a document will help to ensure that the risk is reduced or eliminated. Another important distinction for me is with something Marc mentioned earlier. The steps that transform the inputs into the outputs must be reviewed closely. Not all steps need to be documented, but critical ones might. Determine your critical points. Then ask, ãHow will I ensure that mistakes are avoided?ä Maybe a document, check-sheet, or perhaps poka yoke the process. The choice is yours. Then Train, Train, Train!!

Regards,

Kevin

posted 18 April 2001 12:19 AM               

I would like to know what the real difference is between a process and a procedure? If we document a process - as we must do - does it become a procedure?

posted 18 April 2001 06:01 PM               

quote:

---

Originally posted by Carl Redman:
Dear Colleagues in Quality

I would like to know what the real difference is between a process and a procedure? If we document a process - as we must do - does it become a procedure?

Carl

---

Simply,

A process is an entity that has inputs and outputs.

A procedure is a document that "could" define the process.

I say "could" because many companies use a process flow chart that they do not define as a level II procedure but as a level III instruction. (i.e. flow chart for part# 123 op 100)

Some companies use flow charts exclusively as their level II procedures.

These flow charts are not specifically "product" related as usually is the case in automotive flow charts. They are flow charts that define the flow of how a company meets a certain required ISO/QS/TS element. (i.e. flow chart to define the process for 4.17 internal audit)

posted 18 April 2001 06:42 PM               

As with procedure, there are multiple definitions for the word process.

Many times it does not matter what word you use and, in fact, in some cases which word is used depends upon the level of detail you are looking at. This is to say if you are looking at a high level system map, you might call sub-systems processes. And if you 'blow up' the process and look just at it you may refer to IT as a system and its sub-systems as processes.

Just as there are few documents which you can strictly classify, there is flexibility in word choice many times. An example I see all the time is a level II which includes what could be separated out into a level III. If your level II contains all the level III info, and evn an associated form or two, it is no big deal. Many companies do not have a need for a highly structured documentation system. One small company I worked with a few years back had one manual - their quality manual. All 'system' flow charts were in that 60 some odd page manual as well as procedures. Forms were in the appendix.

I would go so far as to say in general there is little if any difference between a process and a procedure. But I would look at the context in which the word is used.

Nor is there a difference based upon an input or output being present. Both procedures / instructions and processes have inputs and outputs if you look closely.

One last comment. Al said:
->Some companies use flow charts exclusively as their level
->II procedures.
->These flow charts are not specifically "product" related
->as usually is the case

which implies that a flow chart is not a procedure for some reason.I disagree. A flow chart is every bit a procedure as a text document and it is totally unrelated to the 'level'. Nor is it related to whether or not the procedure is product related. Most of my clients flow chart 'level II' procedures / systems as well as level III procedure (or instructions or whatever you want to call them). If you can write an instruction/procedure for something, it can be done in flow chart form.

Rule of thumb is the bigger the company, the more they have to define in detail their documentation structure and definitions. What I call a work instruction, someone else will call a procedure. Others will call it a process procedure. I have seen them called '...the Mapix...' in a company where their process documents came from a certain software package. I see other companies where everything is on the router - asking for a work instruction will get you a totally blank look.

posted 19 April 2001 12:21 PM               

Procedure is action, the other five are knowledge.

Process is defined as what happens or how it works, malted barley is ground in a two-roll mill. "a series of events, stages, or phases that takes place over time and has an identifiable result."

Procedure is defined as how to do it, set up two-roll mill, weigh malted barley, press start switch on mill, pour malt into mill feed hopper, remove cracked malt from mill discharge hopper, switch off mill, clean up. "a set of steps that a person performs to achieve a specified outcome, including decisions that need to be made"

The basic difference between process and procedure is point of view. There are two: from outside the process and from within the process. In classical math and physics speak, Eulerian and Lagrangian frames. If you are within the process, you are in procedure-space. There is no "process" relative to this frame of reference, because you are moving through time with it. If you are outside the process, you are in process-space. With respect to this frame of reference, the rest of the world, there is a process happening.

posted 19 April 2001 12:41 PM               

I posted:

.......Some companies use flow charts exclusively as their level II procedures.

These flow charts are not specifically "product" related as usually is the case in automotive flow charts. They are flow charts that define the flow of how a company meets a certain required ISO/QS/TS element. (i.e. flow chart to define the process for 4.17 internal audit).....

I was not implying that flow charts are not procedures, only that some companies consider them differently in their document structure.

For example, some companies consider the flow chart that is generated through APQP/PPAP as a level III instruction.

The same company might use a flow chart to define the entire APQP/PPAP process and consider it a level II procedure.

I think all flow charts are procedures and
instructions. The only difference is how the company sets up their document levels.

As you said, there are multiple definitions for words and I think a company should make sure they have a common understanding of the meanings.

posted 19 April 2001 12:49 PM              

"
Procedures are driven by completion of the task
Processes are driven by achievement of a desired outcome

Procedures are implemented
Processes are operated

Procedures steps are completed by difference people in different departments with different objectives
Process stages are completed by different people with the same objectives - departments do not matter

Procedures are discontinuous
Processes flow to conclusion

Procedures focus on satisfying the rules
Processes focus on satisfying the customer

Procedures define the sequence of steps to execute a task
Processes transform inputs into outputs through use of resources

Procedures are driven by humans
Processes are driven by physical forces some of which may be activated by humans

Procedures may be used to process information
Information is processed by use of a procedure

Procedures exist they are static
Processes behave they are dynamic

Procedures cause people to take actions and decisions
Processes cause things to happen
"

posted 19 April 2001 01:11 PM               

quote:

---

Originally posted by ikar:
Al Dyer writes:"A procedure is a document..."

---

Sorry, what I meant to post was:

A procedure can be a document that "could" define the process.

You refered to "documented procedure ...".

By belief is that the writers recognized that some procedures may not be written down (documented) and wanted to ensure that the procedures they deemed "important" were written down (documented).

posted 19 April 2001 07:37 PM               

NOTE 1 - The procedure could be doccumented or not.