A Comprehensive Business Process Method

To organize our discussion of enterprise-level concerns we will begin by considering the method taught by BPTrends. This is not the only possible approach, but it is one possible approach, and it provides a good starting point for our discussion of how we might systematically address concerns at the enterprise level. Figure 3.1 provides an overview of BPTrends’ process change methodology. In this figure we actually picture two complementary methods: one for business architecture development and one for business process redesign projects. The transformation planning shown at the top of the figure is not part of the BPTrends method, but rather a set of activities that senior executives undertake. Similarly, the actual development of training, facilities, or software systems that takes place at the bottom of the figure is undertaken by more specialized groups using their own methods. The BPTrends method focuses on structuring two different sets of activities: those involved in creating a business process architecture and those involved in undertaking a specific business process redesign project. The business process architecture method is concerned with creating the tools that a company can use to organize and manage all its process work. This method does not so much define a project as an ongoing effort on the part of management to create and maintain the tools they need to function as a process-centric organization. The process-level method is similar to many other process improvement methods and is designed to be used over and over again. The two methods are connected, in practice, because it is the tools created by the business architecture effort that enable an organization to define, prioritize, and manage all its ongoing business process change efforts. In Part I of this book we will focus on the concerns defined by the business process architecture method. In Part II we will consider specific business process change methods.

We show transformation planning in a box above the phases in the business process architecture effort. This is to remind us that those working on a process architecture must be constantly interacting with the strategies, goals, and business initiatives defined by the organization’s senior executives.

Understanding your business. The first phase in BPTrends’ business process architecture method focuses on understanding the organization as a whole. This phase often involves the executive committee and the senior executives of the company. It is absolutely critical that everyone understands and agrees on the basic value chain processes the company supports and the strategic goals each value chain is responsible for achieving.

The understand business context phase begins with an analysis of the organization to define the organization’s strategy, goals, and key relationships and gradually refine everyone’s understanding of the organization and its stakeholders, including stockholders, customers, suppliers, distributors, and various governmental entities. During this phase the value chains of the organization are defined. The goals of each value chain and the relationship between core processes and managerial and support processes are also specified. Thus a specific business process architecture is developed for each individual value chain. As a result of this phase everyone agrees on the basic value chains and the organization is in a position to proceed to define architectures for each value chain.

Defining a business process architecture. The second phase begins with the selection of a specific value chain and the commitment to create a business process architecture for that value chain. At a minimum each value chain is defined by elucidating the core business processes and subprocesses in the value chain. Then, using the business processes defined in the architecture the team proceeds to define how each process will be monitored and measured. Depending on the needs of the organization, resources can then be aligned to the processes in the process architecture. Some companies will want to align policies and business rules with their processes. Some will want to align IT resources, like software applications and databases. Others will want to align HR, including jobs, skill requirements, training programs, and knowledge management programs.

There are different approaches to the creation of a business process architecture. Historically, the most popular way to define a company’s processes has been to put a group of managers in a room and discuss how things get done. Usually, following much discussion the group arrives at a high-level overview of the company’s major processes. Today, that activity, and the associated activity of defining process measures, can be considerably accelerated by using a business process framework. The BPTrends enterprise method usually relies on using the extended version of a business process framework to help managers develop a basic business process architecture and measurement system with a minimum fuss.

Define process governance. Once the business process architecture is in place and measures are defined for each of the major processes the team should move on to the development of a plan to manage their organization’s business processes. Different organizations take various approaches. Some rely primarily on a functional (departmental) organization. A few rely on a process-oriented management organization. Most end up with some kind of matrix that includes both functional and process managers. We will consider the options in Chapter 5. At the same time the enterprise process team will want to consider how to measure and monitor the performance of process managers. Many companies rely on a Balanced Scorecard–oriented approach, either using a portion of each manager’s scorecard to track his or her performance as a process manager or creating a dual scorecard system with one set of scorecards monitoring process work and another monitoring functional responsibilities.

