The Scope and Evolution of Business Process Management

Abstract

Business Process Management describes a broad movement toward improving how business people think about and manage their businesses. There are many different approaches to business process change and this article explores the three most important approaches. The oldest tradition is work simplification and quality control which is currently represented by Six Sigma and Lean. A second tradition is a management tradition driven by teachers and consultants like Porter, Rummler and Hammer. The third tradition is driven by Information Technologists and focuses on process automation of all kinds. Each tradition has its heroes and its own vocabulary and each emphasizes some practices over others. There is a growing emphasis on combining the various traditions in a comprehensive approach.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Business Process Management or BPM, broadly speaking, is part of a tradition that is now several decades old that aims at improving the way business people think about and manage their businesses. Its particular manifestations, whether they are termed “work simplification,” “six sigma,” “business process reengineering,” or “business process management,” may come and go, but the underlying impulse, to shift the way managers and employees think about the organization of business, will continue to grow and prosper.

This paper will provide a very broad survey of the business process movement. Anyone who tries to promote business process change in an actual organization will soon realize that there are many different business process traditions and that individuals from the different traditions propose different approaches to business process change. If we are to move beyond a narrow focus on one tradition or technology, we need a comprehensive understanding of where we have been and where we are today, and we need a vision of how we might move forward.

We will begin with a brief overview of the past and of the three business process traditions that have created the context for today’s interest in BPM. Then we will turn to a brief survey of some of the major concerns that process practitioners are focused on today and that will probably impact most corporate BPM efforts in the near future.

2 The Three Business Process Traditions

The place to begin is with an overview of the world of business process change technologies and methodologies. In essence, there are three major process traditions: the management tradition, the quality control tradition, and the IT tradition. Too often individuals who come from one tradition are inclined to ignore or depreciate the other approaches, feeling that their approach is sufficient or superior. Today, however, the tendency is for three traditions to merging into a more comprehensive BPM tradition.

One could easily argue that each of the three traditions has roots that go right back to ancient times. Managers have always tried to make workers more productive, there have always been efforts to simplify processes and to control the quality of outputs, and, if IT is regarded as an instance of technology, then people have been trying to use technologies of one kind or another ever since the first human picked up a stick to use as a spear or a lever. All three traditions got a huge boost from the Industrial Revolution which started to change manufacturing at the end of the eighteenth century. Our concern here, however, is not with the ancient roots of these traditions but the recent developments in each field and the fact that practitioners in one field often choose to ignore the efforts of those working in other traditions.

We’ll begin by considering each of the traditions pictured in Fig. 1 in isolation, and then consider how companies are using and integrating the various business process change technologies today.

Fig. 1

An overview of approaches to business process change (BPTrends Associates. © 2013)

3 The Work Simplification\Industrial Engineering\Quality Control Tradition

In Fig. 1 we pictured the Quality Control tradition as a continuation of the Work Simplification and the Industrial Engineering traditions. The modern roots of quality control and process improvement, in the United States, at least, date from the publication, by Frederick Winslow Taylor, of Principles of Scientific Management, in 1911 (Taylor 1911). Taylor described a set of key ideas he believed good managers should use to improve their businesses. He argued for work simplification, for time studies, for systematic experimentation to identify the best way of performing a task, and for control systems that measured and rewarded output. Taylor’s book became an international best-seller and has influenced many in the process movement. Shigeo Shingo, one of the co-developers of the Toyota Production System, describes how he first read a Japanese translation of Taylor in 1924 and the book itself in 1931 and credits it for setting the course of his work life (Shingo 1983).

One must keep in mind, of course, the Taylor wrote immediately after Henry Ford introduced his moving production line and revolutionized how managers thought about production. The first internal-combustion automobiles were produced by Karl Benz and Gottlieb Daimler in Germany in 1885. In the decades that followed, some 50 entrepreneurs in Europe and North America set up companies to build cars. In each case, the companies built cars by hand, incorporating improvements with each model. Henry Ford was one among many who tried his hand at building cars in this manner (McGraw 1997).

In 1903, however, Henry Ford started his third company, the Ford Motor Company, and tried a new approach to automobile manufacturing. First, he designed a car that would be of high quality, not too expensive, and easy to manufacture. Next he organized a moving production line. In essence, workmen began assembling a new automobile at one end of the factory building and completed the assembly as it reached the far end of the plant. Workers at each point along the production line had one specific task to do. One group moved the chassis into place, another welded on the side panels, and still another group lowered the engine into place when each car reached their station. In other words, Henry Ford conceptualized the development of an automobile as a single process and designed and sequenced each activity in the process to assure that the entire process ran smoothly and efficiently. Clearly Ford had thought deeply about the way cars were assembled in his earlier plants and had a very clear idea of how he could improve the process.

By organizing the process as he did, Henry Ford was able to significantly reduce the price of building automobiles. As a result, he was able to sell cars for such a modest price that he made it possible for every middle-class American to own a car. At the same time, as a direct result of the increased productivity of the assembly process, Ford was able to pay his workers more than any other auto assembly workers. Within a few years, Ford’s new approach had revolutionized the auto industry, and it soon led to changes in almost every other manufacturing process as well. This success had managers throughout the world scrambling to learn about Ford’s innovations and set the stage for the tremendous popularity of Taylor’s book which seemed to explain what lay behind Ford’s achievement.

Throughout the first half of the twentieth century, engineers worked to apply Taylor’s ideas, analyzing processes, measuring and applying statistical checks whenever they could. Ben Graham, in his book on Detail Process Charting, describes the Work Simplification movement during those years, and the annual Work Simplification conferences, sponsored by the American Society of Mechanical Engineers (ASME), that were held in Lake Placid, New York (Graham 2004). These conferences, that lasted into 1960s, were initially stimulated by a 1911 conference at on Scientific Management, held at Dartmouth College, and attended by Taylor and the various individuals who were to dominate process work in North America during the first half of the twentieth century.

The American Society for Quality (ASQ) was established in 1946 and the Work Simplification movement gradually transitioned into the Quality Control movement. The Institute of Industrial Engineers (IIE) was founded in 1948. In 1951, Juran’s Quality Control Handbook appeared for the first time and this magisterial book has become established at the encyclopedic source of information about both the quality control and the industrial engineering movements (Juran 1951)

In the 1980s, when US auto companies began to lose significant market share to the Japanese, many began to ask what the Japanese were doing better. The popular answer was that the Japanese had embraced an emphasis on Quality Control that they learned, ironically, from Edwards Deming, a quality guru sent to Japan by the US government in the aftermath of World War II. (Deming’s classic book is Out of the Crisis, published in 1982.) In fact, of course the story is more complex, and includes the work of native Japanese quality experts, like Shigeo Shingo and Taiichi Ohno, who were working to improve production quality well before World War II, and who joined, in the post-war period to create the Toyota Production System, and thereby became the fathers of Lean (Shingo 1983; Ohno 1978). (The work of Shingo and Ohno work was popularized in the US by James Womack, Daniel Jones and Daniel Roos in their book The Machine That Changed the World: The story of Lean Production, 1991. This book was a commissioned study of what Japanese auto manufacturing companies were doing and introduced “lean” into the process vocabulary.)

3.1 TQM, Lean and Six Sigma

In the 1970s the most popular quality control methodology was termed Total Quality Management (TQM), but in the late-1980s it began to be superseded by Six Sigma – an approach developed at Motorola (Ramias 2005; Barney and McCarty 2003). Six Sigma combined process analysis with statistical quality control techniques, and a program of organizational rewards and emerged as a popular approach to continuous process improvement. In 2001 the ASQ established a SIG for Six Sigma and began training black belts. Since then the quality movement has gradually been superseded, at least in the US, by the current focus on Lean and Six Sigma.

Many readers may associate Six Sigma and Lean with specific techniques, like DMAIC, Just-In-Time (JIT) delivery, or the Seven Types of Waste, but, in fact, they are just as well known for their emphasis on company-wide training efforts designed to make every employee responsible for process quality. One of the most popular executives in the US, Jack Welsh, who was CEO of General Electric when his company embraced Six Sigma, not only mandated a company-wide Six Sigma effort, but made 40 % of every executive’s bonus dependent on Six Sigma results. Welch went on to claim it was the most important thing he did while he was CEO of GE. In a similar way, Lean, in its original implementation as the Toyota Production System, is a company-wide program embraced with an almost religious zeal by the CEO and by all Toyota’s managers and employees. Of all the approaches to process improvement, Lean and Six Sigma come closest, at their best, in implementing an organizational transformation that embraces process throughout the organization.

An overview of the recent history of the quality control tradition is illustrated in Fig. 2. Throughout most of the 1990s, Lean and Six Sigma were offered as independent methodologies, but starting in this decade, companies have begun to combine the two methodologies and tend, increasingly, to refer to the approach as Lean Six Sigma.

Fig. 2

The quality control tradition (BPTrends Associates. © 2013)

3.2 Capability Maturity Model

An interesting example of a more specialized development in the Quality Control tradition is the development of the Capability Maturity Model (CMM) at the Software Engineering Institute (SEI) at Carnegie Mellon University. In the early 1990s, the US Defense of Department (DoD) was concerned about the quality of the software applications being delivered, and the fact that, in many cases, the software applications were incomplete and way over budget. In essence, the DoD asked Watts Humphrey and SEI to develop a way of evaluating software organizations to determine which were likely to deliver what they promised on time and within budget. Humphrey’s and his colleagues at SEI developed a model that assumed that organizations that didn’t understand their processes and that had no data about what succeeded or failed were unlike to deliver as promised (Paulk et al. 1995). They studied software shops and defined a series of steps organizations went through as they become more sophisticated in managing the software process. In essence, the five steps or levels are:

