Re: Process vs. Activity - What are the differences?
Hi Jim!
I think that trying to find a distinction between "process" and "activity" will ultimately be futile because it's a false dichotomy. Don't conflate the container (what something's called) with its contents (the stuff that actually matters).
Hmm... I feel somewhat confused by this...
One one hand, I believe that technically (that is, by applying ISO's definitions per se) any activity can be considered to be a process and vice versa; therefore, "process vs. activity" indeed is a false dichotomy. (Unless I misunderstand the word "dichotomy".

) That's why I changed the OP's question...
On the other hand, I don't understand your note about "conflating containers and their contents". What did you mean by "container" and "contents" here?
In what used to be called "data processing" and is now referred to generally as "information technology," there is the simple concept of the IPO (Input-Process-Output) cycle. Some sort of input material is processed (somehow transformed) into the desired output (a product). Although the middle part of IPO is "process," the whole thing is a process. In the first instance (the "P" in IPO) "process" is a verb, while in the second it's a noun. When the verb form is used, "process" denotes activity.
The best way to think about in ISO terms is similar to the IT concept--input is transformed into output. In a manufacturing process, raw material is transformed (processed) into a product.
I think you are right. The ISO's definition of process does feel very similar to this simplistic Input-Process-Output concept.
I wish it was a little bit more compex, though. For example, this simplistic definition is mute about
temporal aspects of processes. I mean questions like these:
- Is availability of input sufficient for actual processing of this input to begin?
- If a process has multiple inputs, does it mean that actual processing of those inputs begins only when they all are available?
- If a process has mutliple outputs, does it mean that they become available simultaneously?
- ...and so on, and so forth...
In other words, I think one big part of my confusion is this: Does the ISO's "process approach" sorely lack such concepts as, for instance, process execution triggers? Or is this omission intentional? In the latter case, what was the intent and what are the answers on the "temporal questions" like the ones listed above?
I think these temporal aspects are quite important part of the picture if the concept of "process" is expected to be applied to situations more complex than trivial assembly line (i.e. a trivial chain of processes where inputs of each process do trigger execution of that process).
Or I am missing/overthinking something? (Which, of course, is totally possible.)
For example, I do understand that all those questions about temporal aspects can be answered for a particular process by looking
inside the process - i.e. by looking at the actual activities behind this process. But... is this really a viable approach? I mean, wasn't one of the key points of the "process approach" to describe interfaces of processes (inputs, outputs, resources, goals, etc.) not only to guide effective implementations of those processes but also to facilitate management of the entire system - where interactions of the processes are not a single bit less important than each individual process?
In each situation identification of important processes and invoking controls--such that the output is acceptably predictable--is the key to the process approach.
Well, I am not sure what do you mean by "importance", but
identification of processes that are useful from the management viewpoint is exactly what my question (not OP) was about. Technically, any arbitrary set of activities can be declared to be a process. However, not every technically possible set of activities is useful for management purposes. So the question is: how do you arrive at those sets of activities that, once declared to be processes and then managed as processes, would help to manage the entire system in effective and efficient manner?
So far, the answers that I found at Cove (and elsewhere) boil down to something like this:
(1 - Plan) Find the set of activities that looks like a possible useful process to you. Declare this set of activities a process.
(2 - Do) Try to live with this newly defined process for some time.
(3 - Study) Analyze whether this process was useful from the management viewpoint.
(4 - Act) If it was useful, institutionalize this process. Otherwise, remove debris (if any) and go start the next PDSA cycle.
NOTE: If you want more specific advice on how exactly the Plan and Study steps are conducted... well, tough luck! Go get an MBA or something!

Which, of course, would be a totally fair way to answer my question.
Thank you,
Yarik.