cis677 4 reengineering

20
Issues & Opinions: Myths About Reengineering Reengineering: Business Change of Mythic Proportions? By: Thomas H. Davenport Ernst & Young Center For Business Innovation 1 Walnut Street Boston, Massachusetts 02108 U .S. A. Donna B. Stoddard Harvard Business School Soldiers Fleld Boston, Massachusetts 02163 U .S. A . [email protected] Abstract Reengineering is a powerful change approach that can bring about radical improvements in business processes. However, the popular management literature has created more myth than practical methodology regarding reengineer ing. It has relied more heavily on hype than on research, common sense, or lessons of the past. In this paper, we attempt to "demythologize" some key aspects of reeingineering by describ ing what we have observed in our research and practice. Seven reengineering myths are iden tified, discussed, and dispelled. By separating rhetoric from reality, we hope to help others to have reasonable expectations for success with their reengineering initiatives.

Upload: sohail-shaikh

Post on 07-Dec-2015

19 views

Category:

Documents


1 download

DESCRIPTION

Through the treacherous years of manual processes, outdated legacy systems, inaccurate performance data and internal operational breakdowns, most organizations are ready for a heavy dose of business process reengineering (BPR).While this is mostly good news; there is a catch. As unfortunate as it may be, everyone has differing opinions of what business process reengineering actually means and wonders what its correlation is to ERP implementations. However, over the last decade, our team has found seven common myths associated with BPR that we have decided to share with you along with a healthy dose of reality check to go with them.

TRANSCRIPT

Issues & Opinions: Myths About Reengineering

Reengineering: Business Change of Mythic Proportions?

By: Thomas H. Davenport Ernst & YoungCenter For Business Innovation 1 Walnut StreetBoston, Massachusetts 02108

U .S.A.

Donna B. Stoddard Harvard Business School Soldiers FleldBoston, Massachusetts 02163U

.S.A .

[email protected]

Abstract

Reengineering is a powerful change approach that can bring about radical improvements in business processes. However, the popular management literature has created more myth than practical methodology regarding reengineer ing. It has relied more heavily on hype than on research, common sense, or lessons of thepast. In this paper, we attempt to "demythologize" some key aspects of reeingineering by describ ing what we have observed in our research and practice. Seven reengineering myths are iden tified, discussed, and dispelled. By separating rhetoric from reality, we hope to help others to have reasonable expectations for success with their reengineering initiatives.

Business process reengineering has been touted as the magical elixir that will empower managers to free themselves from existing constraints, to "think out of the box" and to achieve significant benefits. Hundreds of organizations around the world have begun reengineering projects. They are inspired to duplicate the legendary exploits of Ford's accounts payable department, IBM Credit Corporation, and Mutual Benefit Life.

Unfortunately, the popular management literature, by relying too much on hype and too little on research, common sense, and thelessons of the past, has created more myth than practical methodology. Reengineering has become larger than life. Expectations frequent ly go unfulfilled, and frustrations that "we must be doing it the wrong way" contribute to the failure of many promising reengineering efforts.

The concept of business process redesign, in novation, or reengineering has been with us for about four years, and today is one of the most popular concepts in business (Davenport and Short, 1990; Hammer, 1990). It is widely misunderstood and has been equated to downsizing, client/server computing, quality, activity-based costing, and several other manage ment nostrums of the past several years. One astute manager has even defined reengineering as, "any project you want to get funded." As a result of this imprecision, many managers are pursuing reengineering because of its positive press, without truly understanding what reengineering is. Further, many have come to re ly on some common and potentially harmful myths to guide them to successful completion of their projects.

While the final word on reengineering is certain ly not in, our remarks are based on interviews and conversations with more than 200 companies, as well as rigorous research on 35 reengineering in itiatives (Jarvenpaa and Stoddard, 1993). As a result of this research and broad observation, we have identified seven reengineering myths. These myths have rhetorical power, and as such, are powerful tools for the evangelism that has gripped proponents of reengineering. Nonetheless, they are fundamentally false. The myths explored are the following:

1. The Myth of Reengineering's Novelty2. The Myth of the Clean Slate

MIS Quarterly/June 1994 121

lssun & Opinions: Myths About Reenglneerlng

3. The Myth of IS Leadership4. The Myth of Reengineering vs. Quality5. The Myth of Top-Down Design6. The Myth of Reengineering as

Transformation7. The Myth of Reengineering's Permanence

