Beware the BPM Sirens

Steve Craggs, Vice Chairman of the Integration Consortium, advocates taking a pragmatic approach to business process management.

Business process management (BPM) has been an ever-present theme in the marketing messages of many vendors over the last few years. The concept is relatively simple – allow business processes to be described visually, from building blocks representing individual process steps, and then magically translate these business flowcharts into the underlying IT implementation for execution. Human workflow and IT component interaction are both addressed within this execution. The seductive charms of BPM rapidly become clear, promising business-oriented control over IT, clarity and visibility of business operation execution and agility in addressing changing business demands. In essence, BPM seems to finally put business executives in control of IT, rather than held to ransom by it.

But if BPM is so wonderful, then why are so many companies struggling to navigate a course to help them reach this Promised Land? And what are the lessons to learn from those that have started to achieve BPM benefits? In short, the key is BPM pragmatism.

Vendors will draw out the benefits of deploying BPM throughout the business, across the entire value chain. The answer, they say, is to invest in a BPM infrastructure that allows your business analysts to define processes in spreadsheet form, and then aligns IT components to fulfill these processes. Some vendors even offer migration tools to enable the analysts to bring current process flowcharts into the new BPM system. Other vendors may also offer business activity monitoring (BAM) tied in with BPM, providing valuable insight into the performance of various processes in business terms and relating this performance to key performance indicators (KPIs) and other operational metrics.

These infrastructures may indeed deliver functionality to support the desired goals, but the siren-like messages are, in reality, somewhat disingenuous. There are a number of problems that threaten to derail this top-down approach to BPM.

First, companies must closely examine their own level of process maturity. It is all very well to point to the value of being able to specify business processes graphically and then automatically align IT resources to underpin them, but this presupposes that these processes are well enough understood to write them down in the first place. In fact, many companies find that their processes have evolved over time, and are only ‘recorded’ in the implementation of the IT infrastructure. Although the basic process may be understood, there are often nuances and exceptions that only exist in lines of code. Secondly, this top-down approach may encourage analysts to start from a clean sheet of paper and write out the process as they feel it should be, in an ideal world. But current operations will be based on practical experience, and switching to an idealized view of process operations will involve substantial change and associated risk. And thirdly, the investment model demanded by this approach is front-end loaded – a company must invest in a substantial software outlay before benefits can flow, often resulting in the purchase of functionality that will not be fully utilized for a number of years.

In contrast, successful BPM experiences often start out small. The optimal approach appears to be the pragmatic, ‘softly, softly’ one. Perhaps the most practical approach is to work from the bottom-up view. Companies today are finding a lot of advantages in moving towards a service-oriented architecture (SOA) model for their IT usage. SOA is an evolution rather than a revolution, in which companies gradually start to assemble IT components into business services. These services represent pieces of business functionality – such as ‘get customer details’ – in BPM terms, process steps. As these services are built, they can be used (and reused) by other IT components, without the need for major change, resulting in the ability to evolve into SOA piece by piece.

Once a number of services have been built, these services can then be linked together in an intelligent fashion, with the linkages controlled automatically based on sets of business rules. This is usually done through the use of a visual tool. And all of a sudden, the company adopting this approach has arrived at BPM.

This pragmatic approach to BPM brings key differences from the previous one. As companies experiment with SOA, building services and starting to combine them, IT staff are actually learning about the practicalities of operating at a process level, increasing the level of process maturity. Understanding individual services provides a step-by-step approach to understanding the underlying business processes that are implemented by the IT systems. Investment is on an incremental basis, with additional tools and licenses being deployed only when needed. Changes are made in a much more steady and controlled fashion. Finally, once the company is ready and it makes sense, full BPM technology can be purchased to maximize value.

BPM is a laudable aim, and can deliver big benefits. Companies can become more effective, more responsive and more competitive by taking control of IT and aligning it more closely to business goals, and managing operations more efficiently through improved clarity and visibility. But beware the BPM sirens – start from the bottom, adopt an SOA approach, develop process experience and stage investment before making the final plunge.