Mandatory Documented Procedures - What processes do mandatory procedures belong to?

[Yarik]

Hello everyone!

I have to admit that my current understanding of processes and process approach is still very shaky (to say the least ). But it's getting stronger, bit by bit - thanks to invaluable help from this great community.

Here are some questions that I was pondering lately:

---

(Q1) Let's say, there is an activity that is important enough to deserve a documented procedure describing how this activity is carried out. It seems to me that such an activity has to belong to at least one process that is important enough to be identified (and therefore described in QMS documentation).

NB: In some cases, such an important activity can itself be identified as a process (and described in QMS documentation as such).

Would you agree with this "theorem"? If not, why? Any examples?

---




(Q2) ISO 9001:2008 requires documented procedures for the following 6 activities:

• control of documents (4.2.3)
• control of records (4.2.4)
• internal audit (8.2.2)
• control of nonconforming product (8.3)
• corrective action (8.5.2)
• preventive action (8.5.3)

What identified processes (if any) each of these activities belongs to in QMS(es) that you encountered? Is it absolutely random (that is, totally organization-specific) or are there any patterns in relationships between these mandatory activities and identified processes?

---

Thank you,
Yarik.

[Sam4Quality]

Hi Yarik:

In order to answer your questions, first lets define a PROCESS, albeit its been done n number of times before.

Input + Set of Activities+ Output = PROCESS
(using Resources)

This, I believe, is a universal equation derived from the ISO 9001 standards, Clause 0.2 - Process Approach, and everyone involved with quality will agree to it without a doubt. The understanding of a 'process' and 'process approach' have been pretty clearly given within the same clause. I am sure you must have taken the time to read it carefully.

Coming to your questions:
1. Yes - I would agree that if an activity is important enough to be documented, it would actually form part of a process that is important enough to be documented. But, I would not agree that in any scenario/case would an activity itself be identified as a process. NEVER. Hence, comes the clear distinction between activity and process. To explain very simply,
consider the example -
Drinking Tea - There is no input, no output just plain drinking tea. This is an Activity. 'What' are you doing? I am drinking tea. The 'What' factor.

Now, ask yourself,
Why do I need to drink tea?
How will I make it?
When should I make it?
What are the resources required?
Where will I make it?
Who will make it/store it/drink it?

Combine all of the above answers, interlink them, and the resulting concoction is what you would call a 'Process'.

Similarly, "Making Tea" is also an activity (work instruction) part of the whole process of drinking tea.

Take any activity for that matter, it cannot be called a process unless you start putting an input in the beginning, an interlinking of acitivties in the middle and an output in the end. An Activity is part of a process, not the process itself. Also, a process can have a set of smaller mini-processes within. Hence, your 'Nota Bena' does not comply.

2. I believe the reason why these SIX procedures are mandatory in the first place is because they apply to all documented processes inside of a Quality Management System.
All I can say is, some or all of these 6 procedures may or may not apply to identified processses within a system that are NOT documented. There is no specific processes that you would focus on to apply the 6 procedures. They are Organization specific.

I hope this has clarified some of your doubts.

Ciao.

[jelly1921]

One more thing should be added to the processes in QMS, in ISO9000:2005 3.4.1 Note 2 :"Processes in an organization (3.3.1) are generally planned and carried out under controlled conditions to add value", that means two things: the process should be under control like Ciao mentioned above with 5W1H, and should ADD VALUE.

[JaneB]

In Reply to Parent Post by Yarik

(Q1) Let's say, there is an activity that is important enough to deserve a documented procedure describing how this activity is carried out. It seems to me that such an activity has to belong to at least one process that is important enough to be identified (and therefore described in QMS documentation).

NB: In some cases, such an important activity can itself be identified as a process (and described in QMS documentation as such).

Would you agree with this "theorem"? If not, why? Any examples?

To some extent only.

I think it's confusing to talk about 'an' activity, as a process usually involves a collection of activities. If you gave a specific example or two of what you mean by 'an activity' it would help.

But let's think about, say, 'quoting'. Now, in some businesses quoting is a very small and pretty quick activity; in others it can be more formal and/or large and important enough to be a process in its own right.

I think purpose, importance and outcomes are important in what's a process and what's simply a procedure or an activity. It depends - as so much always, always does!! - on the context: the organisation in which it occurs. Some people like to use 'making a cup of tea' as an example of a process - I don't as I think it's such a small and relatively insignificant thing that it isn't a helpful example to illustrate a process.

In Reply to Parent Post by Yarik

(Q2) ISO 9001:2008 requires documented procedures for the following 6 activities:

1. control of documents (4.2.3)
2. control of records (4.2.4)
3. internal audit (8.2.2)
4. control of nonconforming product (8.3)
5. corrective action (8.5.2)
6. preventive action (8.5.3)

What identified processes (if any) each of these activities belongs to in QMS(es) that you encountered? Is it absolutely random (that is, totally organization-specific) or are there any patterns in relationships between these mandatory activities and identified processes?

NB: As 'activity' 'procedure' and 'process' are all different things, each with their own ISO 9000 definition, this question is a bit confusing for me the way it's worded!

1. Control of docs usually is involved in just about every other process in the organisation - so any process that uses or generates documents that require control. One reason it's often considered a 'support' process. Or procedure.

2. Records = any process that uses or generates records, ie, most if not all!. Similarly, often thought of as a 'support process'. Or procedure.

3. Usually all, or possibly nearly all. Others will differ here, but, for example, I rarely find much there's much value added by auditing the management review process/es in a very small organisation.

4. NCP = any process that creates product (or a component) where NC may occur. That can include incoming product/bought product/outsourced etc. Tends to be associated more with product realisation processes than not. And often makes very little, if any, sense in many service environments, while manufacturing, chemical, etc etc get very excited about it (and rightly so).