During this same phase the team will probably also create a business process management (BPM) group (or BPM center of excellence) to provide the staff to help senior executives monitor processes, maintain the architecture tools, and undertake ongoing responsibilities, such as prioritizing project change projects.

Keep in mind that these phases will need to be adjusted to the individual organization. One organization, for example, might already have an existing BPM center of excellence. In this case it would probably be the BPM center of excellence that creates the architecture. In other cases an ad hoc group will be established to create the architecture and then to create the BPM group to maintain it. When attempting to change the way things are organized at the enterprise level, one always starts with what is already in place and moves forward from there.

Day-to-day management of enterprise processes. An enterprise methodology focuses on helping an organization develop the basic tools needed to create and manage a process-centric organization. Once the basic tools are in place and a BPM group is established the ongoing maintenance and use of the tools becomes a matter of execution. We will discuss what the day-to-day governance of a process-centric organization entails and provide a case study to show how a process-centric organization functions.

Strategy and Enterprise BPM

Everything should begin with a corporate strategy. In most cases the corporate strategy has already been developed by an executive committee or a group whose major responsibility is the creation and review of strategy. Thus, in most cases the business process team that is charged with developing enterprise-level process tools for the company will simply establish a working relationship with the strategy group. In fact, in most large companies strategy work occurs on many levels. There is an enterprise strategy, strategies for specific value chains, and in many cases strategies for major business processes. It is not uncommon to speak of a supply chain strategy or a marketing strategy. Thus, even if a corporate group creates the company strategy, the business process group may be heavily involved in ensuring that the corporate strategy is reflected in the specific strategies of the individual business processes.

Figure 3.2 illustrates one way of thinking about the relationship between the work of a process group and a strategy group. The ongoing work of the strategy group is described in the upper box. The executive team may spend a good bit of their time considering what the competition is doing or how customer tastes are changing; however, ultimately, to determine if the current strategy is working they need some kind of performance measures. Specifically, they need to know which activities are generating what type of results. If there was no process group the strategy group would need to generate some kind of map of the organization and determine how to associate metrics and performance outcomes with the entities on their map. Put a different way, the strategy group needs some tools and they need a constant flow of data.

Managers and the BPM group need information about how the organization is divided into value chains, processes, and subprocesses and how specific processes are measured and managed, and they also need to keep track of changes in performance. In essence, an enterprise process method is just a systematic plan for generating the tools that managers, the strategy group, and the BPM group need to do their work. The creation of a BPM group is simply an efficient way of ensuring that the needed tools are maintained and the needed data are gathered and distributed to those who need them in a timely manner.

In the past most organizations have undertaken strategy efforts without the availability of good process tools. Since the 1980s, relying on Michael Porter’s work on value chains, there has been a significant shift. Strategy no longer depends on data drawn primarily from functional units. Today, strategy depends on processes, how processes interact with each other, how process performance is measured, and a deep understanding of how processes interface with customers. Thus, with or without a formal enterprise process, organizations are engaged in defining enterprise-level tools that will provide the structure and the data needed to make important day-to-day decisions and to support key initiatives, like the entry into new markets, mergers, acquisitions, or outsourcing. As we have already suggested, a business process enterprise method simply provides a systematic way to achieve that goal.

Understand the Enterprise

An enterprise methodology begins with a phase that focuses on understanding the enterprise. During that phase we develop a generic diagram of the enterprise, define value chains, and identify stakeholders. This chapter focuses on understanding enterprises.

The Traditional View of an Organization’s Structure

In Improving Performance, Rummler and Brache provided a nice example of the distinction between the thinking of those who rely on organization charts and those who focus on processes. When asked to describe their organizations, most managers will draw something like the traditional organization chart shown in Figure 3.3. In some cases they will simply give the various groups or departments names, such as marketing and production. In other cases they will detail who manages each department and to whom they report. This kind of information is often useful. But, it is important to notice what kinds of information a traditional organization chart does not provide.

