Today, making small but steady improvements in performance is only a recipe for falling further behind. What's needed, instead, is the ability to identify—and then capture—the opportunities for genuinely large-scale changes in performance. And that means rethinking and, if necessary, fundamentally re-engineering how a company delivers value to its customers. The problem, of course, is that such rethinking inevitably runs up against the company's entrenched business system and organizational structure. In this Roundtable, four McKinsey practitioners discuss how using process redesign can help managers break through these barriers.

Browning: What made all of you start thinking about core process redesign? Why has it become so active an area of interest just now?

Hagel: For me, it was watching closely as a company I knew well made a huge performance improvement in a very brief period by taking an integrated approach to redesigning one of its major business processes.

Browning: What do you mean by an "integrated" approach?

Hagel: When this company first approached us, they thought of their performance problem in very narrow terms: it was a sales problem, a salesforce problem. After having launched a lot of TQM and continuous improvement initiatives, they were still frustrated by their inability to achieve the kind of performance improvement they needed to be competitive. The gap was just too big for them to get there the way they were going.

As we started asking questions about the factors that drove the company's salesforce performance, we quickly found that their sales process encompassed a whole range of activities that cut across organizational and functional boundaries. Conceptually, the key breakthrough for us was to make explicit—and then analyze—the linkages among a series of activities that had not been thought of as connected before. No wonder continuous improvement efforts were not enough. They had been shaped by a standalone functional viewpoint. They did not address any of the cross-functional linkages.

Browning: What about the other half of your earlier comment: the notion of viewing a business as a set of processes? What do you mean by "process"?

"Process" is an organizing concept that pulls together absolutely everything necessary to deliver some important component of strategic value

Laird: Everybody uses the word in a different way, but most people would probably agree that, at a minimum, it refers to the flow and transformation of materials and information: logistics, operations (turning swords into ploughshares), communication, coordination, synthesis, decision making. A better way to think about process is that it is an organizing concept that pulls together absolutely everything necessary to deliver some important component of strategic value. "Everything" here includes individual patterns of behavior—how people actually react at the customer interface. Defined in this way, process is a pretty powerful concept. Once you have combined material flows, information flows, and behavior, the rest of what an organization is about follows pretty directly.

Browning: How did this view of things affect the way you tackled the salesforce problem you described?

Prang: The company had been looking at its sales process as something that happened from the time a salesperson called on a customer to the time the salesperson closed the order. They saw it this way largely because all these activities had historically been the ultimate responsibility of one manager. So when we started to ask questions like "Which activities lead to identifying a customer in the first place?" it helped free them up to think about their overall sales process in a new way.

Browning: But why does redesigning such processes improve performance?

Most performance improvement programs are incremental. Managers are bothered by particular symptoms, and they want symptomatic relief

Heygate: Most performance improvement programs are incremental. Managers will often say, "Here is something so wrong it smells." So you go and fix that. Then they detect odor coming from another direction. So you go and fix that. It's a perfectly understandable thing. They are bothered by particular symptoms, and they want symptomatic relief. If you devise a project that helps them remove the smell, you feel that you have achieved something worthwhile. And you have. But what you really want is more a zero-based approach, in which you step back and say, "Let's fix the whole thing so that no odor even gets produced." That is, you want to move from a project-based perspective to a program-based perspective.

Hagel: Professor Alfred Chandler has said that structure follows strategy. What we are trying to do is add an intermediate step that says: What follows directly from strategy is a clear definition of the core processes required to execute that strategy, and it is this definition that enables you to build the kind of organization necessary to support the strategy. Now, when I say core processes, of course, I mean something more than the limited sets of information and material flows that manufacturing organizations have always tried to optimize or re-engineer. I mean what Rod was referring to when he spoke about disaggregating any business and then reconfiguring it around a small number—say, three to five—of end-to-end processes, which contain everything needed, in performance terms, to deliver to the market some critical aspect of strategic value.

Browning: Let's make this concrete. Can you give me an example?

Hagel: A successful company in the fast food business had ambitious plans for growth over the next decade. In talking with them about what they needed to support those plans, we discovered that they had only three genuinely core processes: logistics (delivering food, cooking it, and training people to serve it); devising new restaurant formats and communicating their value propositions to potential customers (market research, branding); and network development (finding sites and building restaurants). Everything else was, in effect, a support activity.