• 1. Initial – Processes aren’t defined.

• 2. Repeatable – Basic departmental processes are defined and are repeated more or less consistently.

• 3. Defined – The organization, as a whole, knows how all their processes work together and can perform them consistently.

• 4. Managed – Managers consistently capture data on their processes and use that data to keep processes on track.

• 5. Optimizing – Managers and team members continuously work to improve their processes.

Level 5, as described by CMM, is nothing less that the company-wide embrace of process quality that we see at Toyota and at GE.

Once CMM was established, SEI proceeded to gathered large amounts of information on software organizations and begin to certify organizations as being level 1, 2, etc. and the DoD began to require level 3, 4 or 5 for their software contracts. The fact that several Indian software firms were able to establish themselves as CMM Level 5 organizations is often credited with the recent, widespread movement to outsource software development to Indian companies.

Since the original SEI CMM approach was defined in 1995, it has gone through many changes. At some point there were several different models, and, recently, SEI has made an effort to pull all of the different approaches back together and have called the new version CMMI – Capability Maturity Model Integrated. At the same time, SEI has generalized the model so that CMMI extends beyond software development and can be used to describe entire companies and their overall process maturity (Chrissis et al. 2007). We will consider some new developments in this approach, later, but suffice to say here that CMMI is very much in the Quality Control tradition with it emphasis on output standards and statistical measures of quality.

If one considers all of the individuals working in companies who are focused on quality control, in all its variations like Lean and Six Sigma, they surely constitute the largest body of practitioners working for process improvement today.

4 The Management Tradition

At this point, we’ll leave the Quality Control tradition, whose practitioners have mostly been engineers and quality control specialists, and turn to the management tradition. As with the quality control tradition, it would be easy to trace the Management Tradition to Ford and Taylor. And, as we have already suggested, there have always been executives who have been concerned with improving how their organizations functioned. By the mid-twentieth century however, most US managers were trained at business schools that didn’t emphasize a process approach. Most business schools are organized along functional lines, and consider Marketing, Strategy, Finance, and Operations as separate disciplines. More important, operations have not enjoyed as much attention at business schools in the past few decades as disciplines like finance and marketing..

Joseph M. Juran, in an article on the United States in his Quality Control Handbook, argues that the US emerged from World War II with its production capacity in good condition while the rest of the world was in dire need of manufactured goods of all kinds (Juran 1951). Thus, during the 1950s and 1960s US companies focused on producing large quantities of goods to fulfill the demand of consumers who weren’t very concerned about quality. Having a CEO who knew about finance or marketing was often considered more important than having a CEO who knew about operations. It was only in the 1980s, when the rest of the world had caught up with the US and began to offer superior products for less cost that things began to change. As the US automakers began to lose market share to quality European and Japanese cars in the 1980s, US mangers began to refocus on operations and began to search for ways to reduce prices and improve production quality. At that point, they rediscovered, in Japan, the emphasis on process and quality that had been created in the US in the first half of the twentieth century.

Unlike the quality control tradition, however, that focuses on the quality and the production of products; the management tradition has focused on the overall performance of the firm. The emphasis is on aligning strategy with the means of realizing that strategy, and on organizing and managing employees to achieve corporate goals. Equally, the management tradition stresses the use of innovation to radically change the nature of the business or to give the business a significant competitive advantage.

4.1 Geary Rummler

The most important figure in the management tradition in the years since World War II, has been Geary Rummler, who began his career at the University of Michigan, at the very center of the US auto industry. Rummler derives his methodology from both a concern with organizations as systems and combines that with a focus on how we train, manage, and motivate employee performance. He began teaching courses at the University of Michigan in the 1960s where he emphasized the use of organization diagrams, process flowcharts to model business processes, and task analysis of jobs to determine why some employees perform better than others. Later, Rummler joined with Alan Brache to create Rummler-Brache, a company that trained large numbers of process practitioners in the 1980s and early 1990s and co-authored, with Alan Brache, one of the real classics of our field – Improving Performance: How to Manage the White Space on the Organization Chart (Rummler and Brache 1990). Rummler always emphasized the need to improve corporate performance, and argued that process redesign was the best way to do that. He then proceeded to argue that improving managerial and employee job performance was the key to improved processes.

Figure 3 illustrates Rummler’s approach which integrates three levels of analysis and concerns with measures, design and implementation and management. This diagram suggests the broader concerns that the management tradition in process has always embraced. The focus is on process and on all the elements in the business environment that support or impede good process performance.

Fig. 3

A performance framework (Modified after a figure in Rummler and Brache, Improving Performance.)

A good example of this is illustrated in Fig. 4, another diagram that Rummler frequently uses, that illustrates the role of the process manager. Where someone in the work simplification tradition might be inclined to look at the steps in a procedure and at how employees perform, Rummler is just as likely to examine the performance of the process manager and ask if the manager has provided the needed resources, is monitoring the process, and is providing the feedback and incentives needed to motivate superior employee performance.

Fig. 4

Each process or activity must be managed (Modified after a figure in Rummler and Brache, Improving Performance)

Unlike the work simplification and quality control literature that was primarily read by engineers and quality control experts, Rummler’s work has always been read by business managers and human resource experts.

4.2 Michael Porter

The second important guru in the Management tradition is Harvard Business School professor Michael Porter. Porter was already established as a leading business strategy theorist, but in his 1985 book, Competitive Advantage, he moved beyond strategic concepts, as they had been described until then, and argued that strategy was intimately linked with how companies organized their activities into value chains, which were, in turn, the basis for a company’s competitive advantage (Porter 1985).

Figure 5 provides an overview of a value chain as described Michael Porter described it in Competitive Advantage.

Fig. 5

Michael Porter’s value chain

A Value Chain supports a product line, a market, and its customers. If your company produces jeeps, then you have a Value Chain for jeeps. If you company makes loans, then you have a Value Chain for loans. A single company can have more than one value chain. Large international organizations typically have from 5 to 10 value chains. In essence, value chains are the ultimate processes that define a company. All other processes are defined by relating them to the value chain. Put another way, a single value chain can be decomposed into major operational process like Market, Sell, Produce, and Deliver and associated management support processes like Plan, Finance, HR and IT. In fact, it was Porter’s value chain concept that emphasized the distinction between core and support processes. The value chain has been the organizing principle that has let organizations define and arrange their processes and structure their process change efforts during the past two decades.

As Porter defines it, a competitive advantage refers to a situation in which one company manages to dominate an industry for a sustained period of time. An obvious example, in our time, is Wal-Mart, a company that completely dominates retail sales in the US and seems likely to continue to do so for the foreseeable future. “Ultimately,” Porter concludes, “all differences between companies in cost or price derive from the hundreds of activities required to create, produce, sell, and deliver their products or services such as calling on customers, assembling final products, and training employees…” In other words, “activities… are the basic units of competitive advantage.” This conclusion is closely related to Porter’s analysis of a value chain. A value chain consists of all the activities necessary to produce and sell a product or service. Today we would probably use the word “processes” rather than “activity,” but the point remains the same. Companies succeed because they understand what their customers will buy and proceed to generate the product or service their customers want by means of a set of activities that create, produce, sell and deliver the product or service.

So far the conclusion seems like a rather obvious conclusion, but Porter goes further. He suggests that companies rely on one of two approaches when they seek to organize and improve their activities or processes. They either rely on an approach which Porter terms “operational effectiveness” or they rely on “strategic positioning.” “Operational effectiveness,” as Porter uses the term, means performing similar activities better than rivals perform them. In essence, this is the “best practices” approach we hear so much about. Every company looks about, determines what appears to be the best way of accomplishing a given task and then seeks to implement that process in their organization. Unfortunately, according to Porter, this isn’t an effective strategy. The problem is that everyone else is also trying to implement the same best practices. Thus, everyone involved in this approach gets stuck on a treadmill, moving faster all the time, while barely managing to keep up with their competitors. Best practices don’t give a company a competitive edge – they are too easy to copy. Everyone who has observed companies investing in software systems that don’t improve productivity or price but just maintain parity with one’s competitors understands this. Worse, this approach drives profits down because more and more money is consumed in the effort to copy the best practices of competitors. If every company is relying on the same processes then no individual company is in a position to offer customers something special for which they can charge a premium. Everyone is simply engaged in an increasingly desperate struggle to be the low cost producer, and everyone is trying to get there by copying each others best practices while their margins continue to shrink. As Porter sums it up: “Few companies have competed successfully on the basis of operational effectiveness over an extended period, and staying ahead of rivals gets harder every day.”

The alternative is to focus on evolving a unique strategic position and then tailoring the company’s value chain to execute that unique strategy. “Strategic positioning,” Porter explains, “means performing different activities from rivals’ or performing similar activities in different ways.” He goes on to say that “While operational effectiveness is about achieving excellence in individual activities, or functions, strategy is about combining activities.” Indeed, Porter insists that those who take strategy seriously need to have lots of discipline, because they have to reject all kinds of options to stay focused on their strategy.

Rounding out his argument, Porter concludes “Competitive advantage grows out of the entire system of activities. The fit among activities substantially reduces cost or increases differentiation.” He goes on to warn that “Achieving fit is difficult because it requires the integration of decisions and actions across many independent subunits.” Obviously we are just providing the barest summary of Porter’s argument. In essence, however, it is a very strong argument for defining a goal and then shaping and integrating a value chain to assure that all the processes in the value chain work together to achieve the goal.