First, an organization chart does not show the customers. Second, and equally important, it does not show the products and services the company provides to customers, or where the resources needed to create the products and services come from in the first place. It certainly does not show how work flows from one activity to another before ultimately being delivered to a customer.

A manager might reply that an organization chart is not expected to show such things, and we would agree. Then, we would ask our manager to show us whatever charts he or she uses that do show those things. Most managers are not prepared to create or show diagrams that provide a systems or process-oriented view of their organizations.

Traditional organizational charts are often described as a vertical view of the organization. The departments or functional groups within a department are referred to as “silos,” similar to the tall, windowless grain storage buildings one sees in farming regions of the United States. When managers conceptualize their organizations as vertical organizations they tend to manage in a vertical manner. They focus on who reports to whom, and set goals for each group independent of the others. At the same time silo thinking leads managers to focus on making their departments as efficient as possible, without much regard to what is going on in other silos. When cross-departmental issues arise they tend to get bounced up the reporting chain until they reach a manager who is responsible for the work done in both departments. That, in turn, guarantees that senior managers spend much time resolving cross-functional or interdepartmental problems that could have been better resolved at a lower level by people with a much better grasp of the specific problem. And, of course, the time that senior managers use for resolving these cross-functional disputes is time they do not have to focus on customer concerns, on creating new strategies, or on improving productivity.

This problem has been widely discussed since the late 1980s. Many books have been written about the problem. Silo thinking tends to lead to departmental or functional suboptimization. This often occurs at the expense of the whole organization. An obvious example would be a sales department that gets praised for selling lots of products without considering that production cannot deliver the products in time to meet the delivery dates promised by the salespeople. Or it could be an engineering department that creates a product that is efficient to manufacture, but does not have the feature set that marketing has promised or that salespeople can most readily sell. In essence, suboptimization occurs when one process within one silo is improved at the expense of other processes in other silos, or at the expense of the value chain as a whole.

Managers, like all people, tend to think in terms of their models. There is a saying in the medical profession that, when undertaking a diagnosis, physicians only find what they are looking for. Managers are the same. To think of organizations as wholes, managers need to learn to visualize their organizations with diagrams that provide insight into how their organizations actually work, as a whole. They need to think in terms of organizational systems and value chains, rather than thinking primarily in terms of divisions, departments, or their own functional unit.

A Case Study of Organization Transformation

John Roberts is a professor of strategy and management at Stanford University and the author of a popular book, The Modern Firm: Organizational Design for Performance and Growth. I discussed the book on the BPTrends website when it first came out; at that time I remarked on the fact that the book only had one reference to process in the index and that referred to process control. I did not find this unusual because most business schools do not, in general, have a business process orientation. Despite this, however, The Modern Firm is a good book with much interesting information about how companies approach strategy and organizational design. Recently I found myself reading The Modern Firm while researching a strategy question. As I read it, I became focused on a case study describing how BP made strategic and organizational changes to improve the performance of the firm. It is a great case study, from my perspective, because it has so much to say about the importance of business processes, and I decided to share it with readers, while putting my own spin on Roberts’ explanation.

The case occurs in a chapter on Organizing for Performance. From Roberts’ perspective it is a matter of developing an efficient reporting structure and disaggregating overly complex organizational designs. The chapter focuses on BP, a major oil and gas company. In the early 1990s, BP was in trouble and the financial crisis of 1992 nearly resulted in bankruptcy. By the early 2000s the firm recorded some of the highest profits ever reported by any firm in history. The question that Roberts asks is how BP managed the transition.

The transition began in 1989 when BP hired Robert Horton as CEO. When Horton was hired, BP’s corporate headquarters was a 32-story building filled with staff people. The company’s performance was declining and the company was heavily in debt. Horton’s initial days were focused on meetings with some 86 different executive committees.