It can take a while to see this. Some time ago, Greg and I went to talk with a manager who was interested in redesigning his company's customer service activities. When we asked him to identify the performance need behind his wish to redesign, he said, "Well, the problem is that we have an avalanche of phone calls coming in to our customer support lines. Therefore we need to re-engineer our customer support processes so that we can handle that many phone calls." We wondered, though, whether the "core" issue was really handling a lot of phone calls, or trying to preempt them before they happened. So when we began to ask him, "What could you do in terms of product design to make your products easier to use?" and "What could you do in terms of documentation, training programs, third-party channels, and infrastructure to provide support?" a whole new range of options suddenly became visible. This manager had not seen them before because he was responsible only for customer service, not product development or training programs. And he could not tackle them alone. No one could. Redesigning the core process, however, put them within reach.

Consensus on the need for redesign, however, does not come easily. Usually there are only two kinds of situation that lead to a perceived need for core process redesign: a clear threat in the marketplace, as when industries face a massive restructuring, or a clear management vision of what a business could be, but is not today. These are not equally likely possibilities. Most of the situations we have seen have been threat based; relatively few have been opportunity based.

Browning: I understand the concept, but can you walk me through what an actual "redesign" effort is like?

Laird: The starting point is to help managers articulate their company's value proposition—a concise statement of the distinctive value it proposes to deliver to customers. The next stage is to derive from that value proposition a short list of key performance imperatives—that is, the limited number of things the company has to do or skills it has to master (the rapid commercialization of new technology, for example) to succeed. With this in hand, we can then help management define the flows of material and information that most affect critical dimensions of performance.

If rapid commercialization of technology is of central importance, we might look first at the relevant activities and flows within R&D. But we would quickly move beyond R&D itself to look at the linkages between, say, development and manufacturing, the cross-functional cooperation needed to design for manufacturability, and the means for ensuring that a product performs reliably in actual customer use. In all this, our focus would be on linkage points, those tell-tale places where core processes cut across traditional boundaries defined by organization or function or activity.

Browning: How does this differ from what you usually do?

There is always a danger of being trapped by an organization's desire not to change too much

Heygate: There is always a danger of being trapped by an organization's desire not to change too much, by its wish that we help it fix just the marketing function or just the finance function or just the production function. But if we re-sculpt only a limited part of the organizational jelly, after a time it will wobble back into place again. CPR helps us overcome the inevitable reluctance to change too much.

Browning: But if redesigning core processes means taking a genuinely holistic view, can you ever do it in a situation where you do not have the opportunity to reinvent a whole company? Does it work on a small scale?

Heygate: You do not have to reinvent a whole company, except in the rarest of circumstances. Most of the time, all you need to do is help a company improve its capabilities faster than average competitors improve theirs.

Browning: If that's the case, what makes this kind of approach different from the more familiar types of project-based techniques for improving organizational performance? I thought the point here was to realize huge jumps in performance by taking an integrated, holistic view of things.

Heygate: It is. But huge jumps do not have to be made in a single leap. Working through core processes, rather than function-specific projects, allows you to set holistic targets for being competitive at world-class levels. But those targets should not be simple, bald-faced assertions of where performance levels have to be in three or five years. They should also reflect detailed, carefully sequenced plans for realizing year-by-year improvements—that is, for managing the learning curve.

For each point along the curve, you need to have in advance a rolling view of precisely where your chosen solution space—the corrective actions you are taking at that time—fits against all the possible initiatives you could be taking. In other words, you need to plan, up front, to create and capture the benefits of an ongoing series of changes. The core process approach allows you to do that.

By contrast, project-based improvement efforts lead managers to think of an evolving solution space not at strategy time, but only at execution time. You develop a strategy, translate it into lots of projects, get the IT guys involved, wait for them to report back a year later, wait again until they complete their detailed analyses, wait even longer until they agree on functional specs, and wait yet again while they do the necessary programming or whatever. Our core process work puts the sequenced thinking right up front. And it backs up that thinking with techniques for systematically managing a planned series of incremental improvements—"release" programs, for example, and a step-by-step process for making incremental changes in IT architecture, something the IT gurus mistakenly argue you should never do.

