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 - *!@$%, this is going to be hard to implement!

Vote 0 Votes

In the 3 years since publication of my book "Human Interactions - the Heart and Soul of Business Process Management", reactions from BPM specialists have been mixed.

One frequent response is: "at last someone is saying what I've always thought". In other words, the mixture of consultancy observations and insights from varied disciplines that is Human Interaction Management (HIM) seems like simple common sense.

Another frequent response is "that can't be right". In other words, please don't let this be right - because if it is, we've got to start again, almost from scratch. Both consultants and software vendors are going to have to make dramatic changes to the solutions they are offering.

Current BPM solutions (both method and theory) relegate human collaboration to the fringes of organizational life, treating as an backwater of unmanageable "ad-hoc" work where "here be dragons". This is not good enough, is it. Organizations need knowledge workers to be:

  1. More efficient - work faster and leave tidy information behind. Basex estimate that 28% of knowledge worker time is lost to poor control of interactions. So we need better teams, better communication channels, better generation of knowledge from information, better time management, and better planning tools (these are the 5 HIM principles, by the way). How are current BPM and case management solutions going to give us any of these? To the worker, "human-centric" software offerings are still just task lists, with the added complication that they are now expected to create their own tasks.
  2. More effective - adapt their work to changing objectives. The key word is "changing". It is not enough to allow people to plan their own activities in ad-hoc fashion - this is just a gateway to chaos, in which people go off at tangents the whole time, leaving behind a sea of unstructured audit trails. Human work needs to be part of a management framework geared around driving top-down change (i.e., from current strategy) while empowering bottom-up decision-making (i.e., allowing people to negotiate next steps in a structured way as they go through a process).

In this blog series, I am relating these needs specifically to BPMN, by showing how BPMN notation cannot express constructs that are critical to the efficient and effective management of human work - while HIM notation can do so easily. Here is another example.

In the HIM diagrams featured in previous posts in this series, you will notice that each Role (yellow rectangle) has the word INSTANCE underneath its name. This means that the Role is active in the process - it represents a real, working participant. Some Roles, however, are used differently. Here is another version of the HIM solution to Respond to RFP from a few posts back, again generated using the free HumanEdj:

Notice that this time the Technical Consultant Role is shown as a TYPE rather than an instance. Also, the Account Manager has a new Activity, to assign a Technical Consultant. What is going on?

The new diagram reflects the fact that, in some cases, the Salesperson will not need technical consultancy - they will be familiar enough with the solution to be offered to the client that they can prepare the proposal unaided. In the new version, the Salesperson and Account Manager can discuss this via the Initiate Submit Proposal Interaction - and depending on the outcome of that discussion, the Account Manager may or may not create an "instance" of the Technical Consultant Role "type".

How would this be depicted in BPMN? You would have to create a swimlane for the Technical Consultancy work, and make all its activities optional in the process. In other words, work has been assigned but may never happen. Further, there is no explicit depiction of how the work will be assigned - under what circumstances, when, who by, to whom, the sort of skills and experience required, and so on. Critical aspects of human resource planning are omitted from the process - of necessity, since there is nowhere to put them.


To remedy process description deficiencies such as those described in this blog series, software vendors typically advocate the use of business rules in conjunction with process execution software based on BPMN and/or XPDL.

While one of the 6 key HIMS object types is a Rule, which can be applied in many ways, Rules alone are not the answer, since in large quantities they are unmaintainable. For routine work, we are moving toward an agent-based approach in which rules are key - when you run a process a million times, the effort of maintaining the rules is worth it. But for human-driven work, in which every process instance is different, there is no value-add in burdening it with huge numbers of rules. Not only does it constrain the work artificially (just ask a doctor whether they would let a system diagnose for them), but there is zero motivation for the people involved to help maintain the rules, since they are only putting themselves out of a job - so people will work around the rules and let them degrade. I've seen this in many organizations over the years.

The key issue is that human-driven work is fundamentally different to routine work, for a variety of reasons ranging from socio-economic issues such as globalization (in particular, the availability of very cheap workers) to psychological issues such as team building (as Handy predicted 20 years ago, corporations are becoming virtual). Organizations ignore this at their peril! As Jon Pyke, Chair of the Workflow Management Coalition, wrote in an article on this site in 2006:

Process-based technology that understands the needs of people and supports the inherent "spontaneity" of the human mind is the next logical step, and we might be tempted to name this potential paradigm shift "Knowledge Intensive Business Processes."
KIBPM falls into two main categories, which will probably merge over time, and the vendor that recognizes that potential will steal a march on the others. At the simplest level we have case management, and secondly, we have Human Interaction Management. I doubt there are many BPM products on the market today which will be able to meet this seismic shift in requirements - certainly those that rely on BPEL and SOA won't; what's more, any that have been in the market for longer than five years will need radical surgery to meet the coming challenge.
Why Workflow Sucks

In other words, radical new ideas and accompanying new technology are required, that go way beyond case management. So why have the major software vendors stuck with the kind of workflow and state-based case management solutions that have been available for years? Well, all suite vendors have a huge code base to maintain, and it's easier to tinker with what they've got than to develop new code from scratch. But this isn't serving the market, or ultimately, themselves.

To thrive in the next 50 years, we need new insights, new practices and (ultimately) new forms of software.


Keith - Found your discussion very interesting.

I've done a considerable amount of process design / optimization work over the years, and the biggest challange has always been not in describing how a process is supposed to work, but how it actually works.

Building a model and optimizing how a process is supposed to work is relatively easy, but in the end, it comes down to people and the better they are at their jobs, the more they will go "off script".

In my experience I've found that most of the time this variability arises when I've tried to get too granular in my analysis. As a result when I'm in a session and I start go get people saying "Well, I do it this way" we stop and checkpoint to make sure we're not getting too detailed.

I'm not sure how you can avoid this, but I'd appreciate your thoughts.

Hi Dave

I think the problem is 2-fold.

Firstly, as described in my blog post, use the wrong tools, and accurate process description becomes very hard indeed. One household name spent months trying and failing to capture a set of divisional processes - using HIM, we captured, re-engineered and implemented the lot in 2 weeks.

Secondly, you can't capture most human-driven processes at the outset - there's too much uncertainty, requiring adaptation on the fly - which is why you need human skills, experience and ingenuity in the first place! To deal with this you need process management techniques that allow processes to change themselves, not by bolting on unstructured workspaces, but by extending the existing structure to deal with the situation in hand. Ideally such techniques should also allow the best-handled cases to be re-used as template processes in future.

HIM and the HIMS exist to meet these needs - and bizarrely, they seem currently to be the only organizational-scale solution available. Nothing else scales UP to deal with enterprise management or scales OUT to deal with processes that cross organizational boundaries.

This is because process management has become an IT niche, and hence is funded (i.e., controlled) by incumbent software vendors with legacy products to promote. The resulting mainstream is not necessarily in the interests of process designers and process users, who end up in the sort of impossible situations you describe.

This is all changing. I suggest you join the HIM groups to stay up to date.

All the best

Great article and really hits home the fact that we need to keep on our toes as well as push our partners and employees to embrace new ideas, software and practices.

I recently began researching a lot of new time management programs and gave a few to my staff members to test. It worked out really well as the feedback I got from them was not only interesting to me but they also felt that they were becoming part of the future of the company.

Like all things in life it’s good to keep things fresh and updated.

Thanks for the article Keith and I will look forward to the next one.

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