Horton’s first decision was to focus on the organization’s core business and to sell businesses that did not support that focus. As a result of several executive meetings he decided that BP was composed of three “business streams.” (We would have called them processes, but more information will be given later.) The three streams were as follows:

• • Upstream Oil and Gas Exploration and Production
• • Downstream Petro Refining and Marketing
• • Downstream Petrochemical Products

The upstream process fed both of the two downstream processes. Horton concluded that there was no special value generated by internal transactions among the three streams and that they could be decoupled and run independently. (Put a different way, BP’s upstream unit could sell to any of several refining companies and BP’s downstream petro refining and marketing unit could buy oil and gas from any of several production companies. In all cases the only important consideration was getting the best price).

Once Horton reached this conclusion, he changed the management structure and appointed individuals to head each of the three “streams” and then proceeded to assign responsibilities to the three stream managers while simultaneously eliminating jobs at the corporate headquarters. (In effect, Horton had identified three value chains and had created a business process manager for each chain.) At the same time, Horton began to sell the business units that were not part of one of the three core streams he had identified. From 1992 to 1995 BP decreased from 97,000 employees to approximately 50,000, and the staff at BP’s headquarters was reduced by 80%.

In 1992 BP had a loss of $811 million and by 1994 BP had a profit of $2.4 billion. During the same period BP’s debt decreased by $4 billion. After starting the transition to an organization structure based on the three core streams, Horton was replaced by David Simon, who proceeded along the same lines that Horton had defined.

During this period the biggest changes were occurring within the upstream unit, headed by John Browne (who was to become CEO in 1995). Browne began by asking the question: What is the BP upstream good at? The upstream team concluded that it was good at exploiting large hydrocarbon deposits that required sophisticated technology and heavy capitalization. Other competitors could exploit smaller deposits more efficiently, but BP could manage high-risk projects better than its competitors. This strategy led BP to focus on areas like the North Sea, the North Slope of Alaska, and Russia.

Browne organized the upstream unit (called BPX for BP eXploration) into regional operating companies (ROCs) that each consisted of a specific field, or a closely related group of fields, and assigned independent managers for each of the ROCs. He also significantly increased the responsibilities of each ROC manager.

In the past BP had focused on aggregated performance numbers. Browne switched to performance data for each ROC so that the performance of each ROC could be compared. Henceforth, each ROC head negotiated directly with BPX for his or her budget. At the same time, Browne tied not only executive compensation, but all employee incentives, to the performance of their individual ROCs. (Put a little differently, Browne broke an abstract “value chain” into several concrete instances of a generic value chain and then assigned process managers for each specific value chain. And he made compensation dependent on the performance of the specific value chain.)

As time passed the ROCs began to complain that some of the comparisons were unfair. At the same time, Browne and the ROC managers realized that even as they were becoming more efficient, they were failing to share knowledge and insights among the various ROCs. At this point Browne and his team classified the various ROCs according to where they were in the BPX life cycle. All ROCs were divided into one of four groups:

• • Exploration Rights Being Developed
• • Assets Being Brought into Production
• • Full Plateau Production
• • Fields in Decline and Ending Production

ROCs in the same life cycle group were termed “peer groups” and were compared during evaluations. They were also encouraged to share information. (In essence, BPX realized that there were subprocesses within the overall value chains that were in fact common processes, and that they should use the best practices achieved by any one instance of a common process to improve all similar processes.)

Roberts believes that Browne’s innovations were directly tied to BP’s increased success, and after Browne become CEO of BP in 1995, his approach was applied across the entire company. Roberts also believes that BP’s successes are the result of strategic focus and better organizational design. Obviously, how the reader understands the example will depend on how he or she understands BPM. We believe that BPM is in essence a management philosophy, and that it involves doing everything possible to improve the performance of the organization. Thus, we believe those involved in BPM are as much concerned with customers, employees, strategy, and the management of the organization as they are with workflow or the automation of activities.

