Levels of Concerns

Organizations undertake process change initiatives for a variety of reasons. Organizations new to process work usually start by deciding to improve a specific business process. More experienced companies usually have some kind of corporate business process architecture and a business process management (BPM) group assigned to consider all possible process change initiatives, to prioritize interventions, to coordinate efforts, and to document results. Organizations that are more sophisticated usually support a number of ongoing activities that are managed at the enterprise level. These business initiatives may include the maintenance of a corporate business process architecture, the ongoing measurement and analysis of process performance, and some kind of corporate process management. These activities are not typically projects, but ongoing managerial processes performed to support executive decision-making efforts and to define specific process change opportunities.

At the same time, these organizations normally undertake a variety of specific projects to create, redesign, or improve specific business processes. These projects are usually managed by divisional or departmental managers. We refer to these projects as process level concerns.

Allied to the projects at the process level, but at a further remove, are more specific projects undertaken to acquire and install new software applications or to create new training courses that will actually implement changes defined at the process level. Thus, for example, an enterprise-level BPM group might decide that a company supply chain is operating inefficiently. The BPM group initiates a supply chain process redesign effort. The supply process redesign project team undertakes a study of the supply chain, considers options, and concludes that a number of different changes should be made. Once the process level project team’s recommendations are approved by senior management, information technology (IT) launches an implementation level project to acquire new enterprise resource planning (ERP) software to support some of the changes in the supply chain. At the same time, training creates new job descriptions and launches a separate implementation-level project to develop a new training course to provide new employees with the skills they will need to implement the new supply chain process.

One of the major insights we have drawn from studying a wide variety of business process efforts during the past several years is that it is very useful to distinguish between the various levels of concern. Projects or activities at different levels require different participants, different methodologies, and different types of support. We illustrate these three different levels of concern with the business process pyramid shown in Figure I.1.

Throughout this book we will rely on the distinction between different levels of concern to help organize our discussion. We will describe the major process initiatives being undertaken at each of the three levels and present appropriate methodologies for work at each of these levels. Some of the material will be the same as it was in the first edition of Business Process Change, but there are also new insights, concepts, and techniques that have evolved and become popular during the past 15 years. This is especially true at the enterprise level, where business process architectures are now the focus of efforts at leading companies, and at the IT implementation level, where new Business Process Management Software (BPMS) products have become popular. Each of these developments, and others besides, are rippling through all aspects of business process work and effecting subtle changes in emphasis and practice.

