Category: process

business process management

BPM independent becomes less so

eBizq announced today that Peter Fingar has joined Bluespring Software‘s advisory board to “provide advice, assistance and guidance on future releases of Bluespring’s BPM technology and contribute thought leadership towards the evolution of the company’s business model”.

We all have vendor biases, and I count a few vendors as my customers, but to join the advisory board of one company seems to be taking oneself firmly out of the ranks of the independents.

Integration stacks explained and compared

A good explanation of integration stacks (including EAI and BPM) by Greg Wdowiak. He makes a nice distinction between task flow management in the EAI layer and business process management in the BPM layer:

The Task Flow Management function of the broker coordinates relatively simple, short time activities amongst the integrated systems… The Task Flow Management function service translates the business task into a set of lower-level (often application specific) technical tasks.The Business Process Management function (BPM) coordinates long-running business processes. In many aspects, BPMS resembles Task Flow Management function. BPM differs from Task Flow Management in that:

  • It is geared towards managing tasks that may range from hours to months in duration. BPM persists its state in a database.
  • BPM focuses on business-level tasks, frequently tasks that are performed by humans. To support such tasks, BPM support sophisticates access control and authorization models, escalation procedures, task delegation, etc.

He goes on to compare the integration stacks of TIBCO and IBM, including the history of what was developed internally versus what was acquired, although he’s missing a few details about the BPM side of things since his expertise appears to lie at the EAI end of the spectrum (for example, the InConcert BPM product, now owned by TIBCO and probably soon to be discontinued, was originally developed by XSoft, a division of Xerox), but I think that this is a work in progress.

I really like that way that he overlays the five technology layers (connectivity, MOM, transformation & routing, task flow, and BPM) with the various products from both vendors so that you can see what’s what: something that most vendors don’t do, so it’s very hard to tell what portion of the stack that a product covers.

TIBCO and IBM definitely compete head-to-head technically at the MOM layer: I’ve seen a lot of holy wars about TIB/Rendezvous versus MQ Series in my financial services customers, and usually they end up with some of each, although MQ has a large enough market share to be considered a de facto standard. At the BPM layer, however, it’s hardly a fair fight: Staffware is recognized by Gartner as one of the top two or three pure-play BPM products, whereas MQ Workflow doesn’t even make it onto the chart. I wouldn’t be surprised to see IBM replacing MQ Workflow, or radically overhauling it, in the near future in order to remain competitive and get on Gartner’s pure-play BPM radar.

Greg’s impressions of the vendor smoke screens are bang-on:

IBM constantly re-brands products (most recently, pre-pending all names brands ‘WebSphere’) making it difficult to understand… Both [TIBCO and IBM] stacks include products with overlapping functionality. It is not clear from the vendor which product should be used under what circumstances; rather, both vendors attempt to create an impression of perfectly coexisting and augmenting each other components.

Some things never change.

Intelligent Enterprise BPM cover

Today’s Intelligent Enterprise cover story “Business Process Management is Under Construction” is focussed specifically on modeling, analysis and reporting, business activity monitoring (BAM) and simulation features (since they cover integration and automation features in an earlier article).

Their assessment shows BPM as still at a relatively early adoption state:

BPM software is headed for mainstream adoption, but it’s still a relatively small, immature market… Plenty of organizations have yet to discover BPM… 36 percent said they were considering BPM and 29 percent said they had no plans to implement it, while only 24 percent said they were either piloting, rolling out, in production with or upgrading BPM.

That’s certainly what I’m seeing in many organizations, and why BPM evangelism is going to be required for some time still. Yes, there’s lots of successful BPM case studies to point at, but if you dig into the infrastructure at a large financial institution (for example), you’ll find a lot of EAI and not a lot of real BPM. Intelligent Enterprise states that even the basic automation and integration are still a challenge for many organizations, but I’m finding that the integration part has pushed forward because EAI is typically an IT initiative to integrate systems behind the scenes: the business benefits obliquely but their environment may not be impacted at all. On the other hand, automation requires true BPM (including human-facing workflow, modelling and simulation, and a whole raft of other features not typically found in EAI), plus full involvement of the business in order to achieve success, so gets hung up on the continuing disconnect between IT and the business that they serve.

Compliance is certainly going to push BPM forward, although that requires closed-loop process control throught the addition of analytics and simulation. There needs to be a bigger focus on making BPM performance monitoring and improvement a part of the larger corporate performance management framework, and showing how BPM fits into an organization’s enterprise architecture framework.

There are two more BPM articles in this issue of Intelligent Enterprise, “IT Detours on the Road to BPM” that discusses nine BPM suites’ closed-loop capabilities, and “Simple Process Management: Quick, Cheap and Easy” about Nsite, a hosted solution for a limited range of administrative-type workflows. I’d love to stay and blog all day about them, but it’s a holiday here and I’m going sailing.

SOA from a BPM perspective

Terry Schurter of BPMG has a great article yesterday on IT-Analysis.com about using a BPMS as the core of your SOA. His take on the current craze of SOA as a standalone big budget item:

Granted, I may be flying in the face of a storm of pundits, analysts, and technology gurus that endorse, promote and make great claims regarding the value SOA will deliver as I expose the seamy underside of this wolf in sheep’s clothing but hey — they’ve been wrong before — and the hard facts of the matter are that SOA expenditures will in many cases push important expenditures onto the backburner while they fiercely consume limited resources on a one way track to zero ROI.

I met Terry at the BPMG conference in London in May, and he definitely tells it like it is. I think that he’s just stirring the hornet nest here to see what happens, but he has some valid points about how a competent BPMS already does a lot of what you may be reinventing with your SOA initiative.

Interestingly, this post on Six Sigma Technologies’ site this week went through a checklist of SOA uses and benefits that sounds an awful lot like BPM…

