We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anne Stuart’s BPM in Action

Dennis Byron

Is There a Need for the 'Lean BPM,' 'BPM Lite' or 'RBPM' Categories of Business Process Management?

Vote 0 Votes

In an ebizQ "Around the Web" post I put up on June 9, I mentioned the need for a business process management (BPM) taxonomy. Then, as part of my research on an upcoming ebizQ article on process discovery, I had an interesting discussion with Tim Zonca, Director of Product Marketing, of Serena.

I had said in my call for input to the article that:

"I am interpreting process discovery loosely as anything you are doing as a supplier or a user to simplify and streamline the development and deployment of BPM solutions."

Tim took me up on that statement and introduced me to an interesting program and product that Serena offers to support certain types of BPM solutions.

More on the discussion with Tim in the upcoming article but our conversation led me further down the BPM taxonomy road. Serena's Mashup Composer product/program applies to process discovery in the sense that there is a need for Rapid BPM (RBPM--to draft off the old term RAD for rapid applications development) or BPMLite (Tim did not like that term) or Lean BPM (which Tim credits to Clay Richardson of Forrester--whom I have met virutally through our being co-judges in the Global 360 competitive program in March 2009)

In Serena's case, Tim says this program/product applies best to collaborative apps which may be freestanding or front-end to more full-bodied case-management or STP BPM automated by another BPM supplier's software. As with the concept with RAD, he says many clients are telling Serena there's just a need to get something up there fast and inexpensively. Serena supports such development through a 2-day half-day-each workshop. It is part of the Serena pre-sales process and gets the right line and IT people in a room; maps out the need and implements it in Serena's free Mashup Composer. The app gets deployed on demand; and the interval to the second half-day session lets the client look at how the app works on real data. In the second half-day Serena returns and the conversation continues. With or without the workshop you can try Serena Mashup Composer-developed applications for 30 days.

I hear them called situational applications as well as mashups. What do you think? Is there a need for such BPM? Will it recreate the 1970s COBOL/RPG spaghetti-code problem or the 1990s VB problem?

-- Dennis Byron


| Leave a comment

The premise of BPM, situational or composite applications, call them what you will, is that they can be implemented far more quickly than traditional technologies and approaches.
The software supports capturing of requirements often directly into the tools as Pega, Serena and Corizon propose in their methodologies. While there is every need to get a prototype or indicative application in front of the client, I do not think providing a separate toolset is the way forward. The front end UI is often the easiest part to get right and iterate quickly, as we all know it is the integration and the business rules is where the pain comes.
Serena and Corizon should be applauded for the lean approach to requirements gathering because getting the process and UI into a demonstratable harness can significantly reduce project time, increase understanding of requirements definition and thereby reduce cost. However if the guts of the application are left out (Rules and interfaces) then we are only delivering an empty shell, leaving the hard development to the another full blown BPM app, or worse in a legacy application which will eventually have to be replaced, or by passed leaving the client with a patchwork of apps, a support nightware and probably increased TCO!
The BPM solution should be ease customer pain by either replacing inflexible systems or at the very least provide the customer with a migration path. However a sexy front end is often just not enough


Interesting column on Cloud Oriented Business Architecture and "Situational Business Processes"

Dennis, our notion of Lean or Lightweight BPM is the ability to quickly move from concept to process execution. You can do so in two ways:

- Move fast from process design to execution through a easy to use, easy to implement tool

- Move directly to process execution without up front modeling. The best example is email, but email doesn't provide the same visibility into and control over a process as does BPM.

BPM has to be nimble to help customers get apps up and running in days/weeks vs months/years.

BPM must also support dynamic processes which are largely unstructured. This is the area of the "Knowledge Worker." We're making BPM suitable for Knowledge Management in that workers from anywhere can automatically create process instances on-the-fly, include who they want, and allow participants to include others as well, all the while allowing the initiator (aka product manager) to track everything going on.

Of course the result is fast process execution and self-learning process discovery.

I think this is a key issue. Take Active Endpoints vs. Intalio. The latter has stack ambitions, the former none. Who's right? My vote goes to the nimble or stackless. I think the major growth area going forward will be the contributors of single function, lightweight BPM piece parts.

Leave a comment

Business process management and optimization -- philosophies, policies, practices, and punditry.

Anne Stuart

I am the editor of ebizQ.

Recently Commented On

Monthly Archives