5-6. All and any.

I'm not sure this will help though.

[Yarik]

In Reply to Parent Post by JaneB

To some extent only.

I think it's confusing to talk about 'an' activity, as a process usually involves a collection of activities. If you gave a specific example or two of what you mean by 'an activity' it would help.

Good point, Jane (as always). Thank you.

Okay, let me try to both reword the question slightly and include some examples:

(Q1') Let's say our we decide that our QMS documentation should include a documented procedure describing something that we do. (For example, a procedure called "How Do We Quote".)

Does that mean that our QMS documentation also should (shall?) include one of the following:

At least one identified process that would be described by the given procedure. (For example, if quoting is a very complex "thing that we do", we may choose to identify a process called "Quoting"; inner workings of this process is exactly what the given procedure would describe in this case.)

or

At least one identified process that would include at least one instance of an activity, which in turn would be described by the given procedure. (For example, if quoting is not complex, we may choose to identify an activity called "Quoting" and identify a process called "Order Fulfillment" that would contain the activity called "Quoting"; in this case, the given procedure would describe inner workings of the "Quoting" activity.)

In both cases, the given documented procedure ends up being associated with at least one identified process (either directly or via some activity). And the "theorem" proposed that there can't (or at least shouldn't) be any other cases
- that any documented procedure should/shall be associated with at least one identified process (directly or via an explicitly identified activity).

Does this help to make the question any clearer?

In Reply to Parent Post by JaneB

NB: As 'activity' 'procedure' and 'process' are all different things, each with their own ISO 9000 definition, this question is a bit confusing for me the way it's worded!

I can see why it may be confusing, but I don't see a clear way to fix that. I tried to use ISO's vocabulary, I tried to quote ISO's documens (yes, it is an ISO document - not me - that calls these 6 mandatory things "activities"!), but it seems that this part of ISO's vocabulary is confusing to many people. I think this is also demonstrated by another concurrent discussion (http://elsmar.com/Forums/showthread.php?t=14403), in which we both participate lately.

BTW, I can't find any definitions of "activity" in ISO 9000:2005. Where else could it be defined? Should it be defined?

Anyway, what I was trying to figure out is how do people fit these six mandatory... er... activities into "process-based models" of their QMSes. Which of these activities end up being processes? And when they... er... remain being activities, then which processes (if any) they end up belonging to. How often do they end up being "orphan procedures" (that is, procedures without parent processes). And so on, and so forth...

I am not sure that this version of my question makes things clearer, but maybe two versions together would work better than one.

In Reply to Parent Post by JaneB

1. Control of docs usually is involved in just about every other process in the organisation - so any process that uses or generates documents that require control. One reason it's often considered a 'support' process. Or procedure.

2. Records = any process that uses or generates records, ie, most if not all!. Similarly, often thought of as a 'support process'. Or procedure.

3. Usually all, or possibly nearly all. Others will differ here, but, for example, I rarely find much there's much value added by auditing the management review process/es in a very small organisation.

4. NCP = any process that creates product (or a component) where NC may occur. That can include incoming product/bought product/outsourced etc. Tends to be associated more with product realisation processes than not. And often makes very little, if any, sense in many service environments, while manufacturing, chemical, etc etc get very excited about it (and rightly so).

5-6. All and any.

I'm not sure this will help though.

Actually, it did help quite a bit. In spite of your confusion. And my confusion.


I guess I need some more time to digest your response (as well as other responses).


Thank you,
Yarik.

[Yarik]

In Reply to Parent Post by jelly1921

One more thing should be added to the processes in QMS, in ISO9000:2005 3.4.1 Note 2 :"Processes in an organization (3.3.1) are generally planned and carried out under controlled conditions to add value", that means two things: the process should be under control like Ciao mentioned above with 5W1H, and should ADD VALUE.

From what I have read so far at Cove (and elsewhere), the concept of "adding value" appears to be extremely ambiguous. By any chance, is there any authoritative definition of "value"?

Without clear understanding of what is meant by "value" it is really difficult to take this ISO's note seriously...

[Yarik]

In Reply to Parent Post by Sam4Quality

I hope this has clarified some of your doubts.

Yes, it was helpful.

Thank you, Sam!

[JaneB]

Yarik - thanks, I find it's much clearer talking in real examples. Theoretics get too... well... theoretical!

In Reply to Parent Post by Yarik

Q1 Let's say our we decide that our QMS documentation should include a documented procedure describing something that we do. (For example, a procedure called "How Do We Quote".)

Does that mean that our QMS documentation also should (shall?) include one of the following:
At least one identified process that would be described by the given procedure.

No, not necessarily. You have to 'determine' processes (know what they are and how they work etc) but not necessarily document every single one.

In Reply to Parent Post by Yarik

(For example, if quoting is a very complex "thing that we do", we may choose to identify a process called "Quoting"; inner workings of this process is exactly what the given procedure would describe in this case.)

Yes, just so.

In Reply to Parent Post by Yarik

or, At least one identified process that would include at least one instance of an activity, which in turn would be described by the given procedure. (For example, if quoting is not complex, we may choose to identify an activity called "Quoting" and identify a process called "Order Fulfillment" that would contain the activity called "Quoting"; in this case, the given procedure would describe inner workings of the "Quoting" activity.)

Yes, I agree. In fact, if it isn't complex, you may not even need any documentation, much less a procedure for it. You could, for example, do it by completing a form or a checklist (which = the record of what was done). And there's not much point writing a procedure which just says 'fill in form x'!


In general, by writing procedures first and then looking for the process you may be putting the cart before the horse, ie. doing it backwards. But you will know better than I do the areas of greatest need right now in your company. And often in the early stages of getting the system together, it is a bit messy / back and forth type activity, putting the bits together.