The importance of this approach, according to Porter, is derived from the fact that “Positions built on systems of activities are far more sustainable than those built on individual activities.” In other words, while rivals can usually see when you have improved a specific activity, and duplicate it, they will have a much harder time figuring out exactly how you have integrated all your processes. They will have an even harder time duplicating the management discipline required to keep the integrated whole functioning smoothly.

Porter’s work on strategy and value chains assured that most modern discussion of business strategy are also discussions of how value chains or processes will be organized. This, in turn, has led to a major concern with how a company aligns its strategic goals with its specific processes and many of the current concerns we discuss in the following pages represent efforts to address this issue.

Figure 6 pictures Rummler, Porter and some of the other major trends in the management tradition.

Fig. 6

The management tradition

4.3 Balanced Scorecard

One methodology very much in the management tradition is the Balanced Scorecard methodology developed by Robert S. Kaplan and David P. Norton (1996). Kaplan and Norton began by developing an approach to performance measurement that emphasized a scorecard that considers a variety of different metrics of success. At the same time, the Scorecard methodology proposed a way of aligning departmental measures and managerial performance evaluations in hierarchies that could systemize all of the measures undertaken in an organization. Later they linked the scorecard with a model of the firm that stressed that people make processes work, that processes generated happy customers, and that happy customers generated financial results (Kaplan and Norton 2004). In other words, Kaplan and Norton have created a model that begins with strategy, links that to process and people, and then, in turn, links that to measures that determine if the operations are successfully implementing the strategy.

In its initial use, the Balanced Scorecard methodology was often used by functional organizations, but there are now a number of new approaches that tie the scorecard measures directly to value chains and business processes, and process people are increasingly finding the scorecard approach a systematic way to align process measures from specific activities to strategic goals.

4.4 Business Process Reengineering

One can argue about where the Business Process Reengineering (BPR) movement should be placed. Some would place it in the management tradition because it motivated lots of senior executives to rethink their business strategies. The emphasis in BPR on value chains certainly derives from Porter. Others would place it in the IT tradition because it emphasized using IT to redefine work processes and automate them wherever possible. It probably sits on line between the two traditions, and we’ll consider in more detail under the IT tradition.

5 The Information Technology Tradition

The third tradition involves the use of computers and software applications to automate work processes. This movement began in the late 1960s and grew rapidly in the 1970s with an emphasis on automating back office operations like book keeping and record keeping and has progressed to the automation of a wide variety of jobs, either by doing the work with computers, or by providing desktop computers to assist humans in performing their work.

When your author began to work on process redesign with Geary Rummler, in the late 1960s, we never considered automation. It was simply too specialized. Instead, all of our engagements involved straightening out the flow of the process and then working to improve how the managers and employees actually implemented the process. That continued to be the case through the early part of the 1970s, but began to change in the late 1970s as more and more core processes, at production facilities and in document processing operations, began to be automated. By the early 1980s we were working nearly full time on expert system problems and focused on how we could automate the decision making tasks of human experts, and had realized that, eventually, nearly every process in every organization would either be automated, or performed by human’s who relied on access to computers and information systems.

We will not attempt to review the rapid evolution of IT systems, from mainframes to minis to PCs, or the way IT moved from the back office to the front office. Suffice to say that, for those of us who lived through it, computers seemed to come from nowhere and within two short decades, completely changed the way we think about the work and the nature of business. Today, it is hard to remember what the world was like without computer systems. And that it all happened in about 40 years. Perhaps the most important change, to date, occurred in 1995 when the Internet and the Web began to radically alter the way customers interacted with companies. In about 2 years we transitioned from thinking about computers as tools for automating internal business processes to thinking of them as a communication media that facilitated radically new business models. The Internet spread computer literacy throughout the entire population of developed countries and has forced every company to reconsider how its business works. And it is now driving the rapid and extensive outsourcing of processes and the worldwide integration of business activities.

Figure 7 provides an overview of the IT Tradition. It is the youngest, and also the most complex tradition to describe in a brief way. Prior to the beginning of the 1990s, there was lots of work that focused on automating processes, but it was rarely described as process work, but was instead referred to as software automation. As it proceeded jobs were changed or eliminated and companies became more dependent on processes, but in spite of lots of arguments about how IT supported business, IT largely operated independently of the main business and conceptualized itself as a service.

Fig. 7

The information technology tradition

5.1 Business Process Reengineering

That changed at the beginning of the 1990s with Business Process Reengineering (BPR), which was kicked off, more or less simultaneously, in 1990, by two articles: Michael Hammer’s “Reengineering Work: Don’t Automate, Obliterate” (Harvard Business Review, July/August 1990) and Thomas Davenport and James Short’s “The New Industrial Engineering: Information Technology and Business Process Redesign” (Sloan Management Review, Summer 1990). Later, in 1993, Davenport wrote a book, Process Innovation: Reengineering Work through Information Technology, and Michael Hammer joined with James Champy to write Reengineering the Corporation: A Manifesto for Business Revolution (Davenport 1993; Hammer and Champy 1993).

Champy, Davenport, and Hammer insisted that companies must think in terms of comprehensive processes, similar to Porter’s value chains and Rummler’s Organization Level. If a company focused only on new product development, for example, the company might improve the new product development subprocess, but it might not improve the overall value chain. Worse, one might improve new product development process at the expense of the overall value chain. If, for example, new process development instituted a system of checks to assure higher-quality documents, it might produce superior reports, but take longer to produce them, delaying marketing and manufacturing’s ability to respond to sudden changes in the marketplace. Or the new reports might be organized in such a way that they made better sense to the new process development engineers, but became much harder for marketing or manufacturing readers to understand. In this sense, Champy, Davenport, and Hammer were very much in the Management Tradition.

At the same time, however, these BPR gurus argued that the major force driving changes in business was IT. They provided numerous examples of companies that had changing business processes in an incremental manner, adding automation to a process in a way that only contributed an insignificant improvement. Then they considered examples in which companies had entirely reconceptualized their processes, using the latest IT techniques to allow the process to function in a radically new way. In hindsight, BPR began our current era, and starting at that point, business people began to accept that IT was not simply a support process that managed data, but a radical way of transforming the way processes were done, and henceforth, an integral part of every business process.

BPR has received mixed reviews. Hammer, especially, often urged companies to attempt more than they reasonably could. Thus, for example, several companies tried to use existing technologies to pass information about their organizations and ended up with costly failures. Keep in mind these experiments were taking place in 1990–1995, before most people knew anything about the Internet. Applications that were costly and unlikely to succeed in that period, when infrastructures and communication networks were all proprietary became simple to install once companies adopted the Internet and learned to use email and web browsers. Today, even though many might suggest that BPR was a failure, its prescriptions have largely been implemented. Whole industries, like book and music retailers and newspapers are rapidly going out of business while customers now use online services to identify and acquire books, download music and provide the daily news. Many organizations have eliminated sales organizations and retail stores and interface with their customers online. And processes that were formerly organized separately are now all available online, allowing customers to rapidly move from information gathering, to pricing, to purchasing.

Much more important, for our purposes, is the change in attitude on the part of today’s business executives. Almost every executive today uses a computer and is familiar with the rapidity with which software is changing what can be done. Video stores have been largely replaced by services that deliver movies via mail, directly to customers. But the very companies that have been created to deliver movies by mail are aware that in only a few years movies will be downloaded from servers and their existing business model will be obsolete. In other words, today’s executives realize that there is no sharp line between the company’s business model and what the latest information technology will facilitate. IT is no longer a service – it has become the essence of the company’s strategy. Companies no longer worry about reengineering major processes and are more likely to consider getting out of an entire line of business and jumping into an entirely new line of business to take advantage of an emerging development in information or communication technology.

5.2 Enterprise Resource Planning Applications

By the late 1990s, most process practitioners would have claimed to have abandoned BPR, and were focusing, instead on more modest process redesign projects. Davenport wrote Mission Critical, a book that suggested that Enterprise Resource Planning (ERP) applications could solve lots of process problems, and by the end of the decade most large companies had major ERP installation projects underway (Davenport 2000). ERP solved some problems and created others. Meanwhile, workflow applications also came into the own in the late 1990s, helping to automate lots of document processing operations (van der Aalst and van Hee 2000).

5.3 CASE and Process Modeling Tools

The interest in Computer Aided Software Engineering (CASE) tools, originally created in the 1980s to help software engineers create software from the diagrams created by software developers using structured methodologies, declined, rapidly in the early 1990s as companies embraced minis, PCs and a variety on non-COBOL development languages and new object-oriented development methodologies (McClure 1989). The CASE vendors survived, however, by redesigning their tools and repositioning themselves as business process modeling tools. Thus, as companies embraced BPR in the mid-1990s they did it, in part, by teaching business people to use modeling tools to better understand their processes (Scheer 1994).

5.4 Expert Systems and Business Rules

