Definition Process vs. Activity - What are the differences between a Process and an Activity?

J

JaneB

#31
Re: Process vs. Activity - What are the differences between a Process and an Activity

Sam,

Thanks for the better examples - good ones and some good points.

Process (definition) We all, by now, definitely know what a process is.
Would that were so, Sam ;) But even two quality professionals may disagree about what is, or is not, a process or a sub-process.

I prefer the standards definition because thats what the context is and thats what it should be.
Doesn't mean it's a good or a helpful one though. It is pretty limited.

You say, re Peter's preferred definition that you
don't see any standards defying difference here that makes it sound any better than the standards.
'triggered by an event' - input
'to achieve an objective' - output

The recognition of a "trigger" is the input, and the "objective" is the output, to make it generic and applicable to all scenarios.
Actually, I think Peter makes a very good point about the trigger. Because there IS one definite thing about a process - it needs a 'trigger' to kick it into action/make it happen/start it. Sometimes it's an event (receive phone call), or a piece of data (email/automated prompt from system), a document (CA Request say!). And that trigger is not 'just another input' - there may be other inputs used through the process, which are not triggers. Think of recruiting - a request to recruit/recruitment form may be the trigger, but the process will almost certainly also require a position outline and 'ideal candidate criteria' which are inputs... but aren't the trigger. You may be happy to brush it off as 'just another input' - I am not.

And as for giving an activity an input and an output and then declaring it's now a process? no, spare me. Would you really dignify your 'painting task' example as a process? And yet - I can also argue the other side and say that in some contexts it might be. In a small business dedicated to supplying painted sheets to its customers... yes. Or in a large business which supplies painted items, where the sheet is simply one component, it might be an example of the overall 'widget painting process'. As a tiny activity in a much larger business manufacturing, say, carparts, where the painted sheet is one component, I wouldn't.
 
Elsmar Forum Sponsor

Peter Fraser

Trusted Information Resource
#32
Re: Process vs. Activity - What are the differences?

However, I would like to challenge some of your statements, if you don't mind
The more the merrier! You are already making me think more about how I see and explain some of this - and after David Hoyle's presentation last night (on "Systems and processes – is there a difference?") I have some better examples and a clearer understanding of why ISO9001 fails to recognise and promote these concepts.

Somehow I feel very uneasy about the word "sequence" in your definition. I think that would unnecessarily limit applicability of the concept. So what's wrong with "a set of related tasks"?
You are correct - thanks for putting me right! David gave the example of the process for Developing a Business Strategy: a number of things need to be done, but you can do them in more or less any "sequence", so long as they all get done. Perhaps at a lower operational level you may have less choice, and there is a "normal" sequence - the fact that we tend now to draw flowcharts implies that a linear flow, but I always suggest that the process owner has to ensure that the people let loose on the process are competent to make sensible choices.

Also I am taking an issue with singularity of a triggering event. IMHO, there is nothing wrong with allowing a process to have more than one trigger.
In practice I believe that there is usually one event, but it can be different each time. For example, you would recruit a new member of staff if someone leaves / business increases / there is a reallocation of duties...

Finally why would you replace "activity" with a "task"??
I hadn't really thought about it until now! We use "task" to mean "a discrete activity or piece of work”, or “the smallest essential part of a job”. But now that you mention it (and this takes us back to the original post)... could "activity" not be used at any of a number of levels? For example: "What activities do you follow to find out what is happening in the world of quality?" - "Oh, I look up the Elsmar Cove every evening". Maybe "action" is closer to "task".

An interesting point! Frankly, I never thought about "transformations" in ISO's definition literally, but... now that you've mentioned it. I guess, you are right: the term "transformation" does seem to be quite inadequate.
Agreed!

I respectfully disagree.
(You could also say that a trigger of a process is actually a trigger of some task/activity that belongs to the process. However, you do not exclude that trigger from the process definition. Why are you proposing to treat inputs and outputs differently? ;))
The "process" is theoretical if there is no trigger. It is only "realised" (heaven help me for using such a term!) if the trigger event happens. To me, it is an essential element which needs to be recognised for understanding and managing a process. Actually for "managing" - how people react to individual "events" will depend on training, procedures, workload, company culture...

