Human Interaction Management and other process modelling notations

The latest BPTrends newsletter pointed to a case study on Human Interaction Management by Keith Harrison-Broninski which, unfortunately, didn’t do a lot towards explaining the benefits of HIM. It’s a bit like any sort of process modelling that uses swimlanes, except that the swimlanes are boxes rather than lanes, so the topology of the process is quite different that the left-to-right flow that we’re used to in most process modelling notations. He uses, as justification for HIM, the following anecdotal evidence:

The person responsible for re-engineering this process spent several months drawing up process documents which no-one used, and struggled even to understand, before turning to the techniques of Human Interaction Management, and finding that everything they had written so far, and more, could be expressed in a single 1-page diagram — further, a diagram that elucidated the processes concerned so clearly that all parties involved were able to agree on a re-engineered version within 2 meetings.

Doesn’t that just support the argument that a simpler process modelling diagram is easier to communicate than a complex one, without necessarily saying that the simpler diagram needs to be HIM? I believe that it’s possible in many modelling notations to create simpler diagrams that are more appropriate for a widely-varied audience through various levels of abstraction. HIM diagrams tend to cram a lot of information on one page (see the example on page 2 of his article), but I don’t see that it’s any more or less understandable than other process models.

The same issue of BPTrends has an article in which Paul Harmon decries the dichotomy between modelling techniques for human and system processes, in counterpoint to Harrison-Broninski. This is labelled as a “A Response to Harrison-Broninski’s Response to My November 15th BPTrends Email Advisor”, so obviously these guys have been having some heated discourse over this topic for a while. I tend to agree with Harmon (although the name-dropping in the article gets a bit thick), since his reaction to Harrison-Broninski’s article is pretty much the same as mine:

A case study developed by Harrison-Broninski has been posted on BPTrends this month. It contains a RAD diagram of a Business System-Support Process. To my eye, that diagram is just a complex version of a Rummler-Brache swimlane diagram, turned on end. If you reduced it to swimlanes, boxes, and arrows, I think it would make it easier for most business people to understand. Obviously there a lot of subjectivity about what looks simple to whom. All I can tell you is that I’ve worked with lots of business people. Most weren’t interested in automation, and workflow diagrams have always worked just fine.

Earlier in the article, Harmon comments on how a high-level process diagram is usually sufficient in order to communicate with business people for the purposes of reaching a common understanding of the process and identify opportunities for process improvement; in other words, you don’t have to spend months creates a multi-page process diagram that details every last system function before you reach consensus on the direction to take. And, he believes that BPMN is the sort of simple, standard notation that can be understood and used by business people while still providing the power to model more complex lower levels of the process at a later point.

This holy war on process modelling notations puts me in mind of a project that I was involved in a couple of years ago, where I was doing the user requirements and functional specifications for a BPM system (a typical role for me on a project). A large SI was also heavily involved in the project for some mainframe integration portions, and when I said that I’d be doing process maps as part of my work, a project manager from the SI immediately jumped on me about notation, asking what notation that I’d be using, and listing off everything from UML activity diagrams to use cases to more exotic modelling techniques usually associated with software design rather than communicating ideas with business people. I said that I’d be doing a simple flowchart notation in order to make it more understandable to the business people, and she looked at me like I had just grown a second head (I get that look a lot). To her, modelling was part of the dark arts that were intended to be used and understood only by the technical wizards, and she never really came close to understanding why I would want to create high-level diagrams that fit on one or two pages, and are intended to be understood by all the stakeholders.

Whether you use HIM, BPMN or any other notation, there’s a key lesson in all this: the business people don’t care about multi-page, overly-detailed view of the process. You need to create the high-level views for communicating with all stakeholders, then drill down to the lower levels during detailed design and implementation as required.

If you’re interested in more information on HIM, there’s a good HIM info site (and a related product site) and an article by Peter Fingar. There’s also some information on linkages between HIM and Martin Ould’s RIVA methodology in Ould’s book. I’ve talked about BPMN many times before on this blog if you’re looking for more information and links on it.