"Organizations will need CIOs to guard against disintegration. This will require a full-time expert with plenty of leadership ability and a whole new set of skills in the area of corporate information dysfunction, personal and organizational technology adoption, and the role IT plays in shaping and reshaping corporate culture."

Opening Statement

Is business process management (BPM) really more than the analysis, documentation, simplification, and automation of workflows -- a notion that dates back several decades? BPM meant "business process modeling" as far back as 1967, the year S. Williams published an article in Automation titled "Business Process Modeling Improves Administrative Control."¹ That concept merged with business process improvement (BPI) and business process reengineering (BPR), but the last term was soon doomed when it became a euphemism for outsourcing -- and therefore domestic job cuts.

During the 1990s, the focus was on designing new workflows or simplifying existing ones using various flowchart notations. A colleague showed me the TeamFlow product (from CFM Inc.) in 1992, exposing me to the "swim lane" representation of process flows, and I used it on and off in my work until 2003. During the last decade, we started looking at the entire lifecycle of business processes (design, modeling, execution, monitoring, optimization -- not necessarily performed in that order), which resulted in the broader, more ambitious scope we tend to associate with BPM today. The M for "management" indicates that the focus has shifted from a documentation activity, typically driven by IT, to a business responsibility in which processes are monitored and managed against key process indicators (KPIs).

This larger meaning of BPM also encompasses capabilities to simulate processes directly from the models, and/or to actually execute them without having to write application code, typically by converting the model to the Business Process Execution Language (BPEL).

The following events indicate that BPM has, at least to some extent, penetrated the business and IT cultures:

• The BPM Initiative (since absorbed into the Object Management Group [OMG]) originated the Business Process Modeling Notation (BPMN), whose first version was developed between 2001 and 2006. When concepts are still in flux, standardization can be premature, but when industry participants agree on a standard notation, it validates the fact that the concepts have become broadly accepted. Recently, BPMN has evolved, and a subtle name change -- to "Business Process Model and Notation" -- indicates that its goal is not just to draw pretty diagrams (process descriptions), but really to help analyze and perform processes (process models).

• The BPM Consortium, "an advocacy group and community of BPM Practitioners, visionaries, and authorities," also managed by the OMG, listed 66 members in 2009.

• A significant market in BPM consulting and tools has emerged, especially with the BPM suites offered by some companies. The BPM Consortium Web site lists close to 200 "BPM vendors." Of course, not all of them offer services or products at the same level.

• More recently, we have seen the emergence of "BPM as a service," consisting of cloud-based offerings on a subscription basis; some companies even offer BPM freeware.

It is also a positive development that BPM and service-oriented architecture (SOA) are converging. It now seems well accepted, after about five years of discussion, that SOA is not a technology for technology's sake, but an approach to the modular delivery of business capabilities in the form of services. And to understand what business capabilities are required, a focus on business process is clearly needed. Reflecting this convergence, the BPM Consortium and SOA Consortium recently announced their merger. The two disciplines, separated at birth, should be reunited.

Yet there are unresolved questions about the effective scope of BPM -- in particular, whether the process execution and measurement aspect is as "ready for prime time" as the process design aspect -- and about who should be in charge. 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.

Definitions are just words, and one could brush off the lack of clarity by paraphrasing the famous words of a US Supreme Court justice: "I don't know how to define BPM, but I know it when I see it." On the other hand, ambiguity about roles and responsibilities is a more fundamental issue. The correct choice of who should lead the effort can determine the success or failure of the initiative, or at least its ability to create an effective alliance between the business and IT. Logically, BPM should be owned by the business, because it's not just about driving the requirements for IT systems. It should be primarily about understanding and improving the processes, even if they are executed on notepads and stickies, not on computers. When this is the case, BPM is related to the role of "business architect," a relatively new term for someone who has both the domain knowledge and the analytical skills to formalize the analysis and design of the business organization and its governance.

In practice, however, many BPM efforts are led by IT, specifically by the business applications group or sometimes by the enterprise architecture (EA) team. This is not because BPM is in fact an IT concept, but because of a pathological combination of factors:

• IT analysts need business process descriptions in order to generate the use cases that drive system requirements.

• The business is often, paradoxically, too busy executing the current suboptimal processes to have, or take, the time to improve them. (Hence the sarcastic maxim, "We don't have the time to do it right, but we sure have the time to do it again.")

• The detailed analytical skills required for process analysis and improvement are more present in the enterprise architects (in IT) than among business managers.

• The techniques of business process modeling and execution are seen as the province of IT. Businesspeople may spend hours polishing their PowerPoint presentations or debugging their Excel functions, but they usually think it is beneath them to learn to use a process modeling tool.

• IT therefore "wins" by default. Since they need the models and no one else will supply them, the analysts have to step in and create them, interviewing users if they are available or "reverse engineering" the process models from the existing applications if not.

In this issue of Cutter IT Journal, we aim to bring a balanced perspective to the definition, scope, benefits, opportunities, and challenges of BPM. We asked our contributors to consider 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 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?

In the following articles, seven authors from very diverse backgrounds will help you understand and explore -- if not entirely resolve -- some of the challenges and myths affecting the current preoccupation with BPM. Their thoughtful analyses provide guidance to those who wish to raise the awareness of business processes in their organizations and arrive at better control over their design, execution, monitoring, and optimization.

We start with Paul Clermont, who paints a very useful picture of the reasons that business process management (in the generic sense) often failed in the past and how BPM emerged as a discipline to fix the past shortcomings. Clermont outlines what BPM should and should not be and specifies the requirements for BPM teams to succeed.

Next, Kevin Brennan takes on the challenge of further defining the skills needed for BPM. He defines the role of the "business analyst" and lists the competency areas needed in that position. He then analyzes the skills gap that often hinders effective BPM and proposes a method to assess and improve the business analyst's skills.

Ian Gotts recognizes that BPM means different things to different people, and instead of just bemoaning the confusion between these definitions, he exploits the distinctions by identifying four audiences for BPM -- end users, the IT department, IT system suppliers, and risk/compliance management -- and assigning each a different colored hat. This scheme allows him to discuss the various models of the business and the connections that must exist between them.

Then, Fred Cummins positions business processes in the context of value chain analysis, a technique first introduced in 1985 but made more relevant now by the increased complexity of "extended enterprise" structures. Value chain modeling ensures that we keep focusing on delivery of customer value and optimize processes across multiple lines of business, not just within operational or functional silos.

Matthew Ganis and Lekha Panikulangara draw on the popularity of project retrospectives to advocate their use for process improvement. Quantitative measures of process efficiency are hard to come by, so Ganis and Panikulangara use statistics about the nature and subject of comments made during retrospectives to measure and improve BPM efforts.

Finally, Sandy Kemsley goes for the gold by painting a picture of dynamic adaptation of processes on the fly. In this vision of the model-driven enterprise, business users and managers can tune their own processes without having to go through the typical IT project lifecycle to make changes. A key component of this new approach to agility is explicit and documented collaboration between the actors as they execute the processes. Kemsley gives us two examples of products that include such capability.

As you can see, five out of six of the articles refrain from ambitious projections of what BPM can achieve, focusing instead on clearly defining the discipline and what people can expect and specifying what skills they must possess. However, it would be wrong to think that BPM has stood still since Williams's 1967 Automation article. For one thing, the careful exposé of the definitions and requirements offered by our contributors is needed and useful, especially because of a renewed interest in putting the business owners back in the driver's seat. Perhaps BPM evolved relatively slowly for the first 40 years because it was mostly practiced by IT people. Now that the business is beginning to recognize its responsibility to direct the effort, BPM can be reenergized.

In fact, 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. Meanwhile, the six articles in this issue will help you correctly position your BPM initiative as an effort that can help bridge the common divide between the business and IT. They paint a picture of a discipline that is not just about drawing pretty diagrams, but about getting closer to the elusive goal of the model-driven, real-time enterprise.

ENDNOTE

¹ Williams, S. "Business Process Modeling Improves Administrative Control." Automation, December 1967, pp. 44-50.