The Business Process Trends website (http://www.bptrends.com) has undertaken a survey of its readers every other year since 2005 to determine what companies were doing to support business process change. The questionnaire remains online for a little over a month, and during that time hundreds of people complete the questionnaire. The respondents came from large and small companies from throughout the world and from a wide variety of different industries. Given the size of the response and the distribution of the respondents, we believe this represents the best current data on worldwide business process activity.

Every time we undertake the survey we ask if the respondents’ organizations are active in any aspect of business process change. About 25% of the organizations that respond say they have a major strategic interest in BPM. About 25% say they have no interest or are exploring the possibilities. Everyone else falls in between.

We also asked respondents to indicate what the term BPM meant to them. The largest group of respondents (40%) say that BPM is a “top-down methodology designed to organize, manage, and measure the organization’s performance based on the organization’s core processes.” This response is consistent with lots of other data about why companies undertake business process projects. In bad times, companies seek to make their processes more efficient to save money. In expansive times, companies seek to redesign processes to make them more competitive, to offer new services, or to get into new lines of business. Or they acquire companies and have to integrate the processes used at the two different organizations. In addition, especially during expansive periods, companies look to see if they can gain a competitive advantage by incorporating a new technology. During the past several years much technology-driven work has been a result of developments in Internet and digital technologies and companies have redesigned processes to let customers or employees access information and make purchases via the Web, or to take advantage of the communication efficiencies offered by email or Internet-based phone services.

The fourth major reason for undertaking business process change is perhaps the most interesting, and ultimately the most revolutionary. A growing number of leading companies have begun to believe that a corporate-wide focus on process provides a superior way of managing the company. These companies tend to be in industries that are undergoing rapid, extensive changes. Their senior executives have concluded that they need the insights and the agility provided by a process-oriented approach to management to respond quickly and effectively. These are the organizations that are making major commitments to developing enterprise-level business process tools and management systems to assure that they have aligned all their business resources and functions to their value chains and can manage those processes in something close to real time.

To summarize this more graphically, consider Figure I.2. In this case, we use the process pyramid to suggest changes that have occurred between the emphasis on process that was typical of leading organizations in the 1990s and the emphasis we see at leading organizations today.

In the 1990s most organizations were focused on business process redesign or reengineering projects. Leading companies focused on processes that cut across departmental or functional lines, but most companies concentrated on redesigning processes within specific departments or functional units. At the same time, Six Sigma was popular in manufacturing organizations for process improvement efforts. Toward the end of the 1990s standard or off-the-shelf software applications, such as ERP and customer relationship management (CRM), became a popular way to standardize processes and reporting systems. During this same period workflow systems became popular as tools to automate document-processing systems. In the past 6 years, all of these process change strategies have continued to be popular. Today, however, leading companies are putting more emphasis on developing enterprise-wide business process architectures and corporate performance management systems. They seek to standardize specific processes throughout their divisions and subsidiary organizations to assure that the same ERP or CRM modules can be used throughout the corporation, and they seek to understand their corporate value chains to assure regulatory compliance. At the same time, there is major emphasis on installing new software automation technologies—usually termed Business Process Management Systems (BPMS)—to automate the day-to-day control of processes and to provide real-time performance data for senior management.

This book is written for today’s manager and focuses on the business process change problems today’s managers face. This book was written to educate managers in the best practices available for today’s challenges and to provide practical tips for anyone undertaking the development of a business process architecture, undertaking a business process change project, or considering the development of a BPMS application.

Business Process Change and Management

Every company wants to improve the way it does business, produce things more efficiently, and make greater profits. Nonprofit organizations are also concerned with efficiency, productivity, and with achieving the goals they set for themselves. Every manager understands that achieving these goals is a part of his or her job.

Consider the management of the automobile industry. 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.

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, Henry 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.

Ford’s success is a great example of the power of innovation and process improvement to revolutionize the economics of an industry. Other examples could be drawn from the dawn of the Industrial Revolution or from the early years of computers, when mainframes revolutionized the census process in the United States and began to change the way companies managed their accounting and payroll processes.

The bottom line, however, is that the analysis of business processes and their improvement to increase the efficiency and productivity of companies is a perennial management responsibility. Managers, of course, have other responsibilities, but one of the most important requires that they constantly examine the processes by which their companies produce products and services and upgrade them to assure that they remain as efficient and effective as possible.

Some business process gurus have advocated crash programs that involve major changes in processes. In a sense they are advocating that today’s managers do what Henry Ford did when he created the moving production line. In some cases this kind of radical redesign is necessary. Today’s managers can often use computers to automate processes and achieve major gains in productivity. Similarly, in responding to challenges created by the Internet, some managers have been forced to create new business processes or to make major changes in existing processes. Amazon.com and eBay come to mind. In most cases, however, gradual improvements are more effective.

There are other times, however, when a crash program is too far reaching and a gradual improvement effort would not be enough. These are cases that we refer to as business process redesign projects. They implement a significant change without redesigning the entire process. Many projects that automate a portion of an existing process fall in this category. In some cases, redesign takes place in a series of steps to minimize disruption. A series of modules, for example, could be installed over the course of several months, one after another, with enough time between each change to assure that the employees can adjust as the changes are made.

The Evolution of an Organization’s Understanding of Process

Managers have been thinking about business process change for several decades now. Some organizations are more sophisticated in their understanding of business processes than others. Software organizations, for example, have spent quite a bit of time thinking about the software development process. In the 1990s the Department of Defense (DOD) funded a major effort to determine how the software development process could be improved. This task was entrusted to the Software Engineering Institute (SEI), which is located at Carnegie Mellon University. The SEI/DOD effort resulted in a model of the stages that software organizations go through in their understanding and management of processes.

The SEI model is known as the Capability Maturity Model (CMM). It was initially described in a book, The Capability Maturity Model: Guidelines for Improving the Software Process, published in 1995. In essence, the CMM team defined five stages that organizations go through as they move from an immature to a mature understanding of business processes. These stages were defined using examples from software organizations, but they apply equally to any large organization.

Although the CMM model is more commonly applied to large organizations, the model can also serve as an excellent reference model for small- and medium-size firms. Remember the key point of such reference models is to help you understand where you are today and to assist in developing a roadmap to help you get where you want to go. No one is suggesting that all companies should attempt to follow the model in the same exact way.

The key assumption that the CMM team makes is that immature organizations do not perform consistently. Mature organizations, on the other hand, produce quality products or services effectively and consistently. In the CMM book, they describe it this way:

Watts Humphrey, one of the leading gurus behind the CMM effort, describes it this way:

CMM identified five levels or steps that describe how organizations typically evolve from immature organizations to mature organizations. The steps are illustrated in Figure I.3.

The CMM model defines the evolution of a company’s maturity as follows:

• • Level 1: Initial. The process is characterized by an ad hoc set of activities. The process is not defined and success depends on individual effort and heroics.
• • Level 2: Repeatable. At this level, basic project management processes are established to track costs, schedule, and define functionality. The discipline is available to repeat earlier successes on similar projects.
• • Level 3: Defined. The process is documented for both management and engineering activities, and standards are defined. All projects use an approved, tailored version of the organization’s standard approach to developing and maintaining software.
• • Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
• • Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

The CMM approach is very much in the spirit of the Total Quality Management movement that was popular in engineering and manufacturing during the late 1980s. (The latest version of CMM is termed Capability Maturity Model Integration (CMMI). We will consider CMMI and some alternative process maturity models later in the book.)

Every organization can be assigned a maturity level. Most software organizations studied by SEI were in either Level 2 or 3. In effect, they had processes, but in most cases they were not as well defined as they could be. Their management systems were not well aligned with their processes, and they were not in a position to routinely improve their processes. Put a different way, most organizations today are focused on redesigning specific, departmental-level processes, and only beginning to move to a more comprehensive process architecture. Leading companies today, however, are focused on moving from Level 4 to level 5. They have created comprehensive business process architectures that describe how all the processes fit together (Level 3) and have then moved on to create management systems that measure process performance and assign specific managers with responsibilities for assuring that processes perform as necessary (Level 4). The best organizations have integrated management systems that automatically trigger process improvement efforts whenever there is a failure to achieve targeted process goals (Level 5). This progress reflects the concerns illustrated in Figure I.3.

In this book we will not make any assumptions about where your organization is today. We will, however, put lots of emphasis on how companies document processes, how they develop process architectures that describe how processes relate to each other, and how they align management systems to assure that corporate goals are aligned with managerial goals; and we will stress the importance of routine, continuous process improvement. In effect, this is a book that should help managers conceptualize where their organization should go and provide the tools they need to help with the transition.

The Variety of Options

If there were one way of handling all business process problems, we would be happy to elaborate it. Unfortunately, there are many different types of business process change problems. They vary by the organization’s level of concern, industry, and the nature of the environmental change that needs to be accommodated. Some changes are undertaken to provide executives with the tools they need to manage a process-centric organization. Other changes only require modest improvements in existing processes. Still others require complete redesign of an existing process or the creation of a new process. Some focus on changes in how people perform, while others involve the use of software applications to automate a process. In some cases a software application can be purchased, and in other cases it must be developed and tailored for your specific needs. In a nutshell, there are many different ways to improve or redesign business processes. Managers face options. This book will provide you with an overview of all the options and describe the best practices available to help you choose the approach that is best for your situation.

The Variety of Solutions

One of the problems with the business process field is that various authors and vendors use the same terms in different ways. In this book we will use certain terms in very precise ways to avoid confusion.

Process improvement refers to relatively minor, specific changes that one makes in an existing business process. Every manager responsible for a process should always be considering process improvements. In addition, on occasion, special process improvement efforts are required to get everyone focused on improving a specific process. Six Sigma is a good example of a popular approach to process improvement.

Process design or redesign refers to a major effort that is undertaken to significantly improve an existing process or to create a new business process. Process redesign considers every aspect of a process and often results in changes in the sequence in which the process is done, in employee jobs, and in the introduction of automation. Business Process Reengineering, Business Transformation, the BPTrends Process Redesign methodology, and the Supply Chain Council’s SCOR methodology are all good examples of popular approaches to process redesign.

Process automation refers to the use of computers and software applications to assist employees or to replace employees in the performance of a business process. The use of BPMS tools, workflow systems, or XML business process languages are ways to automate the management of processes or activities. Off-the-shelf ERP and CRM applications are also examples of automation. Similarly, software development methodologies like Rational Software’s Unified Process or the Object Management Group’s Model Driven Architecture are other examples of popular approaches to process automation.

Many authors use the term BPM to refer to process automation efforts. It is used to refer to the fact that, once processes are automated, the day-to-day execution of the process can be managed by means of software tools. Business executives, however, often use the term BPM in a more generic sense to refer to efforts on the part of business executives to organize and improve the human management of business processes. At the corporate level BPM is also used to refer to the development and maintenance of a business process architecture. We will use the term BPM in its most generic sense to refer to how business managers organize and control processes. When we want to use it in the more specialized sense to refer to automated systems, we will use the term “Business Process Management Software” or BPMS.

How This Book Is Organized

This book provides a pragmatic introduction to business process change. It is designed to provide managers with an overview of process concepts and best practices and to explain the options managers face as they seek to improve, redesign, or automate their business processes.

We will start with an overview of the kind of systematic business process improvement methodologies companies have used during the past decade. In effect, Chapter 1 will provide a brief history of business process change, just to assure we understand the basic options and are all using the same vocabulary.

The remainder of the book is divided into three major parts. Chapters 2 through 7 (Part I) consider organization-wide concerns. Chapters 8 through 14 (Part II) focus on process-level concerns. Then in Chapters 15 through 17 (Part III) we discuss implementation-level concerns. Chapter 18 pulls together all of these concerns and provides some final advice. Now let us consider this plan in a little more detail.

Notes and References

All references to anything published by BPTrends can be accessed on the BPTrends website: http://www.bptrends.com. All information on the BPTrends website is available without charge.

Specifically, BPTrends has published a series of surveys. To access the complete survey cited in this introductory chapter go to http://www.bptrends.com and click on the tab marked BPTrends Surveys.

McCraw, Thomas K. (Ed.), Creating Modern Capitalism: How Entrepreneurs, Companies, and Countries Triumphed in Three Industrial Revolutions, Harvard University Press, 1997. There are several books that describe the Industrial Revolution and the birth of modern corporations. This is my favorite, and it is where I got my basic information on Henry Ford and the Ford Motor Company.

Paulk, Mark C., Charles V. Weber, Bill Curtis, and Mary Beth Chrissis (principal contributors and editors), The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995. This book provides a good introduction to the concepts underlying CMM. To access information about CMM check http://www.esi.cmu.edu/cmm.

Chrissis, Mary Beth, Mike Konrad, and Sandy Shrum. CMMI: Second Edition: Guidelines for Process Integration and Product Improvement. Addison-Wesley, 2007. This book provides a summary of where CMMI is today.