Inputs/outputs are involved but are not needed to define a "process" - in fact they could define things that are not "processes". I take in air, food, information, and output posts like this(!), but no-one has called me a "process". Randy's new car takes in petrol, him (as a driver), moisture from the air, and will output enjoyment, noise, fumes and eventually rust... (mind you, a "Ford Process" sounds good as a name)

As far as I understand, one of the key ideas of this whole "process approach" shebang is to use a process to "shield" the rest of the organization from most of the complexities/intricacies of all those activities/tasks that are encapsulated by the process. Whatever happens inside a process (specific activities/tasks and their interactions that involve triggers, inputs and outputs) may or may not directly affect other processes. But if something can - then that something should be a part of the process definition. Those "border crossing" inputs, triggers (events), and outputs is exactly what is involved into that pesky "interaction of processes" that ISO requires to understand and demonstrate.
The main reason for focusing on processes is that how work gets done. The "interaction of processes" is sometimes barely touched on, probably not well understood, and not always critically assessed.

IMHO, resources should not be excluded from the process definition either.
I don't - "It uses resources and is subject to influences." But I did wonder if they are actually needed to define "process", or if they are (just) something that you need to consider when managing one.

Thanks again (and to Jane too) - I am glad that someone (else) is concerned about what so many folk seem to accept ("because it is ISO"?) Maybe it highlights some problems in the process of defining standards...
 

Jim Wynne

Staff member
Admin
#33
Re: Process vs. Activity - What are the differences?

The more the merrier! You are already making me think more about how I see and explain some of this - and after David Hoyle's presentation last night (on "Systems and processes – is there a difference?") I have some better examples and a clearer understanding of why ISO9001 fails to recognise and promote these concepts.


You are correct - thanks for putting me right! David gave the example of the process for Developing a Business Strategy: a number of things need to be done, but you can do them in more or less any "sequence", so long as they all get done. Perhaps at a lower operational level you may have less choice, and there is a "normal" sequence - the fact that we tend now to draw flowcharts implies that a linear flow, but I always suggest that the process owner has to ensure that the people let loose on the process are competent to make sensible choices.


In practice I believe that there is usually one event, but it can be different each time. For example, you would recruit a new member of staff if someone leaves / business increases / there is a reallocation of duties...


I hadn't really thought about it until now! We use "task" to mean "a discrete activity or piece of work”, or “the smallest essential part of a job”. But now that you mention it (and this takes us back to the original post)... could "activity" not be used at any of a number of levels? For example: "What activities do you follow to find out what is happening in the world of quality?" - "Oh, I look up the Elsmar Cove every evening". Maybe "action" is closer to "task".


Agreed!


The "process" is theoretical if there is no trigger. It is only "realised" (heaven help me for using such a term!) if the trigger event happens. To me, it is an essential element which needs to be recognised for understanding and managing a process. Actually for "managing" - how people react to individual "events" will depend on training, procedures, workload, company culture...

Inputs/outputs are involved but are not needed to define a "process" - in fact they could define things that are not "processes". I take in air, food, information, and output posts like this(!), but no-one has called me a "process". Randy's new car takes in petrol, him (as a driver), moisture from the air, and will output enjoyment, noise, fumes and eventually rust... (mind you, a "Ford Process" sounds good as a name)


The main reason for focusing on processes is that how work gets done. The "interaction of processes" is sometimes barely touched on, probably not well understood, and not always critically assessed.


I don't - "It uses resources and is subject to influences." But I did wonder if they are actually needed to define "process", or if they are (just) something that you need to consider when managing one.

Thanks again (and to Jane too) - I am glad that someone (else) is concerned about what so many folk seem to accept ("because it is ISO"?) Maybe it highlights some problems in the process of defining standards...
My head hurts. While disassembling something to find out how it works is an edifying experience, if we start grinding down the nuts and bolts we'll be left with a bunch of ground-down nuts and bolts, and the results won't help us much in understanding what makes the machine work.