A core process focus redefines how top-level time gets spent: not on reviewing outdated reports, but on managing, daily, the process of change itself

Perhaps most important, with project-based efforts the mechanism for regular top management involvement is just not there. These managers usually spend most of their time going through papers that report variances in operating results—and that are probably six weeks out of date. A project focus merely reinforces this pattern. A core process focus, however, redefines how top-level time gets spent: not on reviewing outdated reports, but on managing, daily, the process of change itself.

Browning: Where do we wind up at the end of the day? With an organization that is still more or less functionally organized? That still has the same style of management and the same reporting relationships?

Hagel: It varies. The implications of the core process approach for organizational change usually unfold in waves. In the first wave, what you find is a lot of change both at the top and at the front lines, among the people who are closest to the customer or the product or the relevant driver of performance. Initially, middle managers need not be greatly affected because the focus is on getting the work of the front line redesigned and on establishing senior-level accountability for the full performance of the relevant core processes.

Laird: The idea is that someone whose responsibility cuts across functional boundaries is now held accountable for the performance of a complete, integrated process. This is new. It creates a new organizational role—the "process owner"—which never existed before.

It's a pincer movement: changes at the front line and at the top pose unavoidable questions about what should happen in between

Hagel: The reason there is no uniform thinning of middle management at this stage is that redesign efforts need to show good results fast. Focusing on front-line change will give you these quick performance hits. Then you can step back—the second wave—and say, Well, if the front line has changed in such-and-such a way, what does that mean for the people they report to, the way their jobs are structured, the kinds of roles they play? How many of them do you really need? What kind of information must they have? It's a pincer movement: changes at the front line and at the top pose unavoidable questions about what should happen in between.

CPR is not some faddish religion that you get, the way we got TQM or competitive advantage in the 1980s. This is something that fundamentally changes what managers do

Heygate: Organizationally, this is the interesting part. CPR is not some faddish religion that you get, the way we got TQM or competitive advantage in the 1980s. This is something that fundamentally changes what managers do. It gets rid of hierarchies, permanently. If the work of top managers is change management, if the work of an organization is to make core processes run well, and if the work of the front line is to deliver the performance benefits of those processes, there is no place left for middle management hierarchies. If left in place, they will resist change. If you trim them back but do not cut them out, they will grow again, like dry rot.

How does this sort of change, especially at the front line, relate to empowerment?

Heygate: Most of what you hear about empowerment comes out of TQM and other bottom-up movements. It says, in effect: Allow people to have an active role in redesigning the processes in their work environment, and they will be happier and more productive. This makes good sense, but remember the context. The archetypal environment for empowerment-related experiments is assembly-line work groups in traditional automobile plants, where the jobs are just awful—like attaching a wheel cap every twenty seconds, forever. It's Charlie Chaplin's view of purgatory. In this kind of environment, helping people take more pride in their jobs by extending the substantive content of those jobs is eminently sensible.

But there are huge areas of activity where the situation is totally different, where getting people involved in the redesign of their jobs creates more problems, not more pride. Take branch salespeople. What they want to do is to get on with the job of selling, of influencing people in a sales situation. They do not want to redesign the expert systems in their sales support computer. Make suggestions, certainly. But not be responsible for the redesign.

With core processes, the difference is still more pronounced. Here the heart of the task is to step back from daily activities and take a fresh, radical, end-to-end view of the skills, capabilities, flows, and linkages that drive critical aspects of overall performance. This is not a perspective that often flourishes at the front line. Pointed suggestions for incremental improvements? Of course. But probably not an integrated vision of core processes, which extend well beyond local organizational boundaries.

Browning: Let's go back to an earlier point. How do you translate core process analysis into a blueprint for performance improvement?

Prang: As we've said, for each core process, you have to understand both performance drivers and performance targets. This means you have to get very explicit about the levels of performance you need to achieve. Then you can do a "gap analysis": I know where I need to be, but where am I today? What obstacles are in the way of my getting there? What sources of leverage can I tap to overcome them?

The most difficult thing here is to strike the right balance between maintaining an overall end-to-end focus and going into enough detail in high- impact areas to get some quick wins. If you tried to cope with an entire core process at this greater level of detail, you would drown it—and yourself.

The art is knowing where and how to balance breadth of vision with depth of analysis

