process – Page 113

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.

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.

Complex Event Processing

A good intro article on complex event processing (CEP), subtitled “Bringing BPM into the real world”. The future of BAM.

Getting — and keeping — your BPM project on track

Derek Miers, who I had the pleasure of meeting at the BPMG conference in London last May, has a recent white paper on the Keys to BPM Project Success on BPTrends. Much of the paper is focussed on a repeatable BPM delivery methodology that is not fundamentally different from the delivery methodology for any IT project, but there are some key BPM-specific points to consider:

Step 5, “Form the BPM Project Team”, highlights the need for a process architect. Not an IT architect, more of business analyst or a hybrid business-systems analyst that will “provide the analytical rigor and techniques” and guide the business users and subject matter experts when identifying improvement opportunities.

Step 6, “Understand the Process”, discusses the need to model the as-is process as a baseline, but not get stuck with the notion that the new process is just the old process with some automated bits. This ties in with (the first) step 7, “Identify Breakthrough Opportunities”, which lists techniques for analyzing a process in order to achieve some degree of process innovation. I use Tom Davenport’s nine areas of process innovation (automational, informational, sequential, tracking, analytical, geographical, integrative, intellectual, disintermediating) as a framework for discussing this topic in my BPM course, and Derek’s list covers some of the same territory.

Overall, some good pointers and a lot of IT project common sense.

BPM Leaders?!

I know that I’m going crazy with posts today, but there seems to be so much interesting stuff out there after two weeks of dreck.

After my earlier post about BPM and SOA, I had to link to Bruce Silver’s article in Intelligent Enterprise called Sizing Up the BPM Leaders, wherein he quotes a survey that shows that more than 1,600 participants believe that IBM, Microsoft and Oracle are the leaders in BPM, in spite of the fact that they’re offering only agile development environments for their SOA middleware rather than true BPM; in fact, they’re missing most of the functionality that the analysts believe to be essential in order to even call your product “BPM”. His summary:

BPM is much more than Web services orchestration: It must also integrate business modeling, simulation, business rules, analytics and BAM. BPM connects business analysts and process owners more directly to IT solutions rather than leaving them as frustrated bystanders. BPM pureplay vendors have largely implemented this vision but aren’t getting the recognition for it. The blissfully ignorant big platform players are nevertheless perceived as BPM leaders.

Egad.

Hey, you’ve got SOA in my BPM! No, you’ve got BPM in my SOA!

BPTrends has a newly-published article by a new author, Mike Rosen, on BPM and SOA. He makes the distinction between BPM and SOA, then wraps up with why they’re so complementary:

Together, BPM and SOA provide a perfect combination for enterprise computing. BPM provides the higher-level abstraction for defining businesses processes, as well as other important capabilities of monitoring and managing those processes. Services provide the functions that support those processes. SOA provides the capabilities for services to be combined together and to support and create an agile, flexible enterprise. BPM without SOA is useful for building applications, but difficult to extend to the enterprise. SOA without BPM is useful for creating reusable and consistent services, but lacks the ability to turn those services into an agile, competitive enterprise.

In other words, SOA provides the design philosophy and enterprise context for building services, and BPM orchestrates those services. Two great tastes, together at last.

He also discusses the practice of creating relevant services based on the required functionality of the enterprise, rather than just putting lipstick on the pig by developing a pass-through wrapper around each legacy application. There’s a good diagram in the article (it’s a PDF, so I can’t link to it directly) showing the layers and linkages involved.

Changing business models = changing business processes

I read this post by Alex Osterwalder on the external forces that impact an organization’s business model — technological change, competitive forces, customer demand, social environment, and legal environment — which in turn has me thinking about how these business model changes impact business processes.

This is precisely why I look at issues of enterprise architecture and BPM together, even when a client has specifically engaged me for a BPM initiative. In a perfect world, the following occurs:

A business model changes based on internal or external factors
One or more business processes have to change to respond to the changing business model
The business processes are implemented using a BPMS
EA provides the linkages between the business model and the information systems (including the BPMS) so that the right changes can be made to the process in order to respond to the changing business model

Unfortunately, there’s a lot of roadblocks to establishing what I feel is a fairly obvious requirement for remaining competitive in the face of changing business models:

Impact analysis: many organizations don’t document their business models (by this, I mean their high-level company business models, not their departmental business processes and procedures), or don’t make adequate links from their “strategic planning” sessions to all the layers below that have to implement those models and plans. Because of this, there is no clear link between the change to a business model, the change to an underlying business process, and the change to the supporting information systems.
Automation: many organizations are still using manual processes and decision-making for well-understood business processes. For example, some insurance companies process all of their claims manually; others have greatly improved productivity by using automated adjudication systems that pass only the more complex claims to a human claims adjudicator. Although the former may understand that a BPMS can help their business, they see it primarily as a way of paving the cowpaths so as to provide faster movement of information between the same old human decision-making processes, rather than a tool for automating some of the steps and — with the addition of business rules — removing some of the human decision-making.
Agility: some organizations that implement a BPMS end up with automated business processes that are frozen in time due to an excessive amount of customization around the implementation. Although they’ve achieved automation (albeit, optimized for a point in time usually about a year prior to implementation), they’ve completely lost agility due to the complexity of changing the BPMS by creating a legacy business process.