In a similar way, software developed to support Expert Systems development in the 1980s morphed into business rule tools in the 1990s. The expert systems movement failed, not because it was impossible to capture the rules that human experts used to analyze and solve complex problems, but because it was impossible to maintain the expert systems once they were developed. To capture the rules used by a physician to diagnose a complex problem required tens of thousands of rules. Moreover the knowledge kept changing and physicians needed to keep reading and attending conferences to stay up-to-date (Harmon and King 1985; Harmon and Hall 1993). As the interest in expert systems faded, however, others noticed that small systems designed to help mid-level employees perform tasks were much more successful. Even more successful were systems designed to see that policies were accurately implemented throughout the organizations (Ross 2003). Gradually, companies in industries like insurance and banking established business rule groups to develop and maintain systems that enforced policies implemented in their business processes. Processes analysis and business rule analysis have not yet fully merged, but everyone now realizes that they are two sides of the same coin. As a process is executed, decisions are made. Many of those decisions can be described in terms of business rules. By the same token, no one wants to deal with huge rule bases, and process models provide an ideal way to structure where and how business rules will be used.

In the near future business rules will be reconceptualized as one type of decision, and the emphasis will shift to analyzing and managing decisions that occur in processes. The OMG is working on a Decision Management Notation (DMN), and the rules field increasingly reflects ideas derived from David Taylor (Taylor and Raden 2007) and from Barbara von Halle and Larry Goldberg (2010). At the same time Decision Management and the use of Analytics seems likely to be combined (Davenport et al. 2010).

5.5 Process and the Interface Between Business and IT

Stepping back from all the specific software initiatives, there is a new spirit in IT. Executives are more aware than ever of the strategic value of computer and software technologies and seek to create ways to assure that their organizations remain current. IT is aware that business executives often perceive that IT is focused on technologies rather than on business solutions. Both executives and IT managers hope that a focus on process will provide a common meeting ground. Business executives can focus on creating business models and processes that take advantage of the emerging opportunities in the market. At the same time, IT architects can focus on business processes and explain their new initiatives in terms of improvements they can make in specific processes. If business process management platforms can be created to facilitate this discussion, that will be very useful. But even without software platforms, process seems destined to play a growing role in future discussions between business and IT managers.

One key to assuring that the process-focused discussions that business and IT managers engage in are useful is to assure that both business and IT managers begin with a common, comprehensive understanding of process. A discussion of only those processes that can be automated with today’s techniques is too limited to facilitate discussions that can help business executives. Business executives are just as concerned with customer and employee issues as they are with automation issues. While it is impossible, today, to think of undertaking a major business process redesign project without considering what information technology can do to improve the process, it is equally impossible to think about a major redesign that doesn’t call for major changes in how employees perform their jobs. Employees and the management of employees are just as important as information technology and business managers need, more than ever, an integrated, holistic approach to the management of process change.

6 Business Process Change Today and Tomorrow

While many individuals continue to work largely within one of the three traditions we just described, a growing number are struggling to create a new synthesis, which is increasingly referred to as Business Process Management (BPM) and which, at its best, embraces all three traditions.

To organize our discussion of some of the more important efforts under way today, it is useful to have some general framework. The one we are most familiar with describes corporate business process change efforts in terms of levels. Some organizations are only focused on one level. Organizations with a CMM maturity of 2.5 are focused mainly on the Business Process Level. Increasingly, however, as organizations become more mature in managing their processes, they are working on all levels, simultaneously. At the Enterprise Level organizations seek to organize their processes across the entire enterprise, aligning processes with strategies and defining process governance and measurement systems for the entire organization. At the Process Level, organizations are exploring a wide variety of new approaches to process analysis and redesign, and at the Implementation level, new technologies are evolving to support process work. Some of the initiatives at each level can be associated with specific traditions, but, increasingly, as companies seek an integrated approach to process, we are witnessing the evolution of approaches at each level that combine elements of more than one tradition. We will organize the discussion that follows around the current initiatives on these three levels. (See Fig. 8.)

Fig. 8

The business process trends pyramid

7 Enterprise Level Initiatives

Enterprise Level initiatives are focused on strategy, architecture, process governance and on process measurement systems. As companies become more mature in their use of processes and increasingly try to integrate around business processes they continue to place more emphasis on enterprise level initiatives.

7.1 Business Architecture

Enterprise Architecture has always been a concern of those in IT. The focus has traditionally been on identifying how all of the software technologies, applications and infrastructure elements fit together. The leading IT approach to enterprise architecture development was defined by John Zachman (1987), and is usually termed the Zachman Framework. It’s an approach that is very oriented towards classifying elements and storing them in a database. The Zachman Framework mentions processes, but process concerns are simply not a major focus of the Zachman Framework.

Beginning in the early years of this decade, however, Enterprise Architecture began to take on a different meaning, and was increasingly used to not only define IT elements, but to show how the IT elements supported business processes. In effect, senior IT managers have begun to redefine their jobs and consider that they are not so much service providers as business managers who are responsible for using new technology to improve the companies business processes. IT managers who used to try to sell new technologies are now more likely to work with other business managers to see how business processes can be improved. This reflects the fact that IT no longer consists of applications running on mainframes in a special location, but, with the advent of the PC, the Internet, and email, is now integrated throughout every process in the organization. This, in turn, has led those involved in architectural efforts to embrace a broader, more process-oriented view of an enterprise architecture. In fact, the tendency has been to shift from speaking of enterprise to either speaking of Business Architecture or of Business Process Architecture. In essence, the Business Architecture defines how the business is organized to achieve its goals. Then, IT and other groups align their architectures to support the business architecture. At the same time, processes are increasingly aligned with corporate strategies and performance measures to generate architectural models that emphasize alignment and facilitate the rapid identification of related elements when strategic and process change is required (Harmon 2007).

In the US, Enterprise Architecture work has been strongly influenced by recent government laws that require government departments to have and use Enterprise Architectures to justify new initiatives. Although some of these architectures are more traditional IT architectures, increasingly they are modeled on the US government’s Federal Enterprise Architecture Framework (FEAF) and rely on a layered, hierarchical model that emphasizes the alignment of strategy, missions and customer results, and business processes with human and IT resources. (See Fig. 9.) (www.gov.cio/Documents/fedarch1.pdf)

Fig. 9

An overview of the US government’s Federal Enterprise Architecture Framework

The emphasis on process-focused ways of conceptualizing an enterprise architecture have, in turn, led architects to explore ways of representing value chains and high level processes. Today, there is a lot of emphasis on creating a Business Process Architecture and not too much agreement on exactly how to do it.

7.2 Value Chains and Value Networks

For the last 20 years the organizing principle that most business process architects have relied upon has been the Value Chain. Michael Hammer relied heavily on the concept in Reengineering the Corporation which he published in 1993. He urged companies to begin their process work by identifying their value chains and then, as needed, to reengineer each value chain.

In the last decade, however, the value chain has come under attack in academic circles. Those who dislike the value chain approach argue that it is too rigid; that is was developed when most companies emphasized manufacturing operations and focused on making large-scale processes as efficient as possible. In other words, they argue that the idea of the value chain is another artifact of the over emphasis on mass production. As companies become more agile and respond to customers in more creative ways, they argue, companies need a more flexible way of representing the relationships among their business processes.

Value Nets. Most of those who oppose the Value Chain approach support an alternative model that is usually termed a Value Net. There have been several books published on Value Nets. The book that is most cited is David Bovet and Joseph Martha’s Value Nets: Breaking the Supply Chain to Unlock Hidden Profits (Wiley 2000). Recently, IBM’s Global Services group has begun to suggest that companies develop Component Business Models (CBM), which IBM claims it derives from a Value Nets approach. IBM’s Component Business Models offer a very specific and practical approach to organizing a Business Process Architecture, and thus they move the discussion of whether one should emphasize a Value Chain or a Value Net out of the academic arena and make it an issue that business process architects and practitioners will need to consider.

Clearly IBM has thought quite a bit about its Component Business Model approach. Two IBM publications trace the evolution of CBM. The first is a paper by Luba Cherbakov, George Galambos, Ray Harishankar, Shankar Kalyana and Guy Rockham entitled “Impact of Service Orientation at the Business Level.” This appeared in the IBM Systems Journal in April 2005. It clearly lays out the Component Business Model, but seems to suggest that the CBM can be derived from the Value Chain, which seems to come first. The method has apparently evolved since then. In a white paper, Component Business models: Making Specialization Real, issued by IBM Institute for Business Value in August 2005, and authored by George Pohle, Peter Korsten and Shanker Ramamurthy, IBM suggests that a CBM can be developed without reference to a value chain. Recent practice seems to rely grouping similar processes based on interviews and statistics. In either case, the result on an IBM CBM effort is a diagram like the one pictured in Fig. 10.

Fig. 10

IBM’s Component Business Model

An IBM CBM architecture starts by grouping processes into broad categories, which it terms Business Competency Domains. The domains vary from company to company and seem to be an informal way to organize the specific company’s large-scale processes. Typical domains include Managing Customers, Supply Chain and Administration. IBM subdivides those categories into three fixed Accountability Levels: Strategy, Tactics, and Operations to form the basic CBM matrix. Both Strategy and Tactics level processes tend to be management processes. Operations level processes include both core and support processes.

No explicit relationships between the Business Components placed within the matrix are indicated. In other words, if we imagine a company with two value chains, each of which had an inventory process, both inventory processes would be merged here into a single generic Inventory process. Thus, an IBM CBM classifies a set of business processes (i.e. components) but does not suggest how they combine to provide specific value to particular customers. The whole point of the IBM CBM is to avoid showing specific chains of business processes in order to emphasize common, standard processes that are independent of any specific chain.

