UNIVERSITÄT BAYREUTH
The Divided Software Life Cycle of ERP Packages Lars Brehm, M. Lynne Markus
Working Paper 1/2000
presented and published as a full paper atGITM 2000
Reference: Brehm, L. , and Markus, M. L., "The Divided Software Life Cycle of ERP Packages," Proceedings of the 1st Global Information Technology Management (GITM) World Conference, Memphis (Tennessee, USA), June 11- 13 2000, pp. 43-46.
Working Papers in Information Systems Editor: Prof. Dr. Armin Heinzl University of Bayreuth Chair of Information Systems Universitaetsstrasse 30 D-95440 Bayreuth, Germany Phone +49 921 552807, Fax +49 921 552216 E-Mail:
[email protected] Internet: http://wi.oec.uni-bayreuth.de
THE DIVIDED SOFTWARE LIFE CYCLE OF ERP PACKAGES Lars Brehm, University of Bayreuth, Germany,
[email protected], +49 (0) 921 55 2812 M. Lynne Markus, Claremont Graduate University, USA,
[email protected], + 1 909 607 3151 ABSTRACT The traditional information system life cycle (SLC) focuses on the activities performed by a company developing, implementing and maintaining software for its own internal use. Enterprise resource planning (ERP) software packages change the SLC in several important ways. This paper presents an extension of the SLC model for ERP packages. The ‘divided software life cycle’ (DSLC) model features an equal emphasis on the activities performed by the ERP adopting company and the ERP vendor. INTRODUCTION The software life cycle (SLC) has been a center of attention in IS research for decades (Alavi and Carlson, 1992; Morrison and George, 1995). The SLC is the process by which an information system is developed, used and maintained until it is retired. Usually, the SLC is described in terms of a series of temporal phases. The focus of attention in traditional IS SLC research is the activities performed by a company developing, implementing, and maintaining software for its own internal use. Enterprise Resource Planning (ERP) software packages change the software life cycle in several important ways. For one thing, most of the development activity is performed by a vendor, while the adopting company implements the software, perhaps with consulting assistance. Unfortunately, IS research has paid scant attention to differences between the ERP package life cycle and the traditional SLC. Textbooks on system analysis and design focus mainly on traditional custom software development, often neglecting maintenance, and many do not even mention ERP packages as a way to support business processes (Kendall and Kendall, 1999; Whitten, et al., 1998). When ERP packages are mentioned, it is usually only briefly under the topics of selecting off-the-shelf software and package implementation (Hoffer, et al., 1999). Compounding the problem, research on ERP systems has focused mainly on initial implementation activities and has not addressed the overall ERP software life cycle, particularly ongoing use and upgrades (Bancroft, et al., 1998; Bingi, et al., 1999; Buckhout, et al., 1999; Kirchmer, 1998; Lozinsky, 1998). This paper presents an extension of the traditional SLC model for ERP packages. The model is called the ‘divided software life cycle’ (DSLC) model; its key feature is an equal emphasis on the life cycle activities of the ERP adopting company and the ERP vendor. THEORETICAL BACKGROUND Software development life cycle models generally explicate the processes of developing IS applications; they present the temporal phases of development and the sequence in which they occur. Often, a different occupational role (like system analyst or programmer) is responsible for the activities in each phase. Typical phases are project definition, analysis, design, coding, test and implementation. When the phase of ongoing operation or maintenance is added, the word “development” is dropped from the title, and the model is referred to as the software life cycle model or the software process model. Software life cycle models are generally meant to be both descriptive of what usually happens in practice and prescriptive of what should happen in practice. Traditional Custom-Developed Software The first software process model was the so-called ‘classic life cycle’or ‘waterfall model’ (Royce, 1970). It viewed software development as a linear, sequential project with a defined start and end. The model allowed for feedback loops, but only between immediately adjacent phases. The model featured activities performed by system analysts in the earlier phases and by programmers in later phases. With experience, the waterfall development model proved to have several drawbacks. For example, if the users are not able to state all requirements explicitly up-front, project schedules may increase unacceptably, and there is a high probability that the completed software will not meet users’needs.
The prototyping model emerged in the context of decision support systems, where user requirements were especially difficult to determine up-front. In this model, initial user requirements are gathered in meetings between user(s) and developer(s). Then rapid development occurs, producing a quick and dirty prototype that can be evaluated by the user(s). Often this process is iterated until an acceptable design has emerged, at which point traditional development activities may take over (Pressman, 1997). With growing recognition that software and users’ requirements evolve over time, the development life cycle as a straight path to an end product seemed increasingly unrealistic. This led to the creation of evolutionary software process models. The spiral model (Boehm, 1988), combines the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. In this model software is developed in a series of “releases” (Pressman, 1997). The spiral model was particularly useful for characterizing the activities of commercial software developers working on large-scale systems. The waterfall, prototyping and spiral software process models are diagrammed in Figure 1. Waterfall model
Prototyping model
Spiral model
Project definition
Coding & Test listen to customer
Analysis
Release & Implementation
build / revise mock-up
Design
Coding
Design Test
customer test drives mock-up Implementation
Analysis Maintaining
modified from (Boehm, 1981) adopted from (Pressman, 1997) modified from (Boehm, 1988) Figure 1. Traditional Custom Software Process Models The prototyping and spiral models aim to improve the definition of user requirements and to shorten development activity through more effective feedback loops. However, the failure rates of software projects adopting the new development models remained high. Attempts were made to improve software development with automation in the form of CASE tools. But success has proved elusive (Fichman and Kemerer, 1999; Orlikowski, 1993). Personal Productivity Software Packages Another approach to solving the problems of custom software development was to outsource the activity to a commercial software vendor, who specializes in the development of software packages and thereby achieves economies of scale (Butler, 1999). Software packages for mainframe computers have been around since the mid-1960s, but they were used only to a limited extent (Markus, 1984). With the success of the personal computer in the middle 1980s, a full-fledged PC-based software package market emerged. Such packages, including word processing and spreadsheet software, supported the information processing needs of individual end-users. Also in this period business packages for areas such as CAD and small business accounting became widely available. Because early software packages were relatively inflexible, some package adopters modified package source code. Experience showed that software modification had a high failure rate (Laudon and Laudon, 1988) and hindered the adoption of vendors’newly released upgrades (Lynch, 1985). Consequently, software development activities on the part of package adopters are discouraged. Since the adopter does not develop software, the emphasis of package software life cycle models shifted away from development and toward implementation. Some research has addressed the special issues in the implementation of packaged software (Launi, 1991; Lynch, 1985). Software packages introduce large changes into the software life cycle. The adopter of such packages does not have to develop software. Rather, the adopter buys software ready made and installs it on a computer, while setting some parameters (Laudon and Laudon, 1988).
ERP Packages The early 1990’s saw the success of huge integrated packages known as ERP packages (Stefanou, 1999). The scope of ERP packages is much broader than that of early software packages; they integrate many formerly discrete applications around a common database. ERP packages enable adopters to integrate data and processes throughout the organization; they support nearly all functions, e.g., accounting, human resources, operations and logistics (Davenport, 1998). Davenport therefore calls these packages ‘megapackages’(1996). Characteristics of ERP Package Implementation Before an adopting company can use an ERP package, the package must be configured to fit organizational structures and processes. Configuration means setting parameters (and/or tables) within the boundaries of the provided functionality to match the software’s execution of functions and/or processes to the organization’s mode of doing business. The process of configuration differs fundamentally from programming. ‘Programming involves creating new software functionality. Configuration involves adapting the generic functionality of a package to the needs of a particular organization’ (Markus and Tanis, 2000). The major ERP packages can support a wide range of organizational possibilities through configuration, and adopting companies expend a great deal of effort on configuration. Adopters also have the option of modifying the source code of ERP packages to change or add functionality. But ERP systems are much more complex than the personal or business packages mentioned above, and ERP software modification is strongly discouraged. To benefit from vendors’ ongoing development and maintenance efforts, adopters enter into long-term partnerships with ERP vendors. ERP packages evolve through new releases that remedy bugs in earlier versions and provide new functionality (Markus and Tanis, 2000). Consequently, ‘implementation of an ERP system is fundamentally different from traditional systems development, and is also distinct from system use’(Volkoff, 1999). Research on ERP Packages Most research on ERP systems deals with the question of how to implement them successfully in an adopting organization. Life cycle models of ERP implementation are relatively common; they typically focus on activities performed by adopting companies or their agents (consultants or system integrators), but they generally ignore the activities of vendors. In a study of some two dozen companies, Markus and Tanis (2000) identified the following phases in a life cycle that extended beyond initial package implementation: “chartering,” “project” (with configuration and roll-out), “shakedown,” and “onward and upward.” Through 40 telephone interviews at 15 different companies, Ross also investigated the life cycle of ERP packages. She divided it into the stages of design, implementation, stabilization, continuous improvement and transformation (Ross, 1999). Neither of these studies identified the life cycle activities performed by software vendors. THE DIVIDED SOFTWARE LIFE CYCLE MODEL Adopters’ activities of implementing and operating ERP systems are important, but so are vendors’ activities of software development, maintenance, enhancement and support. To accommodate both parties’activities, we propose a divided software life cycle (DSLC) model, explicitly incorporating the interrelated spirals of vendor and adopter activities. (See Figure 2.) Initial Development and Adoption of the ERP Package The left spiral of the model refers to the vendor’s initial development of an ERP package or of a new package release or upgrade. This process involves the phases of system analysis, design, coding and testing, after which the vendor releases the software. Issuance of a software release is the starting point for the adopter’s cycle, shown in the spiral on the right. (See (Alter, 1999) for a helpful treatment of the vendor’s roles in the adopter’s life cycle.) The adopter evaluates the software in the concept phase, then configures it and rolls it out in the organization. The adopter’s first loop corresponds to the ERP implementation models mentioned above.
Configuration
Coding & Test
Release Rollout
Design Concept
Analysis
Usage
Indirect influence
Vendor
ERP Adopter
Figure 2. The ‘Divided Software Life Cycle’Model Evolution of the ERP Package and the Adopter’s Implementation of It Over the lifetime of an organization’s relationship with an ERP package and vendor, the DSLC may be repeated many times. The vendor normally releases a ‘continuous’ flow of upgrades in order to fixes bugs, to add new functionality to the ERP package and/or include changes necessitated by external factors (e.g., human resources changes related to new tax laws), and to keep pace with competition in the software marketplace. Each new release involves a new loop in the vendor spiral. If the adopter wants to benefit from the vendor’s additional development work, the adopter must implement the new release, thus triggering a new loop in the adoption spiral. Feedback from Adopter to Vendor Indirect feedback from the ERP adopter to the vendor, such as desired bug fixes and enhancements, comes through channels such as complaints, user feedback questionnaires, or developers’ visits to adopter sites. Occasionally, users band together in formal or informal user groups to exert greater pressure on vendor behavior. The influence of one adopter varies with factors like importance of the adopter, the market position of the vendor and market maturity. DISCUSSION The DSLC model extends prior research on the traditional custom software life cycle and on the implementation of ERP packages. The model has the following characteristics and benefits: • It reveals both the adopter’s and the vendor’s activities and the interactions between the two parties, • It shows the evolution of the software and the adopter’s implementation of it through successive releases, and • It highlights the long-term, interdependent nature of the relationship between ERP adopters and vendors. The model can be applied at several levels: an ERP adopter and vendor dyad, a group of adopters (e.g. in the same industry) with one vendor, or one adopter with several vendors (if the adopter uses a best-of-breed approach). Future research should recognize the dual nature of the life cycle of today’s software packages and should explore the relationships between vendors’and adopters’activities. For example, the DSLC model can provide insights about: • Factors influencing the organizational learning of vendors and adopters, • Vendors’management of development resources, and • The post-implementation experiences of ERP adopters.
REFERENCES Alavi, M. and Carlson, P. "A review of MIS research and disciplinary development," Journal of Management Information Systems: JMIS (8:4), 1992, pp. 45-62. Alter, S. Information systems : a management perspective, Addison Wesley, Reading, Mass., 1999. Bancroft, N.H., Seip, H. and Sprengel, A. Implementing SAP R/3, Manning, Greenwich, 1998. Bingi, P., Sharma, M.K. and Godla, J. "Critical Issues Affecting an ERP Implementation," Information Systems Management (16:3), 1999, pp. 7-14. Boehm, B.W. Software engineering economics, Prentice-Hall, Englewood Cliffs, N.J., 1981. Boehm, B.W. "A Spiral Model of Software Development and Enhancement," Computer (21:5 May), 1988, pp. 6172. Buckhout, S., Frey, E. and Nemec, J.J. "Making ERP Succeed: Turning Fear Into Promise," Journal of Strategy and Business (17:2), 1999, pp. 60-72. Butler, J. "Risk Management Skills Needed in a Packaged Software Environment," Information Systems Management (16:3), 1999, pp. 15-20. Davenport, T.H. "Holistic Management of Megapackage Change: The Case of SAP http://hsb.baylor.edu/ramsower/ais.ac.96/papers/devenpor.htm," (1999:08.Feb.), 1996, Davenport, T.H. "Putting the enterprise into the enterprise system," Harvard Business Review (76:4), 1998, pp. 121131. Fichman, R.G. and Kemerer, C.F. "The Illusory Diffusion of Innovation: An Examination of Assimilation Gaps," Information Systems Research (10:3), 1999, pp. forthcoming. Hoffer, J.A., George, J.F. and Valacich, J.S. Modern systems analysis and design, Addison-Wesley, Reading, Mass., 1999. Kendall, K.E. and Kendall, J.E. Systems analysis and design, Prentice Hall, Upper Saddle River, N.J., 1999. Kirchmer, M. Business process oriented implementation of standard software : how to achieve competitive advantage quickly and efficiently?, Springer, Berlin [u.a.], 1998. Laudon, K.C. and Laudon, J.P. Management information systems : a contemporary perspective, Macmillan ; Collier Macmillan, New York, London, 1988. Launi, J.D. "A Structured Methodology for Off-the-Shelf Software Implementation," Journal of Systems Management (42:10), 1991, pp. 6-9. Lozinsky, S. Enterprise-wide software solutions : integration strategies and practices, Addison-Wesley, Reading, Mass., 1998. Lynch, R.K. "Nine Pitfalls in Implementing Packaged Applications Software," Journal of Information Systems Management (2:2), 1985, pp. 88-92. Markus, M.L. Systems in Organizations: Bugs and Features, Pitman, Boston, 1984. Markus, M.L. and Tanis, C. "The Enterprise Systems Experience - From Adoption to Success," In Framing the Domains of IT Research: Glimpsing the Future Through the Past, R. W. Zmud (Ed.), Pinnaflex Educational Resources, Inc., Cincinnati, OH, 2000, Morrison, J. and George, J.F. "Exploring the software engineering component in MIS research," Communications of the ACM (38:7), 1995, pp. 80-91. Orlikowski, W.J. "CASE tools as organizational change: Investigating incremental and radical changes in systems development," MIS Quarterly (17:3), 1993, pp. 309-340. Pressman, R.S. Software engineering : a practitioner's approach, McGraw-Hill, New York, 1997. Ross, J.W. "The ERP Revolution: Surviving Versus Thriving," Working Paper CISR WP 307, Sloan WB 4086, Center for Information System Research, Sloan School of Management, MIT, August 1999. Royce, W.W. "Managing the Development of Large Software Systems: Concepts and Techniques," Proceedings of the Proceedings WESCON,, 1970, Stefanou, C.J. "Supply Chain Management (SCM) and Organizational Key Factors for Successful Implementation of Enterprise Resource Planning (ERP) Systems," Proceedings of the Fifth Americas Conference on Information Systems, Milwaukee, Wisconsin, 1999, pp. 800-802. Volkoff, O. "Using the Structurational Model of Technology to Analyze an ERP Implementation," Proceedings of the Fifth Americas Conference on Information Systems, Milwaukee, Wisconsin, 1999, pp. 235-237. Whitten, J.L., Bentley, L.D. and Dittman, K.C. Systems analysis and design methods, Irwin/McGraw-Hill, Boston, Mass., 1998.