Until recently most business process efforts focused on redesigning or improving specific business processes. In the past decade, however, leading organizations have realized that they cannot achieve the results they want by modifying specific processes in isolation from one another. The only way to achieve significant competitive advantage is to assure that all the processes that make up a common value chain are integrated and support each other. Moreover, as organizations have become more international, they have become focused on assuring that they perform processes the same way in each country or region in which they operate. These insights have led organizations to begin to focus on organization-wide process concerns.

In essence, organizations have shifted from trying to improve specific processes to conceptualizing the entire organization as a system of interacting processes, and working to maximize the effectiveness of the whole system. Once executives shift from worrying about specific processes to worrying about all the processes in the organization, they naturally want a business model that shows how all the organization’s processes fit together, a set of business-wide process measures that show how processes support business strategies, goals, and major business initiatives, and models that show all the processes and subprocesses are aligned to achieve the goals of the organization.

Anyone who becomes involved in the analysis of all the process activities at an organization needs an overview to keep track of all the different process concerns. We picture such an overview in Figure P1.1. In essence, we create a matrix that considers two separate types of concerns. On the vertical axis we ask whether the focus is on the organization as a whole, on a specific business process, or on providing resources or support services for one or more specific business processes. On the horizontal axis we consider whether the activity we are focused on is a project with a specific timeframe and goal, or if it is an ongoing activity of the organization. Thus the sell insurance policies process is an ongoing set of activities. Every day employees struggle to sell insurance policies. There is a sales manager who oversees the ongoing activities of those involved in sales. If the sales manager were to decide that the sell insurance policies process was broken and arranged for a team to redesign the sales process, there would be a period of time when the process team was working on the sales process redesign project at the same time the existing sell insurance policies process continued to work to sell policies. When the project team completed the redesign the new sell insurance policies process would be substituted for the current one, the project would end, and the team responsible for selling policies would continue to do so, following a new process.

In Figure P1.1 the vertical axis indicates the scope of the concern. At the top we show concerns that are organization wide. Below that we show concerns that are focused on specific business processes, and on the bottom row we show concerns that involve providing resources or support for one or more processes. The top level is divided into two different concerns. The very top is focused on defining organization strategy, goals, and business initiatives. This is almost always performed by the CEO or an executive committee. Usually, there is a project or a series of meetings to review and update strategy, goals, and initiatives. Then there are the executives who are assigned to track the achievement of the goals and initiatives on a day-to-day basis.

On the second row there are projects to define a business process architecture, including process models, measurements, and occasionally process management systems. Then, on an ongoing basis, there is usually some kind of group to maintain the business architecture and to support groups attempting to improve processes. Process practitioners are only rarely involved in the development of strategy and the selection of business initiatives, but they are almost always involved in the development of a business process architecture.

We’ll consider other levels of Figure P1.1 when we turn to process and implementation concerns, but in this part we will focus on organization-wide concerns and what is involved in developing and supporting organization strategies, goals, initiatives, and all the various components of a good business process architecture.

Organizations that develop a good model of their business processes usually also want to define metrics to evaluate the success of their processes and to specify who will be responsible for managing each of the processes. This entire set of models and measures and the description of the resources aligned to support them is referred to as a business process architecture.

In the 1990s, when companies focused on improving specific processes, most process change was project oriented. One started with a broken process and worked until it was fixed. As companies shift to enterprise-level process work they find that they need to develop tools and organizational structures to support a sustained effort. A business process architecture isn’t a product that can be developed in one push. A business process architecture is usually developed in stages over a period of time. It’s usually easiest to begin with a description of an organization’s processes and then later progress to defining measures and managerial responsibilities. The sophistication of the architecture tends to evolve as managers learn to use it as a tool for strategizing and decision making. Moreover, to be useful an architecture needs to be maintained and that requires an organization to constantly monitor processes and changes and incorporate them into the architecture. Thus, as companies begin to focus on organization-level process concerns, they find that they need to adopt an entirely new attitude and a new level of commitment to generate the desired results.

Restated in slightly different terms, any organization that shifts from focusing on specific processes to organization-wide concerns is making a major shift in its process maturity. It is undertaking a shift from CMM Level 2 to CMM Levels 3 and 4. Today it is common to refer to organizations whose executives decide to commit to organizing around processes as process-centric or process-focused organizations.

In this part we are going to focus on some of the key organization-wide concepts and practices that organizations need to understand and implement to become process-centric organizations.

In Chapter 2 we will discuss organization goals and strategies and business initiatives and how they can be tied to processes and to competitive advantage.

In Chapter 3 we will present an overview of a business process architecture methodology, one approach to defining and implementing the tools and practices needed to manage processes at the organization-wide level. We will also consider what’s involved in understanding an enterprise and defining its major value chains and key business processes.

In Chapter 4 we will consider the idea of a business process architecture. A business architecture defines the major processes in a value chain, establishes their relationships, defines their performance measures, determines who manages each process, and describes how the processes are aligned to other organizational resources, including goals and policies, business rules, IT resources, training programs, and knowledge management systems.

We can’t consider all aspects of a business process architecture in a single chapter, so we focus on modeling processes and resource alignment in Chapter 4, and then consider process measurement in Chapter 5 and management in Chapter 6.

In Chapter 7 we conclude our discussion of enterprise-level concerns by considering how a business process management (BPM) group—or BPM center of excellence—can be used to maintain the business process architecture, provide executives with timely reports, and support the ongoing process activities of an organization. We will also look at a case study in Chapter 7 to see how one organization has managed to implement all of the enterprise-level tools we have discussed in Part I.