Reading the Value Net literature, one could easily conclude that Value Nets are primarily being used by consulting companies that are primarily focused on how to assemble unique processes to support one-of-a-kind engagements. The Value Net is just the shelf they keep their skill and knowledge on before they will assemble it in any way necessary to satisfy a given client.

On the other hand, we have encountered clients who increasingly focus on their management competencies and put less emphasis on their core or operational processes. This is often the case when companies outsource manufacturing to China and rely on distributors to market to customers. The traditional core capabilities of these companies have become commodities. Increasingly their new core competencies consist of designing new products and assembling the capital and organizing the overall supply chain needed to bring new products or services to market. In other words, the core competencies of virtual companies are tactical and strategic management processes. For these companies, value nets seem to place more emphasis on the management processes and less on the traditional operational processes.

In a similar way, many companies are focused on building Service Oriented Architectures and want to have a way of thinking of alternative services that can be used in any given process. Other companies are interested in simplifying their ERP systems, and want to standardize similar processes throughout the company to facilitate shifting to a single instance of ERP. And, finally, value net approaches often seem to provide a better way of describing business process frameworks like SCOR and VRM. Suffice to say there are lots of groups that are deemphasizing value chains and focusing, instead, on sets of business processes that can be integrated on an ad hoc basis.

Tight Integration and Efficiency versus Flexibility. Recall that Michael Porter argued that a company should work hard to integrate a value chain. Porter (1996) his primary concern was not efficiency, as such, but the fact that a tightly integrated value chain that focused on executing a specific strategy was much more difficult for a competitor to copy. In other words, you optimize a value chain to not only assure efficiency but to implement a strategy in a manner that gives you a competitive advantage that competitors find it difficult to duplicate. The alternative, which Porter terms “operational effectiveness,” tries to make each individual process as efficient as possible, while ignoring the integration of the processes.

The Value Net theorists and IBM’s CBM approach argue that few companies, today, have the time to integrate and refine their value chains. New technologies and new customer demands keep coming faster and product lifecycles keep getting shorter. Thus, they argue, that companies should conceptualize their organizations as a set of competencies, and to refine the business processes that embody each of the competencies. Then, as specific and unique challenges arise the companies are well positioned to combine these competency-based processes, as needed, to create the large-scale processes they need to satisfy ad hoc customer needs. Obviously IBM’s approach is very much in the spirit of the Service Oriented Architecture (SOA) that increasingly thinks of processes as assemblages created as needed. It’s also very much in line with efforts underway at companies that seek to standardize business processes throughout the company in order to support a single instance (or at least a few instances) of ERP throughout the company.

A tightly integrated value chain can usually produce outputs for the minimum price in the fastest possible time. A flexible value net, assembled quickly, probably can’t produce outputs as efficiently or as cheaply. On the other hand, it can be hard to change a tightly integrated value chain, although it can be done if one designs variation in from the start. In either case efficiency and success will depend on anticipating the right scope and size of the business components one creates. Too large and they won’t snap together to handle the various and changing demands one faces. Too small and one faces too many hassles when one seeks to assemble them for a specific purpose.

Table 1 pictures the two approaches and compares some of the obvious advantages and disadvantages of the two approaches.

Table 1 Advantages and disadvantages of value chains and value nets

The authors who have written about Value Nets have tended to be both defensive and over enthusiastic. They suggest that there is a sharp either-or difference between the two approaches and that everyone will want to shift to the “more modern” value net approach. In reality, we suspect, most large companies will want both. Most large companies have at least some large-scale processes that are done over-and-over. Success in these operations requires efficiency and tight integration. It makes sense to model those processes as value chains and to work hard to make those processes as efficient as possible. In these cases, competitive advantage will clearly reside with tightly integrated processes that support a high quality, low cost strategy. At the same time, most large companies also have large-scale processes that change rapidly and that generate highly tailored outputs. It may not make sense to model those processes as value chains, or to spend too much time trying to integrate all the subprocesses. In this cases competitive advantage will lie with a strategy that emphasizes flexibility.

Overall, however, the business process architects job is not becoming easier. Companies will increasingly need to rely on a variety of different approaches to organize their business process architectures.

7.3 Business Process Frameworks

Business Process Frameworks (also called Operation Reference Frameworks) are one of the most exciting developments in process work in the past decade. Frameworks provide a quick way for a company to establish a high-level process architecture, complete with core, management and support processes, and with measures to use in evaluating performance. The use of process frameworks were driven, initially, by the growing interdependency of company supply chains, by outsourcing, and by a heightened need for a standard vocabulary to facilitate communication between companies that are trying to coordinate how their respective processes can work together. As more companies have decided to create formal business process architectures, however, frameworks have become popular as templates that can be used to help a company quickly create a business architecture.

7.3.1 The Supply Chain Council’s SCOR Framework

The Supply Chain Council’s SCOR Framework is undoubtedly the best known example of a business process framework. The Supply Chain Council (SCC) was established as a nonprofit consortium in 1996. Today, it is a worldwide organization with over 700 members. The Council conducts meetings that allow companies to gather together to discuss supply chain problems and opportunities. In addition, it has been working on a standard supply chain framework or reference model (Bolstorff and Rosenbaum 2007; Poluha 2007).

SCOR is comprised of three levels, as illustrated in Fig. 11. The SCOR Reference Manual defines each level 2 and level 3 subprocess and also indicates what planning and support processes are typically linked to each of process or subprocess. The SCC does not define a fourth level, leaving the specification of level four activities to individual companies. In other words, SCOR defines a supply chain architecture and all of the high-level processes and leaves the technical implementation of the level 3 processes to the individual members.

Fig. 11

The three levels of a SCOR architecture

In a similar way, the SCOR Reference Manual defines metrics for each of the processes in the SCOR framework. Thus, using SCOR a company can quickly characterize its supply chain architecture and choose metrics appropriate to their industry and strategy. Several organizations that track benchmarks are working with the Supply Chain Council and can provide generic benchmarks for SCOR measures for specific industries. Thus a company cannot only create an architecture but also obtain information to determine where their existing processes are superior or deficient.

7.3.2 Other Business Frameworks

The Value-Chain Group has created its own model, the Value Reference Model or VRM, which is similar to SCOR, but more comprehensive and, in some ways, better integrated. Figure 12 illustrates the VRM architecture.

Fig. 12

The Value-Chain Group’s VRM framework

Although Fig. 12 does not show any details, VRM defines an extensive set of Planning and Managing processes. If we wanted to analyze B4:Verify Product in some detail we would not only want to look at the relationships between B3-B4-B5, but we would also look at relationships between B4 and other core processes but also with a variety of planning and managing processes. Consider Fig. 13 which shows some of the basic Level 3 processes that link to B4. Then imagine that each of those processes had four or five inputs and four or five outputs. Thus, the high level processes we find in Frameworks and Business Process Architectures, in general, are often simply nodes in a complex network of relationships and hard to represent in traditional flow diagrams. We’ll consider the implementations of this in a moment.

Fig. 13

Processes linked to B4 in the VRM framework

Another effort to define a complete value chain framework was undertaken by the TeleManagement Forum, a consortium of telecom companies. Their framework is highly tailored to the needs of telecom companies. Thus, it can’t be used by non-telecoms, but it does provide a comprehensive approach for telecom companies.

In addition to SCOR, VRM and eTOM, there are a number of other initiatives underway to create business process frameworks. AQPC offers a framework that incorporates elements of SCOR. ITIL and COBIT are more specialized frameworks that can be used by IT departments. The insurance industry consortium, ACORD, is working on a framework for the insurance industry, the OMG’s Finance Task Force is working on a framework for finance companies and there are probably others we haven’t heard of yet.

All of these framework efforts not only provide companies with an easy way to create a process architecture, but they focus everyone on the various issues involved in the creation and maintenance of a process architecture. There is already talk about how to best model frameworks and there are software tools being developed to help companies use the various frameworks. ISSSP has a SIG focused on how to integrate SCOR models with Six Sigma development efforts and similar initiatives will undoubtedly appear in the next few years. Once companies accept the idea that they don’t need to create their own process architecture from scratch, many different aspects of process work will gradually change.

7.4 Roger Burlton, Process Scope, and Value Chain Diagrams

Roger Burlton, a well-known process consultant, is also very much in the management tradition and his book, Business Process Management, published in 2001, is, as far as we know, the first book to use the term BPM in its modern sense (Burlton 2001). As with all those working in the management tradition, Burlton emphasizes the need to align organizations from the top, down, to assure that processes are measured and can be shown to support customers and strategic goals. Similarly, he puts as much emphasis on the management and the way employees implement the processes as on the formal organization of the processes themselves.

Just as Rummler is associated with process flow diagrams (Rummler-Brache Diagrams) that include swimlanes and a top line for the customers of the process, Burlton is associated with Process Scope Diagrams or IGOEs (Inputs, Guides, Outputs and Enablers). (See Fig. 14.)

Fig. 14

Burlton’s Process Scope Diagram

Scope diagrams represent an extension of an earlier type of diagram found in a US Air Force methodology – IDEF – but extended by Burlton and others to support high-level process analysis work. IGOE diagrams are particularly useful for analyzing the problems associated with the types of processes you find in process architectures and in frameworks like SCOR and VRM – processes that linked, in complex ways, to a variety of other core, management, and support processes. They are also useful for emphasizing the role of policies and rules and management and employee issues that are largely ignored in traditional flow diagrams.