Hagel: The art, as Greg says, is knowing where and how to balance breadth of vision with depth of analysis. What you want, after all, is to get to the point where you can say, OK, if we rethink these few parts of the process and come up with a fundamentally redesigned way of doing them, we can achieve our target performance objectives.

In practical terms, you would then probably run a set of workshops to brainstorm how best to redesign the process at each of these critical leverage points. Rod has a very interesting way of doing this, which he calls zero-based information redesign. What you do is take a particular element of the process in a workshop setting and say, If we had perfect information instantaneously available at zero cost, what would we do differently? How would this process look? Then you back off and say, OK, that's the perfect world. Now, how much of that can we do, at reasonable cost, with the information technology that is commercially available?

Laird: Not coincidentally, this also gives managers a way to look into the future. Technology is all about cost performance curves. If you can't afford a technological capability today, that doesn't mean you won't be able to afford it tomorrow. It's getting cheaper all the time. So this exercise gets you thinking about the sorts of things you really want to do when and as prices fall. It can also provide some useful insights about where competitors might come from in the future—and when they might get dangerous.

Changing where you deliver information, how you deliver it, and what you deliver can have a dramatic impact on performance

Prang: There's another important point here: information is an extraordinarily powerful lever for the redesign of core processes. Changing where you deliver information, how you deliver it, and what you deliver can have a dramatic impact on performance.

Typically, redesign works at two levels. First, at the micro level, you see a lot of things where you say, Boy, if you took this information over here and delivered it to that person over there, you would eliminate a lot of rework and so really boost performance. But then you step back from all these individual ideas to see the pattern that runs through them, the emerging vision of a whole new way of doing things.

Laird: It's an iterative process: the broad concept, the narrowing tunnel of idea refinement, the micro process detail, and the broad view again. And at each stage, you ask the same questions: How do we do things now? How could we? What is feasible?

Hagel: But you are also paying attention to the time dimension. Time is critical in core process redesign because you have to deliver one-third to one-half of the total performance improvement potential within the first twelve months. Otherwise, motivation fades. So part of your brainstorming effort in the workshops is to bracket the ideas and initiatives that emerge by the time frames in which they can be implemented. If everything on the board or the flip chart is out there in the three- to five-year bracket and there is nothing that can be implemented within twelve months, you need to pull people back to a discussion of what is doable in the near term.

Browning: What role does information technology play in all this?

Prang: As I said, information can be a powerful lever for process change. But it can also be a roadblock. Today, many of the IT architectures in place do not allow particular information to be delivered in particular ways. And, of course, information can be a breaker of roadblocks as new technologies become available that can deliver information in ways that were not possible in the past.

Laird: It's important to differentiate between the technology that's embedded in a product or service, which we are not talking about here, and the technology embedded in core processes—communications that enable material flows, process linkages, decision-support systems for activities like risk management in banks, things like that. There are also accountability information systems, which give feedback on how well a process is performing, and screen-based training systems to help build new skills and sensitivity in areas like customer service. The list is endless.

Heygate: What you have to remember, however, is that you cannot build all this functionality in a short period. Realistically, an organization can probably deliver only about 100–150 man years of applications development programming in any one year. Otherwise, the project grows so big that it never gets delivered. So if you need to deliver a lot of functionality, you had best find a way of buying in 95 percent of it. You have to know which applications solutions are available commercially, and you have to be ready to buy them or license them or cobble them together.

At last, you have to say, Look, the realistic solution space I live in is such that to become world class within a given period of time, I have to do X, Y, and Z. But I cannot do more than a little bit of X each year. So I cannot get there this way.

Then you begin to think more radically. Maybe you cannot improve on all relevant dimensions at once. Maybe you have to focus on, say, the cost dimension and forget service in year one. Or maybe even that outruns the ability of your management team to manage change.

Redesign is not an IT exercise. It is about changing how a messy, real-world organization works

Hagel: Richard makes a good point. No core process redesign will work effectively unless the solution spaces for all these different kinds of change can be at least roughly aligned. Technology can help, as an enabler of behavioral and managerial change, but it is not by itself anywhere near enough. Redesign is not an IT exercise. It is about changing how a messy, real-world organization works.

Laird: Absolutely right. Technology enables redesign. It should not drive it. The difference is fundamental.