sandy

We need a BPM camp

I received yet another email about the upcoming Gartner BPM Summit, and I continue to be horrified by the price of conferences: U$1,895 for 3 days?! Or how about the AIIM records management conference in Toronto next week: C$2,899 for 3 days? By the time you add in travel and living, it’s no mean chunk of change when you’re an independent: I don’t have the luxury of a big company picking up my tab. Even those of you working for larger companies know that it’s not easy to find funding for attending conferences, even if you believe that they’ll be of value.

I know that analysts are in the business of making money from knowledge (so am I), but knowledge is becoming a commodity these days, and a lot of people won’t (or can’t) shell out that much cash just to sit in a room for three days and hear someone talk when the same information is available (albeit in a less structured manner) in a variety of other forms at a much lower cost: blogs, podcasts, vendor seminars, webinars, analyst reports and other sources that don’t believe that it’s in their best interests to charge everyone an arm and a leg just to have a conversation.

I only attend these big-money conferences once every few years; in the interim, I do just fine with my RSS feeds, daily email newsletters, webinars, vendor seminars, and other sources of free or reasonably-priced information. For example, in the past year, I’ve attended two major conferences: BPM 2005 in London, where I paid full price as an attendee, and FileNet’s user conference in Las Vegas, where I was a speaker so had my conference fee waived (check out the series of entries in my November archive, where I was blogging live from the conference sessions by emailing from my Blackberry). I also attended some local seminars/mini-conferences at little or no cost, such as e-Content Institute, plus some vendor seminars; in fact, I spent yesterday morning at a LabOne seminar hearing about how their next generation of products is going to better integrate into my insurance clients’ systems.

I attended a ton of webinars last year, most from ebizQ and BPMinstitute.org, but also from vendors such as Global 360 and Proforma (search my archives for “webinar” to see my comments on the webinars). I have a list of past webinars that I want to watch but haven’t found time yet: a wealth of information delivered to my desk, for free, with a relatively modest amount of vendor promotional material wrapped around it.

There is something to be said about a conference atmosphere, however. As much as I dislike most professional networking (I’m a closet introvert), conferences provide a great opportunity to meet people with the same interests: for me, that includes potential clients, but also vendors, potential partners, industry analysts and a variety of other types. Most conferences also include some sort of vendor showcase where I can have a peek at the latest and greatest technology.

The dilemma is this, then: given that much of the “information” (content) of the big conferences is available in the public domain or through lower-cost alternatives, how do we share that information in a conference-like networking atmosphere?

The answer may lie in the new generation of “un-conferences” or “camps”. These still exist mostly as technical conferences, but with the focus on collaboration rather than presentations (i.e., have a conversation guided by an actual practioner rather than death-by-Powerpoint from a hired speaker), limited enrolment, and free (or nearly so) fees for attending, this movement has the potential to expand into other traditional conference areas. One popular technical camp is BarCamp, including the recent TorCamp. David Crow, the prime organizer of TorCamp (and my neighbour), just posted about the camp format for un-conferences, and links to Chris Heuer with more about these sort of amateur conferences. A camp with a specific focus on integration is Mashup Camp next month in San Jose, which I’ll be attending because I want to explore how to use mashup concepts in the context of enterprise application integration: this is the part of the future of orchestration. And the expected “conference fee”? $0.

Camps are still, for the most part, for techno-geeks (I admit it, I am a geek). But how long before this “amateur” format hits the mainstream? How long before Gartner’s BPM summit is competing with BPMcamp?

Selecting a BPMS without falling into the chasm

This week’s BPTrends Advisor newsletter discusses the “crossing the chasm” paradigm when it comes to BPM, and highlights a current issue with BPM within organizations that still leaves us in the “early adopter” (i.e., pre-chasm) phase:

Most companies talk about processes these days, but few are willing to make a comprehensive, top-down commitment… [T]hey see business process management as a means of curing specific problems or of making specific, incremental improvements. Most companies don’t see process as a management philosophy and a way to organize the company.

I see a lot of that happening with companies that I work with: BPM is typically selected, purchased and customized for a departmental project, and when it comes time to look at other applications, it’s like starting all over again since no one considered the enterprise requirements from the beginning. Sadly, one exception that I saw to that was an organization that selected an integration broker suite as their BPM “standard” after looking at only the EAI-type process requirements across the organization, with the type of results that you might expect. There’s some fairly well-accepted criteria for selecting a BPMS these days; Gartner recently published a report on them that’s worth reading if you’re in the marketplace.

I don’t think that every acquisition should be held up in order to perform a full enterprise-wide needs analysis, but for a technology that is becoming as pervasive as BPM, you should at least be looking beyond that first project. You wouldn’t buy an RDBMS without considering enterprise-wide needs; we need to start thinking about BPMS in the same way, or we’ll never get across this chasm.

SOAinstitute launched

BPMinstitute.org, a free BPM informational site, has just launced SOAinstitute.org. If you’re already a BPMinstitute.org member, you just need to login and add it to your profile. There’s quite a bit of content there already, likely moved over from the BPMinstitute.org site, and it has the identical format to BPMinstitute.org (e.g., webinars are listed as “round tables”).

Blogs just a fad?

As you can tell by the multiple postings, I’m catching up on email newsletters and RSS feeds that have gone neglected for the past few days. This one caught my eye: in the same email from ebizQ that announced my blog joining this site, they preface the link to an AMR Research report with “wikis and blogs may seem hokey and faddish”.

To be fair, it’s a direct quote from the article, but I’m ROTFL, as we say in the blogosphere.