The process-in-scope is placed in the middle box. Inputs and outputs are then examined. The sources of the inputs and those who receive the outputs are also identified. Then, in addition, one looks at Guides – information that controls the execution of the process, including business rules and management policies – and we look at what Enables the process, including employees, data from IT applications and the physical layout of the work environment. As we define the flows into and out of the process-in-scope, we look for problems and we also begin to define how we will measure the effectiveness of the process and where the problems seem to reside.

As companies begin to work with process architectures, they will need ways to focus on specific processes and examine all of the relationships between a given high level processes and all of the other processes associated with it. Rummler-Brache process flow diagrams have evolved into BPMN diagrams. We wouldn’t be surprised to find that Burlton’s IGOE diagrams, or something very similar, will evolve into a new standard type of diagram that those interested in process architectures sand frameworks will use to document, analyze and model high level business processes. Some authors have begun to refer to this type of diagram as a value chain diagram.

7.5 Process Maturity Models

CMM, and CMMI remain the most popular descriptions of process maturity, but they are increasingly seen as too oriented towards the concerns of groups like the US Department of Defense, that uses this approach to evaluate contractors. In the past few years we have seen several effort aimed at producing maturity models that are more aligned with the concerns of business process architects.

One effort, the Business Process Maturity Model was developed by Bill Curtis and Charles Weber, researchers who had formerly worked with SEI. Their effort resulted in a process-oriented maturity standard, BPMM, that has been adopted by the OMG. (www.omg.org Search BPMM)

Another effort has been led by Dr. Michael Rosemann and Tonia de Bruin at the Business Process Management Research Group at Queensland University of Technology, in Australia has been undertaken in conjunction with a related effort which is being led by Tom Davenport and Brad Powers at Babson College (Rosemann 2007). This group has been developing a Holistic Model for BPM Maturity. In essence, this work has extended the CMM model to three dimensions and seeks to coordinate a wider range of variables in their characterizations of maturity. This model has been derived from a comprehensive study of related literature in the areas of maturity models and critical success factors of Business Process Management. The model has been applied in a number of case studies and the findings from these case studies motivated further revisions. Rather than simply analyze existing process efforts, the maturity model developed by Rosemann and others has proven useful in helping companies develop their BPM strategies and create roadmaps to guide their ongoing process efforts.

All of these efforts, and undoubtedly others we don’t know about, seek to provide tools that companies can use to characterize how they currently manage processes and suggestions about what steps companies can take to improve their performance. The costs for the user range from a few thousand dollars for a “quickie” evaluation by an individual consultant, to over $100,000 for a very detailed assessment by a certified team. Maturity modeling isn’t the right approach for everyone, but many companies have found these assessments can serve as a way to rally their organization and focus everyone’s attention on a specific process management improvement effort. Others use assessments to establish milestones and then re-evaluate in subsequent years to determine their improvement and maintain their focus. It’s a tool that many companies have found very useful and we will undoubtedly witness more work in this domain in the near future.

7.6 Integrated Process Measurement Systems

Most business process practitioners have struggled to define systematic process measurement systems. It’s relatively easy to define measures that can be used to determine if a specific process is functioning efficiently. It’s much harder to determine if a given process is contributed to customer happiness or company success. What’s needed is a way of systematically aligning company goals with process goals. At the moment the approach that is attracting the most attention is a variation on the Balanced Scorecard system popularized by Kaplan and Norton. Today there are a variety of scorecards, including Six Sigma Scorecards and SCORcards (Gupta 2004; Bolstorff and Rosenbaum 2007; Poluha 2007). The real challenge, however, is not to come up with a scorecard on which to record a variety of measures, but to create a system that aligns the measures from the top to the bottom of the organization.

Most scorecards developed by those working in the Balanced Scorecard tradition have tended to align functional or departmental measures rather than process measures. Using such a system, one begins by creating an Organization Scorecard. Then each division or department creates its own variation on the Organization Scorecard, showing how the division or department will measure its contribution the organizational effort. Similarly, each department or group in each division creates its own scorecard to show how it will support the divisional effort. Once the scorecards are complete and aligned, the scorecards are used to evaluate the divisional, departmental and group managers responsible for the respective business units. A wide variety of organizations currently use some slight variation on this approach.

Imagine tailoring the scorecard approach for a company that is serious about measuring the performance of its processes. In effect we begin with an organizational scorecard, then create scorecards for each value chain, and then for each major process and each subprocess, etc. A few organizations have experimented with this approach.

Most organizations that embrace process management in a significant way, however, also maintain a functional structure and end up with a matrix pattern, with some managers responsible for processes and others for functional units. This requires a dual set of scorecards, as illustrated in Fig. 15. In this case one divides the organizational goals between goals that will be the responsibility of a functional manager and others that will be the responsibility of a value chain manager and then proceed to decompose each independently. Done with care this can provide an organization with interesting insights into which of its goals are really dependent on processes and which are independent of process considerations.

Fig. 15

A dual scorecard system for a company with both functional and process managers

Aligning process measurement systems via scorecard hierarchies is relatively new and there is a lot of experimentation going on to determine the most efficient ways to create and manage these systems (Gupta 2004; Smith 2007).

7.7 Managing Culture Change and Organizational Transformations

In additional to the more or less technical concerns, companies are very interested in tools and techniques that facilitate large scale changes in their organizations. Many companies have launched programs to make managers and employees more conscious of the importance of quality or of processes. Many others have launched programs to achieve some more strategic culture change – sometimes called organization transformation -- as when a company tries to change from a technical to a customer focused orientation, or from being manufacturing-oriented to being service-oriented.

Anyone who wants a trivial example of this need only look at the HP-Compaq merger. HP was well know as an engineering oriented company that toward operational excellence and wasn’t very good at marketing. Compaq was very much a marketing company. In the heady early days of the merger executives speculated that the new HP would be able to combine the best of both. When the merger initially took place the executive team was balanced between Compaq and HP executives. Two years later there were only one or two Compaq executives still on the executive team. To those who observed the merger at close range it was obvious that the old HP engineering culture had rejected the marketing positioning that was represented by Compaq.

Figure 16 suggests some of the culture change activities that occur and contrasts culture change with concerns about more traditional process methodologies, tools and techniques. Popular books on organizational transformation or culture change often offer platitudes. Undoubtedly it is important to communicate with everyone and meet together and maybe even share a rock climbing experience. Beyond that, however, anyone who has really tried to transform a company knows that it requires a major top-down effort and a very forceful senior executive to drive the changes and a well-structured plan to drive the effort. Organization transformation is about politics and motivation, as well as communication.

Fig. 16

Tools and techniques versus culture change activities

We’ve visited several companies and been told by senior executives that they intend to reorient their companies, to make them more process centric. If all they mean is that they intend to analyze their processes more effectively and begin to gather data on their processes that will support better decisions, then we are usually reasonably confident they can succeed. If, on the other hand they are really talking about an major organizational transformation and they want to create a company, like Toyota’s automotive business, in which every manager and employee obsesses about process and quality, then we are usually much less sanguine about their prospects. Put a little differently, organizational transformation is very hard.

The best cultural change stories we know of come from the Six Sigma community. Six Sigma has often been introduced and strongly supported by the CEO of the company. One thinks of Jack Welsh, at GE, who made a significant portion of every senior executive’s bonus dependent on getting results with Six Sigma. Under those circumstances organizational transformation is much more likely.

Consider, however, the situation discussed by BusinessWeek in its June 11, 2007 issue. The cover story was on 3M and described how 3M hired James McNerney as CEO in 2000. McNerney had previously worked for Jack Welch at GE and promised, when hired, to use Six Sigma at 3M to make the organization for process focused. 3M’s stock was down – it had stayed nearly flat during the hyperactive late 1990s – and most outside analysts thought that 3M was overstaffed. McNerney introduced Six Sigma after laying off 11 % of the workforce (8,000 people). Thousands of 3M staffers were trained as Black Belts and many more received Green Belt training. The company embraced both DMAIC and Design for Six Sigma and began to improve its processes with a vengeance.

McNerney slashed capital expenditures by 22 % from $980 million to $763 million in his first year and was down to $677 by 2003. Operating margins went from 17 % in 2001 to 23 % in 2005. As a percentage of sales, capital expenditures dropped from 6.1 % in 2001 to 3.7 % in 2003. Profits under McNerney grew by 22 % a year.

After four and a half years McNerney left 3M to become the new CEO of Boeing. Given the training and the good results, one might have thought that 3M, a company previously famous for its product innovation focus, might have transitioned to a more process or operationally oriented culture. In fact, according to BusinessWeek, McNerney’s successor at 3M, George Buckley, immediately began to dial back the Six Sigma effort. The major complaint among the 3M people, was that “innovation” was down. 3M had always been a company that promoted innovation. It’s where Thinsulate and Post-Its were invented. The company had historically prided itself on the fact that, at any one time, at least 33 % of its products sales came from products released in the past 5 years. By the time McNerney left the percentage of sales from products released during the past 5 years was down to 25 %. Those who complained argued that Six Sigma is somehow incompatible with innovation. Given growth of 22 % a year and operating margins that grew from 17 % to 23 %, one might have thought that 3M had made a reasonable transition to be better balanced culture. At this point, however, it seems likely that 3M will reject the effort at organizational transformation and shift back to the norms of its earlier product focused, innovation-oriented culture.

As we suggested: culture change is hard. It takes a massive, sustained effort, and even then it often fails. Clearly anyone interested in process change is going to want to pay close attention to developments in this area in the years ahead.

8 Process Level Initiatives