The Myth of Reenglneerlng's NoveltyA quote from management authority Peter Drucker adorning the cover of the best-selling book about reengineering (Hammer and Cham py, 1993) proclaims, "Reengineering is newl " If reengineering is truly new, managers may be forced to disregard much that they have already learned about business change. This myth of newness can be tested by examining each of the components of reengineering.

There are five primary concepts that make up reengineering:

1. A clean slate approach to organizational design and change.

2. An orientation to broad, cross-functional business processes, or how work is done.

3. The need for, and possibility of, radical change in process performance.

4. Information technology as an enabler of change in how work Is done.

5. Changes in organizational and human ar rangements that accompany change In technology.

Let's consider the novelty of each. Starting from a "clean slate" Is central to reenglneering rhetoric, If somewhat mythical Itself (see below). But It cannot be called new. Making change through a fresh start as an alternative to modifica tion of the status quo is common sense.

Business processes have been with us at least since the mld-1940s, when they became the focus of continuous Improvement efforts. Process analysis really goes back to Frederick Taylor, who first advocated the systematic study of work pro cedures (Taylor, 1911). However, reenglneerlng proponents advocate the redesign of broad, cross-functional business processes. This Idea

122 MIS QuartBrly/JunB 1994

is more recent than Taylor, but It Is older than reengineering; witness the value chain concept (Porter, 1985) or te idea of design for manufacturing ..

Radical change In business processes is also not a particularly novel idea. Both Joseph Juran andW. Edwards Deming, known primarily as ad vocates of more incremental process change, an ticipated and advocated such change (Gabor, 1990; Juran, 1964). Furthermore, several authors preceded reengineering with the notion of radical improvements in process cycle time (Bower and Hout, 1988; Stalk and Hout, 1990).

There is a long history to both technical and human/organizational "enablers" of change in processes. The idea that computers and com munications could change the way work was done, and were only valuable if they did so, has been argued almost from the beginning of the systems analysis role in the 1950s and '60s. And the awareness that technological changes should be accompanied by changes In organizational structure, policies, and human resource manage ment approaches has been well known since the socio-technical school at the Taavistock Institute in the 1950s (Chems, 1976).

So what is new about reengineering? It is that familiar concepts are combined in a new syn thesis. These key components have never been together before, not in quality nor socio-technical design nor systems analysis nor anything else. Unfortunately, as we will show, most popular writers on reenglneerlng have ignored its historical roots; therefore, some important ideas have been forgotten. Since reengineerlng is a combination of known elements, traditional management wisdom should apply. As a syn thesis of several approaches, reengineering Is a very ambitious approach to change. But, while it may contribute to the popularity of a concept to suggest that It Is new, to ignore historical antecedents strengthens the arguments of those who view reengineerlng as a fad.

The Myth of the Clean Slate"Don't automate, obliterate!" (Hammer, 1990). The suggestion Is for firms to throw away all ex isting processes, activities, systems, people, etc. By throwing away these troublesome assets and building a new environment from scratch, firms

Issues & Opinions: Myths About Reengineering

would find solutions that were expected to be less expensive and more effective than if they worked "within the box."

In practice, clean slate change is rarely found. A "blank sheet of paper" used in design usually requires a "blank check" for implementation. "Thinking out of the box" can lead to "spending out of the box." Most firms are not willing to com mit the resources-both money and time-to im plement from a clean slate. One firm we studied, for example, developed a very innovative new process design for its order management pro cess. Management discovered that to implement the "clean slate" process would require portable workstations for all salespeople, a packet radio network, replacements for legacy systems, new skills, and many new people. The total estimated cost to build and operate this process over seven years was $1 billion. Although the return on this investment was conservatively estimated to be very high, managers believed the firm could not afford the investment.

One approach to clean slate implementation is to implement the new designs by opening a new location. However, such "greenfield" sites can be expensive. An insurance company opened a new office where the employees, the culture, the information systems, and the real estate were to reflect the values and priorities associated with the clean slate design. It took the organization 24 months to open the new office, and even then, the systems they needed were not available. Employees who had to be kept busy when the project was delayed spent 12 months in training rather than the planned three months. When the office opened, management found that custo mers liked the new approach to service but the financial viability of the clean slate design could not be demonstrated.

So what do firms do when they cannot afford clean slate change? First, they make a distinc tion between clean slate design and clean slate implementation. Clean slate design-creating a detailed vision for a process without conc•rn for the existing environment- ls not particularly ex pensive. Many firms have found that it is useful to have a "best-of-all-processes" world to which they can move, even if the movement is piece meal over several years. As one manager noted, "You can design assuming a clean slate, but you must Implement

