IT Directions

Keith Harrison-Broninski

BPEL4People and human interactions

user-pic
Vote 0 Votes

Now that the BPEL4People specification has finally been released, it is important to clarify exactly what it covers, and what it doesn't cover.

Let's start with something my fellow ebizQ writer Michael Dortsch 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).

BPEL4People is related to HIM, in that both deal with humans, but the 2 approaches are complementary rather than competitive.  In fact, they are often closely tied together.  Let's take a third example - a system responsible for resolving faults in a telecommunications network.  Most of the faults are handled entirely automatically.  Some need minor manual involvement - for instance, to approve an engineer visit.  However, a small but significant percentage cannot be resolved in either way.  This last type of faults is the complex problems, those that humans need to work together to solve.  Typically, a solution may require several different people to collaborate - call centre staff, network specialists, service engineers, exchange staff, and the customer themselves - in order to determine the cause of the fault and find a way to deal with it.

Managing complex problems like this is where much of the money is spent.  A large telco may spend tens of millions of dollars per annum on such work - at least, they may if they have not yet adopted HIM techniques and tools.  With HIM, the solution is simple.  Most faults are handled via conventional workflow - defined using BPMN, BPEL (with or without BPEL4People), XPDL, or any other notation.  When it comes to a complex fault, a human using the workflow system passes the issue out to a Human Interaction Management System (HIMS) for resolution, choosing as a starting point what seems to be the most suitable template "Story" (i.e., work process).  The humans involved in the Story - who may well increase in number during its life - bring the issue to the point at which automated resolution is again possible; they evaluate the problem, agree a solution, and set it up.  Then the work is passed back to the workflow system, by invoking a suitable set of Web services to clear the fault.

When the complex faults are handled like this, the work becomes tractable.  It can be structured, managed, supported, and improved - just like the automated or semi-automated work required to resolve simpler faults.  When it comes to the bottom line, less money is spent, less time is taken, and both the telco and their customers are happier.

TAKE AWAY

Lots of things that happen in organizations simply do not match in any way the underlying "parallel flowchart" paradigm of a language like BPEL, no matter how you extend it. Look at the sort of things you personally do at work, for example. The "human interaction" patterns that the BPEL4People specification authors are concerned with are useful in integrating some forms of workflow, such as document approvals, into mainstream BPM.  It will be useful for many organizations to handle such patterns using the same BPEL-based technology that they use for fully automated processes.  However, these patterns are totally inappropriate for activity that is innovative, collaborative, and adaptive.

Today's attempts to bundle H2H process support into workflow systems or office applications are confusing apples with oranges, since they are attempting to impose on H2H interactions the wrong metaphor.  Humans trying to collaborate find it not only unhelpful but actually abhorrent to view their interactions with each other as a set of pre-defined steps carried out in sequence, and will either ignore, work around or subvert such bastardized pseudo-solutions.  They know there is a lot more involved: notions of responsibility, accountability, goal-directed communication, privacy, rework, prioritization, consensus, authority, and a lot more besides.

To deal properly with H2H interactions, you need appropriate techniques (HIM) and tools (the HIMS).  These techniques and tools are not hard to use, since they are nothing but a formalization of common sense - a direct reflection of what really happens.  This formalization comes from many years of research and practical experience, which has resulted in well-defined ideas, principles and patterns - ideas, principles and patterns that genuinely meet organizational and individual needs for control over H2H interactions.

9 Comments

Hello Keith,

Just a bit provocative to stimulate discussion...how about using Case handling systems for this kind of problems. Do you think Case handling can be a good BPMS extension to support H2H processes ?

Regards, Artur

Hi Artur

Case management tools do give you more flexibility then (say) BPEL4People, since they essentially provide a shared workspace into which people and documents can be included as required.

However, this gives you no real way to structure the process that the people carry out using the documents. In particular, their interactions tend to be obscured by the system, so people often end up bypassing or working round it.

Why? Although case management tools often provide a limited number of standard actions (e.g., "forward for approval"), this isn't the same as having a process view based on what people really do when working together. For example, the need for discussion and consensus on decision-making is rarely catered for.

Further, case management does not provide any means to manage the process - to monitor it using goal-driven metrics, prioritize actions, facilitate the work of the people involved, assess how effectively they are working, and improve the way the work is carried out.

I don't see a huge difference between Case Management and "Web 2.0" technologies like Groove, or even Wikis, where you have a shared repository of some kind plus a thin layer of tooling to administer it collaboratively. All these applications lack a true process view of H2H work, which is what both individuals and organizations need in order to become more effective.

--
All the best
Keith

Hi Keith
Perhaps you remember we discussed this issue in Gent a while ago. I do agree with your views, but I also know from experience that it is difficult but necessary to integrate H2H and H2S, both as an approach and as a system. After having attended and presented at the Gartner BPM get-together in London recently I realised that BPM suite vendors find it difficult to understand that BPEL4People will not solve it all. I would love to see an approach and a system which will allow me to model both; do things such as scoping, defining hierarchies, model DFD's, do some high level modeling, include HIM, perhaps some conceptual ERD's etc.. Ie, true enterprise modeling without having to use 3 or more tools. When asked about this, vendors eyes glaze over and I am sure they are thinking of there next holiday rather then ponder on such a silly idea. May the process be with you...
Noël - Gent - Belgium