Things come in the front door, and we do stuff (for pay) with it in order to make it into something that customers want to buy, then it goes out the back door. The sustaining of this cycle is what we should be concerned with, not what "the" means in a given sentence. Achieving and maintaining an optimum level of control at each step in the cycle is what ISO 9001 is about. Note that the concept of "optimum" includes the need for continualous improvement, but only when such improvement is beneficial.

The question "What is a process?" has been beaten into a bloody, unrecognizable pulp in this thread--the nuts and bolts have been ground into powder. Ask the question "What might happen if x isn't controlled?" and if the answer is "Something bad," control it, but only to the extent that the likelihood of something bad happening is acceptable.
 

JoCam

Trusted Information Resource
#34
Re: Process vs. Activity - What are the differences?

The question "What is a process?" has been beaten into a bloody, unrecognizable pulp in this thread--
Well said Jim. I'm sticking with the input through activity/ies to output = process theory, which you can make as simple or as complicated as you wish.

Jo
 
Last edited by a moderator:
Y

Yarik

#35
Re: Process vs. Activity - What are the differences?

Re: sequence vs. set

David gave the example of the process for Developing a Business Strategy: a number of things need to be done, but you can do them in more or less any "sequence", so long as they all get done.

Perhaps at a lower operational level you may have less choice, and there is a "normal" sequence - the fact that we tend now to draw flowcharts implies that a linear flow, but I always suggest that the process owner has to ensure that the people let loose on the process are competent to make sensible choices.
True. At any level. And it can be much more complicated than that (in our company's business it definitely is).

FWIW, there is a great Web site, http://www.workflowpatterns.com/patterns/index.php, that defines dozens of so-called "workflow patterns" with multiple examples for each. Can be a useful resource when discussing what might happen inside a process. For example, David's example is an instance of Parallel Split pattern, which is one of the most trivial patterns...


Re: multiplicity of triggers

In practice I believe that there is usually one event, but it can be different each time. For example, you would recruit a new member of staff if someone leaves / business increases / there is a reallocation of duties...
I see your point (I think).

Perhaps we are experiencing a typical misunderstanding when meta-things (things that describe other things) are not clearly distinguished from those "other things". Like classes vs. members/instances of those classes; or processes/activities/tasks vs. actual executions of those processes/activities/tasks.

For example, if process and triggering event are meta-things (and I believe that's how these terms are used most of the time), then a process obviously may have multiple triggering events; however, each actual execution of such process is usually started when only one (any one) of the triggering events actually happens.

BTW, I think what I call "process execution" is what you call "process realization" elsewhere in your post.


Re: activities vs. tasks

I hadn't really thought about it until now! We use "task" to mean "a discrete activity or piece of work”, or “the smallest essential part of a job”. But now that you mention it (and this takes us back to the original post)... could "activity" not be used at any of a number of levels? For example: "What activities do you follow to find out what is happening in the world of quality?" - "Oh, I look up the Elsmar Cove every evening". Maybe "action" is closer to "task".
Some modern behavior modeling languages (those that I am more or less familiar with) do distinguish behaviors that can be decomposed into into sub-behaviors from those that cannot. The former are called "activities" in all languages that I know; the latter are called either "actions" (UML) or "tasks" (BPMN).

But, interestingly enough, neither of those languages has a separate concept for what ISO calls "process". For example, UML has only "activity groups" (abstract sets of activities) and "composite activities" (also sets of activities but: unlike an activity group, a composite activity also exhibits all the traits of an activity; in other words, a composite activity is itself an activity, whereas an activity group is not).

But... UML is an extensible language, and some people do try to extend it by additional concepts/elements catered to business process modeling. Probably the most famous and elaborated BPM extension for UML is EPBE (Eriksson-Penker Business Extensions). I didn't dig into this stuff very deep (yet), but... the interesting things about their approach (that may be pertinent to this discussion) are:
(a) Processes themselves are being modeled as special kinds of activities (not activity groups) and therefore have all the traits that activities have. In particular, they can be started by events (including completions of other activities) or by availabilities of objects (physical or non-physical, obviously), just like activities and actions can.

(b) The newly introduced special modeling elements include: process inputs and outputs (physical or information); supplies (physical or information); controls (people); and achievements (goals).
There is much more to EPBE (including things like business rules, goal allocations, resource allocations, etc.), but in the context of this thread it is worth noticing that they model a process as a special kind of activity. Which supports the idea that the "process vs. activity" probably is a false dichotomy, and that "definition of a process" (whatever it is) should have all the elemens that "definition of an activity" would have PLUS some additional elements.

Anyway, I am not an expert in EPBE yet, but it does "feel right" and probably deserves some attention from anyone who is trying to get most of the "process approach". So I hope my side-stepping into this area would not be considered as a gross off-topic.


Re: "importances" of triggers vs. "importances" of inputs/outputs

The "process" is theoretical if there is no trigger. It is only "realised" (heaven help me for using such a term!) if the trigger event happens. To me, it is an essential element which needs to be recognised for understanding and managing a process. Actually for "managing" - how people react to individual "events" will depend on training, procedures, workload, company culture...

Inputs/outputs are involved but are not needed to define a "process" - in fact they could define things that are not "processes". I take in air, food, information, and output posts like this(!), but no-one has called me a "process". Randy's new car takes in petrol, him (as a driver), moisture from the air, and will output enjoyment, noise, fumes and eventually rust... (mind you, a "Ford Process" sounds good as a name)
I'm still not convinced that "importances" of triggers and inputs/outputs are different. In fact, I doubt that they are really comparable.

Perhaps, the truth is that there are two perspectives that can be used to define/describe a process: a temporal one (where triggers and sequences are the most interesting concepts) and an informational one (where inputs and outputs are of the most interest). Those perspectives are independent and, in general, equally important.

BTW, the "Workflow Pattern" site that I mentioned earlier also uses several independent perspectives for workflows: they call them "control-flow", "data", "resources", and "exception handling". (I am really perplexed by the last one - IMHO, it should be a part of "control-flow". But I digress...)


Re: Purposes/reasons of "process approach"

The main reason for focusing on processes is that how work gets done. The "interaction of processes" is sometimes barely touched on, probably not well understood, and not always critically assessed.
Somehow this does not agree with what I constantly read/hear everywhere: that interactions between processes are very critical; that many difficult problems are rooted exactly in process interactions; that without good understanding of those interactions it is way too easy to deoptimize the entire system by optimizing an individual process, and so on, and so forth.

If by "how work gets done" you mean "how internals of a process work", and therefore the main focus is on process internals... well, obviously that would work well when processes do not interact with each other much. But how common is a situation when processes do not interact much? Because if it is common enough, then... are we just heading from department-based silos to process-based silos??

I'll risk to repeat myself, but... what is not a false dichotomy, is distinction between interface of something from internals of that something. So maybe the question "what is a process" is not the right question in the first place? Maybe the real problem is not to find a better "definition of process", but to find a better definition of what constitutes interface of a process (or an activity, to that matter)?

The more I read and think about the "process approach" the more it looks like just one of the applications of the systems approach: in order to improve manageability of the system (what organization does and how) it simply aims to decompose organization's behavior into subsystems (processes) in such a way that
(a) certain aspects of each process get clearly isolated from the rest of the system, thus enabling certain improvements to be easily confinable to a single process (process owner's primary responsibility);

(b) interactions between processes get clearly defined to prevent, as much as possible, the notorious "system deoptimization by optimizing a subsystem" phenomenon.
If that's the real goal, then (b) is in no way less important than (a). Otherwise, we'd get ugly silos again...


Re: importance of resources

I don't - "It uses resources and is subject to influences." But I did wonder if they are actually needed to define "process", or if they are (just) something that you need to consider when managing one.
Ooops, my bad! I had overlooked resources in your definition. :eek:

As for their place in the "process definition"... I can see some good reasons to distinguish resources from inputs/outputs (and, of course, from events), but I don't see any good reasons why any of these three "things" - events, in/outputs, and resources - would be "more important" than others in any situation (well, except when you consciously - and temporarily! - decide to focus on only one of the three). Again, maybe those guys at "Workflow Patterns" had some good reasons to introduce "resource" perspective in addition to "control" and "data" ones? ;)

In fact, if you let me go back to my "fixation on process interactions", I would say this: certain resources are UNAVOIDABLY shared by multiple processes (or departments, or whatever other decomposition you choose) and thus become an important part of interactions between processes (or departments, or whatever); and if interactions are considered important, then it is very difficult to justify any "secondary role" for resources.


...after David Hoyle's presentation last night (on "Systems and processes – is there a difference?") I have some better examples and a clearer understanding of why ISO9001 fails to recognise and promote these concepts.
By any chance, is there any readable version of this presentation (accessible for mere mortals like yours truly)? Googling yielded only a couple of announcements of this presentation, but no documents with actual contents...

Thank you,
Yarik.
 

Caster

An Early Cover
Trusted Information Resource
#36
Re: Process vs. Activity - What are the differences between a Process and an Activity

I'd be sorry to see that. Processes are important, although many people find them hard to grasp. (And I'd never argue for departments = processes, ever!) .
I almost hate to keep this thread going, but I will! Please note I am saying MOST in what follows.

Right or wrong most companies are organized around departments which have bosses. That's the way it is.

Trying to force a process approach onto such a company (even though it may be the best thing ever) leads to frustration and unhappiness.

Again most companies are not looking at 9004 for guidance or are interested in improvement, they just want to get ISO. It is seen as a project with an end, not as an ongoing cultural change. And they will get ISO, but can we have a small win even so?

So for them why not set departments = processes and let the fun begin.

We can then audit where Sales/Marketing hands off to Engineering/Design and where they hand off to Manufacturing. There will be big nonquality costs dollars to be saved just at these two interfaces. Which I think could add value rather than making people run and hide from that ISO guy rambling on about processes/activities again.

Defining a "perfect process" in most companies creates a problem of diffuse ownership. Since most companies are set up by department a perfect process will span several departments and thus will have several owners. In my experience has been a sure fire guarantee than each of the owner's sees the other as at fault and no action will occur.

So why not leave it at departments with department bosses for most companies. They understand this set up, these new fangled processes/activities not so much.

You will not I said MOST companies throughout the above.

For those few companies that get it, this discussion is of course moot (and are they hiring, I'd love to work for one again).
 
Y

Yarik

#37
Re: Process vs. Activity - What are the differences between a Process and an Activity

...

Trying to force a process approach onto such a company (even though it may be the best thing ever) leads to frustration and unhappiness.

...

Defining a "perfect process" in most companies creates a problem of diffuse ownership. Since most companies are set up by department a perfect process will span several departments and thus will have several owners. In my experience has been a sure fire guarantee than each of the owner's sees the other as at fault and no action will occur.

So why not leave it at departments with department bosses for most companies. They understand this set up, these new fangled processes/activities not so much.
That's a very good point - about "multiple ownership". "Multiple ownership" rarely works well, no matter how good the intentions are.

Still, here is some idea that I would like to run by you (and by everyone else interested).

I've attached two very, very raw and very simplified drafts of how I see processes (and their interactions) in our company (secondary market hardware supplier).
The dashed lines designate interactions of processes; at this level of details, the arrows show dependencies between processes (usually they show the direction of request flows, but not always). I am not sure I've got all the dependencies right. And of course, these diagrams leave out some other important processes and their interactions. But all these "deficiencies" are not important for the point I am going to make.
So...

The first diagram shows three processes that I would call "customer facing" processes. They are the most important ones (I'm sure it's obvious why) and each of them indeed does span multiple departments. Some person(s) from Sales & Marketing is(are) likely to be the owner(s) of these three processes. This diagram does not show the entire picture (or the real picture, actually). The only purpose of this diagram is to emphasize the fact of department spannings by processes.

The second diagram shows what's really (well, almost really :)) going on in more details. In particular, it shows that there are at least four other processesthat are being "used" (or interacted with) by the 3 customer facing processes that you saw on previous diagram.
Please note that not all of those additional processes cross department borders. (On this diagram overlaps of processes and departments are less obvious, because you have to look not only at the location of a process' own box but also at locations of boxes of all other processes on which the given process depends. I don't know how to make overlapping more visually obvious, but I don't think it is really necessary - please, read on.) Anyway, if a process does not cross department borders it does not mean that the process is in any way imperfect. IMHO.
Now, to the issues with multi-ownership:

Let's say someone from Sales owns "bidding" process. Does it mean that this person also co-owns "shopping" and "ordering" processes with someone from Purchasing? Well, not exactly. What they really co-own are are just interfaces of "shopping" and "ordering" processes - i.e. all "things" that cross borders of those processes (like requisition orders, for instance, in this particular case). The internals of the "shopping" and "ordering" processes may remain in full custody of Purchasing (Sales should not care much about those internals, anyway). Those internals provide quite a lot of managerial troubles to undertake, so why would Purchasing feel that now they do not own anything and just co-own what they used to own before?

I cannot say that multi-ownership can be eliminated. But the multi-owned things do not have to be entire processes! Only interfaces of some processes have to be co-owned (by the process owner and by owners of all other processes that depend on a given interface).

Do you think that this way of defining co-ownership would help to "convert" department bosses into "process approach religion"? After all, even without processes, department bosses have to co-own SOMETHING with bosses of other departments, anyway - something that crosses department borders. So process approach does not seem to really introduce any new co-ownership difficulties, does it? All it introduces is a new "ownable" entity - process, and that's what is supposed to be a very good thing (provided the process makes sense in the first place).

Best regards,
Yarik.
 

Attachments

Peter Fraser

Trusted Information Resource
#38
Re: Process vs. Activity - What are the differences?

Perhaps we are experiencing a typical misunderstanding when meta-things (things that describe other things) are not clearly distinguished from those "other things".
A bit like "tasks" being called "work instructions", and "printed or electronic process descriptions" being called "processes"? (ie actions being confused with descriptions of what should happen)
Re: activities vs. tasks
Some modern behavior modeling languages (those that I am more or less familiar with) do distinguish behaviors that can be decomposed into into sub-behaviors from those that cannot. The former are called "activities" in all languages that I know; the latter are called either "actions" (UML) or "tasks" (BPMN).
So I hope my side-stepping into this area would not be considered as a gross off-topic.
I think that we have lost enough readers already without going into the realm of process modelling!!!

Other recent posts illustrate that interest in and perhaps even understanding of "business processes" and "the process approach" is not high - which makes me question how much of a change there has been since ISO9001:2000 came out.

Re: "importances" of triggers vs. "importances" of inputs/outputs
If you remember the OP's question, and your amended version of it, we can't start to say what is one thing or another if we don't have a clear idea of what the two options mean. Even if it is popular, the ISO9K definition of a process is flawed.

What I was trying to do was to decide how little we need to include in a definition for it to capture the essential characteristics but omit those that do not in fact define it as being different from other entities which share those characteristics. [“Definition” = a statement expressing the essential nature of something]

I had a look on the Internet and found the following:
"(Business) Process” =
• a collection of interrelated tasks, which accomplish a particular goal
• a collection of related, structured activities (a chain of events) that produce a specific service or product for a particular customer
• the execution of a sequence of related steps in response to an event that leads to a clearly defined deliverable or outcome. A number of role-players may contribute to the execution of an end-to-end business process
• a collection of activities that have definable starting and ending points and that achieve something of value to one or more organizations
• an activity or set of activities that are part of a service either to a citizen or to another organisational unit within or outside the particular ...
• a set of linked business activities that take one or more inputs and transform them to create an output
• a set of activities performed by companies to achieve corporate goals.
• a series of related business activities aimed at achieving one or more business objectives in a measurable manner.
• a group of business activities undertaken by an organisation in pursuit of a common goal. Typical business processes include receiving orders ...
• a set of associated procedures or activities with defined roles and relationships carried out to realize a business function in pursuit of business objectives
• a particular course of action intended to achieve a result.

All state or imply a “goal” or “objective”. Seven mention “activities”, mainly at the level below “process”. Two mention a “trigger” or “start point”. Only one talks of “transforming inputs” (and I wonder where that came from!)

“Task”
• an activity that needs to be accomplished within a defined period of time
• any piece of work that is undertaken or attempted
• a piece of work done as part of one’s duties; a difficult or tedious undertaking; an objective
• generically, an activity or set of activities that might be defined as part of a process.
• a work item that has to be completed according to specific criteria, usually with a deadline
• a subunit of a job or the group of activities that accomplishes the work objective or job.
• described in terms of the goals or a desired end-result of activities a user wants to achieve
• part of a set of actions which accomplish a job, problem or assignment. Task is a synonym for activity although the latter carries a connotation of being possibly longer duration.

Five state or imply a “goal” or “objective”. Five mention “activities”, mainly at the same level as “task”.

So "activity" looks like a more generic term which covers both "process" and "task", both of which have a number of similarities.

Re: Purposes/reasons of "process approach"
If by "how work gets done" you mean "how internals of a process work", and therefore the main focus is on process internals... well, obviously that would work well when processes do not interact with each other much. But how common is a situation when processes do not interact much? Because if it is common enough, then... are we just heading from department-based silos to process-based silos??
I meant that managing activities by procedure (as in previous versions of ISO9K), or by department, leads to inefficiencies, internal competition and a silo mentality (as you say). Managing processes is all about "meeting objectives" and "getting the job done". Many organisations struggle to identify and define their processes, never mind manage the "interactions". But these are key requirements of management and the implementation of strategy, and (I would hope) was the reason for the change of emphasis in 2000.

The more I read and think about the "process approach" the more it looks like just one of the applications of the systems approach:
... or systems thinking, ie how inter-relationships matter. [David Hoyle used a number of examples and concepts from Peter Senge] It requires "quality management" to become an intrinsic part of "business management".

By any chance, is there any readable version of this presentation (accessible for mere mortals like yours truly)? Googling yielded only a couple of announcements of this presentation, but no documents with actual contents...
David is preparing a paper based on his presentation and it will go on the CQI web site - I'll let you know when it is there.
 
Last edited:
J

JaneB

#39
Re: Process vs. Activity - What are the differences between a Process and an Activity

So why not leave it at departments with department bosses for most companies. They understand this set up, these new fangled processes/activities not so much.
Yes, they do. But a department is not a process. It may play an important part in one or a number of processes.

But to ignore processes as new fangled (not so) or 'too difficult' to understand misses the point. And no, I won't go along with the 'they don't want to improve, they just want the certificate' line either.
 
J

JaneB

#40
Re: Process vs. Activity - What are the differences?

I think that we have lost enough readers already without going into the realm of process modelling!!!
Nah, really you think? (Think?) The attempt to turn any activity associated with human beings into one that can be universally modelled is one I always find an interesting one. As I skip on to do something else.

Do carry right on. And have fun doing it. (Perhaps you could move on to peace in the Middle East when you can find the time?) :lol:
 
Last edited by a moderator:
Thread starter Similar threads Forum Replies Date
C Process Maps vs. Activity Network Diagrams - Differences Process Maps, Process Mapping and Turtle Diagrams 7
J Definition Activity vs. Task - Definitions in Process Mapping and Projects Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 9
Q Activity process sub-process/procedures? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
R Failure analysis process or activity need to be audited? Internal Auditing 3
H Clarify the Difference between Activity and Process - What is Data Analysis IATF 16949 - Automotive Quality Systems Standard 9
D TS 16949 - Is there a difference between a process and an activity? IATF 16949 - Automotive Quality Systems Standard 5
J Need Help with FPY Data in Assembly Process Manufacturing and Related Processes 7
A When someone refuses to follow a process.... Misc. Quality Assurance and Business Systems Related Topics 21
E Software maintenance Process Software maintenance Process to IEC 6204? IEC 62304 - Medical Device Software Life Cycle Processes 3
R AS5553 Clause 3.1.7 f - "Implement a returns process....." AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
normhowe "The Problem with Quality Management: Process orientation, controllability and zero-defect processes as modern myths" Book, Video, Blog and Web Site Reviews and Recommendations 2
Judy Abbott General temperature used in the blasting process and laser process Manufacturing and Related Processes 2
B SOP for CNC turret punching machine for sheet metal process Manufacturing and Related Processes 0
A API Monogram audit review process Oil and Gas Industry Standards and Regulations 4
R AS9102 FAI Change in Material / Process Supplier AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 4
A Process mapping Process Maps, Process Mapping and Turtle Diagrams 1
R MDEL Process Canada Medical Device Regulations 4
optomist1 Rates Daily or Hourly Process Improvement Training Consultants and Consulting 2
S Manufacturing Process FDA FOIA Medical Device and FDA Regulations and Standards News 3
S Manufacturing Process FDA FOIA US Food and Drug Administration (FDA) 4
B Toyota PPAP Process - Three Questions APQP and PPAP 3
R Changes vs CMO - How can we simplify this process? Supplier Quality Assurance and other Supplier Issues 3
A Ethics Committee Review Process for IVD Products EU Medical Device Regulations 2
V Laser Welding Process - Impact on Electrical Properties Reliability Analysis - Predictions, Testing and Standards 4
Q Process: Knowledge Section 7.1.6 of ISO 9001:2015 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
L Documented Information in Internal Audits Process (9.2) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
A Sampling plan for in-process QC (medical devices) Inspection, Prints (Drawings), Testing, Sampling and Related Topics 13
R MRB (Material Review Board) Process using MS Sharepoint or MS Teams Manufacturing and Related Processes 2
M Clinical Benefit of device that only aids in a process for managing or treating disease EU Medical Device Regulations 2
C In-process inspection - Tooling and assembly lines for automotive companies AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 6
M Efficacy of an IT process after a cyber attack ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
N Sterilization Protocol Change in Validation Process and further impacts ISO 13485:2016 - Medical Device Quality Management Systems 1
N Riveting - special process Manufacturing and Related Processes 11
M Material incoming to the production process reflected in PFMEA FMEA and Control Plans 9
A API Spec Q1 Purchasing Process - Supplier Reevaluation based on Supplier Risks 5.6.1.4 Oil and Gas Industry Standards and Regulations 17
B Handling lower detection limits for SPC and process performance Statistical Analysis Tools, Techniques and SPC 1
D Measurables for Plastic Injection molding process Manufacturing and Related Processes 1
S Cleaning process center change ISO 13485:2016 - Medical Device Quality Management Systems 4
Z Rapid audit template for plastic parts manufacturing process Manufacturing and Related Processes 12
R Inspection and Work order process Inspection, Prints (Drawings), Testing, Sampling and Related Topics 9
T ISO 13485:2016 Clauses related to process matrix ISO 13485:2016 - Medical Device Quality Management Systems 3
A How to reduce the process SPC monitoring Capability, Accuracy and Stability - Processes, Machines, etc. 3
John Predmore Configuration Management as a process instead of a procedure AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 10
R PCBA process validation Qualification and Validation (including 21 CFR Part 11) 2
U Internal Auditor not trained but done Audit for some process Nonconformance and Corrective Action 5
B Two excellent examples of process capability analysis from Quality Magazine Capability, Accuracy and Stability - Processes, Machines, etc. 5
D ECO (Engineering Change Order) process questions ISO 13485:2016 - Medical Device Quality Management Systems 7
S Sterilization validation after changing sterilization process provider Qualification and Validation (including 21 CFR Part 11) 3
Pau Calvo Quality Management process is mandatory in ISO9001? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
Tagin Template or Checklist for Process Change Document Control Systems, Procedures, Forms and Templates 5

Similar threads

Top Bottom