Processes “R” Us

I had several appointments and errands today, and I listened to podcasts as I walked around downtown Toronto. One of them was the Sound of Vision podcast from back in May wherein Ethan Johnson interviews me about BPM (starting at 21:00 in the ‘cast), and there’s one point where I get really passionate about the fact that everything is a process: my true evangelist colours shining through. I do have a very process-centric view of business, to the point where some work that I’ve been doing recently on compliance started out being about content and records management, and has shifted to have a very strong focus on process.

I also saw an article this afternoon by Terry Schurter of BPMG, and he states that BPM and a process-centric view are so popular because such a high percentage of BPMS implementations (compared to other enterprise software) deliver on their promise of ROI. His view is that taking a process-centric view — “the idea that businesses can be viewed as a series of processes, and that those processes can be identified and managed to improve quality, efficiency, and cost-effectiveness” — resonates with end-user organizations, vendors and analysts, and that BPM aligns with the natural business structure.

It seems that you can’t pick up a business or technology article these days without it containing some reference to process, which means that Terry and I are not alone in our views.

More open source BPM

An infrequently-updated but informative blog on open source BPM:

We share our discoveries in our search for open source workflow management tools. For tools that we find interesting, we download the code, try to execute the engine, or even get our reference process model working.

Also includes a list of open source BPM tools, including their evaluation notes where applicable.

Note that these are the only two sections of the site in English; for the rest, you’d better brush up on your Dutch (or use AltaVista’s Babel Fish translation utility, since Google’s translation doesn’t support Dutch).

BPM templates

I tuned in to a Global 360 webinar today for long enough to hear Nathanial Palmer from Delphi speak about process templates and their importance in BPM (you should be able to find a replay of the webinar here in a few days). He revealed some very telling numbers, soon to be officially released, from a recent survey of over 100 active BPM project participants:

  • 98% agreed that pre-defined templates accelerate BPM deployments. 73% answered definitely “yes”, while the other 25% said “maybe”, and only for simple or standardized processes. I’m curious to know what the 2% “no” contingent was thinking, since it’s hard to imagine anyone not seeming some potential value in a pre-defined solution template.
  • Although few people expect templates to be an application rather than a project jump-start, 70% expect them to be a fairly complete framework with screens, rules, integration adapters and the like. In other words, the respondants definitely expect the templates to be customizable, but they want to have a pretty high starting point.
  • 70% stated that they would be more likely to buy a software solution that had process templates specific to their industry, which seems obvious but is something that many vendors haven’t figured out yet.
  • 76% agreed that the templates should be documented in “business” language rather than being a tool for IT, and one of the key values stated for process templates was to align busines value with IT.

Not surprisingly, SOX compliance was at the top of the list of which processes should be templated, although the votes were pretty evenly spread over all of the business processes surveyed.

The value of vendor white papers

Every vendor writes white papers that try to appear vendor-neutral (in an effort to build their street cred), but which have subtle — or not-so-subtle — hidden agendas. That doesn’t mean that you shouldn’t read them, just don’t take them as the whole truth and nothing but the truth. The best approach is to read a variety of sources on a subject from both vendors’ white papers and “independent” analysts (who, of course, have their own agendas as well) and start looking at the common themes and messages across all of them. If a vendor doesn’t mention something that is considered important by several others, that could highlight a missing functionality or flaw in their system. However, when one vendor offers an opinion that is vastly different from all the others, then either they’re trying to justify a flaw, or they’ve really discovered a better way of doing things and are the first to flaunt it. Don’t discount the latter possibility out of hand, because a vendor is much more likely to be silent about their flaws rather than try to justify them, so if they’re talking about it in a white paper, then they may have something to say.

I read a lot of vendor white papers and analyst reports because it’s my job to stay on top of what’s happening in the BPM and related spaces, and it’s nice to run across one that I can recommend every once in a while. Last week, I saw this report from Metastorm published on TechRepublic (TechRepublic free registration required to view) about choosing a BPMS. It includes five very valid steps along the selection path:

  1. Consider the vendor’s core competence.
  2. Consider the vendor’s reputation and position in the market.
  3. Validate the essentials.
  4. Evaluate implementation & maintenance requirements.
  5. Ensure the solution can support your unique process needs.

and provides a checklist of activities as well as a description for each of these activities. In the first step, they take a direct shot at EAI vendors who have grown into the BPM space: a hidden agenda of sorts, since Metastorm built their product as BPM from the start, but one that I don’t necessarily disagree with:

Many of the solutions marketed for BPM today were not actually developed for BPM — for example, EAI may be great for data to data integration and automation of system flows, but because it was not developed to address human interaction, it is unlikely to be the ideal solution for human-intensive process management, where human involvement and decision making is key.

I’ve run into situations in the past where an EAI vendor has positioned themselves as BPM and made large (and inappropriate) sales because of it. At some point, however, an EAI vendor will presumabely have built sufficient BPM functionality and expertise to be allowed into the club. Furthermore, it’s fair to say that the line between EAI and BPM is sufficient vague that there will be many vendors who play in both arenas instead of being in one and interfacing to the other: check out my post last week on integration stacks as well as Gartner’s emerging view of what’s in a BPMS.

All in all, there’s very little in the Metastorm white paper that most other BPM vendors would disagree with. At only 2-1/2 pages of real content, it’s a somewhat superficial look at the vendor evaluation process, but a good starting point.

We needed the business for this?

Gartner recently issued a report entitled Business Process Management’s Success Hinges on Business-Led Initiatives, the abstract of which states “organizations that had the most-successful BPM initiatives spent more than 40 percent of the initial project time on process discovery.”

This is newsworthy? Hands up if you still thought that IT could implement BPM without a significant involvement by the business. Of course, there are a few IT departments that I know that definitely haven’t figured that out yet.

What’s in a name?

Just discovered mwd blog through their post about BPEL; they believe that the “business process” part of BPEL is a bit of a misnomer, and that “at the very best what vendors are really representing are definitions of integration processing.” I knew that I was in tune with these guys when I read their earlier post on ESB, which tears a strip off technical marketing types that invent new terms for existing concepts in order to attempt to achieve some sort of marketing advantage.

Their BPEL post also includes a link to a Bruce Silver article about BPM standards that’s definitely worth reading.

BPM standards, architecture and modeling

Thanks to David Ogren’s BPM Blog for a pointer to “What is Business Process Modeling?” Like one of the commenters on the article, I also disagree with Mike Havey’s use of the term “business process modeling” as being interchangeable with “business process management”, since modeling is typically seen as being the business-focused activity at the front end of BPM, not the entire range of activities. I also don’t make such a sharp distinction between BPM and EAI: they’re part of the same continuum of technologies, and it is common to include EAI as part of BPM functionality (or vice versa): certainly the former EAI vendors who have hopped on the BPM bandwagon would agree with me on this point. His vision of a BPM architecture is not well-grounded in the current reality of BPMS, starting with “the heart of the architecture is a runtime engine that executes processes whose source code is written in the XML-based BPEL language” (I wish) and continuing with “human participants view and execute pending manual work activities using a graphical worklist application” (not necessarily).

Other than those minor points, it’s a good look at how the current morass of overlapping and competing BPM standards fit together, and has a very clear view of how BPM components are used during the design, development, deployment and monitoring cycle. I’ve been blogging about BPM standards from the beginning, and am completely on side with anyone supporting standards over the continuation of proprietary fiefdoms of process modeling and execution.

Last, but not least, he shows some examples of and provides a reference to itp-commerce‘s Process Modeler for Microsoft Visio, which allows you to create BPMN process models and (in the professional edition) transfer them to BPEL for execution. itp-commerce’s site links to an article by Bruce Silver that reviews the product, but more importantly, talks about the use of BPMN in general, and the use of Visio as a business process modeling tool.

By the way, if you’re interested in some of the theory behind BPM, Mike Havey’s written an article on Pi Calculus and Petri nets.

Operational Innovation

I don’t normally read the Harvard Management Update, so I missed an article back in April by Michael Hammer on operational innovation; however, there’s an excerpt here. In the excerpt, he discusses six steps to operation innovation:

  • process focus
  • process owners
  • full-time design team
  • managerial engagement
  • building buy-in
  • bias for action

I consider the first of these, process focus, to be critical. As Dr. Hammer points out, most companies taking on a business process initiative for the first time start with a smaller departmental or non-critical process. If you think this through, it’s obvious that a number of other problems are going to arise if you’re introducing BPM on a small scale: non-dedicated team members, lack of high-level ownership, lack of buy-in, and a host of other problems that are addressed directly by his second through sixth steps. These latter steps are no different than what we have to address with any IT initiative, but in the case of BPM, you can’t do the remaining steps until you’ve addressed the first step: get a process focus in the organization, and create “an enterprise process model, which describes a business’s operations in terms of a small number of value-creating end-to-end processes”, including performance metrics.

In other words, if you’re not addressing the mission-critical processes and all the participants that define an organization’s ability to succeed, then your efforts have a much lesser chance of measurable (i.e., relevant) success. It doesn’t mean that you have to implement all of these processes on the first go-around, but you’d better be considering them in the scope of what you’re doing. Improving business processes is not about automating every process, it’s about identifying and improving the ones that are critical to the success of the organization: a philosophy that will be familiar to Six Sigma and other quality advocates.

BPM, BI and performance management

From a Forrester report published last week, “Business Process Management (BPM) Meets BI And Performance Management (xPM) Head On”:

Most business process management (BPM) vendors have integrated their products with business intelligence (BI) for analyzing historical process data; but BPM products should also integrate with BI to support decision-intensive business processes like order management, credit risk management, and sales opportunity management. The problem is that BPM vendors are not currently thinking about BI in this context. They are thinking about automating decision-intensive processes, but current performance management (xPM) products lack the capacity to define and execute business processes. The situation is about to change, however, as BI vendors begin partnering with BPM vendors or even OEMing BPM products. Within the next 12 to 18 months, this trend may even culminate in BI vendors acquiring BPM. As this unfolds, we will be on the brink of a Process to Data (P2D) explosion.

The requirement to integrate BPM data into BI and performance management systems is becoming obvious: I’ve touched on that in several posts in the past, including the integration of BPM with Six Sigma, BPM maturity levels, and the various posts on BPM and compliance that really drive home that BPM is just a part of a much bigger picture. This report talks about the other side of that: having BI and performance management systems launch processes in order to gather information required for decision making.

I’m not sure that I agree with their prediction of BI vendors acquiring BPM, since the ease of integration with many of the top BPM products now would mean that there would be little added value in a BI vendor wedding themselves to a single vendor. BPM in all its forms (including everything down through the integration stack) is a much too pervasive within the average large organization for a BI vendor to assume that they can foist their chosen BPM product on a customer that already likely has at least one other BPM product in use.