InfoSci®-Journals Annual Subscription Price for New Customers: As Low As US$ 4,950

This collection of over 175 e-journals offers unlimited access to highly-cited, forward-thinking content in full-text PDF and XML with no DRM. There are no platform or maintenance fees and a guarantee of no more than 5% increase annually.

Receive the complimentary e-books for the first, second, and third editions with the purchase of the Encyclopedia of Information Science and Technology, Fourth Edition e-book. Plus, take 20% off when purchasing directly through IGI Global's Online Bookstore.

APA

Balint, B. (2017). To Code or Not to Code: Obtaining Value From the Customization of Packaged Application Software. In M. Tavana (Ed.), Enterprise Information Systems and the Digitalization of Business Functions (pp. 238-257). Hershey, PA: IGI Global. doi:10.4018/978-1-5225-2382-6.ch011

Chicago

Balint, Bryon. "To Code or Not to Code: Obtaining Value From the Customization of Packaged Application Software." In Enterprise Information Systems and the Digitalization of Business Functions, ed. Madjid Tavana, 238-257 (2017), accessed March 19, 2018. doi:10.4018/978-1-5225-2382-6.ch011

Abstract

Businesses that purchase packaged application software – for example, an Enterprise Resource Planning system – must make choices about customization. Software vendors, anecdotal evidence, and practitioner-oriented research all recommend that organizations should customize software as little as possible, and instead adapt their processes to meet the “best practices” of the software. However, businesses continue to exceed their budgets on implementing and maintaining customized software, often to a significant extent. This suggests that either these organizations are making poor decisions, or that the conventional wisdom about customization is incorrect. In this paper we model the primary factors in the customization decision: “fit” between the desired business process and the packaged software; costs related to development, maintenance, integration, and performance; and benefits related to increased fit, integration, performance, and user acceptance. We use simulation techniques to illustrate the conditions under which customization is likely to provide value to the organization, as well as conditions under which customization should be avoided.

Introduction

Enterprise Resource Planning (ERP) systems are the most complex category of Enterprise Information Systems. While ERP adoption has progressed into some service industries, the vast majority of the ERP user base continues to be large manufacturing firms (META Group, 2004). Firms make the decision to implement ERP systems for many reasons, sometimes technical (Y2K or the obsolescence of old systems, for example) but predominantly to meet operational business requirements. One reason that many firms choose to implement ERP is in order to achieve competitive advantage over other firms in the same industry (Jafarnejad, Ansari, Youshanlouei, & Mood, 2012). The logic is that by following the business processes prescribed by the functionality and structure of the ERP system, business units (BU’s) within a firm will be collectively more efficient because they will be able to share data effortlessly (Ravasan & Rouhani, 2014). ERP systems have been shown to give firms an advantage over their competitors on several performance dimensions including profit margin, return on assets, and inventory turnover (Hitt, Wu & Zhou, 2002; Tang & Marthandan, 2011). However, many companies decide to implement an ERP system after some of their competitors have already implemented or started implementing the same ERP system. For example, General Motors, Ford, Volvo and BMW all use SAP, the ERP market leader (SAP, 2014).

One way in which companies seek to extract additional gains from an ERP systems and other packaged software is to tailor it using custom development that meets business-specific needs. For example, a publisher may have a complex royalty structure that is not handled within the standard accounting functionality of an ERP package. Given this situation, the publisher can either choose to simplify its royalty process or to modify the ERP package with custom development in order to handle its existing process. Most ERP vendors provide a mechanism for custom development but warn against it. One advertised benefit of ERP systems is the “best practices” that are embedded in the software; custom development may be incongruent with these practices, or may interfere with their use. Custom development may also affect the integration of data across different areas, another important benefit of ERP systems. In addition, all custom development must be maintained over time, and custom development that is done poorly may slow down system performance (Ng, 2013).

In spite of these potential issues, many firms in the publisher’s situation would choose to customize the package. A responsible implementation project manager would conduct some form of cost-benefit analysis to decide which pieces of custom development to create. Unfortunately, not all of these analyses are complete or accurate. Benefits from customization may be overstated, and software development costs are notoriously underestimated (Harter, Krishnan, & Slaughter, 2000). As a result, firms may not derive the value from custom development that they expect; in fact, custom development may decrease the overall value of the system. However, ERP project managers that fully understand the costs and benefits of custom development should be able to make more knowledgeable decisions about it.

In this paper we present a model of custom development in the context of packaged application software. The model is most relevant to large-scale business software such as ERP systems, but can be generalizable to any business application software. We then use simulation techniques to model different conditions under which custom development may occur. As a result, we are able to describe and interpret the optimal conditions for the custom development related to packaged software. Implications and limitations of our model are also discussed.