Global 360 Active Compliance Framework

I watched a webinar earlier this week about BPM and compliance, a topic that I’ve been working on for a while, in which Global 360 announced their Active Compliance Framework (today’s Computer Business Review also reviewed their announcement). The speakers were from Doculabs and BWise, the latter of which has just partnered with Global 360 (and a bunch of other ECM/BPM vendors) for a compliance offering. Global 360 states the advantages of their compliance framework as follows:

Improved Compliance & Risk Management (i.e., do a better job of being compliant)

  • Standardized, structured approach
  • Focused on highest risk controls & processes
  • Centralized visibility and control

Reduced Compliance Costs (i.e., be compliant in a more cost-effective way)

  • Reduced project costs via control reduction based on risk
  • Reduced testing costs for remaining controls via automation
  • Eliminated testing costs for continuously compliant processes

Process Optimization & Control (i.e., provide an opportunity to optimize your business processes)

  • Optimize process performance while increasing control
  • Proactive compliance issue visibility, notification
  • Evolution from obligation to optimization

I liked the focus on the last of these sections, or what they called “from obligation to optimization”: changing the organization’s attitude from compliance being a chore that they’re forced to implement, to compliance being an opportunity to improve business processes through standardization and measurement.

If, like 1/3 of Doculabs’ current customers, compliance is one of your highest priorities for 2005, it’s worth your time to check out compliance solutions like this from ECM/BPM vendors. The whole compliance field is still chaotic; a Gartner report on compliance management software lists 26 vendors and clearly states that the compliance market is not mature:

A key finding of our research is that there is no comprehensive compliance management application. Whether buying from one or many vendors to get a solution, you will need significant services for implementation and integration.

Partnerships like the one between Global 360 and BWise start to address this problem, but there’s still a long way to go before we can even agree on what “compliance management software” is.

FileNet shaking the “content” label

When I was the eProcess (BPM) evangelist at FileNet back in 2000-2001, I fought a lot of battles — both internal and external — about FileNet’s focus on content versus process. FileNet came from a content background, but finally they’ve reached a milestone of having BPM in more than half of their current deals. Nice statistic, but given that this is current deals and not existing customers, I think that they still have a long way to go.

BPM, Six Sigma, & the Road to Process Perfection

An article in Business Integration Journal about using BPM to achieve Six Sigma objectives, by Carl Hillier, a former colleague of mine at FileNet. I first met Carl about 10 years ago when he was a FileNet systems engineer in London and I owned a professional services firm that helped customers implement FileNet systems, and I’ve always had a great deal of respect for his opinions (although not always for his choice of bosses): not only is he smart technically and knows more about FileNet BPM than just about anyone, but he can write beautifully coherent sentences about it.

Of course, he does give space to the FileNet party line in several spots, (“a robust BPM solution provides a fully integrated content repository” — I consider an integrated content repository to be “nice to have” but not essential), but he does hit the nail on the head when he talks about BPM helping to provide a “closed loop” environment for Six Sigma’s Define, Measure, Analyze, Improve, Control (DMAIC) continuous process improvement cycle through the inclusion of process analytics and simulation.

Who touches production?

Last week’s post on the BPM/BR webinars originally contained a lot more of my brain pouring out onto the keyboard because of things said during both of the webinars about business, IT and production systems, so I gathered up all the ideas and let them stew for a few days.

As long as I’ve been working with workflow and BPM products, the vendors have been claiming that the business users/analysts can design the process flows and modify them in response to changing business conditions, and in fact have implied (or actually stated) that the business side would make changes to the business process in production. And, as long as I’ve been working with these systems and their users, that has never happened.

I haven’t worked much with business rules systems, but I see a lot of the same type of claims about business users/analysts being responsible for modifying the production systems and that gave me a bit of hesitation because I know how that really translates over in BPM land. Both of the BPM-BR webinars reaffirmed my suspicions: no one really lets the business side touch a production business rules system, even if it has a pretty user interface. Give the business a sandbox for changing testing rules, but they’re not going to be the ones responsible for regression testing these against what’s already in production, and then getting them into production.

In the second webinar, John Rymer (the Forrester analyst) stated in one of his slides that business analysts will make changes, thereby providing the business agility promised by these systems, but when he returned to the point later, he requalified this as “business analysts or garden-variety programmers”; what he really appeared to mean is that you don’t have to use a highly-trained business rules specialist to do this — quite a bit different than what was stated on the slide, or implied by most of the BR vendors.

Furthermore, during the Q&A at the end of the webinar, Rymer admitted that the “single source of truth” that he referred to earlier in the presentation would be governed by IT, although the content would be developed collaboratively with the business.

I don’t disagree with this: I think that if IT is responsible for care and feeding of a system, they should be responsible for making what are essentially programming changes (albeit through that pretty UI) to a production system. As I mentioned previously, in most cases the business side doesn’t have the systems skills to take responsibility for this — not that they’re stupid, but they’ve developed their skills in other areas that IT is clueless about, such as how the business actually works. The big problems are:

  • How do you distinguish between a change that can be made by the business versus one that must be handed over to IT? The answer to this lies in assessing the potential damage that can be caused by making the change in the absence of regression testing against the existing environment.
  • How do you ensure that when IT must make a change, they make the right change? The answer to this lies in communications and signoff procedures between the business and IT, particularly in making sure that they are using the same language and that the change requests are in writing.

And now we’re putting together two types of systems — BPM and BR — that both state (seemingly erroneously) that business users/analysts can make changes during production. Yeah, right.

After more than 15 years of working with BPM vendors who were passing around the same Kool-Aid, the BR vendors should take a lesson from what you lose by overstating ease of use, and provide some realistic guidelines for exactly what who’s going to do what in a real BR production environment.