These issues, which I often uncover during a client assignment, require more than just a few tweaks to their BPMS: they require that both EA and business rules be brought into consideration in order to provide the business agility that the client is expecting.

To begin with, EA can help to create the necessary models and the linkages between the layers to allow the impact of a business model change to be reflected in the business processes and the supporting information systems. If you can’t do impact analysis, then you don’t have any type of reliable business agility since you won’t understand all of the impacts that a change to any part of the organization might have on other parts.

BRMS are an essential facilitator to business agility. First, because they put the business rules in the hands of the business (or at least in a form that’s understood by the business), so that there’s much less latency in the process of changing business rules. Secondly, if a shared repository of business rules is implemented across the organization, then a change to a business rule can be immediately be reflected in every process and system that accesses it, from the next call handled by a call centre operator accessing a CRM, to work in progress in a BPMS.

Of course, I see BPMS as a given for business agility: it lets you automate business processes while still involving human intelligence at the points required in the process; integrate business rules for decision-making; and more easily make changes to the business process with less user retraining. There are good and bad ways to implement a BPMS (as with any system), and care must be taken to integrate other tools (such as BRMS or BI) where appropriate, rather than go down the path of excessive customization which can hinder agility.

The bottom line is that although a BPMS can be a huge contributor to business agility, it can’t do it alone: you need some amount of EA in order to understand what you’re supposed to be doing with that BPMS (that’s the business-IT alignment that everyone talks about), and you need some other tools like BRMS to keep things agile through a minimum of customization.

Integration Trends 2006 webinar

Catching up on a few webinars that I missed live, I just reviewed the replay of ebizQ’s Integration Trends 2006. There’s a nice summary slide up front by David Kelly, an ebizQ analyst, where he talks about the current focus of most businesses (reducing costs, increasing flexibilty, becoming process-driven) and most IT departments (composite applications, modernizing legacy systems, moving to SOA and event-driven architecture). Certainly true for all of my customers.

The webinar was sponsored by PolarLake, makers of an ESB product, and it turns out that the CEO, Ronan Bradley, has a blog that includes some interesting stuff, such as his recent post that “exposes the myth” of run-time discovery of web services (he quotes and comments on a post on the same subject by Brenda Michelson). Alas, I’m unlikely to read his blog much since he chooses not to publish full feeds, and I find it too much of a hassle to click through to every blog on my list of daily reads.

Anyway, back in the webinar, Ronan Bradley made a huge point about how ESB is not EAI, but I’m not sure that the lines are that clearly drawn. David Kelly later asked how he made that distinction, and it seems to be based on attributes such as “distributed, standards-based, extensible” and providing “productivity and agility”, but I don’t think that the lines are that clearly drawn between ESB and EAI: it’s more of a spectrum of capabilities than the black-and-white picture that Ronan puts forward. He depicts EAI as having functionality without these attributes, “lightweight ESB” as having the attributes but little functionality, and (of course) PolarLake as having both the functionality and the attributes.

Of course, what vendor doesn’t find a graph to publish where they’re in the upper-right quadrant? Gartner probably just calls it all integration-focused BPM anyway.

Regardless of any distinction between EAI and ESB, he does make an interesting point about how orchestration isn’t so simple as it is often portrayed, but requires “mediation” around the orchestration that may be many times larger and more complex than the orchestration itself: things such as complex data manipulation and translation beyond simple XSLT transformation, interaction with existing infrastructure and applications, and complex and recursive data transformation, enrichment and management.

Squidoo BPM portal

I grabbed an invitation a few months back to participate in the beta for Squidoo, the latest Seth Godin project. I haven’t had much time to do anything with it, but a few things prompted me to go back and fiddle with the BPM “lens” (portal) that I created on Squidoo: first, there was an email that came out from some anonymous prat on the Squidoo beta team that threatened to nuke my lens if I didn’t do something with it, which was promptly retracted in a second email from Seth himself — that at least had me think about it again (which may have been the carefully crafted intent…hmmm). Second, I was playing around with moving my bookmarks into del.icio.us, and after adding a number of BPM-related links to my list, I linked through to other people’s lists with the same links to see what else that they had of interest and found that David Ogren’s list had a link to my Squidoo BPM lens on his list. Yikes! There’s nothing that kicks me into action faster than having someone watching me.

I’m not sure what direction that I’m taking it in, but for now, my BPM lens is a variety of information related to BPM that I use as a reference, and may be of use to you as well. Click here to check it out; I’ve organized the following modules so far:

An RSS feed of all blog posts with the Technorati tag “BPM”. I check this daily, since the explicit tagging means that it filters out all of the music and prenatal references where bpm=beats per minute, hence much more valuable than a regular automated search.
An RSS feed of this blog. In general, I likely won’t put other blog feeds on the lens since I link to them on my blogroll.
A set of links to BPM standards-related sites.
A set of links to BPM informational and reference sites.
A list of BPM and re-engineering books on Amazon, most of which are in my personal library. I’ll try to add more descriptive information about the books in the future.

If you’d like to suggest something to add to it, just drop a comment or email.