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.
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.