assuming the existing state."

His firm breaks implementation into several proj ects, beginning with those that offer the most im mediate benefit. Just as product developers focus on "design for manufacturability," process developers must consider the implementabilty of process designs.

Alternatively, designers could start with a "dirty slate." Designs could take into account the op portunities for enabling the new process (new technology, skills, organizational structures) as well as the constraints that disable it. With both design elements in mind, the design team could construct the best possible process given the enablers and the constraints. Whereas this is a less exciting and more difficult design method, designing with a "dirty slate" will normally yield a more implementable process.

The Myth of IS LeadershipOur research shows that IS organizations often introduce reengineering in their organizations. A systems planning or data modeling project fre quently provides the genesis for reengineering as the organization becomes aware that a plan ning process focusing primarily on systems may not deliver the business solutions it needs.

When asked why reengineerlng had become a major agenda item, the CIO of a major insurance com pany responded:

In the late 1980s, I began to look at how technology was !Inked to our overall corporate strategy. Itried to assess how new appllcatlons Impacted the enterprise; my Intuition was that we were Investing a lot but not getting the desired productivity. As Ibegan to focus on what we were doing, It was clear that, generally, we did not change the processes that were being automated. Rather, we took sophisticated ap plications and layered them onto an old organization. I began to envision a need to reenglneer. Further, I recognized that In all of our years of focus on the technology, It was as If we had been looking through the wrong end of the telescope. IS personnel needed to focus on processes, not technology (Jarvenpaa and Stoddard 1993, p. 2).

However, there comes a point when IS must relin· quish its leadership role. Most managers with

MIS Quarterly/June 1994 123

Issues & Opinions: Myths About Reengineering

reengineering experience whom we have inter viewed stress the importance of a partnership between IS and the managers associated with the business process being redesigned. Many emphasized the desirability of a non-IS business sponsor with responsibility for the entire process and a champion or project leader (also usually non-IS) who works with a cross-functional team that includes IS. Whereas IS may be a key enabler of the new approach to work, other organizational changes, including changes to structure, training, role definition, and culture, must ensue to facilitate a new process. In short, there is much about reengineering that can never be under the control of the IS function.

Perhaps the most important ongoing IS role is to avoid being an inhibitor or disabler to reengineering, either because of the lead time to develop new systems or because of difficulties in modifying existing ones. In the insurance com pany described earlier, after 24 months was devoted to developing a pilot information system to support the "greenfield" office, it was discovered that the new system could not be scaled up. In another company, the "clean slate" design assumed that advanced IT-based systems, such as groupware, expert systems, and a single system image, would provide seamless access to legacy systems. The lead time to bringthese new capabilities in-house was long, however, and the pilot design had to be modified to include structures and human systems that were not dependent on the ad vanced IT capabilities assumed in the original clean slate design. In this case and many others, information systems were the biggest barrier to rapid and radical change.

The myth that IS should lead reengineering often leads to IS managers starting reengineering proj ects only to discover that the required changes to implement the redesigned process are com pletely outside of their sphere of control. IS is clearly an enabler of reengineering. In fact new organizational roles associated with the rede signed process often cannot be implemented un til employees can access new sources or domains of information. However, our experience suggests that IS partnership with business managers, rather than IS leadership of reengineering, is generally a key to successful reengineering.

124 MIS Quarterly/June 1994

The Myth of Reengineeringvs. QualityA popular management nostrum prior to reengineering was quality or continuous process improvement. Reengineering has been viewed as competitive with quality-not only qualitatively different from, but better than, quality. Hammer and Champy (1993), note that:

Marginal improvements, as a rule, further complicate the current process, making it more dif ficult to figure out how things really work. Even worse making additional investments of time or capital into an existing process only discourage (sic) management from dumping that process down the road. Most perniciously, taking in cremental steps further reinforces a culture of incrementalism, creating a company with no valor or courage (p. 205).

Are the improvements, incremental steps, and in vestments of time or capital into an existing process-steps synonymous with quality undesirable? Most of the firms we have studied don't think so. They believe that no single ap proach to organizational change, including reengineering, is appropriate for all cir cumstances. Many companies have a portfolio of approaches to operational change including reengineering, continuous improvement, in cremental approaches, and restructuring tech niques. Some combine multiple approaches in one initiative-for example, using reengineering for a long-run solution and short-term process im provements in the current process to deliver quick benefit. More specifically, a communica tions company designed a single best process for order fulfillment, but the different regional business units implemented it on a piecemeal basis, adopting first those aspects of the design that addressed their most P essing problems.

