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.

Choosing “same old same old” over “new and exciting”

I met with a friend today who works for a large bank (a former client of mine). That is, he used to work for the bank until his division, which provides institutional financial services through some pretty amazing application of technology, was spun off in a joint venture between the bank and an equally deep-pocketed European firm, in order to provide these services more effectively around the world. We spent much of our time talking about how exciting the new environment is: the head of the new joint venture is doing the whole rock-star/entrepreneur launch thing, with a fancy launch party for the staff, T-shirts and other swag, and various other bits of team-building and corporate culture enhancements. I know, for those of us who lived in technology through the boom, that doesn’t seem like much, but we’re talking about a bunch of conservative banking types here.

Being spun off as a new, smaller company, they can create systems and services in a much more agile way than when they were part of the bank, in part because they don’t need to conform to the bank’s corporate standards any more; from my experience there as a contract architect several days a week for about a year, I can vouch for the fact that these standards were sometimes oppressive since they didn’t account for the needs of this relatively small division.

As our conversation neared a close, I idly asked him if anyone had been spooked by the idea of working for a smaller, more agile company (there are a lot of veterans of 15+ years there), and was shocked to hear that several people had opted to move from this division back to the bank proper before the spin-off. A new company, backed by some very pockets? An agile business and technology environment unchained from irrelevent (to them) corporate IT standards? In other words, new and interesting work with no financial risk? I realize that I’m a bit of an outlier, having worked for only one company larger than 50 people since I graduated from university (and that chafed so bad that I had to leave after 18 months), but I have to ask, what were those people thinking?

Sometimes, being offline helps me focus

The past few days, I’ve been listening to Cory Doctorow’s Down and Out in the Magic Kingdom, as read by Mark “the Brooklyn Bluesman” Forman on his Getting a Leg Up blog. Forman’s not a great reader — or maybe I’m totally spoiled, having just listened to Stephen Fry read the last Harry Potter book — but at least this way I can load it up on my iPod and listen while I’m walking around town or on the subway. If you prefer the printed word, you can also download it in PDF from Doctorow’s site, where he makes some of his writings available for free under a Creative Commons licence.

I was walking and listening today, and heard a bit of prose that describes our current age as seen from the vantage point of people in the future who live with embedded hardware in their brain that provides constant access to their digital environment:

…living like the cavemen of the information age had, surrounded by dead trees and ticking clocks.

I was struck by the imagery that that phrase conjured up for me, of the old days when paper was still a significant budget item, and as a cavewoman of the information age I immediately rushed home and browsed the PDF version to get the full quote. The following line was even better:

Being offline helped me focus.

Oh yeah, I know that feeling. Someone please take away my RSS reader for a day or two?

My 10 geekiest moves so far this month

It’s not even mid-month, and I’ve been a total techno-geek. To wit:

  1. I hooked up my new video iPod to my TV so that I can play video podcasts on the big screen, without using a proprietary Apple cable.

  2. I installed Blackberry Messenger so that I can IM on my Blackberry. As if regular email, PIN messaging and SMS aren’t enough.

  3. I signed up to go to MashupCamp in California next month.

  4. My boyfriend found out that I’m going to California next month because he read it on my blog.

  5. I uttered the phrase “sometimes I think about going back to coding”.

  6. I installed the Firefox X-Ray extension so that I can see the html tags on a page without viewing the source code.

  7. I downloaded ubuntu.

  8. I moved almost all of my bookmarks into del.icio.us.

  9. I loaded Google Local for Mobile onto my Blackberry and I can’t stop grinning and showing people the map directions. Then, within two hours, I convinced three other people to load it on theirs, and gave two of them an in-person tutorial.

  10. I’ve spent the last hour browsing open source shopping cart solutions that I can customize for my wine-tasting club.

Maybe it’s something in the air for 2006?

Who will mash?

Further to my post about enterprise mashup yesterday, I’ve been thinking about who in the BPM space will jump on the enterprise mashup bandwagon first.

