Monday, April 16, 2007

Run better business processes with a BPMS, not a programmer

A few days back, my colleague Steve McDonald asked me a question that went something like: "Do companies need BPMS to make their processes work better, or can you just write custom applications that represent the process?". Well obviously we both have a bias towards the BPMS, but I believe its for good reason - I have wielded a compiler at some point in my career and I can honestly say that the results were 'variable'. So we agreed that having the structure and tooling of a strong BPMS in place allows you to concentrate on the business problem you are trying to solve, rather than the mechanics of writing code and pure custom apps.

Look at any organization and you'll see that business processes do run without a BPMS, as loosely organized paper and email based processes based around a custom Access database application. Many low volume processes that we see in organizations, around processes in HR and Finance for example are commonly run in this way. Making a business case to improve these processes is difficult since it depends mostly on soft metrics like enforceability, compliance and visibility, and taking them the extra step with a complete BPMS may be considered unnecessary.

Now consider a high volume process handling thousands of insurance claims per day. Typically this is a process that has evolved to incorporate human interaction, system to system integrations, paperless operation and fully managed business processes. The business case for BPMS implementation and the measure of its success is metrics like reduced cost and time to process a claim, improved capacity, reduced errors, less customer service call center abandoned calls. These are not metrics that can be achieved without a BPMS – actively executed and managed processes are essential to ensure that the claims process runs like a well oiled machine. There is no room for unnecessary activities to be performed by the process users, either in receiving or delivering work to the right place, or in the oversight to ensure that the process runs as it should.

Attempting to put a process application together out of component parts, a bit of process execution here, a bit integration there, and some loosely defined reporting over the top, is a bit like the factory workers building a BMW attempting to build a luxury car using tools they had brought in from their home garages that morning. Even with a strong process, and great components, who knows whether they would have enough ratchets and the right size spanners to put the car together successfully. I'm sure there would be a lot of use of the 'leather hammer'.

The strength of a BPMS comes from being to apply the management discipline of BPM to the best technology to really ensure that a well oiled process can roll high quality product out the door, and at every stage you can have visibility and control to ensure this happens. Having great visibility over the crew of BMW workers with inadequate tools is probably as unsuccessful as knowing the crew have great tools, but having no idea whether windshields, wheels and brakes have been delivered for them to actually assemble the car. A carefully selected BPMS (not the one you selected to handle 100 travel expense claims a day) can provide the tools and visibility to deliver the business objectives for highly efficient, cost effective and visible business processes.

Technorati tags:

A post from the Improving New Account Opening blog

Wednesday, April 11, 2007

Tying together BPM and SOA technology

BrainStorm has been a hot topic this week for the BPM and SOA crowd. Sandy Kemsley blogged about the BPMS vendor panel (which didn't appear to engage her unfortunately), hosted by Bruce Silver. I would have loved to attend the event, which I couldn't (being sat in my office in Boston at the time). But I was interested to weigh in around some thoughts around BPM and the relationship with SOA technology, a discussion that came up with the panel. This is where my coworker Steve McDonald and I mind-melded a bit.

I have been working through releasing an SOA edition of the process, content and case management product I manage, and in doing so have observed many pitfalls that face human-centric BPM products in an SOA technology world. My view is that a BPMS can get caught in the trap of becoming another component of the SOA infrastructure. The SOA view of BPM and process execution demands that a process engine interacts with other systems and executes branched business processes and not a lot else. The BPM gets sucked down into the SOA infrastructure, lost in a Bermuda triangle of web service acronym checklists. Steve constantly reminds me that this is a waste of the capabilities of a BPM and content based product.

BPM software customers agree that the purpose of a BPMS is to control real business processes and enable effective management and improvement of those processes. I believe that processes that have typically been implemented with BPM are readily identifiable as business services and should be treated as such. For example, large insurance companies that have not yet embraced SOA may run multiple variations of an otherwise identical property claims process in a BPM application for different business units. This claims process is a high level business service that could be reused, and the BPMS should enable that. Within this top level process there are services that should also be reusable, for example Fraud Investigation. The BPMS should clearly identify the services, allowing them to be extracted from the core process and reused, moved elsewhere in the organization (or even outsourced). Treating traditional process components as loosely couple services provides this flexibility, but to achieve this the BPMS must understand SOA and be able to interact with the infrastructure.

To achieve this, the BPMS must have some strong SOA capabilities and link back to the infrastructure, without becoming overwhelmed by it. So I think that three requirements are:
  • A BPMS must be able to consume services published in service registries, and implemented through ESBs, custom applications and other BPM processes
  • A BPMS must be able to host its processes as services for reuse across the organization
  • A BPMS must provide visibility across services and processes that extend the boundaries of its own process model. Pulling loosely couple services into end-to-end business processes demands stronger oversight and visibility of performance than monolithic business processes executed by a single system
The infrastructure of SOA is important to an organization implementing services and business processes. BPMS must consume the services of more technical components than ever before, should host process based services, and be an enabler for exposing process (and content) services that common data centric SOA components do not handle well.

I think its possible that integration of the BPMS into specific SOA platforms as a complete vendor stack leads to artificially tightly integrated architectures. SOA infrastructure relies on web service standards, and SOA as a methodology demands loose coupling of services and identification of components with separate roles. Integration of platforms into a proprietary stack leads the IT team back to a monolithic architecture, and away from the true objectives of SOA. BPMS and SOA platforms should play together, not be tied together.

I'd like to thank Steve for voicing some of our combined opinions around this on the panel. He certainly seemed quite excited by the chance to talk about this common theme in a way that obviously, and unashamedly, reflects the strengths of the products we both work with.

Technorati tags:

Sunday, April 01, 2007

What's in your wallet? The best surveys provide feedback

In the US at least, airline frequent flier miles are the center of marketing efforts for credit cards, hotels, car rental and even restaurants. One of the big marketing campaigns for a credit card mileage program is 'what's in your wallet?' - maybe a credit card accumulating miles with no blackout dates. Since airlines frequent flier programs have become renowned for making it almost impossible to get the free tickets you feel you are entitled to, when you want to use them, does this put people off actually trying to use their miles?

Try this short (one question) online survey to show how you use your miles, and see how you compare with hundreds of other respondents. Interestingly, there is no link back to the sponsoring website (Cheapflights) and nothing asking you to identify yourself. There is no fear of spam, so these guys are relying on word of mouth and good follow up PR to gain any benefit from this survey.

I was happy to do this survey, because it gave me some instant feedback. How many surveys are put out to solicit customer feedback, leaving the customer feeling unrewarded with a 'thanks for your time' but no other feedback. Just seeing the current rating on how I voted alongside everyone else gives a feeling of interactive satisfaction.

Now, I wish it was that easy for me as a product manager to get hundreds of data points to feed into product decisions and better marketing!