The social construction of process

That previous post on process was, yes, I’ll admit it, a bit long: but the key point is that the term ‘process’ is necessarily a bit blurred, and that we get into trouble if we try too hard to sharpen up its definition.

Yet there’s still a lot of pushback on that point – and no doubt there always will be. The real sticking-point comes back again and again to our old adversary: the linear-paradigm’s need for certainty, even where such certainty may not ever exist.

There are places, though, where that need for certainty is inevitable, and does need to be respected. Alexander Samarin brought this up in a comment to that previous post:

Process is explicitly-defined coordination of activities to create a particular result (outcome); process template is abstract description of a process; process instance is enactment of a process template. … Ideally, processes should be explicit and executable (to reduce the wickedness).

(The last comment, in parenthesis, is a reference back to my post ‘Enterprise-architecture is wicked‘.)

It’s true that in general, processes that are run on any kind of automated system – physical-machine, electronics, IT, or any combination of those – or Taylorist-style pseudo-automation – a rigid rule-based ‘work-instruction’ – will indeed need to be explicit, in order to be executable in a predictable, certain way. The whole point is that if they’re not explicit, we’re likely to get unintended results in unpredictable ways.

Yet that’s actually a circular-definition: processes that need to be explicit and executable by automation are those processes that should be explicit and executable by automation. It doesn’t mean that all processes are necessarily explicit; nor does it mean that all processes are necessarily executable by automated systems. ‘Explicit and executable’ is a special-case – a subset of ‘process’, not the whole. If we try to assert that ‘process’ applies only to those activities that are explicit and executable, we’re then left with a term-hijack that allows us no way to describe any activity that falls through its filter – including all of the activities in a customer-journey or suchlike that link between those ‘explicit and executable processes’ that run on automated systems.

The whole point about machine-processes is that they need to be explicit.

The whole point about human processes is that they can deal with the parts that aren’t explicit.

In short, ‘explicit and executable’ is a special-case: we still need a term that describes the whole of what ‘process’ might mean.

There’s a real reason why we need an open, blurry, always-somewhat-implicit always-somewhat-uncertain not-quite-a-definition of ‘process’ – and that’s because what we’re dealing with here is actually a social construction of reality. In a nicely necessary recursion, exploring and answering the question ‘What is the process?’ is itself part of the process.

Which is why we can’t have a pre-definition of process: the definition arises from the context of the process, and only makes sense within the bounds of that context. And since, ultimately, everything is connected to everything else, the boundaries for the context are what we choose to be the bounds for that context.

Which is why, if we’re not careful about this, yep, it’s rabbit-hole time again… 🙂

Which is also why the only viable definition of ‘process’ is that infamous, ubiquitous answer of the experienced enterprise-architect: “It depends…”

Process is a process that always includes the social construction of its own definition of process.

Makes sense, I hope? Or not? Over to you for comments, anyway.