Category: process

business process management

BPM: a moving target

I’m prepping for the 2-day Making BPM Mean Business course that I’ll be delivering this weekend in Las Vegas, and it’s giving me a chance for a complete end-to-end review of a lot of material that I’ve been gathering, thinking about, presenting and rewriting over the past several months. One thing that immediately strikes me is the constant state of change: since I sent these materials for printing three weeks ago, there’s new things that I just have to include. The BPEL for People initiative (IBM-SAP white paper here), for example, which is a critical step to having BPMS products use BPEL more extensively. The ongoing effects of the OMG-BPMI merger. New versions of Enterprise Architecture modelling tools such as ProVision, since I position BPM in an EA context in this course.

There’s also a lot of wisdom that I’ve gathered over time that it will be fun to discuss with the course participants: how to do a business walkthrough, analyzing and designing business processes, and ROI calculations for BPM.

I spent this morning sitting in a local café (a good place to get away from all distractions except the Crackberry, which I am unable to detach from my psyche), putting the final touches on the workshop exercises that I’ll be having the participants do during the course. It’s a small class which should result in a lot of interaction amongst the attendees, and since they’re all from different companies, I’ve decided to do individual projects rather than group projects so that they actually have something usable to take home about their own business processes at the end of the two days. It’s sort of like speed-consulting for me, which should be fun all around.

I’m all a-quiver with anticipation.

Neural nets in BPM?

Just saw this article in eWeek about Fuego releasing neural net capabilities in their BPM product.

Neural Network works through a decision activity capability that lets users define a set of variables that can be analyzed for process improvement…Neural Network takes that set of variables and builds a learning activity set that can monitor decisions and suggest behavior to improve the process.

I haven’t heard the term “neural net” much since my days in graduate school when I was slogging through a thesis on pattern recognition; it usually refers to a hardware implementation consisting of a massively-parallel network of simple processors (modelled on the human brain and its highly-connected network of neurons): think grid computing on a very tiny scale. Because these terms are not widely understood, there’s a long history of misuse: in fact, the first company that I worked for after university had the word “perceptron” (a type of neural net) in its name, although we wrote pattern recognition and scientific image analysis software, with nary a neural net in sight.

That being said, I’m assuming that what Fuego is calling “Neural Network” is actually artificial intelligence (AI) or cognitive modelling, although I can understand why the marketing types would avoid the overused “AI”, with its shades of science fiction, and positively run screaming from the overly-geeky “cognitive”. The problem with introducing a functionality that is barely understood in the marketplace (besides having to explain it to your own marketing people) is that the customers have no clue what to do with it, and probably not much time to spend doing the out-of-the-box thinking required to come up with some real business scenarios that have the potential for ROI. If you keep reading the article, you’ll see that the VP of process management at an existing Fuego customer considered “the Neural Network technology” to be “intriguing but not essential”. See the problem? It’s still “technology” in the minds of that customer, not a solution to a business problem.

I think that AI has a great future in BPM, but it’s still very early in the hype cycle. As a natural extension to business activity monitoring (BAM), pushing it into the milieu of semi-automated corporate performance management (CPM), it’s going to be the next “must-do” on BPM vendors’ product plans.

By the way, I wrote this post on my tablet PC (in tablet mode) — the handwriting recognition is really good, although a bit slower than my typing. I would like copy-cut-paste soft keys on the handwriting input panel, however: I had to keep switching from handwriting mode to keyboard mode in order to use Ctrl+C, Ctrl+X and Ctrl+V.

BPM unplugged

I loved Ethan’s podcast (and post) on The Vision Thing on Friday, which included the wise advice:

You don’t need computers to implement a Business Process Management (BPM) strategy.

I’m in the process of finalizing a 2-day seminar on BPM called “Making BPM Mean Business“, which I’ll be presenting for the first time at FileNet’s user conference in November. The most common question that I get about the course: “Is it is a hands-on course?”, and the second-most common, which usually immediately follows that one: “Will you be doing a [software] demonstration?” The answer to both is no, but a lot of people find it hard to believe that there is two days worth of material on BPM that doesn’t require using a computer. In actual fact, there is probably about 100 graduate degrees worth of material to talk about BPM that would never involved turning on a computer, but there always seems to be a rush to buy some hardware and software and implement something — anything — before the larger context is even considered.

It’s a bit ironic (considering that this is being held at a FileNet user conference) that I’ll be spending the first day of the seminar talking about everything except FileNet: enterprise architecture, business intelligence, corporate performance management, quality management, business process outsourcing, BPM standards and the entire process of process modelling. No computers; just ideas and discussion. After all, if you don’t understand the context for BPM in your organizations, and the processes that are eventually to be automated, you’re not ready to put your hands on a computer yet.