In my Making BPM Mean Business course, I discuss the history of BPM, and I’ve noticed that BPM vendors who started on the workflow side of the house typically expand their capabilities through OEM agreements and partnerships (the “United Nations” approach), whereas those who started on the EAI side typically expand by building functionality in-house or buying a small company outright and submerging it into their product (the “world domination” approach). That could be because the pretty UI stuff that is usually developed for the human-facing workflow functionality is perceived as the “personality” of the BPM product, and everyone needs to author their own personality, or at least be perceived as being its author. (Okay, for a comment about technology, that’s pretty philosophical.) There’s lots of exceptions to this, but I find that’s true in many cases.

Does that mean that the BPM vendors with a workflow heritage are more likely to embrace the mashup concepts than their descended-from-EAI competitors? While the old guard thinks it over, the “nouveau BPM” vendors (who are built on web services from the ground up) are probably already demoing the integration of Yahoo Maps with back-office transaction processing, and rewriting their marketing materials to include the word “mashup”.

By the way, I signed up for MashupCamp, so if you’re headed there in February, look me up.

Mashing up the enterprise

I’ve spent the past few days mulling over the differences between mashups and the more traditional integration that’s done with enterprise applications. My initial reaction? There’s a lot more similarities than differences: in both cases, a third party uses published application interfaces to create functionality that integrates the capabilities of two or more applications/services. I know, that’s a bit of a simplification, but how soon will it be before overly complex (and expensive) enterprise integrations start taking advantage of the lessons to be learned from the mashups of web services?

Obviously, I’m not the only one thinking about this: the ZDNet SaaS blog just posted about enterprise mashups, and what’s needed to make them a reality.

Makes me want to go to MashupCamp.

Gartner’s podcasting!

It’s the last company that I expected to be giving it away (for now), but Gartner is publishing podcasts as Gartner Voice. They cover a wide variety of topics so I won’t be listening to them all, but enough of them look interesting for me to add this to my iTunes feed. I also like that they’re short, 10-15 minutes each rather than the hour-long behemoths from other sites that I never find the time to listen to.

There’s an one on BPM as a business catalyst that has some comments on how an organization’s justification for BPM changes from cost savings to agility (both business and IT) as they implement more BPM projects, and also some insights on the coming market convergence.

I’ll also be checking out the one on articulating enterprise architecture in business terms.

Hooked on Analytics

BAM, BI, CEP, analytics: call it what you will. An article by Tom Davenport in HBR, Competing on Analytics (free!), discusses the value of shining a bright light on what’s happening in your business processes:

At a time when firms in many industries offer similar products and use comparable technologies, business processes are among the last remaining points of differentiation. And analytics competitors wring every last drop of value from those processes.

He makes the point that companies that become proficient at analyzing what’s happening with their business processes become the leaders in their field, like Capital One, Marriott and Amazon. These “analytics competitors” have top management buying in to the concept of analytics as a strategic differentiator, have multiple analytics initiatives going on, and are doing it at the enterprise rather than departmental level. I had a question sent to me via my Squidoo BPM lens recently about the BI/analytics marketplace in Toronto, and I had to admit that a lot of my local customers (and not-so-local ones) are still not seeing analytics as a strategic initiative, but are allowing it to languish in departmental applications where it provides ROI but (probably) not much strategic differentiation at an enterprise level. Read Tom’s full article for his full analysis of what the analytics competitors are doing right, and the difference that it’s making for them. He even pooh-poohs the use of the term “business intelligence” as being “the term IT people use for analytics and reporting processes and software”. Ouch!

The linked sub-article, You Know You Compete on Analytics When…, has a summary of the traits of a successful analytics competitor.

Business-driven EA

A thought-provoking post from Brenda Michelson on the Business-Driven Enteprise Architect, including some steps for the CIO to take in order to ensure EA success, such as:

Make Room at the Table for Architecture Leadership. The architecture leader must have a seat at the CIO’s table in IT leadership and business leadership settings. The architecture leader, particularly one with an architecture background, will listen and contribute to the discussions with an enterprise architecture perspective. Don’t filter his/her information through a leader with a non-architecture focus.