We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

Keith's adventures in BPMN - Respond to RFP revisited

Vote 0 Votes

A commenter on the last post to this blog wrote:

"I agree that BPMN is not targeted to the behaviour of people to people and people to system interaction. Using it for such a purpose is akin to using a chisel to open a paint tin."

This sums up very neatly a typical attitude to what I call human-driven processes. Like paint swirling around in a tin, collaborative human work is seen as lacking any structure. Human interactions appear to be so complex, so ad-hoc, that it is impossible to apply precise descriptive techniques to what is going on.

The result of this viewpoint is that collaborative processes are brushed under the carpet by business analysts, process designers, solution architects, and other people in a position to help organizations work both more efficiently and more effectively. The latest crop of "human-centric" BPM tools, for example, treat knowledge work as an inconvenient adjunct to routine processes - a sort of exceptional case, in which the polished simplicity of a routine process is unfortunately disrupted by the human desire to think, communicate and achieve. The manner in which editing documents, sending emails, and other mainstays of business life is treated by such BPM products relegates them to the fringes of management awareness - a short-sighted strategy, to say the least, since it is this kind of work that delivers most value. Treating such activities as a temporary step outside the "real" process certainly gives little opportunity for the 59%-80% of the US workforce who are knowledge workers to contribute to the sucess of their organization.

Regular readers of this blog will know that the principles and patterns of Human Interaction Management exist to remedy the situation. Using the simple notation of HIM, in conjunction with a small number of standard patterns, it is possible to understand and improve any type of collaborative work. However, these principles and patterns are relatively new (they were documented for the first time in my 2005 book), so in this blog series I am attempting to illustrate them by example.

The particular example used is a simplified process for Response to Request For Proposal. For comparison, in my last post I drew the process in BPMN and discussed the weaknesses of the representation. In this post I will illustrate how the process can be represented using HIM notation.

You will see immediately that the diagram looks quite different from BPMN. The similarities that exist are in fact superficial - don't be misled by them into thinking that the notational constructs are equivalent. Here are some key aspects of the diagram:

Instead of lanes/pools as in a BPMN diagram, with documents/data floating about in thin air, each player in a HIM process has a Role - the vertical rectangles with yellow background. A Role is more than a collection of actions - it is a mini-workspace, that provides you with a lot more than "things to do in a specific order". For a start, each Role has its own goals and responsibilities - which by agreeing to play a Role, you commit to meeting. To help you meet the goals and responsibilities, each Role has its own private documents/data that you can update and share with colleagues when appropriate. A Role also contains business rules that help you decide when to do what, and that help ensure that your work stays in line with higher-level policies and regulations.

Instead of messages from one party to another as in a BPMN diagram, a HIM process has Interactions between Roles - the purple, mainly horizontal lines. A HIM Interaction is a purposeful communication channel - a means by which messages can be exchanged, repeatedly and in any direction, between any number of parties. Think of Interactions as "email plus process context", although any form of messaging can be used to implement an Interaction.

Collaborative Transactions
Instead of sub-processes as in a BPMN diagram, a HIM process has Collaborative Transactions - stages or phases of a process, as highlighted in the marked-up version of the diagram below. Collaborative Transactions start with an Interaction between all parties (to establish the purpose of the ensuing work), contain various actions for each party, and conclude with another Interaction (to agree that the work is completed and decide on next steps). Collaborative Transactions can be nested, as shown here, without introducing a hierarchical structure foreign to human interactions - in reality, people can talk to one another at any time, whatever part of a process they are supposed to be carrying out.

There is a lot more to say about this diagram, and I will return to it in future posts.


Collaborative human work is a quite different thing from the routine, mostly automated work handled by mainstream BPM techniques and tools. Trying to capture human work using BPMN is not so much like using a chisel to open a paint tin as it is like using a chisel to play the violin - the end result will be frustration with your chisel, serious damage to your violin, and a horrible noise.

The diagram above was drawn using HumanEdj, the reference implementation of a Human Interaction Management System - a modelling and execution environment for human work. The diagram not only shows the work, but can be used by all parties to carry it out. If this blog post strikes a chord with you, why not try out HumanEdj - design some collaborative processes for yourself, and see how easy it is to bring order to the apparent chaos. It may not be possible to eliminate real-world complexity, but it is certainly possible to bring it under control. You just need new techniques and new tools.

NOTE: The diagram shown here was drawn using the latest version of HumanEdj, which will be on public release later this week. If you are using an earlier version, your diagrams will look different.

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 in a reader

Recently Commented On

Monthly Archives