In regular hallway conversations at conferences and my daily meanderings through online forums and groups, I still come across a really astounding amount of variation when it comes to people’s thinking about ‘process’.

You can argue that processes (from a business perspective) have been part of the landscape for many decades, but there’s still debate upon debate upon debate.

Where are the edges of what constitutes a process? Does an ‘input’ have to be ‘transformed’? Does there have to be a clear goal? Does there have to be a clear structure and sequence of activities?

These questions are all good ones, but they’re not what really concerns me here—because at least they’re questions that practitioners are exploring and debating explicitly. No, what I’m more worried about is a fundamental characteristic of processes that is very often implicitly assumed in many debates and discussions I come across, without being called out—and the range of implicit assumptions that people make is at the heart of a lot of the confusion that I see still existing around BPM.

At the risk of sounding a bit highfalutin, the issue is: are processes abstract or concrete objects? In less fancy terms: is a process a conceptual description of how things should happen, or an actual mechanism that makes things happen? Or indeed—most confusingly—is it both?

Here’s one definition (from Wikipedia - there are many others):

“A business process or business method is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.”

This definition gives us a bit of guidance, but it doesn’t say anything about the abstract/concrete question. Neither do many of the other definitions I’ve seen.

This might sound a bit of an esoteric thing to worry about, but the answer somebody gives has a pretty fundamental implication for what they will think when they hear people talk about ‘process management’.

For one group of technology vendors and consultants, focused principally on tools that help with process modeling, architecture and process improvement, the ‘processes’ that they’re particularly concerned with are abstract concepts. Processes are descriptions of plans for work that are laid out in maps or models; when this group talks about Process Management, they’re talking about the ability to manage a library of maps and models; manage changes to those models; publish and share those models; and so on. How processes actually translate into work is, pretty much, out of scope (or Somebody Else’s Problem).

For another group, which sells the idea of a complete BPM technology platform that provides a software environment for co-ordinating, integrating and measuring the performance of work as well as providing visual design tools that you can use to map out processes (i.e. BPMSs), references to BPM frame ‘processes’ as concrete objects. Process Management is about how BPMSs help you manage the way that work gets done. But if that wasn’t confusing enough, in truth many in the BPMS technology advocate camp muddy the waters—by sometimes framing the idea of Process Management as being about abstract objects (managing maps and models) and sometimes framing it as being about concrete objects (deploying software systems that guide how work gets done).

Of course, when people get down into the details of running projects and using tools, it eventually (though not always immediately, unfortunately) becomes clear which tools do what. But I would argue that the confusion I see isn’t a brake on people who are already engaged with BPM; rather, it’s one in a line of factors that hold sceptics, cynics and non-believers back from finding out more about BPM and what it can do in the first place.

Is it only me who thinks this is a confusing state of affairs? And is it only me who thinks we would all benefit from some clearer terminology?