Saturday, May 29, 2010

Journey to the essence of BPM - part 1

The last months I have been thinking a lot about BPM, trying to understand what's really the point. It started with doubts on the tangible benefits, but also on the true nature of BPM. What is it really? Still seeing a lot of definitions and notions around on BPM, I wanted to dive deeper and find some true meaning that really resonates, instead of the many "fluffy blabla" definitions.

First I want to share my thoughts about the concept of "process". Here I already see confusing notions and assumptions.

The common definitions of "process" typically resolves into something like "linked activities, reaching a certain goal, having inputs, outputs, people and machines performing them, adding some value to a customer, certain business rules that apply, etc etc".
The thing is: I have never touched a process. Never held one. And things not being physical means abstraction.

Let's get back to process. What is really?

Let's first agree a process is not a process-model. As the belgium painter Magritte stated "C'est ne pas un pipe": the drawing of a pipe is not the same as the real thing.

The only real thing I can think of is human (and systems) behavior. When one or more people and/or machines show certain behavioral patterns repeatedly, you might call that a process.

That already establishes a foundation for BPM. It's people (and machines), and their behavior.

What governs that behavior? What makes that we call certain behavior a process? Some explorations:

If a group of people has "behavioral" responsibilities in a certain area, I also could ask them "how they deliver certain results". Although differences will exist, they are probably able to recall their activities and can also tell me how they will behave the next time a certain result is expected. In that sense, "process" has a memory-construct, that will enable people to remember what to do.

In situations where people need to reach results, that require them to collaborate, people tend to communicate, negotiate and agree on required behavior (if you do.... then I will.....). In that sense, "process" is also about "social contracts".
A short side-step: I recently moved to a new apartment, and the movers showed a fascinating efficiency. The group of men clearly had worked many times together, and where really a team. Without much spoken communication, they rapidly worked together. And while watching them close, I could see various patterns and tacit communication. The "social contract" had been developed over a longer period of time, and was still evolving, improving, quickly reacting to new circumstances. When teams are really performing, process as a social construct does not seem to require "BPM sessions".

Am I getting closer to something that resonates as a true "process" concept?
- It's actual behavior of specific people and machines (without action, no process)
- It's about repetitive behavior of these people (only done once - no process)
- It's about knowledge and social contract (these people and machines are governed, and have, with more of less consent, agreed to/and know certain "playing rules")
- It's (sometimes!) about improvement and adaption (that might be done tacitly), when there is true "teamwork"

People behavior people behavior......sometimes is trying to tell me something, but I'm not there yet.
What I do know is that the traditional definitions of BPM are far from "specific people". It talks about process and maybe of people that are "resources" pushed as little pegs into RACI's. That does not feel right and also severely limits us in our BPM approach.

My gut feeling: BPM is about social interventions.
But more about this in the next parts of my journey!

4 comments:

JacobU said...

Roeland,
I couldn't agree more. The problem is that if you look at BPM as mostly people and their interactions - no BPMS would make the cut. So what does an BPMS do if not BPM?
Take a look at the "Adaptive Case Management" discussions going on - I think many people from the BPM world are coming to the same conclusions you are.

Jacob Ukelson - CTO ActionBase

JacobU said...

Roeland,
I couldn't agree more. The problem is that if you look at BPM as mostly people and their interactions - no BPMS would make the cut. So what does an BPMS do if not BPM?
Take a look at the "Adaptive Case Management" discussions going on - I think many people from the BPM world are coming to the same conclusions you are.

Jacob Ukelson - CTO ActionBase

JacobU said...

Roeland,
I couldn't agree more. The problem is that if you look at BPM as mostly people and their interactions - no BPMS would make the cut. So what does an BPMS do if not BPM?
Take a look at the "Adaptive Case Management" discussions going on - I think many people from the BPM world are coming to the same conclusions you are.

Jacob Ukelson - CTO ActionBase

Mitó said...

Magritte has written:

ceci n'est pas une pipe

http://steynian.files.wordpress.com/2009/11/ceci-nest-pas-une-pipe-magritte.jpg