• What is BPM?


• Can I see a quick example?


• What does BPM provide that other enterprise applications do not?


• How does BPM fit in with legacy, ERP and other enterprise systems?


• What kinds of processes are typically the best candidates for BPM?


• It seems like everyone is selling BPM—what does the BPM vendor landscape look like?


• How is BPM related to service-oriented architecture (SOA)?


• Are there any standards being developed for BPM?


• What does BPM cost? What are the hidden costs?


• What is involved in implementing BPM?


• How do companies organize their BPM projects? Who should own a BPM initiative, business or IT?


• How do I build a business case for BPM?


• How do I measure and actually get ROI from a BPM project?

What kinds of business processes are typically the best candidates for BPM?

BPM investments can yield a high ROI in these areas:

• Dynamic (not static) processes. Dynamic processes change frequently; static processes seldom change. A good example of dynamic processes are those that must be adapted to regulatory compliance changes—for example, retailers modifying how customer information is managed due to changes in federal privacy law and credit card company mandates.

• Processes that involve people and, typically, cross business unit, division, department, workgroup or other functionally organized groups of people.

• Complex processes (such as an order-to-payment process). Complex processes require the orchestration of a variety of people from different functional departments using different software applications and/or data to do their step in the process.

• Measurable mission-critical processes—that is, improvement to the process would directly improve a performance metric that is measurable and important to the business.

• Processes that cannot be completed without calling on more than one legacy application (or a process that provides significant additional capability, like self-service HR functionality to employees).

• Processes with exceptions that are currently handled manually (for example, a furniture retailer's reliance on physical discovery and research into inventory aberrances).

• Processes with exceptions that require quick turnarounds.

Areas ill-suited to BPM include:

• legacy application replacement

• high-volume transaction processing (such as a point-of-sale application, although cross-channel returns might be a good target)

• processes with little or no user interaction

• processes that can be simply and cheaply automated with other tools

Sometimes, the most important part of a strategy is knowing what not to do, especially with a fairly horizontal capability like BPM. For a first BPM initiative, the process should be important—but not your most complex or mission-critical. BPM done right is a good example of the flywheel concept: Focus on a specific and quick solution where a visible business process improvement will foster momentum for broader and more sustained BPM implementations.

It seems like everyone is selling BPM; what does the BPM vendor landscape look like?

(See also, "Providers of BPM Suites.")

Vendors present a broad array of solutions designed for many different industries and needs. At a high level, there are two basic camps of vendors: those that offer BPM as part of a legacy collection of products and those that sell only BPM suites (often referred to as "pure play"). Sometimes you can buy BPM solutions in the first category separate from the legacy system, and sometimes you cannot. For example, Filenet's P8 includes process capabilities that are usable only if you use Filenet's ECM solution, while SAP's NetWeaver technology can stand alone.

Vendors that offer BPM as part of a legacy collection of products tend to offer BPM capabilities that focus on and extend their legacy architectures. For example, a document imaging vendor will typically offer document-centric BPM capabilities, while a middleware vendor will emphasize the data-integration aspects of its BPM solution. In contrast, BPMS pure-play vendors often highlight their product's architectural purity, which means it is built from the ground up to provide integrated BPM functionality. BPM offered with legacy products is often add-ons of technology purchased from another company and then "bolted" on, often making for a fragile solution. Still, both solutions have their advantages and disadvantages.

Emerging in the BPM space are open-source solutions. The most well-known is jBoss jBPM. JBPM has improved substantially with recent releases; however, it lacks many of the functional capabilities of platforms from leading commercial BPMS vendors like Lombardi Software, PegaSystems and Savvion (which do not offer open-source solutions). BPM features that are less robust in jBPM than in many commercial products include model simulation and graphical user interface (GUI) development.

Some key considerations when evaluating BPM vendors include:

• Verify that the vendor's BPM platform is truly integrated. Some vendor platforms have built bridges to modeling and simulation tools and call it BPM. Sometimes the reporting component is just an add-on. This "bucket brigade" approach really slows down the iterative nature of a real BPM approach to process improvement.

• Don't let technology preferences taint an objective comparison of BPMS features and capabilities. Thinking about a BPM tool based on Java versus .NET may be less important than basing one's decision on the BPM features required by business analysts for process modeling or the features required by workers to monitor and execute tasks. For example, don't fall in love with the flashiest rules engine. But don't get boxed in by your existing architecture or vendor partners when selecting a platform to drive process improvement across your organization. In fact, your BPM platform should be independent of legacy constraints so that you have the flexibility to replace source systems without affecting user-facing process automation.

• Always take a good look under the hood. Different vendors take very different approaches to implementing common BPM features, such as how the process model is linked to lower-level implementations or how a user interface is constructed and integrated into the workflow. Some vendors provide better support for heavy business analyst involvement in constructing a BPM application (which does not require substantial programming expertise), while others require substantial programming expertise for even simple development tasks. Some vendors offer well-defined, easy-to-use APIs to allow for custom integration to accomplish more unique requirements. Drilling down into the details will help you understand exactly how a particular vendor's product will fit with the skills and capabilities of your organization and best meet your company's specific needs.