Let's start with something my fellow ebizQ writer Michael Dortch said recently in his blog (12 April 2007), following some comments I made to an earlier post of his:

"I think I now think there are two classes of processes - task-driven and human-driven. I think I also now think that task-driven processes define and/or how tasks get done, often by IT systems and resources, while human-driven processes define and/or describe how people do things. Both are essential to successful business operations. However, they are very different from one another, and cannot likely be equally effectively addressed by any common set of processes or technologies."

Why are BPM experts like Michael making such a dramatic division? Because all mainstream BPM languages, including graphical notations like BPMN, are based on carrying out steps in a pre-defined sequence - and this is not what happens when humans work together.

Turning to BPEL4People, it claims to support patterns for "human interactions." However, in terms of the above division, these are human interactions in "task-driven" processes. In other words, what the specification authors mean by "human interactions" is interactions between humans and systems (H2S) - not interactions between humans and humans (H2H).

Let's take an example. Suppose a document is escalated by Joe to Jane for approval - a typical application for BPEL4People. What happens is this. First, Joe tells the system "this document needs higher approval". Then, the system works out that Jane should do it, and adds the approval task to her worklist. Finally, next time Jane accesses her worklist, she sees a new document for approval. There is no direct interaction between Joe and Jane at all. Everything is mediated by worklists, or notification managers, the logic behind which is largely set in stone at the time the processes were originally implemented.

This is an entirely separate issue from dealing with interactions between humans and humans (H2H). Such work is collaborative, innovative, and adaptive - and cannot be supported with a language such as BPEL, no matter how it is extended. Let's take another example. Suppose Joe uncovers a new opportunity with a client. He knows that to realize the opportunity he will need support from others, including Jane. He needs to start a new work process to deal with the opportunity - and this work process will involve a number of people, although at the start the only person Joe knows he will need is Jane. Others will be included as they go along - similarly, they will define on-the-fly the various responsibilities, activities, and deliverables of each person. If you know anything at all about BPEL4People, it will be immediately obvious that it could never be used to support such a work process. Rather, H2H interactions are the domain of Human Interaction Management (HIM).