We normally recommend that every organization begin by creating a strategy that defines its core strengths. We would then recommend that it then move on to creating a business process architecture, as Horton and Browne did, to define how its processes support its strategy. Then, we would recommend that managers be assigned the responsibility for managing the processes, whether they are called processes, streams, business units, or value chains, and that their compensation be tied to results. We think it is really important to do as Browne did and set process incentives, not just for senior managers, but for all employees, to ensure that everyone understands exactly what they do to generate value for the firm and that they are rewarded on the basis of how well they do it.

Finally, we believe that modern organizations must also work to identify common processes and use that information to ensure that best practices are used for all similar work. Although Roberts did not mention it, common processes tend to use similar software and one key to efficiency is to ensure that the same software modules are used for common processes. The alternative is a proliferation of enterprise resource planning modules, each supporting a similar process, but each tailored in a slightly different way—creating a maintenance nightmare.

John Roberts terms the BP case study a triumph of strategic focus and organizational redesign. We call it improved process management. Perhaps what you call it does not ultimately make much difference. But, how you explain it does. Roberts assumes that BP was improved because great managers arrived at uniquely insightful solutions. We would not want to disregard the important role of great managers, but we believe that overall what the managers did was more predictable than that. BP evolved into a more mature process-focused organization, and its executives did exactly what BPM gurus, like Hammer, Rummler, and Davenport, have consistently recommended. Define processes top-down. Assign process managers and make them responsible for results. Measure process results; do not just focus on arbitrary departmental results. Align measures and strategic goals. Eliminate or outsource noncore (nonvalue-adding) processes. Focus employees on their roles and responsibilities in creating value, and reward them for results. Identify and standardize common processes throughout the organization.

Processes describe how value is created. Smart executives naturally tend to focus on processes because they are concerned with results. BPM merely captures these insights and provides a structured approach.

The Systems View of an Organization

One alternative to conceptualizing an organization in terms of its departments and reporting relationships is to imagine an organization as a system that responds to inputs and generates outputs. This view is often referred to as a horizontal or systems view of the organization. Figure 3.4 illustrates a horizontal view of an organization. In this case we provide a high-level systems view of a hypothetical restaurant called San Francisco Pizza (SF Pizza).

The organization illustrated in Figure 3.4 is at such a high level of abstraction that it could be any organization. Much that could have been added has been omitted to simplify this diagram. This view provides us with much information that we do not get from an organization chart. First, it shows customers, products, and suppliers. Second, it shows how work actually occurs. Third, it gives us an idea of how things are connected and flow from one thing to another—how raw materials flow to meals and how data about customer satisfaction flow back to the organization.

A systems view emphasizes processes and connections and, ultimately, adaptation. What would happen if the restaurant was closed for a period of time? You would need to stop some supplies. You would lose some customers. A systems diagram provides a snapshot of how the key elements of your organization work together to achieve its goals.

Models and Diagrams

In this book we will use two broad classes of diagrams: organization diagrams and process diagrams. In this chapter we will focus on the basic notation used for organization diagrams.

As we have suggested, many different groups are involved in business process modeling. Predictably, different groups use different types of diagrams. Even within a relatively well-defined community, like workflow software vendors, a dozen different notations are used. Some of the notations are different from one another, stressing different ways to view organizations or processes. Some notations differ on such trivial matters as whether a process should be represented as a rectangle or a rectangle with rounded corners.

The key thing to think about in selecting any notation is who is going to use it. We assume that the diagrams described in this book will be used by business managers, business analysts, and process practitioners of various kinds. They may also be used by software developers, but software developers are not our primary audience. Hence we have constrained the types of things we describe in diagrams to the things most managers are interested in, and omitted notation that is only used to describe software conventions. Furthermore, although we recommend the use of software diagramming tools for some purposes, we assume that many managers will create diagrams of their organizations and processes on drawing pads, blackboards, or relatively simple diagramming tools, like Visio or PowerPoint. Hence we have made every effort to use simple, easy-to-understand conventions.

