ISO 9001 4.4.1 "...shall determine the processes needed..."

[Big Jim]

ISO 9000 defines a process as a “set of interrelated or interacting activities which transforms inputs into outputs”.

Ergo, activities are not processes.

Agreed, but it depends on how it is parsed out. Remember that 8.5.1f deals with "special processes", or processes that require validation because that cannot be verified, or at least not in an economically feasible manner. Poster child examples include welding, soldering, heat treating, and plating.

It would be easy to call any of those "activities" although they could be parsed out into a set of activities.

However, I agree that generally activities are not processes, as was pointed out in the video.

What's your point?

 

[Big Jim]

And this is a useful standard too:

IIBA | BABOK | A Guide to the Business Analysis Body of Knowledge®

...especially for the principles of process analysis.

Here is a guide based on these principles:

https://cdn.ymaws.com/www.bfma.org/resource/resmgr/articles/08_64.pdf

But this was my favorite:
The Process Management Memory Jogger: Building Cross-Functional Excellence.

Just because promotional literature says something is internationally recognized doesn't make it so. I have not heard of any of these sources before. They were not mentioned in any of my business school classes.

Most important of all, why didn't TC-176 use any of that information to define what they mean by a process any better than the very loose on you quoted from ISO 9000? Don't you believe they have an obligation to make themselves understood? I do!

 

[John Broomfield]

Yes, that special activities clause could have been rewritten long ago to avoid misusing the word process.

Meanwhile we interpret the standard according to the needs of the organization and its customers.

Perhaps, as in “our work should add value for customers without undue delay”.

 

[John Broomfield]

Just because promotional literature says something is internationally recognized doesn't make it so. I have not heard of any of these sources before. They were not mentioned in any of my business school classes.

Most important of all, why didn't TC-176 use any of that information to define what they mean by a process any better than the very loose on you quoted from ISO 9000? Don't you believe they have an obligation to make themselves understood? I do!

So do I, and we repeatedly attempt to achieve that through our review and comment on the standards themselves. Meanwhile, instead of waiting for ISO/TC176 to adopt our sensible comments we look to other sources to interpret the standards.

For example, our ASQ’s update of Deming’s process diagram:

What is Process View of Work? | ASQ

It’s an excellent summary of our profession’s current understanding of a process view of work that has been evolving since 1986.

 

[Tagin]

ISO 9000 defines a process as a “set of interrelated or interacting activities which transforms inputs into outputs”.

Ergo, activities are not processes.

I would disagree that 'activities are not processes' is at all implied by that definition. Specifically, Note 3 of that definition in 9000 states:

Note 3 to entry: Two or more interrelated and interacting processes in series can also be referred to as a process.

Thus, sequences of processes can be iteratively grouped into a single higher level chunk which can also be called a process, or conversely, a process can be decomposed into smaller sequential chunks which can each also be called 'processes' as long as the smaller chunks meet the definition of 'process'.

So, there is no specified canonical tier or hierarchical level of "interrelated or interacting activities" to which the term 'process' solely applies.

Clause 4 (and that video seems to agree) seems to want us to focus on a top-level, or higher-level, tier of process organization, but also specifically just on the "value chain" (as used in the ASQ link) processes.

On the other hand, as Big Jim notes, in another clause "special processes" need to be identified, and those are typically going to be identified 'processes' only at a lower hierarchical level of organization; i.e., the identification of that process requires decomposition of a higher-level 'process' into a sequence of smaller chunk processes.

The possible degree of decomposition of a process is also made confusing by the vague definition of 'activity'. In 9000, it is weirdly defined only in the context of projects:

3.3.11
activity
<project management> smallest identified object of work in a project (3.4.2)

However, 'project' in 3.4.2 is defined as "unique process (3.4.1), consisting of a set of coordinated and controlled activities...", so 'activity' is here rather circularly defined by the definition of 'process'. Moreover, it is a definition only for project management, not for processes generally.

Note also that it says "smallest identified object of work...", not "smallest identifiable object of work..."