In the future, we expect that firms will routinely assemble a customized approach to operational change. They will assess their need for change and the current environment, and then combine tools from the various traditional approaches, e.g., root cause analysis from quality, process value analysis from focused improvement ap proaches, and IT enablement from reengineer ing. In the meantime, reengineering advocates will reap little advantage by disparaging other, quite valid approaches to organizational change.

Issues & Opinions: Myths About Reengineering

The Myth of Top-Down DesignReengineering was originally viewed as a form of work design that had to be completely top down. Because the process being addressed is usually broad, the thinking goes, only a small group of high-level process designers can analyze its entire breadth. One of us wrote previously, for example, that, "Because large firms' structures do not reflect their cross functional processes, only those in positions overlooking multiple functions may be able to see opportunities for innovation" (Davenport, 1993,p. 12). Again, there is some truth to this myth; innovative designs for broad processes are unlikely to come from anyone whose head is buried deep in the bowels of the existing process. High-level design, including the overall flow of the process and its sub-processes, performance ob jectives, and inputs/outputs, must be done by a small design team that studies the process in its entirety and considers relevant enablers and benchmarks in its design. Even in such design teams, however, all members need not be high in the organizational hierarchy themselves.

More important, the design of the more detailed process activities and flows can be done by those who do the work. In fact, we have observed several post-reengineering work execution teams that paid little attention to the prescribed process design, at least partly because they had no hand in its creation. Most people do not want their jobs fully designed by someone else. What made us believe that a small group of smart people at headquarters could design work in detail for others, who would then slavishly adhere to that design? Not since Frederick Taylor has the design of work been so separated from its execu tion. Further, as Drucker (1991) states, "Now, while still far from being widely practiced, it is at least generally accepted in theory that the workers' knowledge of their job is the starting point for improving productivity, quality, and per formance" (p. 70).