Our goal was to arrive at a way of describing organizations and business processes that is as easy to understand as possible, while still making it possible to describe all the basics that need to be described. In this chapter, as we describe the notation, we will not consider how it might be implemented in a software tool. Several tools, however, implement notations similar to the one we use and thus in later chapters we will show how software tools can be used in process redesign to simplify the creation of organization and business process diagrams. At this point, however, we only want to provide readers with the basic notational elements necessary to draw models of their organizations and business processes. We will begin by explaining the basic elements of an organization diagram. Then, we will proceed to show how this type of diagram can be used to define an organization’s value chains, specific value chains, stakeholders, and high-level organizational concerns.

Organization Diagrams

Organization diagrams are an extension of systems diagrams that are modified so that they can be used to describe the basic structure of an organization, the relationship of the organization to its external environment, and the relationships among the departmental units within the organization. In some cases they may also show the basic processes used by the organization and how those processes relate to the basic departmental units.

Figure 3.5 provides a high-level picture of an organization. Rummler and Brache refer to this diagram as a supersystem diagram to emphasize that it focuses on what happens outside the organization rather than on what occurs inside. This is the kind of diagram a strategy committee might use to picture the relationships between your organization and those it depends on.

The shaded square in the center represents the organization. In this initial version of the diagram we do not show any internal detail, because we want to focus on the inputs and outputs of the organization.

Suppliers of all kinds, including vendors who supply materials, research organizations that supply new technology, capital markets that supply money, and labor markets that supply employees, are shown on the left of the business.

Customers and shareholders are listed on the right. Customers order and receive products and services. Shareholders buy stock and receive information and dividends.

Below the company box we have a rectangle for competitors, companies that compete with the organization for inputs from suppliers and for customers. If the organization we are describing has one or a few major competitors we may list them in separate boxes to help focus everyone on the nature of the competition.

Above the company box we have a rectangle that includes more generic environmental impacts on the business. These could include government regulations, changes in the economy, or changes in popular taste.

The detail one provides on this diagram depends on the purpose it is being used for. In strategy discussions it is often important to show specific types of customers, specific suppliers, and even particular competitors. Later, when one is primarily focused on the relationships between departments and on analyzing internal processes, the external details can be removed to better focus the discussion.

We believe that the organization diagram shown in Figure 3.5 can be used to describe every possible type of organization, including monopolies and government entities. Indeed, we have used these diagrams during consulting engagements with all these types of organizations. The names may change a little, but all organizations are systems, and they must all obtain supplies and generate products or services, just as they all have some kind of competition and operate under some type of environmental constraints. Governments and government agencies don’t have stakeholders, of course, but they have citizens or legislative committees they report to, and they have budgets and goals or targets they use to measure their successes.

Organizations and Value Chains

We defined the idea of a value chain in Chapter 1 (see Figure 1.4) and referred to it again in Chapter 2. It is a powerful concept and should be used to focus attention on the fact that all the processes that go into making and selling a product line ought to be considered as parts of a whole. Unfortunately, it is easier to talk about a value chain than to define it in many specific contexts.

Small or focused organizations tend to have a single value chain. In essence the whole organization is a system designed to produce a single product or service. In such a case the value chain and the organization are interchangeable terms. Large or more complex organizations tend to have more than one value chain. In this case the organization as a whole is the ultimate system or process and it is then divided into two or more value chains, each producing a more or less independent set of products or services. The important thing to remember is that a value chain is just another name for a process. If the term “value chain” (or its increasingly popular equivalent, a “value stream”) is confusing at all, just ignore it and speak of the top or largest processes in the organization.

