BPM in Action

On July 23, for my investment research work, I analyzed the Metastorm's S-1. I said I thought the company was incorrectly betting that enterprise architecture management (EAM), business process analysis (BPA) and business process management (BPM) would coalesce into a market. I didn't spend a lot of time defending my opinion because I also said it didn't matter what I thought because:

"Metastorm is trying to redefine the already redefined category BPM... Such a redefinition is a tough challenge for a small player in a market and the challenge is compounded by the fact that all the major software-market players offer products in all these categories; even if Metastorm were successful in broadening the definition, its competitors are the same; there is no marketing advantage..."

Later I saw an article in a new technical trends journal that crystallized my thinking about why I disagreed with the Metastorm premise.

Metastorm is depending on the combination of process-related functionality into a product that would be used by developers, architects, business analysts, and even end users such as budget analysts and production planners, an unlikely combination in my opinion. Combining functions that all types of end users need is a more likely scenario.

The article that caught my eye is in the newly re-launched PwC Technology Forecast. It predicts that a suite of software will emerge that combines business intelligence (BI), rules engines and BPM. That is the likely combination that will emerge in my opinion and it reminded me that in 2004 at IDC, Dan Vesset and I called it "intelligent process automation" (he being the BI guy and I being the business rules/BPM guy). The term apparently never caught on. I found about 1800 hits on Google, small potatoes when it comes to buzzwords but the concept is emerging pretty much as we predicted as the next wave in BPM.

In 2004, we said it wasn't all there yet because on the BI side there was a lack of event-based analytics and dynamic rules management, a lack of "self-learning" by the software because it did not track decisions and outcomes, and a lack of a process context. On the BPM side we saw the mirror image: a lack of data context (that is, data driving the process flow because BPM systems are traditionally and technically human-centric and exception based) and a lack of tight, hardened multi-enterprise process flows. BPM systems were not then taking advantage of all available underlying middleware technologies and were primarily only utilizing almost-10-year-old web server software capabilities, not much more powerful in many dimensions than the well-known Apache HTTP server.

This meant little to no tight connection to the canonical business flows, which are precursors of the application composites that are buried in every 'ERP system' or equivalent (what Michael Dortch has been calling the "Big Mashup"). Four years later, according to PwC:

"... with heroic effort, these applications can be stitched together to guide management and facilitate process enhancement."

PwC of course would like to be a hero for you but I also suspect the issues are still the same. Although convergence of BPM and BI cannot address all these shortcomings, it would clearly address the the lack of data context and improve the automation of canonical flows.

To understand the implications of some of these issues both in terms of the shortcomings of BPM and BI individually and what a full IPA solution might have, consider giving Dan a call at IDC.