Link: http://weblog.tetradian.com/2012/09/04/the-meaning-of-process/
What do we mean by the term ‘process’? What is a process? For that matter, what isn’t a process?
This came up in a great Skype-conversation today with Kevin Smith, creator of PEAF (the Pragmatic EA Framework), about yet another LinkedIn somewhat-circular discussion – “going down the rabbit-hole”, as Kevin put it – about the definition and meaning of ‘process’.
Not surprised at the ‘rabbit-hole’, though. (And this time I won’t curse at the IT-guys for creating it, either, because they didn’t. 
) ‘Process’ is one of several terms that are used in horribly-blurry ways within business, and worse, it’s also part of that appalling terminology-tangle of process versus service versus function and the rest, where processes can contain functions can contain processes can contain services can contain functions which can contain other functions or services or processes… Yeah, it’s a mess.
Yet whilst the rabbit-hole isn’t the IT-folks’ fault as such, somehow their IT-centric approaches to everything do seem to succeed only in screwing-up this one even further than it is already. For example, one of the IT-folks in that LinkedIn discussion argued that the word ‘process’ should be reserved solely for automated processes, or linear processes: sequences of exactly-repeatable activities with consistent inputs and equally-consistent outputs. Anything that didn’t fit this description wasn’t a ‘real process’, and either could or should be ignored – by IT-folks, anyway. When asked how, given that constraint, we could then describe those parts of customer-journeys and other activity-streams that didn’t fit this description, he suggested the alternate term ‘practice’. Which might be considered okay, except that we would now have two equally-blurry terms for what is, in effect, the same activity-stream, differing only in how they’re implemented – which in practice might change at any moment. Further and further we go down the rabbit-hole…
So let’s back off a bit. Back right up out of the rabbit-hole. Start again – but this time, instead of fighting about which definition is the ‘correct’ one, we start by acknowledging that it is a mess.
What actually is a process, in the way that people tend to use the term? And how does the definition get to be such a mess? Here are some points about it that most people seem to be able to agree on:
- ‘process’ is a blurry kind of term – in fact one of its advantages as a term is that it is kinda blurry
- it’s something sort-of to do with sort-of-sequences of activities that, overall, probably result in something being done to or with something – it’s all a bit blurry and uncertain
- we use the term for sequences that mostly seem to repeat; for sequences that barely repeat at all (and sometimes could barely even be described as sequences); and for just about anything in between, and any mix of in-between as well
- business-folks in particular use ‘process’ to describe things that automated systems do, and things that people do, and any combination of those – including contexts where the process passes back and forth between people and machines, or where people can sometimes do the tasks of machines, and vice versa
- process can be just about anywhere, and at just about any level, from a server-process or web-process to the process of an entire production-line
- processes can be decomposed into smaller sub-processes, and aggregated into broader-scope processes, but we still use the same term regardless of what level of decomposition or aggregation might apply
If ‘process’ is as blurry as that, it’s no wonder that process-taxonomies don’t seem to make much sense…
But let’s turn this sideways on. All of those definitions seem to assume that ‘process’ is the work itself. It isn’t: it’s a description of work – a description of perceived relationships between activities, in terms of some kind of overall objective or goal. It’s a way of looking at the ways in which work is done.
And we already have another term for ‘way of looking at something’: a model.
A process is a map, a description, a model, of ‘work being done’, or ‘work to be done’. A selected subset or view into the totality of ‘work being done’. Processes are a way to view perceived-relationships between activities; and those views (‘processes’) may encompass a spectrum from exactly-repeatable to exactly-unique.
And just as with any other architecture-type model, if there’s a view, there’s a viewpoint from which to observe that view. And we should be able to describe and define the context for that viewpoint – not least, the intended-audience for that viewpoint and view.
The selection of whatever is considered to be ‘part-of’ or ‘not-part-of’ the process is not ‘objective fact’ as such, but a choice as to what will or will not be considered relevant in the view from the viewpoint.
So if a process is, in effect, just a view, and the set of activities or whatever to be shown in that view are just a choice, then it’s no surprise that the term ‘process’ tends to be a bit blurry…
Using ‘process’ solely to mean ‘predictable sequence of automation-delivered activity’ is a term-hijack, much like using ‘enterprise-architecture’ for EITA only. Term-hijacks block the view of the whole, and make it almost impossible to make sense of anything in a real-world context. For example, if the definition of ‘process’ is automation-only, then in effect the EITA-guys are classing every non-automated activity as a SEP – and SEPs don’t cease to exist simply because you choose to ignore them. Not a good idea…
‘Process’ and ‘activity’ are orthogonal – or rather ‘process’ is simply a view into activities. And, in turn, what is or is not considered to be an ‘activity’ is also often just a choice, a way of partitioning what’s going on, as a way of making-sense of what’s going on.
Every ‘process’ is an arbitrary grouping of activities – a view. (Note the word ‘arbitrary’ there…). So processes can always be decomposed and/or aggregated, because a process is just a view.
For example, automated actitivies can be decomposed right down to a single machine-code instruction, or aggregated up to (part of) an overall business-process: a process is an arbitrary (self-chosen) view into activities. And activities themselves may be perceived as ‘being’ at some level of decomposition/aggregation – which itself is a view. So in effect, a process is an arbitrary view into an arbitrary view.
A process is an arbitrarily-selected view from an arbitrarily-selected viewpoint into perceived-relationships between perceived-activities.
That’s it: it’s arbitrary, and it’s completely recursive – hence the rabbit-hole. (More accurately, the rabbit-hole occurs whenever some idiot insists that some arbitrarily-chosen view is ‘the process’…)
In short, ‘process’ means what we choose it to mean – no more, and no less. A blurry kind of term, but usefully-blurry nonetheless: a definition that works because it doesn’t actually define anything.
Hope this makes some degree of sense, anyway – and hope it helps, too. Comments, anyone?
[Update: yep, I admit it: I screwed up somewhat on this one. The screw-up is not actually that fatal – it doesn’t invalidate the key point about ‘inherent-blurriness’ – but as can be seen in the comments below, Nick Gall and Ivo Velitchkov both rightly lay into me about various aspects of this post.The main screw-up is best summarised by Nick: “I can’t believe you’re still getting bogged down in the ‘thing’ vs. ‘description of thing’ quagmire”. As Nick says in his comment, I’m muddling ‘process’ (‘thing’) with ‘process-description’ (‘description of thing’): that arbitrarily-selected view is the process-description, not the process itself.
So, another try:
- a process is the/a set of overall activities, inputs, outcomes and context, in terms of whatever is chosen to be summarised in a process-description
- a process-description is an arbitrarily-selected view from an arbitrarily-selected viewpoint into perceived-relationships between perceived-activities
The real point is the blurriness, the arbitrariness, the uncertainty: a process is whatever we choose to say is ‘the process’. Any definition of ‘process’ that tries to be any more precise than that is missing the point about the need for and value of ‘non-definitions’ of this type.
Hope that makes a bit more sense this time?]