Integration FUD factor

A good article in DMReview (where normally I find much more about data warehousing and business intelligence than integration) on Fear, Uncertainty and Doubt about integration, especially for small-to-medium sized businesses that don’t have IT budgets that look like the GDP of a small Pacific nation. I just love it when someone cuts through all the crap:

Integration is moving data elements from point A to point B with the necessary translation in between…Tier-one integration vendors have conditioned the market to believe that integration should cost millions of dollars and take years to implement. With today’s offerings, this is simply no longer the case.

Couldn’t have said it better myself.

Chief Process Officer revisited

A while back, I read a post by Phil Gilbert (CTO of Lombardi) on his blog about the position of Chief Process Officer. Although he joked (I think) that the term sounds somewhat Orwellian, he rightly points out in this increasing complex world, the process is becoming the business, and that every business needs someone — the CPO — to focus on making this transition to a process-based organization.

About a week ago, I saw this CSC white paper From CIO to CPO via BPM by Howard Smith (co-author of BPM – The Third Wave with Peter Fingar), which opens with:

The prediciton that the CIO’s job will evolve into managing business processes — not just technology — is not new. What is new is the state of process technology. It has reached a point where it is about to go mainstream.

(Note that normally I don’t bother to quote from PDF files that have such an overabundance of DRM wrapped around them that they disallow copying text, and force me to retype a few sentences to reference, since I know that they’re not all about sharing the information anyway. Even Gartner doesn’t do that.)

It’s a rather thinly-veiled CSC promotional piece, and a bit academic and long, but there are some interesting points. First, he makes the point that BPM can fit in a lot of places. He uses an ERP orchestration example, which is really just a subset of the entire SOA/orchestration integration picture that BPM helps to pull together. I believe that too many organizations still think locally when they’re buying BPM initially, and end up with departmental systems that don’t have the legs for the enterprise needs; Smith talks about some situations where BPM can replace ERP (which even I think is a bit radical).

He has a great sidebar called “Distortion of BPM by the IT Industry” (page 24) that I completely agree with, about how any vendor who had anything to do with process suddenly relabeled themselves as BPM. I teach a seminar on BPM called Making BPM Mean Business, and I spend what must seem like an inordinate amount of time on this exact subject, looking at how all of these disparate technologies came to be called by the same name.

Ultimately, Smith’s white paper says almost nothing about the role of a CPO. Is this a new role for the CIO? Or, as some others believe, is this a business-based role (rather than a technology-based role) that works in tandem with the CIO to effect process change across the organization? Or something that lies in between IT and business, much like the postion for the enterprise architect that I discussed back in this post? Organizations have been using this title internally now for a few years, and I’m sure that it will take a few more for there to be any sort of agreement on what a CPO really is, and does.

Business Process Modelling for Dummies

I blogged last week about Human Interaction Management as a process modelling notation, along with some dissenting opinions that favour BPMN for process modelling. I tend towards the BPMN camp, and don’t see any benefit in using different modelling notations for some artifical divisions between “human” or “system” processes, considering that the goal of most BPM implementations is to convert some of the human processes into system processes in order to gain efficiency.

One of the biggest problems with any process modelling notation is that the techies (and, having a very techie background, I sometimes fall prey to this myself) tend to put too much detail in the models that are used to gain consensus among all stakeholders: once a model gets past a page or two, anyone who isn’t intimately involved with the modelling efforts won’t understand it — not because they’re not capable of understanding it, but because they don’t want to spend the time tracing through pages of stuff that has way more detail than they really need to know.

In a recent article on Keeping BPM Simple for Business Users, Michael Havey discusses the inherent problem of comprehensive notations such as BPMN or UML activity diagrams: the business users don’t understand them. Well, they get the gist of them, but don’t understand many of the finer points of the notation, which means that much discussion of the business processes during requirements gathering and functional design ends up being about the notation rather than the business processes that are being modelled. He proposes a “dumbed down” notation of just boxes and arrows, but I think that by modelling processes at a higher level for general communication with the business users, they can understand the notation: I think that the bigger problem is too much complexity in the diagrams — such as trying to present business users with sufficient BPMN detail to map directly to executable BPEL code — not an overly complex notation.

There’s been a significant focus on process modelling notations in the past few months, both as an adjunct to a BPM initiative, and as a way of modelling non-automated processes as part of a Lean or Six Sigma process improvement initiative. As process becomes a key competitive differentiator for more and more businesses, that interest will only increase.

Blog agility

I’ve been invited to move this blog over to ebizQ, where I’ll join David Linthicum and a few other integration-minded bloggers. No, I’m not selling out — I don’t get paid for blogging, and ebizQ has no control over my content — it’s just a symbiotic relationship where we both (hopefully) benefit from greater exposure. I’ll keep this location available since my previous posts won’t be moving over.

I’ll be redirecting my FeedBurner feed, so for those of you who subscribe to that feed, the change should be transparent. If you visit my blog directly instead of through a feed, or if you use the Atom feed, you can link to my Column 2 domain which will redirect you to my blog’s new home to get reconnected. Thanks to the internet services director at ebizQ, most everything on this blog will move from this Blogger template over to that Movable Type template, including my blogroll, links to the Column 2 Frappr map and my Squidoo BPM lens, and my Technorati search form and profile link (if you visit my Technorati profile, you’ll see this blog as “Column 2”, and the new blog as “Column 2 – ebizQ”). All of my other non-blog links are already on my del.icio.us BPM links, the links page on my corporate website or Squidoo.

Please be patient over the next few days while we get any last wrinkles ironed out.

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?