Gartner BPM Summit London - Day 2, Part 1

Ah, a great start of the day with a good presenter: Regina Casonato.
Her research shows (and I agree, from real-life experiences) that there are processes we are currently not able to automate (well) with the current generation of BPM tools: fluid, contextbased collaborative processes.

Small example on my side: ever tried to model collaborative BPM with BPMN and Swimlanes? Right....

So where all vendors talk about S2S and H2S integration (S=System, H=Human), she helped us understand the tricky domain of H2H BPM.

Some important terms that play a role:
-> Presence.
In my definition: your own availability, in terms of for WHO, and via WHICH Channel at WHAT TIME. Something that you manage (already). However, something that in the future, you will be able to manage much more detailed.
Now: I can decide where I will be, if I pick up the phone (general or caller ID), if I will respond to IM (availability, even for certain people), etc. In the future I might detail this more: between 9 - 11 Am, I am available for BPM activities X, Y, and Z, through channels IM and email. Oh, and BPM process A, B and C I will be available during working days. E.g. detailing my presence "rules" to context....

-> Context
More tricky. Whenever we are presented by say an email or a workflow item or a phone call, or whatever thing/person that delivers us information, we need to understand why, what, how, who, when, etc. Context is what we need to be able to do something usefull with provided information and with a activity/request.

(She made an interesting link to BPM and information overflow: a process can be seen as a piece of context - we are doing X for customer Y). When delivering an activity, the process (what needs to be done) + process data (which customer, what step of the process) serve as context to the person doing the activity. So more explicit processes can help us structure reality and fight overload (well a bit - she warned for context overload).

-> Collective Intelligence
Beautifull clear concept - all the mindpower you can have, that you need to really perform some activity in a process well (think decision, strategy, etc).

Now, let's get back to the Collaborative part. Suppose a process requires a collaboration as part of a certain activity. H2H. This could be: synchronous (all people required need to be available, aka a "meeting"), asynchronous (a conversation over time - discussion/forum/email correspondence) or hybrid. The concept of presence becomes important here: a group of people receives a task. Will I get it, will I be involved, am I needed - a mix of context, rules and my presence decisions. And depending on my channel choices, I might be included through face to face, phone, chat/instant messaging, email, etc.
The key question: how to involve the right people at the right time, and support them well?
Her point is that these types of H2H interactions are currently not well integrated in BPM tools, and that if we want to take on the Information Worker processes, we'll need to rethink. From the production workflow transaction based processes (do this, do that) to a mix of do this, do that, hmmm, think about this, collaborate on that...
A mix of technologies, think networking sites (who has knowledge about XYZ and is currently present), IM, email, VOIP, etc.

It's funny, in my current project we spend quite some time how to get certain stakeholders doing certain tasks at the right time (sometimes together), and what if they are not available...
It links to another concept she used:
-> Just-In-Time Intelligence.
Ah. The right task and the right time to the right persons with the right knowledge.

Collaborative Events happening in a process flow can of course:
- Be logged -> to capture the knowledge, so that simular tasks later can re-use this knowledge
- Be traced -> to support compliance

In her view the whole Web 2.0 collaborative technology and BPM could be linked and merged.
And of course, she reminded us: don't do collaborative BPM within your company walls, think larger - customers, suppliers, partners.... How to leverage your collective intelligence!

Interesting times ahead!

A sidenote:
The concept of an Context Engine versus a Process Engine made me realize we currently mix these things. We define BPM models in BPM Suites, where at design time we decide for each activity what the means are to finish this activity (that person, that SOA call). What if we split these concepts:
- A process engine knows only about an activity that needs to be done
- A context engine knows for each activity, based on presence, contextual knowledge, etc, how to get this activity executed...