Process Level Initiatives focus on projects that seek to create, redesign or improve specific business processes. At this level, companies are interested in methodologies and tools that they can use to undertake business change projects.

8.1 The Emphasis on Innovation

Suddenly Innovation is a very hot term. It’s recently replaced Agile and Excellence as the accolade of choice in the business press. It might even replace BPM as a popular way to describe process initiatives. Merriam Webster’s Collegiate Dictionary suggests that Innovation involves: (1) introducing something new, which can be (2) an idea, a method, or a device. The Oxford English Dictionary suggests the word is derived from Latin, where it referred to the introduction of novelty and that it was first used in English, in something like its current meaning, in 1,297. Clearly we are not talking about a new concept here. Equally clearly, businesses have always tried to be innovative. An entrepreneur creates something new when he starts a new business and a manager is innovative when he introduces a new process. Marketing is innovative when they introduce a new ad campaign that gets a lot of attention and New Product Development innovates when they use new technology to create a new product or service.

If we focus more narrowly on innovation in the context of process change, we can divide the recent literature, very roughly, into three broad piles. One school stresses creativity and focuses on brainstorming and a variety of related techniques that can help teams of people think of alternative ways of accomplishing a task. This school might be summed up as the creative thinking school.

A second school derives from the work of Genrich Altshuller, a Russian theorist who has created a systematic or “engineering” approach – called TRIZ – which can be used to examine problems and generate new possibilities. TRIZ is a Russian acronym that means something like the theory of inventive problem solving, and it was originally developed in conjunction with work on patent analysis (Altshuller 1984). Most of the early interest in TRIZ, in the US, was generated by Six Sigma practitioners who adopted TRIZ for use with Six Sigma improvement efforts (Silverstein et al. 2005). Recently, Howard Smith has written a wonderful series of columns for BPTrends in which he has shown how TRIZ can be used in conjunction with process redesign (Smith 2007).

The third major use of the term Innovation is being driven by Michael Hammer, who has written on the importance of innovation (Hammer 2004). Hammer contrasts Innovation with Improvement and suggests that there are times when you simply want to improve existing processes and then there are other times when you want to innovate and completely change the way you do business. In other words, Hammer is simply using Innovation as a synonym for reengineering.

We’ve heard people argue that innovation distinguishes between process improvement and process redesign. Hammer seems to suggest that innovation distinguishes between reengineering and either redesign or improvement. We don’t think either distinction is very useful. Let’s face it: almost everyone is engaged in introducing new ideas, new methods, and new devices. Some are “newer” than others, no doubt, but everyone is looking for new ways to get things done. Clearly if we are going to make sense out of Innovation we are going to need a continuum. The best continuum that we have found is provided by Charles A. O’Reilly III and Michael L. Tushman. O’Reilly and Tushman review a wide variety of different examples of innovation and end up proposing the continuum pictured in Fig. 17 (O’Reilly and Tushman 2004).

Fig. 17

The O’Reilly-Tushman innovation continuum

In the area above the bold arrow in Fig. 18 we describe the three categories that O’Reilly and Tushman use to map the various examples of innovation they studied. Below the bold arrow we have listed the three general approaches to process change. Obviously Fig. 17 is a continuum and there are all kinds of instances that would lie on the line between Incremental Innovations and Discontinuous Innovations, but at least this figure suggests why all kinds of people will be using the term Innovation to mean different things. Once you realize that innovation is usually just a synonym for process or product change and accept that there is a whole continuum of possibilities, then the trick, for a given company, becomes a matter of getting the mix right.

Fig. 18

A process complexity continuum

Everyone is going to hear a lot more about innovation in the years ahead (Seidel and Rosemann 2008). Getting a good idea of what’s involved, and focusing on what’s important, and what can be used at your company today is important. Similarly, every reader should understand that there will be a lot of nonsense peddled in the name of innovation and should try to avoid getting carried away by either narrow definitions or by the spurious correlations that always seem to accompany any hot new business jargon. The bottomline, however, is that if management wants to talk about innovation, then processes practitioners should be prepared to say, we can make innovation happen.

8.2 Analyzing and Modeling Complex Processes

Another area of process work that is receiving a lot of attention involves the analysis and modeling of complex processes. There are different ways of describing complex processes. Some emphasize that they are unique – as when an engineering firm creates a process to create a unique product. Some industries refer to them as Cases. Keith Harrison-Broninski has written extensively about them and has emphasized that collaborative processes that require people to network to find unique solutions (Harrison-Broninski 2005). We sometimes think of them as expert systems – processes that would require tens of thousands of rules if one were to try to describe the decision processes involved. The OMG has recently issued a request for information about what it terms Dynamic Business Processes. However you describe them, we all recognize that there are processes and activities that are very difficult to analyze or describe.

It’s easy enough to describe complex processes a very high level, of course, you simply create a box called “Design Software Architecture,” “Manage Marketing,” or “Write Business Plan.” As you begin to drill down, however, you realize just how little we know about how these activities are actually done. These are processes that – given current technologies – are impossible to automate in a cost-effective manner. In other words, complex processes challenge our ability to define the specific procedures involved.

Figure 18 suggests a continuum from simple to very complex processes. Manufacturing production line processes were easy because they involved watching what people do. Many service processes are more complex, but can still be define without too much difficulty. At the other extreme from procedures, however, there are complex or dynamic processes. Most companies don’t focus on defining the jobs, but concentrate, instead, on hiring people who have already proven they can perform the activities.

As we already suggested, expert systems developers were focused on this type of process in the late 1980s. The expert systems effort failed to create useful applications, in even narrowly prescribed domains (e.g. Meningitis Analysis), not because they couldn’t capture the thousands of rules a human expert used, but because they couldn’t maintain the rule bases. A human expert is always learning and changing his or her rules as the environment changes and knowledge evolves. Using existing techniques, an expert system is out of date the day after its completed.

We recently looked at a BPMS tool, the EMC Documentum BPM Suite, that has introduced a way of dealing, indirectly, with some of the more complex collaborative activities process modelers encounter. In essence, a developer creates a special type of activity, which the EMC product calls an “e-room.” When an input is made to an instance of the activity when the process is being executed, several employees associated with the activity are notified and can create a web dialog which focuses on creating the desired output. If we were to define some of the activities that make up an e-room process, we would find activities like: Name project, identify who should be involved, send emails inviting people to e-meeting, define steps in project, define roles for team members in project, etc. In effect, the BPMS product avoids the problem of analyzing the activity and simply recognizes that people will need to collaborate to arrive at a solution, and then provides groupware to facilitate their collaboration.

Another approach to complex process analysis is termed Cognitive Task Analysis (Crandall et al. 2006). When we first started analyzing human performance problems, in the late 1960s, the techniques we used were generally termed “behavioral task analysis.” This term reflected the dominant trend in psychology in the late 1960s – behaviorism – which stressed observation of overt activity. By the late 1970s, however, most academic psychologists had returned to the study of cognition. Using new techniques, derived primarily from work with computers, psychologists began to conceptualize human performers as information processing systems, and ask questions about the nature of human cognitive processing. The new cognitive psychology put its emphasis on observation and was at least a rigorous as behaviorism. An early classic of cognitive task analysis was Allen Newell and Herbert A. Simon’s Human Problem Solving. In Human Problem Solving Newell and Simon analyzed a variety of human cognitive tasks, including cryptarithmetic, logic, and chess playing and reached a variety of interesting conclusions that formed the basis for several decades of work in both cognitive psychology and artificial intelligence (Newell and Simon 1972). Indeed, it could be argued that their work led directly to expert systems and, more recently to Cognitive Task Analysis. The key point to make here, however, is that psychologists and computer scientists spent several years, in the early 1980s developing techniques to capture human expertise and embed expert knowledge in software systems.

The work in cognitive psychology led to the development of expert systems. They have not provide very useful, but the same techniques are now being used in business rules analysis efforts and in cognitive task analysis, which relies on many of the techniques used in expert systems design. Object models are constructed to describe the concepts and knowledge structures used by the human decision makers and rules are written to describe specific decisions.

The emphasis today, however, is on avoiding expert activities and focusing on the tasks undertaken by knowledge workers. While a true expert, an engineer who could design an M1 Battle Tank, might have models with many hundreds of objects and use ten or twenty thousand rules, the soldiers who diagnose M1 Battle Tank problems in the field might only require a hundred objects and a thousand rules.

The trend, in other words, is to ignore true expertise, which is too hard to analyze or maintain – given our current techniques – and to focus on analyzing the knowledge that knowledge workers bring to bear on their more circumscribed but still demanding tasks. The work of knowledge workers is, of course, very important and valuable, and if we can capture significant portions of it, we can share it, and use it to design processes that can contribute significantly to the value of our organizations. To date, cognitive task analysis has proven very expensive, and is largely confined to complex tasks required by institutions, like military organizations, that need to train large numbers of new recruits to operate very complex equipment in a very short period of time. As more is learned, however, we can hope that new tools and techniques will make it easier to analyze and then automate the more complex tasks in most organizations.

The line between what can be analyzed and automated will keep moving in the decade ahead. The successful process practitioner will want to stay abreast of where the line is at any point in time to assure that the processes he or she chooses to analyze and automate are within the means available at that point in time.

9 Implementation Level Initiatives

The development of specific solutions to business process problems usually occurs on the implementation level. If a process is changed it usually implies that software will have to be developed or changed. Similarly, job descriptions and training programs require changes. In extreme cases, offices will need to be changed to different locations in different countries to support the new processes. Just as there are challenges, methodologies and techniques that are used at the process level, there are other methodologies and techniques that are appropriate to the implementation level.

