What is Business Process Management?

Michael Hammer

Abstract Googling the term “Business Process Management” in May 2008 yields some 6.4 million hits, the great majority of which (based on sampling) seem to concern the so-called BPM software systems. This is ironic and unfortunate, because in fact IT in general, and such BPM systems in particular, is at most a peripheral aspect of Business Process Management. In fact, Business Process Management (BPM) is a comprehensive system for managing and transforming organizational operations, based on what is arguably the first set of new ideas about organizational performance since the Industrial Revolution.

The Origins of BPM

BPM has two primary intellectual antecedents. The first is the work of Shewhart and Deming (Shewhart 1986; Deming 1953) on statistical process control, which led to the modern quality movement and its contemporary avatar, Six Sigma. This work sought to reduce variation in the performance of work by carefully measuring outcomes and using statistical techniques to isolate the “root causes” of performance problems – causes that could then be addressed. Much more important than the details of upper and lower control limits or the myriad of other analytic tools that are part of quality's armamentarium are the conceptual principles that underlie this work: the core assumption that operations are of critical importance and deserve serious attention and management; the use of performance metrics to determine whether work is being performed satisfactorily or not; the focus on hard data rather than opinion to isolate the root causes of performance difficulties; the concept of blaming the process not the people, that performance shortcomings are rooted in objective problems that can be identified and dealt with; and the notion of never-ending improvement, that solving one set of problems merely buys an organization a ticket to solve the next round.

The quality approach suffered from two limitations, however. The first was its definition of process as essentially any sequence of work activities. With this perspective, an organization would have hundreds or even thousands of processes, from putting a parts box on a shelf to checking customer credit status, and the machinery of quality improvement could be applied to any and all of these. Focusing on such narrow-bore processes, however, is unlikely to have strategic significance for the enterprise as a whole; on the other hand, it is likely to result in a massive number of small-scale projects that can be difficult to manage in a coherent fashion. Even more seriously, the quality school took as its goal the elimination of variation and the achievement of consistent performance. However, consistent is not a synonym for good. A process can operate consistently, without execution flaws, and still not achieve the level of performance required by customers and the enterprise.

The other primary antecedent of BPM, my own work on Business Process Reengineering (Hammer 1990; Hammer and Champy 1993), had complementary strengths and weaknesses. On the one hand, at least in its early days, reengineering was positioned as an episodic rather than an ongoing effort; it lacked the continuous dimension of quality improvement. It also did not have as disciplined an approach to metrics. On the other hand, it brought two new wrinkles to the process world. The first was its refined definition of process: end-to-end work across an enterprise that creates customer value. Here, putting a box on a shelf would not qualify as a meaningful process; it would merely be a small part of an enterprise process such as order fulfillment or procurement. Addressing large-scale, truly end-to-end processes means focusing on high-leverage aspects of the organization's operations and so leads to far greater results and impacts. In particular, by dealing with processes that cross functional boundaries, reengineering was able to attack the evils of fragmentation: the delays, nonvalue-adding overhead, errors, and complexity that inevitably result when work transcends different organizations that have different priorities, different information sources, and different metrics. The other new theme introduced by reengineering was a focus on process design as opposed to process execution. The design of a process, the way in which its constituent tasks are woven together into a whole, was not of much concern to the founders of the quality school; they made a tacit assumption that process designs were sound, and that performance difficulties resulted from defects in execution. Reengineering recognized that the design of a process in fact created an envelope for its performance, that a process could not perform on a sustained basis better than its design would allow. Should performance requirements exceed what the design was capable of, the old design would have to be discarded and a new one substituted in its place.