University of Bayreuth
Chair of Information Systems
D-95440 Bayreuth, Germany
Phone +49 921 552807, Fax +49 921 552216
The Divided Software Life Cycle of ERP Packages
Lars Brehm, M. Lynne Markus
Working Paper 1/2000
presented and published as a full paper at
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
THE DIVIDED SOFTWARE LIFE CYCLE OF ERP PACKAGES
Lars Brehm, University of Bayreuth, Germany, Lars.Brehm@uni-bayreuth.de, +49 (0) 921 55 2812
M. Lynne Markus, Claremont Graduate University, USA, M.Lynne.Markus@cgu.edu, + 1 909 607 3151
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 ages change the SLC in several important ways. This paper presents an extension of the SLC model for ERP pack-ages. The ‘divided software life cycle’ (DSLC) model features an equal emphasis on the activities performed by the ERP adopting company and the ERP vendor.
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 main-tained 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.
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 hap-pens 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 us-ers’ needs.
The prototyping model emerged in the context of decision support systems, where user requirements were espe-cially 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 evalu-ated by the user(s). Often this process is iterevalu-ated 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 Analysis Design Coding Test Implemen-tation Maintaining
modified from (Boehm, 1981)
listen to customer customer test -drives mock-up build / revise mock-up
adopted from (Pressman, 1997)
Coding & Test
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 com-mercial 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 spread-sheet 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 ad-dressed 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).
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 appli-cations 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 struc-tures 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 organiza-tional 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 rem-edy bugs in earlier versions and provide new functionality (Markus and Tanis, 2000). Consequently, ‘implementa-tion of an ERP system is fundamentally different from tradi‘implementa-tional 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 or-ganization. Life cycle models of ERP implementation are relatively common; they typically focus on activities per-formed 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 configura-tion and roll-out), “shakedown,” and “onward and upward.” Through 40 telephone interviews at 15 different com-panies, Ross also investigated the life cycle of ERP packages. She divided it into the stages of design, implementa-tion, stabilizaimplementa-tion, 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 re-lease 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.
Coding & Test
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 func-tionality 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.
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 rela-tionships 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
Alavi, M. and Carlson, P. "A review of MIS research and disciplinary development," Journal of Management In-formation 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. 61-72.
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 Manage-ment (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. 121-131.
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 advan-tage 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 Manage-ment (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 Edu-cational 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,