Davenport, Thomas H.

English

AIS Electronic Library (AISeL)

Association for Information SystemsAIS Electronic Library (AISeL)AMCIS 1996 Proceedings Americas Conference on Information Systems(AMCIS)8-16-1996Holistic Management of Megapackage Change:The Case of SAPThomas H. DavenportUniversity of Texas at Austin, tdav@notes.bus.utexas.eduFollow this and additional works at: http://aisel.aisnet.org/amcis1996This material is brought to you by the Americas Conference on Information Systems (AMCIS) at AIS Electronic Library (AISeL). It has been acceptedfor inclusion in AMCIS 1996 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contactelibrary@aisnet.org.Recommended CitationDavenport, Thomas H., "Holistic Management of Megapackage Change: The Case of SAP" (1996). AMCIS 1996 Proceedings. 153.http://aisel.aisnet.org/amcis1996/153Holistic Management of Megapackage Change: The Case of SAP Thomas H. Davenport e-mail: tdav@notes.bus.utexas.edu University of Texas at Austin In the past few years a new phenomenon has emerged in the world of information management. This is the rise of very large, integrated information systems packages that automate the majority of a firmís business activities. These packages have reached their greatest level of popularity in the past five years (somewhat earlier in Europe) in the manufacturing sector, and they are now being adopted in banking, health care, and other service industries as well. By far the most popular of these ìmegapackagesî is offered by SAP AG of Germany.  SAP is the fastest growing major software company on the planet; annual sales of the software, services associated with it, and hardware on which to run it are estimated at over $10 billion. The SAP package incorporates many desired features, including a client/server architecture (in the R/3 version of SAP; the mainframe version is called R/2), language and currency conversion tables, an application generator tool, and others. When changes are entered into one module of the system, other related data elements in the package are automatically updated. SAPís most significant feature, however, is its support for broad, integrated business processes. When (or if) implemented, a firm can coordinate its activities across multiple functional, geographical, and business units. It is clear that SAP makes possible higher levels of business coordination than have been previously possible. However, the use of SAP and other megapackages also requires a higher level of organizational change than for other types of systems. In order to make effective use of SAP, firms typically need to change their business processes, organizational structures, and even business strategies. Companies adopting megapackages, in short, face the prospect of ìchanging everything at once.î Many firms are concluding that they should adapt their businesses to the package, rather than vice-versa. Modifying such a complex, highly integrated package to suit a firmís idiosyncratic situation is extremely difficult, expensive, and time-consuming. In order to better understand the nature of change firms undergo as they adopt and use SAP, an exploratory research project was undertaken in which twenty firms were interviewed with respect to their use of megapackages. Eighteen of these firms had adopted SAP in some part of the organization; two other firms were adopting large, integrated packages but not SAP. Since virtually all of the firms interviewed are not yet finished with their projects, it is impossible to declare that any particular approach leads to success or failure. However, it is also clear that firms are taking different directions on holistic management of megapackages, and the implications of those directions are emerging with increasing clarity.  Of course, one key change domain of megapackages is technical change. For most of the firms we interviewed, SAP was viewed as the largest technical project they had undertaken. Just installing the program can take three years or more. Firms implementing SAP have to make more than 3,000 configuration decisions. Those using the R/3 version of the package have to master client/server technology architecture, perhaps for the first time. Firms implementing SAP often look to external consultants for expertise, for which demand considerably exceeds supply. SAP enables an operational strategy involving tight integration between functions, heavy information exchange throughout the value chain, reduction in cycle time for demand fulfillment, and dispersion of functions across geography. This strategy, which has come to be called ìlean production,î has become almost a generic strategy for manufacturing firms in the 1990s. In the personal computer industry, for example, companies increasingly attempt not to predict customer desires and stock inventory to fulfill them, but rather to build a computer to fill a specific customerís order. In the companies interviewed several differerent means of using SAP to achieve lean production were identified.  Firms implementing SAP and other megapackages should make strategic choices about the source of their competitive advantage, and how much of that advantage can be derived from an industry-wide package. Again, in the personal computer industry, almost all of the large firms are implementing SAP. The package has reached similar levels of popularity in the semiconductor and chemical industries. One personal computer firm estimated that SAP, when fully implemented, will cover between 75% and 85% of its business functions; others have made similar estimates. Most of the firms are implementing the package without major modifications, simply because such modifications are extremely difficult and time-consuming. What, then, becomes the source of competitive advantage when everyone in the industry does business in the same way?  Most firms have viewed certain operational processes as key to their strategies. Therefore, when implementing a megapackage a firm must decide which processes bring competitive advantage and differentiation, and whether or not to employ the capabilities of the package to support those processes. Compaq managers, for example, concluded that a couple of processesóproduction forecasting and order configurationówere critical to their competitiveness. Therefore, they are developing proprietary processes and systems in those areas, and interfacing them with SAP. Similarly, Intel concluded that its advantage came primarily from manufacturing and customer service. It therefore decided not to use SAP in those areas, even though modules are available to support these functions. Instead, it will build systems from scratch or use other packages for those process areas. The strategic implications of SAP, then, are easy to see. Yet only half of the companies interviewed considered SAP an issue to be discussed at the board of directors level, for example. These strategic changes will not happen if SAP or another megapackage is viewed as ìjust another computer system.î The changes necessary to implement these new strategic directions must be made by senior managers who have a good understanding of the capabilities of the package and its relation to the business. When SAP is being implemented from the bottom up, as is true in several of the firms interviewed, it will be difficult or impossible to manage such strategic changes. There is an organizational structure and culture that would fit perfectly with SAP. Such an organization would be highly centralized, with all business units, functions, and geographies being subservient to a central set of strategic and operational decision-makers. There would be few differences in how work is done and information is used across the organization. Local managers would be willing to sacrifice local goals and tactics for the good of the larger organization. This hierarchical utopia was not found in the firms interviewed. Most were not even conscious of the organizational issues involved in SAP. A few firms did make specific organizational adaptations to better fit with SAP. One European oil company implementing SAP created a new layer of organizational structure to oversee common European operations. At Compaq, managers are not taking global commonality for granted. The implementation team, which has representatives from all around the world, asks each member to vote on major operational decisions. Some firms have concluded that the best way to achieve such organizational change is to work through the organization unit-by-unit. While this less ambitious implementation strategy may have a higher chance of success than a one-time, top-down approach, it can lengthen implementation and increase costs. Dow Chemical, for example, was one of the first firms to implement SAP in the United States. Its managers decided that the best way to implement SAP was a product-by-product, geography-by-geography, function-by-function approach. This approach appears to have succeeded at Dow, although it has been very expensive and time-consuming.  Other firms that do not achieve the requisite organizational changes may end up abandoning SAP altogether. Eastman Kodak, for example, selected the package for its worldwide operations and financial management in 1992. It discontinued the project two years later; key managers, including the Chief Financial Officer, never fully supported the project. One of the most interesting aspects of megapackage implementation is how firms handle the process changes associated with a package like SAP. A major benefit of the software is its purported ìenablementî of redesigned, highly integrated business processes (over 800 of them, according to the vendor). However, simply put, SAP implementation requires that companies design business processes to fit the software, not the other way around. Because the software is highly integrated and complex, it is difficult if not impossible to modify it substantially to support an existing set of company-specific processes. Companies that do not begin with the capabilities of the package before they assess their processes are likely to run into difficulty. One consumer goods manufacturer went through a full-blown, six month reengineering exercise for order fulfillment and inventory management processes. The company developed highly specific process visions and improvement objectives. Then the implementation team selected SAP, and the ambitious reengineering goals were subordinated to getting the system up and doing the work in accordance with the monster packageís demands.  In interviews with firms that were implementing SAP, I listened for approaches and tactics that seemed likely to facilitate a more holistic view of mega-package change. These approaches appeared to offer the promise of combining technology change with changes in strategy, organization and culture, and processes, and of achieving the maximum benefit from the expensive and time-consuming implementations. Some of these approaches are mentioned below:  • a very senior project sponsor;  • The use of only one consulting organization for all change domains;  • Cross-functional steering, design, and implementation teams ;  • Cross-functional implementation across an entire business unit rather than function-by-function;  • Rapid implementation of simultaneous organizational, process, and systems change;  • People involved in the project should be made aware of the holistic nature of the changes.  A few firms did seem to incorporate many of the approaches described above. Compaq, for example, recognized the strategy, organizational and process aspects of the SAP implementation and was consciously managing all of them. The software firm Autodesk also seemed to recognize the holistic nature of the implementation and had already achieved substantial improvements in key processes.  Today SAP is perhaps the worldís largest experiment in business change. It is a computer system, but its effective use is intimately connected with changes in how firms get competitive advantage, get organized, and get their work done. For most firms, SAP will be the largest change project in cost and time that they have undertaken in their history. While these changes are by no means over, the experiences of early adopters can inform those who may later adopt SAP or other mega-package alternatives.                           

Holistic Management of Megapackage Change: The Case of SAP

https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1152&amp;context=amcis1996

Holistic Management of Megapackage Change: The Case of SAP

Abstract

Similar works

Full text

Available Versions

AIS Electronic Library (AISeL)