9.1 Business Process Management Systems (BPMS)

A major change has occurred in this decade. Business people have realized that IT is no longer a support service but an integral element in the company’s strategy. IT managers, for their part, have decided to stop focusing on technology and support, as such, and to focus, instead, on how they help implement business processes. In essence, the description of the goals and workings of business processes has emerged as the common language that both business executives and IT managers speak. This reorientation, has, in turn, led to a sweeping reconsideration of how IT supports business managers and to the development of integrated packages of business process management software suites. Software tools that, a decade ago, would have been described as workflow, business intelligence, rules engines, or enterprise application integration tools and now being integrated together and spoken of as BPMS products (Khan 2004).

No one, today, is exactly sure what BPMS means or how BPMS products will evolve. It’s a complex software market, made up, as it is of vendors who would formerly have said they were in different niches (BI, EAI, Rules, Modeling, CASE), and who are now trying to determine exactly how they work with others to generate a common Business Process Management Software platform. Many users don’t discriminate between modeling tools, like ARIS and Casewise, and BPMS suites like webMethods or webSphere and applications suites with some BPMS capabilities, like BizTalk and NetWeaver. Perhaps its not important to do so at this time, as all are rapidly evolving and each will change as the functionality desired by users, after they have had a change to experiment with the various products, becomes clearer.

In 2003, Howard Smith and Peter Fingar wrote Business Process Management as a clarion call for companies to develop and use BPMS products to automate and manage their business processes. Smith and Fingar envisioned a world in which business managers would be able to glance at computer screens and see how their business processes were performing, and then, as needed, modify their processes to respond better to the evolving business situation. In other words, BPMS was to be a new type of software – a layer of software that sat on top of other software and managed all the people and software elements required to control major business processes. It is worth stepping back and asking to what degree that vision has been realized.

With a few exceptions, the BPMS software market has not evolved from scratch. Instead, the BPMS vendors were already in existence, offering workflow, documentation, rules engines, enterprise application integration (EAI), business intelligence (BI), or even ERP applications. Vendors from each of these older software domains have rushed to modify and expand their software products to incorporate capabilities associated with an evolving idea of what a BPMS product might include. Thus, workflow vendors have added EAI and vice versa. Most vendors have added a rule capability and incorporated BI (zur Muehlen 2004).

There has been a lot of consolidation as the various vendors have acquired each other to assemble the right set of capabilities. For all that effort, there is still, as of 2008, a very vigorous BPMS market with at least 15 vendors fighting for market share. At this point the platform vendors – like IBM, Oracle, SAP, and Software AG – seem to be doing best with process automation projects that are essentially EAI projects. The smaller vendors who are more focused on workflow, however, taken together, still constitute about half the market. And this, in turn, suggests the current immaturity of the 2008 BPMS market. In part, vendors have focused on what they know best. Vendors from an EAI background have focused on automating processes that primarily involve software systems. Vendors from a workflow background have focused on automating processes with lots of human interaction. And that, in turn, means that both are working on relatively small scale processes, or only working on one part of larger business processes.

We are still looking for good case studies that describe large-scale business processes whose managers now monitor and control those processes using BPMS suites. Most “BPMS” products, to date, are, in fact, workflow or EAI projects that could have been done in 2000. They are done by IT and IT manages them. This isn’t to say that they aren’t important automation projects and that business managers aren’t happy to have them in place, but we are only beginning to realize the goal proposed by Smith and Fingar – to create overarching process management systems that business managers can own and control (Smith and Fingar 2003).

If there is a major difference between today’s “BPMS” applications and EAI or workflow applications that would have been build in 2000, it lays in the fact that today’s EAI and workflow systems are built to take advantage of the Internet and, increasingly, a Service Oriented Architecture (SOA). Elementary SOA projects can be done without reference to BPM, but sophisticated SOA projects, to be of value to the company, must be integrated with a deep understanding of the organization’s business processes. Indeed, it is the emphasis on SOA, and the role that SOA infrastructure plays in the thinking of the leading platform vendors, that explains their growing support for BPM and BPMS.

The new emphasis on BPMS and SOA, as the two sides of the same coin, is a mixed blessing for the BPM community. It has attracted the interest of the platform vendors and driven their commitment. At the same time, it has led them to emphasize the more technical aspects of BPMS and make discussions of BPMS sound more and more like discussions of enterprise integration. BPM and BPMS need not get lost when the discussion turns to SOA, but they often do (Inaganti 2007). Or, more correctly, they get relegated to a very secondary role. Like too many IT discussions in the past, SOA developers are inclined to simply ask the business people for “their requirements” and then move on to the serious and complex work involved in creating the infrastructure environment.

None of this is final, of course. We are at an early stage in the development of the BPMS market. Some vendors will go off track and focus too much on SOA and thereby confine themselves to selling products to IT developers. Others, however, still have the vision that motivated Smith and Fingar and others of us and will continue to work on BPMS products that subsume technology to an interface that can support business managers as they interact with the business processes that do the work in their organizations. Large-scale business processes invariably involve a mix of software systems and people and true BPMS products must evolve to support both if they are to really help business managers to manage the processes and their companies.

9.2 Standards and Certification

Because BPMS is dependent on the Internet and various Internet protocols (e.g. UDDI, XML) there have been a variety of efforts to generate software standards that would support BPMS development. BPEL, being standardized by Oasis and BPMN, an OMG standard are good examples.

At the same time, a variety of different organizations are working to formalize the knowledge and the competencies needed by business process professionals. There is a certification program at ASQ. The ABPMP has just released a draft Body of Knowledge (BOK) for BPM. The OMG is working on a set of certification exams for the various process standards it supports, and the IIBA has just released an updated BOK for Process Analysts that incorporates more business process ideas.

Certification and standards always take time to develop and are hard to do when a body of practice is evolving as rapidly as BPM is today, but these efforts will undoubtedly bear fruit at some point in the future.

9.3 Other Implementation Concerns

The other major area of implementation activity concerns techniques for redesign jobs and training and motivating employees and managers to implement and support changing processes. We won’t consider human performance change further at this point, having already discussed Haskett’s work when we considered the process level. Suffice to say that automation and employee empowerment continue to evolve together and each needs the attention of anyone seeking to change processes within an organization.

10 Towards a Comprehensive BPM

We have tried to give readers a feel for the breadth and scope of today’s Business Process Management efforts. In reviewing so many different domains and techniques we have undoubtedly misrepresented some of the details. Our goal, however, was not a definitive history, but, instead, a survey that would suggest how much needs to be integrated and coordinated by any company that would organize and manage a comprehensive BPM effort.

This survey has undoubtedly missed a number of important concerns. We have, however, highlighted some of the key issues that we think will increasingly concern business process practitioners in the near future. These concerns include:

• Enterprise Level Concerns

  • Enterprise Architecture

  • Value Chains and Value Networks

  • Business Process Frameworks

  • Value Chain Diagrams

  • Process Maturity Models

  • Integrated Process Measurement Systems

  • Managing Culture Change

• Process Level Concerns

  • Innovation

  • Analyzing and Modeling Service Processes

  • Analyzing and Modeling Complex Processes

• Implementation Level Concerns

  • Business Process Management Systems (BPMS)

  • Standards and Certification

One could easily argue that any one of these topics could be repositioned at a different level. Similarly, though some topics seem more the concern of one tradition than another, all are being discussed by practitioners from each tradition and some already benefit from efforts that draw on practitioners from each of the major process traditions. In other words, they are emerging as the common concerns of Business Process Management.

While our list may be incomplete and while the names may change, we are confident, that the idea of process, and technologies and methodologies to manage and improve processes, will continue to grow in importance. We even expect to see process courses showing up at the better business schools in the course of the next decade.

What we want to urge, here, is the creation of a Business Process Management discipline that embraces all of the various approaches we have discussed. The world is changing very fast and will change even faster in the near future. The very nature of business models and processes will continue to change rapidly as outsourcing and information systems continue to change the way we organize to create value for customers. Change and business process are two sides of the same coin. Process concepts and technologies are the best way to organize businesses to adopt to change. But the use of process concepts and techniques won’t be nearly as effective if different groups continue to approach process problems from their respective silos. We need an integrated, comprehensive process discipline and process mangers and practitioners who can integrate all of the concepts we have considered, and others besides. It isn’t sufficient to provide process monitoring technology and not concern yourself with what employees must do to help the organization succeed. It isn’t sufficient to focus on managing day-to-day processes without concerning yourself with technologies that will soon render your current approach inadequate. It isn’t sufficient to improve specific processes without a clear idea of how the specific process contributes to other processes, or supports the goals of the value chain or results in a great customer experience.

Ultimately, process practitioners must not be so concerned with decomposing and analyzing, although those skills are very important, but the process practitioner must be a holist who works to synthesize and assure that the performance of the whole organization is optimized to achieve its strategic goals.

There are too many commonplace organizations in the world today. There is an oversupply of productive capacity. And, at the same time there are people who are not being served well, or at all. We need to create the next generation of global organizations that will draw on resources and people from throughout the world to produce products they can tailor and deliver anywhere in the world at prices everyone can afford. At the same time we need to create the techniques and technologies that will allow individuals and small companies to flourish in the niches in between the corporate giants. These are the challenges we face and they will call for a new generation of more sophisticated process practitioners who can integrate everything we know to accomplish these tasks.