'Activity' is also defined in figure A.6 as

Activity (dictionary word)
doing something

This definition as "doing something" is the epitome of vagueness. But the two definitions also illustrate that 'activity' does not necessarily imply an undecomposable atomic unit - in some cases, an identified activity might rightly also be a 'process', and further, it might also be decomposable into smaller chunks of identified activities and some of those smaller activities might rightly be called 'processes'.

 

[John Broomfield]

Yes, process hierarchy can get messy. This can be avoided by referring to a company’s value chain(s) as a core process which comprises key processes to turn customer needs into cash (or continued funding). And the system’s support processes sustain, direct and improve the core process(es).

But I see activities, tasks or work as usefully irreducible in system terms and for the sake of clarity I prefer activity instead of sub-process.

A project from its inception to its completion is often a unique value chain or core process. Projects though are usually supported by corporate processes to create, sustain, direct and improve them. Indeed, the first ISO 9002 (or was it BS 5750?) mention of making sure we had the processes necessary to complete the project/order used to be specified under the quality planning activity which operated with the QMS.

All we are doing here though is making sense of an imperfect standard for our clients and their customers; I doubt any future system standard will spell out completely and unambiguously what is required.

The standard continuing to call “special activities” “special processes” is galling but imagine changing the terminology of NADCAP now!

 

[mattador78]

Boggles the mind how repetitive and inconclusive these discussions are.

I think it was Einstein who said "The definition of insanity is doing the same thing over and over and expecting different results."

 

[Big Jim]

I would disagree that 'activities are not processes' is at all implied by that definition. Specifically, Note 3 of that definition in 9000 states:

Thus, sequences of processes can be iteratively grouped into a single higher level chunk which can also be called a process, or conversely, a process can be decomposed into smaller sequential chunks which can each also be called 'processes' as long as the smaller chunks meet the definition of 'process'.

So, there is no specified canonical tier or hierarchical level of "interrelated or interacting activities" to which the term 'process' solely applies.

Clause 4 (and that video seems to agree) seems to want us to focus on a top-level, or higher-level, tier of process organization, but also specifically just on the "value chain" (as used in the ASQ link) processes.

On the other hand, as Big Jim notes, in another clause "special processes" need to be identified, and those are typically going to be identified 'processes' only at a lower hierarchical level of organization; i.e., the identification of that process requires decomposition of a higher-level 'process' into a sequence of smaller chunk processes.

The possible degree of decomposition of a process is also made confusing by the vague definition of 'activity'. In 9000, it is weirdly defined only in the context of projects:


However, 'project' in 3.4.2 is defined as "unique process (3.4.1), consisting of a set of coordinated and controlled activities...", so 'activity' is here rather circularly defined by the definition of 'process'. Moreover, it is a definition only for project management, not for processes generally.

Note also that it says "smallest identified object of work...", not "smallest identifiable object of work..."

'Activity' is also defined in figure A.6 as


This definition as "doing something" is the epitome of vagueness. But the two definitions also illustrate that 'activity' does not necessarily imply an undecomposable atomic unit - in some cases, an identified activity might rightly also be a 'process', and further, it might also be decomposable into smaller chunks of identified activities and some of those smaller activities might rightly be called 'processes'.

Thank you for pointing out some of the "circular logic" to TC-176's definitions.

 

[Big Jim]

Meanwhile we interpret the standard according to the needs of the organization and its customers.

Unfortunately often it is often the Auditors, CBs, and ABs that are interpreting, and usually without paying attention to the organization's needs, and writing NCRs just because they think they can.[/QUOTE]

 

[John Broomfield]

“Unfortunately often it is often the Auditors, CBs, and ABs that are interpreting, and usually without paying attention to the organization's needs, and writing NCRs just because they think they can.”

This behaviour may be caused by auditee uncertainty, especially if the auditor is looking for evidence of nonconformity instead of looking for evidence of effectiveness.

What has happened to auditor training and supervision?