User-driven design

Kathy Sierra recently posted the following helpful hint on Creating Passionate Users:

Seriously, though, she goes on to say:

Most of us realize that focus groups are notoriously ineffective for many things, but we still assume that listening to real feedback from real users is the best way to drive new products and services, as well as improve on what we have. But there’s a huge problem with that — people don’t necessarily know how to ask for something they’ve never conceived of! Most people make suggestions based entirely around incremental improvements, looking at what exists and thinking about how it could be better. But that’s quite different from having a vision for something profoundly new.

This isn’t a new idea (that users themselves are typically not going to come up with breakthrough innovations), but one that we need to constantly keep in mind. When I’m designing a system, I make a deal with the users who are involved in focus groups, JADs and other interviews: they tell me what they need to accomplish to meet their business goals, and I’ll design the best way to do it. In other words, I’ll treat them as the business subject matter experts, and they’ll treat me as the design expert.

There’s a constant struggle with users who insist on specific features (e.g., “the button has to be blue”, when I’m trying to create something that doesn’t even need a button) because they don’t have the perspective to spontaneously visualize the future that is possible for them. Designing BPM systems is particularly problematic, since manual business processes are part of the folklore of an organization, and changing them causes some amount of cultural disruption. Having users involved in the design process is necessary, but it’s also necessary not to be unduly influenced by protests of “but we’ve always done it this way”.

Strangely enough, I was on Amazon yesterday and under “My Recommendations” it came up with Flatland, a short book of fiction about geometry, published in 1880, that I haven’t read since I was in university:

Flatland…imagines a two-dimensional world inhabited by sentient geometric shapes who think their planar world is all there is. But one Flatlander, a Square, discovers the existence of a third dimension and the limits of his world’s assumptions about reality and comes to understand the confusing problem of higher dimensions.

As a designer, sometimes I just have to think like a Square in a Flatland.

Bits and pieces

I’m heads-down on a project this week so not much time for catching up on the news and blogging. However, interesting things keep happening whether I’m watching or not…

  • RUNA WFE 1.0.1, an open-source workflow based on JBOSS-JBPM was released. More details here, including a link to an online demo. Open source BPM is going to be a market force in some sectors, so best to be aware of what’s happening there.
  • Greg Wdowiak published an interesting post on the role of integration brokers within an integration stack. In particular, he discusses what you should expect to get from the integration broker portion of the stack, and where some of the vendors are lacking. If you’re new to EAI, you can read his excellent background post on bus versus broker models. In particular, he talks about how organizations move from a broker to a bus model as their integration needs become larger and more complex.
  • BEA buying Plumtree has been all over the tech news, with lots of interesting analysis. MWD blog thinks that the purchase may not be about what BEA says that it’s about, but more about moving away from complete Java-centricity and into a more neutral technology territory by supporting .Net. The Butler Group sees this as a better fit than some of the previous portal buy-outs, although an earlier post ponders the fate of the Plumtree-Fuego OEM agreement in light of BEA’s existing BPM strategy.
  • On the enterprise architecture front, The first issue of the Journal of Enterprise Architecture was published. Via Nick Mudge’s blog.

Lastly, if you’re free today at noon Eastern, there’s a webinar roundtable on Winning at BPM discussing IBM‘s WebSphere process integration products.

Enjoy.

BPM soft skills

I saw this Gartner article a while back about a “new” BPM definition, and was reminded of it when it hit BPM.com again this week. He turns the focus from the hard technical skills required for BPM to the soft social skills required: much as I have done in my own career over the past 15 years or so: putting the “business” and “management” back in BPM, which has too long been focused on the mechanical “process” part. It’s not by accident that the small systems integration company that I owned in the late 90’s had the slogan “We Make Technology Mean Business”, and that I’m now developing a course called “Making BPM Mean Business“.

In that same vein, Gartner has recreated their definition of BPM to move the focus away from the tools and the mechanics of BPM:

BPM is a management practice that provides for governance of a business’s process environment toward the goal of improving agility and operational performance. BPM is a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization’s activities and processes.

Right on!

Convergence of BPM and BI

If you’re interested in more about the Forrester report about BPM and BI that I mentioned a couple of weeks ago, but still don’t want to shell out the cash for it, you can find a more complete summary on here on BPM.com (registration required), written by a Forrester VP who was one of the original report authors.

The more that I look at compliance, which I’ve been doing a lot of lately, the more that I understand that BPM needs to feed its performance data into a larger BI infrastructure. And I can buy into what the Forrester report refers to as Process to Data, or P2D (as if we needed another TLA), which is the two-way synergy between BPM and BI: BPM feeds process performance data to BI, and BI invokes processes in BPM in order to gather information. However, I have to draw the line at their statement:

BI and BPM can no longer live without each other, and the time is right for these technologies to merge.

I don’t think so, any more than BPM will merge with any number of other technologies, although obviously there will be closer and closer integration ties in order to make all of this work smoothly. BPM and BI are strong, distinct markets served by a variety of strong vendors, and customers develop quite a bit of loyalty to their BPM and BI vendors because both of these technologies are pervasive in an organization’s IT infrastructure. If BPM vendor A decides to merge with BI vendor B and suggests to their customer that they should change all of their existing BI from vendor C to vendor B, there would be a great deal of rolling around on the floor and laughing. There’s a much stronger argument to be had for merging BPM and BR (business rules), but I don’t think that’s going to happen either, for much the same reasons: both technologies have strong, independent markets (that is, the technologies can exist successfully in organizations without each other) and there is little reason for a customer to want to buy their corporate-wide BR from their BPM vendor, or vice versa.

If the merging that Forrester suggets actually occurs, we’ll end up with monolithic Swiss-Army-knife-like vendor offerings from a few large players — how retro! — and a lot of unhappy customers. What most customers want is the best of both worlds: the best-of-breed technology, and the minimum amount of integration; hence the huge popularity of SOA. In the past, you couldn’t get both: you could buy best-of-breed from different vendors and take a lot of effort to integrate it, or you could buy a fully-integrated suite from a single vendor that included at least one sub-optimal component. Today, however, with the advent of integration standards and SOA, the integration effort for properly-constructed products from different vendors should be no more than that required for products from the same vendor.

My conclusion: as long as the vendors do what they’re supposed to in order to enable easy integration, there’s very few customer drivers for merging BI and BPM.

Agility and BPMS Architecture

Bruce Silver writes about the distinction between workflow architecture and service orchestration architecture, pointing out why it’s important to distinguish between these two process architectures and see how they fit together. If you’re having trouble figuring out the difference between what the former workflow and former EAI vendors are saying, this might help.

He also discusses what’s changed in BPMS to actually make it as agile as the vendors would have you believe that it’s been all along: easier application integration. As he puts in, in the bad old days, when the EAI part of workflow systems didn’t work very well:

If you went to a workflow conference or trade show, any vendor could show you how to build a workflow in 30 minutes using no programming, just graphical drag-and-drop design. So once you bought the technology, why did it take six to twelve months to design and deploy real-world workflows?

There was a huge market for systems integration companies to do all that tricky application integration stuff — I know, because I ran a 40-person version of that model up until 2000, with a crack team that did design, development, testing, documentation, training and installation, all targeted at trying to turn the dream that the workflow vendors sold into a reality. If I hadn’t already got out of that business, I’d certainly be looking to do so now, as the EAI part of BPM gets easier and easier, leaving much less of the complex systems integration that used to drive a huge part of the market.

What I find amazing is that some of the large systems integrators continue to stick their heads in the sand and refuse to buy into the new way of doing things. Even though capabilities exist for much simpler (and therefore faster and less expensive) integration of BPMS with other technologies, the SIs have too much of a vested interest in selling huge pieces of custom code that they’ve written to augment previous versions of various vendor products, and the associated 1000’s of hours of customization that they can sell to the unsuspecting customer. They actually win work based on the premise that if it takes that long and costs that much, it must be good.

Back to the Silver article that started this thought, I also find it amazing when vendors (and therefore, by extension, their clients) don’t make the distinction between the two types of process architectures, and try to sell their legacy technology (usually either workflow or EAI) as if it spanned the entire space. Since most former workflow vendors have hopped on the EAI bandwagon by buying in that capability early, I see the problem more often with the former EAI vendors trying to sell service orchestration as if it were workflow, with only the barest of long-running process and human-facing capabilities. I remember leading a discussion on exactly this topic with a client’s IT group who had selected an EAI product as their BPM corporate standard, and never being able to get through to them that there are really two major classes of process functionality and architectures, only one of which was addressed by the product that they selected. Silver’s article may have helped.

BPM course at FileNet user conference

If you want to spend two days learning how to “Make BPM Mean Business“, I’m leading a seminar as part of the pre-conference training at FileNet’s user conference in Las Vegas in November. I’ve tried to strip out all the technical stuff (which FileNet can teach you better than I can anyway), so this is really targeted at business managers, business analysts and process designers.

Sign up through FileNet if you want to do this in Vegas prior to the conference, but if you can’t make it to the conference, I own the course content and can do a private gig elsewhere, preferably somewhere warm and exotic as winter descends on Toronto. The first day (“BPM in Business” and “Modeling Your Processes”) is not specific to any vendor’s products and would be suitable even if you’re not a FileNet customer.