"The variety of definitions of BPM found on the Web and in the mission statements of various organizations attests that the scope of BPM is not yet well agreed." "

Opening Statement

In the February issue of the Cutter IT Journal (Vol. 23, No. 2), we asked ourselves, "Is business process management (BPM) really more than the analysis, documentation, simplification, and automation of workflows -- a notion that dates back several decades?" In that issue, six articles shared the authors' understanding of key aspects of BPM:

• Where BPM came from -- including the rise and fall of business process reengineering

• The skills needed for successful BPM

• The diversity of stakeholders, which itself indicates BPM's broad reach within the enterprise

• The impact of business process on the value chain across an extended enterprise

• How to measure the success of BPM initiatives

• Where BPM might be headed, with business owners being able to modify their processes as required without being hamstrung by IT project lifecycles

One issue that comes out clearly in these articles, and in the BPM literature, is scope. Is BPM strictly the analysis, design, modeling, and -- potentially -- automation of workflows? Or is it a broader discipline, one that touches on the still elusive concept of business architecture? And is this discipline one that really forms the core of the knowledge of how an enterprise functions, and should it therefore be a key focus of knowledge extraction and training in an organization?

As we wrote a couple of months ago:

The scope ambiguity is reflected in the difficulty one encounters when searching for a clear, authoritative definition of BPM. Even the BPM Consortium's Web site is not entirely limpid about this, and the Wikipedia definition reads more like an advocacy piece for a specific methodology than a consensus definition.

The variety of definitions of BPM found on the Web and in the mission statements of various organizations attests that the scope of BPM is not yet well agreed. Definitions are sensitive topics: while it would be easy to say "Pick one, any one, and move on," we must recognize that different definitions imply varying ownership and involvement by high-level stakeholders. Is BPM an IT thing? Is it something that line of business managers should own individually for their respective silos? Is it a key opportunity to bring everyone to the same table to share practices and lessons learned, and in the process discover commonalities they might have underestimated? Or, finally, are business processes the "crown jewels" of the enterprise, worthy of attention at the highest level -- certainly the CEO but perhaps even the board of directors?

When we were planning the February issue, we asked our would-be contributors several key questions:

• How can organizations employ BPM most effectively to maximize business performance?

• What role does BPM play in facilitating a real collaboration between IT and the business? Does it help both sides speak a common language and bridge their conceptual and communication gaps?

• Alternately, is the only real outcome of the BPM fad the emergence of a notation and tools to document processes? (While this is undeniably useful, it is not new and is much less strategic than some ambitious definitions of BPM would lead you to expect.)

• How do you educate both the business and IT to understand their respective roles in managing the complete lifecycle of business processes?

• What are the real strengths that can be leveraged today, as opposed to vendor hype about BPM suites? What are the success and failure stories? How can BPM be improved?

• How do you get started? Should you pilot BPM on new processes, simple processes, troubled processes, or...

• What combination of technical and business skills should be required to ensure a successful BPM effort?

• What are some good examples of BPM and SOA complementing each other?

When we published those first six articles, we concluded:

BPM has become such an important topic in the last couple of years that six articles, even of the highest quality, cannot do justice to the topic or answer all the questions we posed earlier. This is why another issue of Cutter IT Journal, in a few months, will offer additional perspectives from other authors on this key subject.

We're now making good on our promise. The five articles in this issue are qualitatively different from the first six in that they provide alternative, or perhaps complementary, views on BPM's place in the enterprise.

David Wright leads the way by explaining why and how business processes often get "frozen" -- the enterprise evolves, but what has been codified in software applications cannot keep up. He uses a DBMS analogy to make his point: the rules that a DBMS allows you to encode in the database schema can usually not implement all the conditions required by the data model, and thus additional mechanisms had to be invented. Similarly, a process definition does not easily capture all the business rules. Wright proposes a four-layer model (processes, services, rules, data) that allows business rules to assume a prominent place, and he explains how business rule management becomes an instrument of change management.

Cutter Senior Consultant Tushar Hazra and Robert Pillar begin their article by contrasting traditional approaches to BPM, namely the analysis and local optimization of processes without fundamental changes to the organizational and operational environment in which they exist, with enterprise transformation initiatives, in which the solution seeks to rebuild a new organization with completely different processes. The authors then describe how the "coalition" of BPM, enterprise architecture (EA), and service-oriented architecture (SOA) can achieve more than the sum of its parts, and they use the case study of a financial institution's transformation efforts to demonstrate their point.

Fred Cummins (who also contributed to the February issue) and Henk de Man are leading the development within the OMG of a new specification for case management processes, which are related to complex event processing (CEP) and sometimes referred to as "dynamic processes." In their article, the authors describe situations in which one cannot spell out in advance what steps a process will follow, and therefore it is impossible -- or at least much too complicated -- to describe all possible paths in a process modeling notation such as BPMN. This does not mean, however, that case management cannot be automated: the authors discuss the benefits of a structured "case file" and tools to record the events and decisions made along the way.

Ricky Cheong and Eric Tsui are also looking outside of the confines of the management of specific process steps. In their article, they discuss "personal knowledge management," meaning the ways in which individuals gather and organize information, internalize the knowledge to create "wisdom" that guides them in their subsequent actions, and share the knowledge with others. They then explain how these knowledge processes become enablers for BPM. Specifically, Web 2.0 and collaboration tools end up playing a key role in supporting processes that have a strong human component.

Mike Gammage poses as an amateur orchestra conductor, using this metaphor to make us understand how important it is that everyone play from the same score. This leads him to argue for collaborative, community-based ownership of processes, and he illustrates how a process mapping effort in J.P. Morgan's IT group allowed the consolidation of 48 service delivery tools into four. Implicitly, he answers the question "Who should own business process definitions?" with a resounding "You!"

Even after 11 articles on BPM, we are certain that the topic is far from being exhausted. In years to come, our understanding of this domain will continue to evolve.

ABOUT THE AUTHOR