WIXLIB

2014 Proceedings of the Conference for Information Systems Applied ResearchBaltimore, Maryland USAISSN: 2167-1508v7 n3316ERP Customization vs. Business ProcessReengineering: Technical and FunctionalPerceptionsMeg Frylingmfryling@siena.eduComputer ScienceSiena CollegeLoudonville, NY 12211, USAAbstractInformation system failures and cost overruns have plagued organizations for decades. In order totake full advantage of Enterprise Resource Planning (ERP) systems, implementations require drasticstructural and cultural changes within the organization including business process reevaluation andreengineering. These changes are difficult to accomplish and organizations continue to struggle withchange management of ERP systems. Stakeholder involvement and perceptions regarding the ERPsystem change over time. Understanding evolving perceptions may lead to improved long-term ERPsystem management and reduced costs. The purpose of this research is to gain dynamic insight intothe software project management of pre-packaged enterprise-wide information systems (i.e. ERP).This study uses system dynamics modeling together with interviews of ERP project members to betterunderstand the technical and functional perceptions regarding customization versus business processreengineering to satisfy functionality gaps.Keywords: ERP, System Dynamics, Business Process Reengineering, Enterprise Resource Planning,Customization, Total Cost of Ownership1. INTRODUCTIONEnterprise Resource Planning (ERP) informationsystems emerged during the 1990s as a crossfunctional enterprise-wide information systemsolution.ERP systems integrate data andprocessesfromdisparateorganizationaldepartments into a single information system(Dodds & Spencer, 2007; Rashid, 2005;Sammon & Adam, 2005). This vast integrationis intended to improve data access, dataaccuracy and workflow as well as to enhanceefficiency, agility and responsiveness (Sammon& Adam, 2005). ERP systems were initiallyintended for large industrial companies but arenow implemented by a wide variety ns. A key piece of ERP integration is theuse of a single database and multiple softwaremodules covering various departmental businessfunctions.ERP implementations force themerger of disparate organizational data andfunctions (Dodds & Spencer, 2007; Rashid,2005; Sammon & Adam, tments is what makes ERPs more complexand larger in scope than traditional softwarepackages (Brehm, Heinzl, & Markus, 2001;O'Brien & Marakas, 2006). This complexity isdue to the underlying business processesembedded in ERP systems (Bansal & Negi,2008). Therefore, ERP systems require vigilantchange management to implement successfully(Dong, 2000; Somers & Nelson, 2001).Issues related specifically to the implementationof traditional pre-packaged lmed 2014 EDSIG (Education Special Interest Group of the AITP)www.aitp-edsig.orgPage 1

2014 Proceedings of the Conference for Information Systems Applied ResearchBaltimore, Maryland USAISSN: 2167-1508v7 n3316organizations since the 70s, decades before theemergence of ERP systems. As McNeil discussedin 1979, the fact that both user requirementsand vendor offerings are constantly fluctuatingand evolving; making the proper managementof pre-packaged information systems nearlyimpossible. There are unique challengesassociated with implementing these types ofinformation systems. Organizations have littlecontrol over the quality of “off-the-shelf”information system functionality and are at themercyofvendorswhomakesoftwareimprovements based on their strategic internalpolicies and not necessarily customer needs(McNeil, 1979). While customers can s, vendors typically deny softwareenhancementrequestduetothehighdevelopment and maintenance costs (Brehm etal., 2001). Often the software as delivered doesnot fully meet the needs of the organization sofrequentchanges(customizations)andextensive maintenance are required (McNeil,1979).Organizations can choose to havecustom software built to meet their uniquerequirements but this imposes additional costs,risks, and implementation delays (Brehm et al.,2001; Fryling, 2010).requirements of each institution.Thisconfiguration is not technical in nature butrequires functional business process expertise.Therefore, implementation requires technicaland functional communication, collaboration,and active project participation. “Because ERPsoftware has to be implemented rather thansimply installed, it requires a paradigm shift formost functional users” (Frantz et al., 2002, p.40). “ERP implementations usually requirepeople to create new work relationships, shareinformation , and make business decisions theywere never required to make” (Appleton, 1997,p. 52). Often it is the case that in the pre-ERPenvironment there were more efficient ways todo business that were simply impossible withdisparate information systems. For example, in ahigher education environment without ERP thefinancial aid office must wait for nightlyinterfaces to run in order to make decisionsregarding a student’s financial aid eligibility.With an ERP the financial aid staff can accessstudent account and student records informationin real time; thus, improving customer service.These improved business practices can beexploited with ERP only if functional andtechnical project stakeholders communicate andcollaborate effectively.ERP systems differ from traditional softwarepackages because they are neither “custombuilt” nor “off-the-shelf” (Brehm et al., 2001, p.2). ERP systems are, in theory, designed basedon industry best practices and are intended tomeet the needs of all similar organizations(Kumar & Van Hillegersberg, 2000). Since ERPsare developed to meet the needs of a variety ofinstitutions, they are inherently generic andoften reflect the vendor’s perception of bestpractices; these will likely contradict many of theimplementing organization’s notions of bestpractices (Crumbly & Fryling, 2012; Dong, 2000;Orlikowski, 2002). This is further complicatedby the integrated nature of ERP. In the pre-ERPenvironment functional offices could work fairlyautonomously and developed specialized unitbusiness practices (Frantz, Southerland, &Johnson, 2002); hence, technology-wise theywere decentralized. Pre-ERP information systemimplementations did not require cross-functionalcollaboration and in fact necessitated littlefunctional user involvement at all; they wereprincipally IT initiatives (Frantz et al., 2002).The major challenge for the organizationimplementing an ERP is instituting a majorparadigm shift for executive leadership. “CFOsapproach business processes from a practicalorientation, whereas CIOs tend to be moretechnically oriented” (Frantz et al., 2002, p. 40).“ERP systems are really about closely integratingdifferent business functions; this is what setsthem apart from many other IT efforts”(Akkermans & van Helden, 2002, p. 36). Thistight integration provides an information systemwith increased access to real-time data and asignificant reduction of data redundancy, yetthosesamebenefitsimposesignificantcomplexity. The complex design of ERP systemsmakes them difficult to understand, implementand modify (Dodds & Spencer, 2007).While ERP systems are generic in nature, theydo have some flexibility built in and areconfigurable to meet some of the specificInformation system failures and cost n, 2003; Tapp, Hesseldenz, & Kelley,2003). In order to take full advantage of ERPsystems, ERP implementations require drasticstructural and cultural changes within n and reengineering. These changesare difficult to accomplish and organizations 2014 EDSIG (Education Special Interest Group of the AITP)www.aitp-edsig.orgPage 2

2014 Proceedings of the Conference for Information Systems Applied ResearchBaltimore, Maryland USAISSN: 2167-1508v7 n3316continue to struggle with change management ofERP systems.conducted its first major upgrade of that systemin 2008.ERP implementations have distinct phases. Eachofthese phasesinvolvea variety ofstakeholders, with different levels of erinvolvementandperceptionsregarding the ERP system change over time(Besson & Rowe, 2001). Understanding evolvingperceptions may lead to improved long-termERP system management and reduced costs.This study focuses on the perceptions of ERPproject stakeholders in the post-implementationphase, shortly after a major system upgrade.System Dynamics and Casual-LoopDiagramsBecause ERP management consists of dynamicproblemsarisingfromcomplexsocial,managerial and economic systems, the systemdynamics methodology is ideally suited to studyERP project management (Richardson, 1996). Inorder to address the challenges of ERPmanagement, practitioners need a tool that willhelp them understand the complexities of thesystem they are attempting to control. Systemdynamics is a useful methodology for this typeof research because it helps individualsunderstand the dynamics occurring in the realworld (Meadows, 1989) and explore the impactof alternative decision options.2. METHODOLOGYResearch Questions and ObjectivesThe purpose of this research is to gain dynamicinsight into the software project management ofpre-packagedenterprise-wideinformationsystems. This study seeks to better rding customization versus business on system (i.e. ERP) functionality gaps.Primary questions to be addressed are: Are customizations perceived a “slipperyslope” such that the more they areimplemented, the more they aredesired? How likely are customizations to bereevaluated once created? What impact does top managementsupport have on business processreengineering versus customization? Is there a perception that businessprocess reengineering is more timeconsuming than customization? Is there a perception that customizationsare an easier fix for functionality gapsthan business process reengineering? Are customizations perceived as morecostlythanbusinessprocessreengineering?Case StudyThisresearchemployedacasestudymethodology with interviews of key functionaland technical ERP project participants. The casestudy institution is a state research uatestudents,5,000graduatestudents and 4,300 employees. The institutionimplemented its first ERP system in 2004 andCausal Loop Diagrams (CLDs) are influences within a system and helpprovide insight into a system’s structure. CLDsexplicitly show the complex interdependence andcircular causality between components in thesystem (Sterman, 2000). The use of causal loopdiagrams in the interview setting allowed for afocused discussion regarding model elements.Based on the research questions, a CLD wascreated for use during the interviews (seeAppendix A, Figure 1).Interview AdministrationThe interview protocol was developed andpiloted with two case study employees; onefrom a functional department and one from thecentralized technical department. The interviewstructure was modified based on the feedbackfrom these pilot tests. To further improve theinterview structure and consistency betweeninterviews, a comprehensive administrativescript was created. A solicitation to participatewas sent to 9 case study project participants. Apurposive sampling frame was used because itwas important that the researcher interview keyproject participants who are able to provideinformation relevant to the research focus(Bryman, 2004). In addition a solicitation wassent to a technology in higher education listserv.Individuals were selected based on their role anceproject.Ofparticular importance was the recruitment of asampling frame with a balanced mix offunctional and technical stakeholders as well asexecutive leadership.The results of the 2014 EDSIG (Education Special Interest Group of the AITP)www.aitp-edsig.orgPage 3