To begin with, there are always arguments between the “lumpers” and the “splitters.” The lumpers want to combine everything that is even vaguely similar and arrive at one or a few value chains. The splitters want to focus on the differences between different products and different groups of customers and usually end up generating a rather longer list of value chains. Consider whether General Motors supports one value chain, or several. It would be possible to argue that each line of cars represents a different value chain with a different group of customers. Or, perhaps, you might argue that all cars are similar and represent one value chain, while trucks are rather different and represent a second value chain. Most analysts would probably separate the manufacture of automobiles and trucks from GM’s financial operations, and argue that one is a manufacturing value chain while the other is a financial value chain. In fact, however, GM often uses its financial group to support auto sales, offering auto loans without interest for a period of time to encourage sales. Thus it would be possible to argue that even GM’s financial group is a process within a broader autos value chain. The goal of a value chain analysis is to ensure that all the processes involved in the creation of a product line are considered together. Each company will need to determine for itself exactly how broadly or narrowly it wants to use the term “value chain.” There is no right answer. A workable answer usually emerges from a discussion among senior managers.

Another source of confusion derives from the growing use of outsourcing. Figure 3.6 provides one way of thinking about how Dell Computer’s laptop value chain is organized. Dell focuses on designing new laptop computers as components become available, marketing its computers and selling computers online via its website. Once a laptop is actually ordered Dell transmits the order to an outsourcer in China, who assembles the actual computer and ships it to the customer. If the computer subsequently requires service the customer calls an outsourcer, who diagnoses the problem and schedules a pickup. An outsourcer picks up the computer and delivers it to a warehouse run by another outsourcer, who makes the needed repair and returns it to the customer.

One could argue that Dell is simply a design and marketing organization and that laptop manufacturing is not one of its core processes, but Dell is generally classified as a computer equipment manufacturer, and Dell exerts significant control over the processes it has outsourced. On the other hand, Dell does not have a laptop-manufacturing function or a vice president of laptop manufacturing with day-to-day control of computer assembly. That role is performed by an individual working for an outsourcer. More and more companies are trying to think about how a value chain works if significant operational processes are controlled by external organizations. Put a different way, organizations are beginning to talk about value chains that extend beyond the traditional boundaries of the organization. Some refer to this type of diagram as a value chain system.

Another aspect of the value chain concept that many companies find difficult is the requirement that overhead, management, and support processes be combined with primary or core processes. Porter suggested that a company should be able to isolate all the support activities that are used in a single value chain. Most companies find it easier to organize their senior management activities (e.g., corporate image, corporate strategy, stockholder support) and their major support processes (e.g., personnel, IT services) into separate processes that are independent of their value chains and then use some overhead formula to assign a portion of the cost of these management and support processes to each independent value chain. Like Dell, some companies outsource their HR or IT processes to other organizations. In this case one organization’s support process is another organization’s core process.

In the 1990s most companies focused on improving their core processes. In recent years a lot more attention has been focused on management and support processes, but most companies still find it easier to define their value chains only in terms of core processes and to exclude management and support processes. Some organizations use the term value stream as a way of emphasizing that they are only speaking of core processes when they use the term. (Other firms use the terms value chain and value stream as synonyms, so one needs to determine just how a given company is using the term before drawing any conclusions.) Throughout the rest of this book we will use value chain and value stream as synonyms and use them to refer to either a large process that includes only core processes or a top-level process that includes both core processes and management and support processes. This accurately reflects the flexibility that we encounter as we move from one company to the next.

However the concept is defined, each company needs to determine how many value chains it has. A business process architecture describes a single value chain. It is simply too complex to try to analyze more than one value chain simultaneously. Thus one begins by defining the value chains in a company and then, thereafter, one always focuses on one specific value chain at a time.

Figure 3.7 illustrates an organization diagram that shows that a given company has two value chains. An example of such an organization might be Michelin, which sells both tires and restaurant guidebooks. However it might have begun, today Michelin has two value chains selling two different types of products to two different audiences. In this diagram we have pictured a company with two value chains. Separately, we included process boxes (rectangles with rounded corners) for an organization management process, as well as for IT, personnel, and for a finance process that monitors the organization’s use of capital.