Hi Keith,

Thanks for you answer. However, isn't the heart of the idea of case management to have "loosely coupled" (read, not fully structured with control flow) tasks that can be used when necessery around the set of data stored in the common repository ? To me it can, to some extend, be used for H2H processes. The difference, small from tehnical point of view yet fundamental as concept, is lack of support for "private workspace" and probably (my suspection as I am not an expert in using this kind of systems) for mechanism that would allow to fit the H2H comnication into business conext (different, or more precisely, at the lower level of case granularity, that the case itself).

However, looking at Case management concept itself, I have a feeleing it is an attempt to evolutionarily extend current BPMS features to support H2H processes which is good as it means the BMPS Market will promote the concept of H2H itself to the wide audience.

To Noel, you can probably take existing tools and model the thing that you said by extending them by ading your own semantics using stereotypes or similiar mechanisms. That is what we do at our company; we take "agile" toolsets with high potential for extension, supply them with add-ins and incororate our own conventions. It works (at least for us and for the currently implemened enterprise modeling approach).

Regards, Artur

user-pic

Hi Keith,

Thanks for you answer. However, isn't the heart of the idea of case management to have "loosely coupled" (read, not fully structured with control flow) tasks that can be used when necessery around the set of data stored in the common repository ? To me it can, to some extend, be used for H2H processes. The difference, small from tehnical point of view yet fundamental as concept, is lack of support for "private workspace" and probably (my suspection as I am not an expert in using this kind of systems) for mechanism that would allow to fit the H2H comnication into business conext (different, or more precisely, at the lower level of case granularity, that the case itself).

However, looking at Case management concept itself, I have a feeleing it is an attempt to evolutionarily extend current BPMS features to support H2H processes which is good as it means the BMPS Market will promote the concept of H2H itself to the wide audience.

To Noel, you can probably take existing tools and model the thing that you said by extending them by ading your own semantics using stereotypes or similiar mechanisms. That is what we do at our company; we take "agile" toolsets with high potential for extension, supply them with add-ins and incororate our own conventions. It works (at least for us and for the currently implemened enterprise modeling approach).

Regards, Artur

Hi Artur

Yes, the "tasks" you describe are what I meant in my first response by "a limited number of standard actions".

However, I would not say that Case Management is an evolution of BPM software (although some people, Jon Pyke for example, do make this connection). For a start, most Case Management software pre-dates BPM. But more importantly, as you yourself point out, Case Management tasks are neither fully structured into processes, nor part of a wider business context.

Even leading aside the inability of Case Management software to deal with H2H issues (responsibility, accountability, goal-directed communication, privacy, rework, prioritization, consensus, authority, etc), I don't feel that such bolt-on tooling is really process-oriented at all.

And without true process orientation, the benefits people hope to gain from improving efficiency are unlikely to materialize. For example, suppose you are able to reduce the time spent on each case via Case Management. How are you to understand why the time is going down? It may be because customers are getting frustrated with a semi-automated system and giving up, to go elsewhere in future! Or because approval decisions are being taken by the wrong people, at the wrong time, in the wrong way, ...

--
All the best
Keith

user-pic

Hi Keith,

Just for the purpose of the discussion. Suppose we take Martyn's approach for process architecture and thus treat a case handling engine's case process as implementtaion of a CASE PROCESS form Riva. Suppose we incoporate case handling engines into BPMS in the same manner as business rule engines are. Thus RIVA'S CASE MANAGEMENT PROCESS could be supported by BPMS (supported by rule engines). As a whole, the process could be tracked.

What do you think ?

Regards, Artur

I imagine a lot of BPMS and Case Management vendors would like to see this kind of integration.

I appreciate you propose the approach only for discussion, Artur. I wouldn't recommend it to most organizations, for two reasons.

First, as described above, I think that many of the benefits of Case Management are in fact illusory. It is appropriate only in very specific situations, not for general application to H2H processes.

Second, I believe that the notion of a Riva "Case Management" process is appropriate for mechanistic (routinized) processes but not for human-driven (collaborative, innovative, adaptive) processes. For human-driven processes, Human Interaction Management theory identifies 2 separate forms of control (Management and Executive), neither of which are suited to implementation via a BPMS.

--
All the best
Keith

user-pic

Probably not for now it would be to risky, but maybe that is the way future BPM working enviroment can be composed. Riva's aproach for process architectures is, I agree with you, based more on "traditional" perception of process management (however it is much more pro-active and pro-concurent than any other approach that I know) but it still can be applied to many areas of the organization's activities. H2H processes allows to reflect more colaborative and adaptive (thus more flexible proces management is required) but the aproach is applicable to the subset of all company processes.

I am trying to imagine perfect BPMS and it looks to me that we need a "backbone", a process-type-neutral engine, that can communicate to H2H engine, H2S engine and S2S engine (to some extend) and combine its features to manage value chains that are spread onto the process achitecture.

Best regards, Artur

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.

Subscribe

 Subscribe in a reader

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT