At Gartner’s BPM Summit last month in San Diego, everything went fine until the last Gartner analyst left a lasting impression at the last session of the last day. Simon Hayward, VP and Gartner Fellow, who helped kick off the BPM Summit, has the dubious honor of also sounding its death knell. His bombshell? The prediction that, to paraphrase, “By the year 2012, BPM will be subsumed into major applications.” I forget the exact probability he assigned to this scenario, but it was precisely between 0.7 and 0.8 (both inclusive).

Predictably (i.e., with probably 1.0), there was violent disagreement from the audience. Their cries of “No!” reverberated in the auditorium. There was applause for attendees who spoke in protest. I am sure there was concern among the participants about the discipline of BPM itself vanishing (and with it, boondoggles to sunny climes), and among the vendors on the implied demise of their own companies. If Simon’s intention was to end the conference on a vigorous and memorable note of controversy, he definitely succeeded.

Now, I can’t predict the future as accurately as Gartner. I don’t know if BPM functionality will indeed be subsumed under applications from the largest app vendors. What I do know is that if it does happen, it will happen only if one of the following conditions is met:

one, a major app vendor will take over all the applications and supply one huge ERP that covers all businesses end-to-end for all the companies (regardless of size) on the entire planet and the space station;

two, app vendors will package BPM-like functionality without truly understanding what it means, thereby fooling themselves and all of their customers all the time.

Your guess is as good as mine (or Gartner’s) on the likelihood of these scenarios happening.

Conceptually, though, suggesting that BPM functionality will reside in apps is like saying operating system algorithms will be subsumed by applications (i.e., that OS functionality like system resource management, job scheduling, load management, memory management, etc. will be built into each and every application). Talk to your app vendor and ask them if they’d be willing to develop OS functionality (as in Unix and Windows) directly into their apps. Also, ask them if they’d be willing to create their own database engine rather than connect to an existing, independent DB engine. How about their own reporting solution?

BPM is to business processes what the OS is to IT programs: BPM is a process operating system. Just as an OS provides a ‘system process space’ context for pieces of running code, BPM provides a ‘business process space’ context for applications. What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance (the analogy to the OS should be clear: an OS collects and displays system metrics, such as memory utilization, resource handles, CPU utilization etc.; for the design of applications, it provides an API to applications for accessing system level resources; it defines the system semantics through such APIs and through the use of semaphores, threads, handles, sockets, pipes, devices, etc.; it ‘responsibly’ manages the use of system resources to eliminate contention, resolve deadlock, terminate hanging processes, implement prioritized scheduling, etc.) Imagine an app vendor having to build this entire infrastructure (whether OS or BPM) into each application!

BPM provides the abstraction layer that is common to all applications that must function as responsible citizens in the corporate world, just as an OS provides an abstraction layer to all applications that must reside and play nicely together on a computer.

People attend BPM conferences because they see problems that are not (and cannot) be solved by their current stack of applications (CRM, ERP, G/L, etc.) These apps are in a terrible mess in their own right today because they are not designed according to SOA principles (some would question if they were designed in any way at all). App vendors have their work cut out in trying to fix application level problems. Why would anyone egg them on to take on functionality that is an order of magnitude more sophisticated and more abstract?

Let us hope that this is one Gartner prediction that will never come to pass.

Posted by kirankg in BPM | Permalink | Comments (1) | TrackBacks (0)

"Understanding Business Process Management & the 'People' Factor of Process Change"

This is the first of three e-seminars on business process management sponsored by Talisen Technologies. I have been invited to join Howard Webb (Principal, the BPM Group) in this first e-seminar to discuss the “people aspect” of BPM and how change leaders are enabled by BPM adoption. The next two sessions will feature a discussion of process and technology aspects of BPM.

Change management and people issues are a neglected aspect of BPM adoption. In the BPM Master Classes that webMethods conducts, I frequently quiz the audience on their change management practices. Most technologists don't realize the importance of this. They assume that the cool technology of the day will win the hearts and minds of the business folks. In reality, business executives are besieged by change: from customers, competitors, and economic conditions. Many of them are barely coping with it. Asking them to deal with another change—a pretty radical one at that—is rather risky without employing some change management techniques.

While Howard will cover how to get support for BPM and link it with other process improvement efforts, I'll focus on the implications on an organization of implementing BPM.

Register here to attend this webinar on March 16, 2007, at 10:00 am CST.

Posted by kirankg in BPM | Permalink | Comments (0) | TrackBacks (0)