Part of the problem with reengineering as it is classically understood is that it ignores much of what we have previously learned about the value of participative work design, at least for the details of a business process. The concept has ap peared in the socio-technical ("minimum critical

specifications"), work redesign, and continuous improvement literatures (Hackman and Oldman, 1980; Imai, 1986; Pava, 1983). While participative design has its shortcomings (e.g., a more cumbersome change process, the need to tolerate variations in detailed work processes), the greater likelihood of ownership of the work design is usually worth the trouble.

The Myth of Reeingineering as TransformationAnother common myth is that reengineering is an approach that organizations can use to total ly reinvent themselves. Some view reengineer ing as synonymous with organization transformation (Hammer and Champy, 1993).

Organizational transformation (OT) is defined as, "Profound, fundamental changes in thought and actions, which create an irreversible discontinuity in the experience of a system" (Adams, 1984, p. 278). OT is generally the result of the emergence of radically new belief systems. OT necessarily involves reframing, which is a discontinuous change in the organization's or group's shared meaning or culture. It also involves broad change not only in work processes, but also in other dimensions of organization, such as organiza tional structure, strategy, and business capabilities. Some writers are beginning to discuss the concept of the horizontal organiza tion in which reengineering is institutionalized and business processes are the primary focus of organizational structure (Byrne, 1993; Ostroff and Smith, 1992; Stewart, 1992). We have not ob served this type of organization in actual prac tice. Some firms are beginning to create hybrid structures, adding a process dimension to their existing functional structures.

Reengineering is a process that can contribute to transformation, but it is not synonymous with transformation. Our observations suggest that those organizations that approach reengineering with the intent of business transformation typical ly start by defining the seven or more core pro cesses of the business. The zealous ones start reengineering projects for each identified process. We know of no cases of success with this broad-brush approach. The primary reason for failure is that the organizations tried to change all processes at once, and often at a time when

MIS Quarterly/June 1994 125

.(

\

j

I

Issues & Opinions: Myths About Reengineerlng

markets, products, and organizational structures were also changing dramatically. Managers were simply unable to devote sufficient management attention to all these Initiatives. This was the early experience of IBM and Xerox In reengineering, though they later focused their efforts on a small number of key processes (Davenport, 1993). The most successful organizations identify which pro cesses need most attention and attempt to make changes In those first, while preparing the rest of the organization for changes that may subse quently occur.

In summary, while some emerging literature does attempt to place reengineerlng in a broader con text of transformation in how firms go to market (Davidson, 1993; Venkatraman, 1994), we believe reengineering is not synonymous with total organization transformation. It Involves at best transformation of a few work processes at any given time, and there is much more within organizations that can be transformed.

The Myth of Reelnglneering's PermanenceSome advocates of reengineering argue that it is here to stay. But like all popular management notions, reengineering will have a life cycle (Pascale, 1990). Our guess is that it peaked in early 1994 in the United States, and is still in creasing in popularity elsewhere in the world. In evitably, reengineering books will disappear from the best-seller lists, and new management en thusiasms will emerge. At the same time, given the great need for business change enabled by information technology and organizational in novations, the need for reengineering shall un doubtedly remain.

We see three options for reengineering's future. One is that another synthesis of ideas will emerge that includes the precepts of reengineering, along with others (see the "myth of reengineering's novelty" above). The second alternative is that reengineering will be absorbed into existing change methods, e.g., strategic planning or in formation system development. There is already evidence that this is occurring; strategic planners discuss reengineering at planning forum con ferences and in the pages of Planning Review (see, for example, Ramcharandas, 1994), and several providers of system development

126 MIS Quarterly/June 1994

methodologies are beginning to include tech niques for reenglneering processes before building systems.

The third option Is for reengineering to be com bined with quality and other process-oriented Im provement approaches into an integrated process management approach. This is the out come we prefer; under such an environment firms would be able to combine the best of multi ple operational analysis methods. It is likely that all three of these options for the future will be realized in some combination.

ConclusionReengineering Is a powerful change phenomenon and an approach that has enabl· ed organizations to realize radical process im provements. In this paper, we have attempted to demythologize some Ideas about reengineering by describing what we have observed in our research and practice. Knowing how reengineer ing usually works in actual practice will help to prevent miscommunication, frustration, and over ly ambitious change programs.

Reengineering has Its roots in IT management. However, it has become one of the most widely discussed and practiced management phenomena of the 1990s. As we encourage organizations to engage in reengineering, we must remember that successful reengineering is not an IS initiative. Rather, it is a business in itiative that will have broad consequences as we rethink and restructure our businesses to satisfy the needs of our customers and other constituents.

Reengineering is important and more than just another management fad. We have seen a number of successful reengineering initiatives (the exact number depends on exactly how suc cess is defined) as well as many failures. By at tempting to clarify what it is and what it isn't, we hope to enable others to have reasonable-and therefore more attainable-expectations for suc cess with their reengineering initiatives.

References

Adams, J.D. Transforming Work, Miles River Press, Alexandria, VA, 1984.

. j *: 'J'

Issues & Opinions: Myths About Reengineering

Bower, J. and Hout, T. "Fast Cycle Capability for Competitive Power," Harvard Business Review (66:6), November-December 1988,pp. 110-118.

Byrne, J.A. "The Horizontal Organization,"Business Week, December 20, 1993,pp. 76-81.

Cherns, A. "The Principles of Sociotechnical Design," Human Relations (29), 1976,pp. 783-792.

Davenport, T.H. Process Innovation, Harvard Business School Press, Boston, MA, 1993.

Davenport, T.H. and Short, J.E. The New Industrial Engineering: Information Technology and Business Process Redesign, Sloan Management Review (31:4), Summer 1990,pp. 11-27.

Davidson, W.H. "Beyond Re-engineering: The Three Phases of Business Transformation,"

IBM Systems Journal (32:1), 1993, pp. 65-79. Drucker, P.F. "The New ProductMty

Challenge," Harvard Business Review (69:6), November

December 1991, pp. 69-79.Gabor, A. The Man Who Discovered Quality,

Times Books, New York, NY, 1990.Hackman, J.R. and Oldham, G.R. Work

Redesign, Addison-Wesley, Reading, MA, 1980, pp. 231-235.

Hammer, M. "Reeingineering Work: Don't Automate, Obliterate," Harvard Business

Review (68:4), July-August 1990, pp. 104-112. Hammer, M. and Champy, J. Reeingineering the Corporation, Harper Business, New York,

NY,1993.

Imai, M. Kaizen, McGraw-Hill, New York, NY, 1986, pp. 94-124.

Jarvenpaa, S. and Stoddard, D.B. "Business Pro cess Reengineering: Tactics for Managing Radical Change," working paper, Harvard Business School, Boston, MA, 1993.

Juran, J. Managerial Breakthrough: A New Con cept of the Manager's Job, McGraw-Hill, New York, NY, 1964.

Ostroff, F. and Smith, D.K. "The Horizontal Organization," McKinsey Quarterly (1), 1992,pp. 148-168.

Pascale, R. Managing on the Edge, Simon and Schuster, New York, NY, 1990.

Pava C. Managing New Office Technology, The Free Press, New York, NY, 1983.

Porter, M. Competitive Advantage, The Free Press, New York, NY 1985.

Ramcharandas, E. "Xerox Creates a Continuous Learning Environment for Business Transfor mation," Planning Review, March-April 1994, pp. 34-38.

Stalk, G. and Hout, T. Competing Against Time,The Free Press, New York, NY, 1990.

Stewart, T.A. "The Search for the Organization of Tomorrow," Fortune, May 18, 1992,pp. 92-98.

Taylor, F.W. Principles of Scientific Management,Harper & Row, New York, NY, 1911.

Venkatraman, N. "IT-Enabled Business Transfor mation: From Automation to Business Scope Redefinition," Sloan Management Review (35:2), Winter 1994, pp. 74-88.

MIS Quarterly/June 1994 127

IIssues & Opinions: Myths About Reengineering

reengineering experience whom we have inter viewed stress the importance of a partnership between IS and the managers associated with the business process being redesigned. Many emphasized the desirability of a non-IS business sponsor with responsibility for the entire process and a champion or project leader (also usually non-IS) who works with a cross-functional team that includes IS. Whereas IS may be a key enabler of the new approach to work, other organizational changes, including changes to structure, training, role definition, and culture, must ensue to facilitate a new process. In short, there is much about reengineering that can never be under the control of the IS function.

Perhaps the most important ongoing IS role is to avoid being an inhibitor or disabler to reengineering, either because of the lead time to develop new systems or because of difficulties in modifying existing ones. In the insurance com pany described earlier, after 24 months was devoted to developing a pilot information system to support the "greenfield" office, it was discovered that the new system could not be scaled up. In another company, the "clean slate" design assumed that advanced IT-based systems, such as groupware, expert systems, and a single system image, would provide seamless access to legacy systems. The lead time to bring these new capabilities in-house was long, however, and the pilot design had to be modified to include structures and human systems that were not dependent on the ad vanced IT capabilities assumed in the original clean slate design. In this case and many others, information systems were the biggest barrier to rapid and radical change.

The myth that IS should lead reengineering often leads to IS managers starting reengineering proj ects only to discover that the required changes to implement the redesigned process are com pletely outside of their sphere of control. IS is clearly an enabler of reengineering. In fact new organizational roles associated with the rede signed process often cannot be implemented un til employees can access new sources or domains of information. However, our experience suggests that IS partnership with business managers, rather than IS leadership of reengineering, is generally a key to successful reengineering.

124 MIS Quarterly/June 1994

The Myth of Reengineeringvs. QualityA popular management nostrum prior to reengineering was quality or continuous process improvement. Reengineering has been viewed as competitive with quality-not only qualitatively different from, but better than. quality. Hammer and Champy (1993), note that:

Marginal improvements, as a rule, further com plicate the current process, making it more dif ficult to figure out how things really work. Even worse making additional investments of time or capital into an existing process only discourage [sic] management from dumping that process down the road. Most perniciously, taking in cremental steps further reinforces a culture of incrementalism, creating a company with no valor or courage (p. 205).

Are the improvements, incremental steps, and in vestments of time or capital into an existing process-steps synonymous with quality undesirable? Most of the firms we have studied don't think so. They believe that no single ap proach to organizational change, including reengineering, is appropriate for all cir cumstances. Many companies have a portfolio of approaches to operational change includins reengineering, continuous improvement, in cremental approaches, and restructuring tech niques. Some combine multiple approaches ir one initiative-for example, using reengineerin1 for a long-run solution and short-term process irr provements in the current process to delivE quick benefit. More specifically, a communici tions company designed a single best proce for order fulfillment, but the different region business units implemented it on a pieceme basis, adopting first those aspects of the desi! that addressed their most pressing problemi

In the future, we expect that firms will routin• assemble a customized approach to operatio1 change. They will assess their need for char and the current environment, and then comb tools from the various traditional approach e.g., root cause analysis from quality, proc value analysis from focused improvement proaches, and IT enablement from reengin ing. In the meantime, reengineering advoc: will reap little advantage by disparaging ot quite valid approaches to organizational cha

- ---