So far, our organization diagram only pictures a very high–level overview of an organization and its largest processes. Sometimes we want to drill down and look at only a single value chain. To be more concrete let us assume that the organization pictured in Figure 3.7 is Michelin, and that it has two rather separate lines of business. Imagine that we only wanted to focus on the sell tires value chain. In this case we might create an organization diagram like the one shown in Figure 3.8. It pictures a single value chain, which is indicated by the label on the central box, and shows the major processes that comprise the sell tires value chain.

Some analysts would take this one step further and identify some of the subprocesses within the three core processes we have shown in Figure 3.8. In some cases this may be useful, but in most instances we find the level of analysis shown in Figures 3.7 and 3.8 to be sufficient. The goal of an organization diagram is not to define processes in detail, but to get an overview of the whole organization and to help the team think about customers, value chains, and major stakeholders. We have better techniques for analyzing and picturing the details of processes and subprocesses.

Systems and Processes

We began our discussion of how managers understand the enterprise by considering the kind of model that a manager might provide if asked to explain the organization he or she managed. The traditional organization chart that we guessed our manager might provide is a pretty static way of looking at an organization, and it does not provide a good way of thinking about how things are related. It leads to silo thinking.

In this book we urge systems thinking and process thinking. As organizations become more complex, effective managers need an overview that allows each one to see how their work fits within the larger whole. Peter Senge wrote a popular book a few years ago that called systems thinking the “Fifth Discipline” and argued that every manager should cultivate this perspective. We believe that the organization diagrams that we have presented herein provide an important first step toward developing a systems overview. We know that anyone involved in trying to implement a business architecture needs this kind of perspective. The alternative is to try to figure out how to assign strategic goals to departments without a clear idea of how the departments work together to achieve the desired outcomes.

Process thinking is just a subset of systems thinking. Systems thinking puts the emphasis on understanding the organization as a whole. Process thinking stresses thinking about a portion of the system that produces a specific set of results. The key, again, is to think of the entire process, to understand how a specific process fits within the larger process and, ultimately, within the value chain. Remember, departments do not produce profits; value chains and processes produce profits. An excellent department may not result in a great process or significant profits. Indeed, in many cases maximizing departmental efficiency actually reduces the efficiency of the whole process. To avoid this, organizations need to focus on the flows and relationships that actually add value and produce products for customers. Older perspectives need to be subordinated to these newer perspectives if your organization is to prosper.

Notes and References

Rummler, Geary, and Alan Brache, Improving Performance: Managing the White Space on the Organization Chart, Jossey-Bass, 1990. The book is out of date in the sense that diagramming elements are defined in ways that are pre Unified Modeling Language and Business Process Modeling Notation and we have changed various diagrams to bring the Rummler-Brache diagrams into line with current practice.

Geary Rummler’s last position was with Performance Design Lab (PDL) and they give workshops on advanced process analysis and design issues. More information is available at http://www.performancedesignlab.com. Those who have taken a Rummler workshop know that PDL makes extensive use of a set of organization and process diagrams of a Fine Times Restaurant he has created. In effect, our SF Seafood restaurant is a West Coast branch of Fine Times and owes much to the original in Tucson.

Magretta, Joan, “The Power of Virtual Integration: An Interview with Dell Computer’s Michael Dell,” A Harvard Business School Case Study and Commentary, March 1998, available at http://www.hbsp.harvard.edu.

Roberts, John, The Modern Firm: Organizational Design for Performance and Growth. Oxford University Press, 2004. Little on processes, as such, but many good studies of organizations that often rely on process principles.

Senge, Peter M., The Fifth Discipline: The Art and Practice of the Learning Organization, Currency Doubleday, 1994. Senge is also at the Sloan School of Management at MIT, and is a student of Forrester. Senge has created a more popular approach to systems dynamics that puts the emphasis on people and the use of models and feedback to facilitate organizational development. In the Introduction we described mature process organizations as organizations that totally involved people in constantly improving the process. Senge would describe such an organization as a learning organization.