Selecting an ERP software package

0 downloads 0 Views 138KB Size Report
Department of Accounting and Information Systems, College of Business ... Subsequent to that, an overview of the .... (MMIS)) and the manager of inventory.
An investigation of the decision process for selecting an ERP software: the case of ESC

Jacques Verville Department of Accounting and Information Systems, College of Business Administration, Texas A&M International University, Texas Alannah Halingten Department of Accounting and Information Systems, College of Business Administration, Texas A&M International University, Texas

Keywords

Selection, Software use, Organizations, Decision making, Purchasing

Abstract

Decribes how ESC, a holding company for a gas and electric utility and non-utility energy business, completed the acquisition of Oracle's enterprise resource planning (ERP) solution (finance and related applications) at a cost of US$6.5 million in March 1997. From initiation to completion, the acquisition took approximately six months. The structure of the acquisition process that emerged from the data revealed six distinctive iterative, recursive and interrelated processes that, together, form a complex web of activity and tasks for the acquisition of ERP software. These activities and tasks are described and analyzed as a function of the six processes. The ERP acquisition process developed by ESC for this acquisition was non-typical of their normal procurement practices and proved to be a significant learning experience for the entire organization. This case provides a useful illustration of ``good practice'' and sets forth the framework for the ERP acquisition process.

Management Decision 40/3 [2002] 206±216 # MCB UP Limited [ISSN 0025-1747] [DOI 10.1108/00251740210420156]

[ 206 ]

Introduction Enterprise resource planning (ERP) is a suite of application modules that can link backoffice operations to front-office operations as well as internal and external supply chains. ERP software conjoins functional areas and business processes in an integrated environment that provides a broad scope of applicability for organizations. While considered a viable alternative to in-house development (Verville and Halingten, 2001; Verville, 2000; Eckhouse, 1999; McNurlin and Sprague, 1998), the acquisition of ERP software is not without its challenges. At a cost of several hundreds of thousands or even millions of dollars, the acquisition of ERP software is a high-expenditure activity that consumes a significant portion of their capital budgets. It is also an activity that is fraught with a high level of risk and uncertainty. Why? Because, first of all, if a wrong purchase is made, it can adversely affect the organization as a whole, in several different areas and on several different levels, even to the point of jeopardizing the very existence of the organization (Verville and Halingten, 2001; Verville, 2000). This highlights the obvious need for making the right choice of software. It also brings to light the need for finding the best means for acquiring this type of software, so that the right choice can be made. Second, because of the implementation and the risk of its going awry, ERP implementations are said to be the single business initiative most likely to go wrong (Verville and Halingten, 2001; Verville, 2000; Hill, 1999). In light of these concerns, a research project was undertaken to determine the best way to acquire ERP software. However, with little research found on the topic of ERP acquisitions, it became necessary, in the first The current issue and full text archive of this journal is available at http://www.emeraldinsight.com/0025-1747.htm

order, to find out what indeed the process is through which organizations go to buy ERP software (Esteves and Pastor, 2001; Verville, 2000). As such, the research questions for the study were: ``How do organizations acquire ERP software?'', ``What are the processes that are involved for ERP software acquisitions?'' The focus of this paper, then, is on the acquisition process ± that of ESC[1], a holding company which completed the acquisition of a well-known ERP solution in March 1997. The paper will begin with a literature review of the Management Information Systems (MIS) field and be followed by the research methodology that was used for the study. The latter section will include a review of the methods used for data collection, data analysis and ensuring the validity of the study, as well as present the limits of the study. Immediately following this section will be ESC's corporate profile and a description of the circumstances that led to the decision to buy an ERP software solution. Subsequent to that, an overview of the activities through which ESC went to purchase ERP software will be presented. An analysis of ESC's ERP acquisition process will follow, along with the lessons that ESC learned from this acquisition experience.

Literature review A review of the literature in the field of MIS shows that research conducted in the area of ERPs has concentrated on implementation and post-implementation issues (Esteves and Pastor, 2001; Verville, 2000). The types of problems and issues that arise from the implementation of ERP systems range from specific issues and problems that can come up during the installation of an ERP, to behavioral, procedural, political and organizational changes, etc., that manifest subsequent to the installation. One research topic, that of critical issues that affect an ERP implementation, is the focus of the study that was conducted by Bingi et al. (1999). In a

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

similar study, Brown and Vessey (1999) focus on implementation practices to uncover the implementation variables that appear to be critical to the success of ERP implementations. Another research area is that of organizational change. In this area, Boudreau and Robey (1999) present a framework to guide research on ERP-related organizational transition (i.e. organizational change as a process). Another study by Koh et al. (2000) uses a framework, based on a process theory approach, to understand and explain the ERP implementation experiences of organizations. Another subject of research within the area of organizational change is the roles of individuals within organizations. In this vein, Caglio and Newman (1999) propose a study aimed at understanding the change in the roles of management accountants within the wider socio-economic context of the organization in which new ERPs are introduced. Other interesting topics for research include user buy-in, commitment (management, team, organization, etc.), leadership, organizational culture, stakeholders, organizational learning, organizational effectiveness, business process modeling, ERP development issues, and communications, to name but a few (AlMashhari, 2000; Hedman, 2000; Bingi et al., 1999; Boudreau and Robey, 1999; Glover and Romney, 1999; Hill, 1999; Miranda, 1999; Riper and Durham, 1999; Sieber et al., 1999; Sutcliffe, 1999; Wagner, 1999; Appleton, 1997; Best, 1997). While much attention is directed to implementation, post-implementation and other organizational issues, the issue of the acquisition process for ERP software is for the most part being ignored. This issue is important, however, because, as the stage preceding the implementation process, it presents the opportunity for both researchers and practitioners to examine all the dimensions and implications (benefits, risks, challenges, costs, etc.) of buying and implementing ERP software prior to the commitment of formidable amounts of money, time and resources. For researchers, the challenge would then be to ascertain the correlation between the acquisition and the implementation processes, the results of which could be beneficial to practitioners. Another objective of the research presented herein was to gain an understanding of current organizational ERP acquisition practices. The light shed on this process may help practitioners and contribute to the change and improvement of present ERP acquisition practices.

Research methodology Owing to the nature of the study, the research strategy was to do a multiple-case design involving four organizations (one of which is the subject of this paper) from different business sectors (manufacturing, telecommunications, transportation, energy) that had recently completed the acquisition of new ERP software. Since ERP acquisition is a relatively new area of research, the case study approach provides the best means to start exploring this issue. This approach was thought to be particularly well suited for this study, because it was expected to unveil a multitude of factors and dimensions that make the acquisition of ERP software such a complex process. The rationale for the multiple-case design was that as a research strategy, we could direct our focus to understanding the dynamics and complexities present within each case (Yin, 1989; Miles and Huberman, 1994), these being the processes and critical issues of software acquisition within organizations. Site selection for the study was made according to the following five criteria: 1 the acquisition had a significant impact on the organization; 2 the acquisition was significant, totaling several hundred thousand dollars or more; 3 the type of packaged solution that was acquired was of a complex nature such as ERPs; 4 the acquisition was a new purchase; and 5 the acquisition of the software was recently completed.

Data collection

Data collection was done in three parts. The first part consisted of semi-structured interviews. Interviews were conducted with four individuals, each lasting approximately one hour and 15 minutes. The informants, all of whom were directly involved in the acquisition process, included the financial systems project manager, an IT engineer from information technology planning (technical team leader for the financial system), a member of the procurement group, an IT analyst from information technology development (technical team leader for the materials management information system (MMIS)) and the manager of inventory management (member of the reengineering group). Open-ended questions were used throughout the interviews. They allowed for flexibility and provided the ``possibilities of depth; they (also) enable(d) the interviewer to clear up misunderstanding(s) (through

[ 207 ]

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

probing), to ascertain a respondent's lack of knowledge, to detect ambiguity, to encourage cooperation and achieve rapport, and to make better estimates of the respondent's true intentions, beliefs, and attitudes'' (Kerlinger, 1986, pp. 442-3). As it so happened, the informants sometimes gave unexpected answers that indicated the existence of relations (activities, tasks and influences) that were not originally anticipated, and this added to the richness of the cases. For this study, the opening question for the interview with each informant was as follows: ``In your own words, how did you go about buying packaged ERP software? Describe how the acquisition went, from the beginning to the end''. Following the informant's description, follow-up probing and topical questions such as ``Was there a planning scenario? If so, in your own words describe the planning aspect of the process. Describe in your own words the various aspects of the packaged software acquisition planning scenario'' were used to clarify an issue or to delve for more information. These follow-up questions also allowed for the development of ideas without constraining the exploratory nature of the study. The same interviewing protocol was observed with all the informants. The second part of the data collection consisted of the gathering of archival information from various sources within the organization and included documentation from acquisition project, plans, designs, best practices, policies, request for proposal (RFP), letters and memos, reports, etc. These documents allowed for a closer examination of what happened during the decision process. For the third part of the data collection member checks were conducted. Participants were asked to review their transcripts from the interviews in order to verify content and, when necessary, amend or add to them. Follow-ups were also conducted by telephone and/or e-mail to clarify ambiguities or discrepancies, or to confirm information. Feedback from others (peers independent of the organizations and individuals that participated in this study) was also obtained.

Validity

All interviews were audio-taped for subsequent transcription and for verification of accurate interpretation. Member checks were performed (as described in the previous section). Feedback was also obtained from individuals, independent of the study. The data from this study were validated using a triangulation method. According to Robson (1993), ``the by-products of

[ 208 ]

triangulation are as useful as its primary purpose in validating information. It improves the quality of data and in consequence the accuracy of the findings'' (p. 383). In addition, validity, according to Maxwell (1996), refers to the ``correctness or credibility of a description, conclusion, explanation, or other sort of account'' (p. 87). For example, the triangulation of data sources within one case was repeated in each of the other three cases and then for all the cases together. The results show that, while each of the cases is different with regard to the type of software solution that was being acquired, the same process was developed and similar tasks were performed.

Limits of the study

The limitations of this study can be linked to the choices that were made regarding the research and specifically relate to the newness of the research topic, that being the acquisition of ERP software, the minimal amount of research that has been conducted to date in this area, and the methodology that was used for the study. Given the lack of literature on this specific subject, the case study approach was selected as the best means to gain the maximum knowledge and understanding about packaged software acquisition activities, issues, dynamics and complexities. However, each method has its strengths and drawbacks, and the case study approach is no exception. It is more limited than surveys in terms of generalizability. While surveys enable precise extrapolation of results to a defined population (Maxwell, 1996), case studies are more limited in their focus. As such, a single or a few cases are poor representations of a population of cases and may be poor grounds for generalization. This said, a single case as a negative example can establish limits to grand generalization (Maxwell, 1996; Yin, 1989). Hence, case studies are of value in refining theory and suggesting complexities for further investigation, as well as helping to establish the limits of generalization. In the next section, we will be presenting the organization, background information about the case, the case itself and an analysis of each of the processes that comprise the ERP acquisition process, beginning with planning, followed by information search, selection, evaluation, negotiation and choice.

ESC's organizational profile ESC is a holding company for a gas and electricity utility and non-utility energy

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

business. One of its subsidiaries, ESC Plus, supplies natural gas and electricity to about 628,000 customers in Kentucky. The utility's service area covers approximately 700 square miles in 17 counties and includes Fort Knox Military Reservation. Another of its subsidiaries, ESC International, owns co-generation projects and independent power plants in the USA as well as in Argentina and Spain. The company markets energy and related services to customers across the USA through high revenue, lowmargin ESC marketing.

Background leading to ESC's decision to acquire an ERP

In the early part of 1996, an internal study was conducted, during which it was determined that some major enhancements were required to ESC's financial systems. ESC's financial systems consisted of four separate and distinct general ledger systems, and separate ``feeder'' systems and modules such as accounts payable and budgeting. None of these separate systems was linked in a manner that enabled effective reduction in the monthly closing cycle duration, nor did these systems enable the finance and accounting organization to deliver valueadded analysis to management in a fashion that was consistent with the strategic direction of the company. Further, these systems and processes relied heavily on manual effort to gather and interpret much of the available information. Most often, human rather than automated processes bridged the gaps between critical components of the financial reporting value chain. ESC's financial system was IBM mainframe-based and was not Y2Kcompliant. Their financial systems were, in many cases, antiquated, relying on disjointed, outdated and technologically cumbersome software and hardware platforms that would, within the next five or ten years, be unable to support their business growth. While these systems supported their existing business needs, they did so in a manner that was neither efficient nor functionally responsive to user needs. Evaluation of these findings showed a need to implement ``Year 2000'' (Y2K) solutions throughout the entire organization. Given the urgency and magnitude of this task, management set a deadline of September 30, 1996 to determine the plan for bringing the financial management information systems (FMIS) and its related systems into compliance. This plan entailed the hiring of consultants, programmers and the development of a timetable to bring these

systems into compliance in order to avoid a potential disaster. An acquisition team was assembled. After a more extensive review of the situation, the team concluded that failure to replace the existing FMIS in the next 18 to 24 months would result in an inability to migrate to a new financial system for another four to five years. The existing systems would need to be replaced by 1998. The team also concluded that the timing of this system replacement was pivotal to orchestrating ESC's other Y2Kcompliance initiatives. Given the restricted timeframe in which they had to replace this system, the team decided that the most expedient manner in which to do so was with the acquisition of a packaged solution. Hence, in late summer of 1996, a project team for the acquisition of a packaged software solution was formed to look at replacing the current financial system. ESC's management also required that all costs associated with the Y2K-compliance initiative be expensed in the year incurred. They felt that this one-time capital expenditure would substantially increase the value and functionality of the financial systems as well as the ability to manage by providing more timely, accurate and meaningful information. They further realized that the ongoing expenditures associated with the existing legacy system would remain the same. However, the benefits associated with replacing the systems significantly outweighed ``the cost of doing nothing'' in terms of both tangible dollars and intangible costs related to lost productivity, lost business opportunities, and decisions based on untimely or inaccurate information. Since it was felt that no added-value would be gained relative to the significant costs that would be incurred ± loss in productivity, no improved functionality, no increased capacity to respond to changing business needs nor to improve the speed with which information is moved from source to user, ESC decided to keep the existing hardware systems for no other reason than the ability to continue using them beyond the year 2000. The costs that were expected to be incurred over the next four years, if the status quo was maintained, could be broken down as follows: . Estimated cost of making FMIS and related systems Y2K-compliant: $1,000,000 (H$)[2]. . Cost of updating FMIS-related Focus programs to be Y2K-compliant: $1,000,000 (H&S$). . Version upgrade to Platinum G/L, A/P systems: $10,000 (H$).

[ 209 ]

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

ESC's management speculated that, if they had decided to invest the effort needed to make FMIS Y2K-compliant, ESC would in all likelihood have remained on FMIS for at least four more years and, moreover, certain single business units (SBUs) would have probably ended up spending money on new financial systems that would nevertheless have been replaced in an eventual companywide initiative to adopt a common platform. They estimated that the cost of continuing to operate the existing systems would be approximately $1,300,000, while the cost of operating the new system would be approximately $3,310,000. The cost of replacing the existing system was estimated at $6,500,000 over four years. When all was ``said `n' done'', they estimated that the new system's cost would result in net savings of approximately $3,400,000. Further to these tangible monetary benefits, they also saw that qualitative benefits would be associated with the new systems, such as: . Improved ability to manage business as a single enterprise. . Enabled quantification and evaluation of risk across consolidated business enterprise. . Improved query capabilities and timeliness with drill-down functionality for all SBUs. . Better adaptability/flexibility in combining, realigning or restructuring businesses. . Reduced risks with the reduction of the number of systems experts needed to maintain the existing four separate systems. . Improved future merger integration plans with the new platform. . Elimination of the need to pay premium prices for increasingly scarce expertise to maintain obsolete software and hardware platforms. . A better managed disaster recovery plan/ process. . Training that would be performed in a consistent and standardized fashion, thereby reducing cost and increasing ``bench strength'' and inter-SBU staff movement flexibility. They also realized that there were potential technology-enabling synergies that would benefit the organization including: . Consolidation of certain elements of the accounts-payable functions throughout the organization (of which there were a total of six separate functions) and combining the cash disbursement

[ 210 ]

.

.

.

function into a common shared services environment. Reduction of the costs associated with MMIS (materials management information system) ± elimination of the need to ensure that the linkages between the new MMIS system and FMIS are Y2K-compliant. Also, the accounts payable (A/P) module would stand on its own rather than as a component of an MMIS system. Improved relationships with vendors through combined A/P and cash disbursement systems. Improved management of payables and reduced risk of duplicate payments. More value added to resources spent on maintenance and training for a single system than for four separate systems.

Hence, in the early part of 1997, ESC decided to acquire an ERP solution for its general ledger, accounts payable, budgeting and forecasting, and miscellaneous sundry billing, work orders and projects systems. This integrated enterprise-wide solution would replace their existing independent systems.

Description of the acquisition activities for ERP software

ESC had previously purchased packaged ERP software, such as a general ledger package; however, buying a fully integrated packaged solution such as the financials was a first-time experience for them. In this case, they were looking to replace not only the general ledger package, but also budgeting, work orders and projects, etc. and these were systems that were written in-house. Therefore, to assist them with the acquisition process for a fully integrated solution, they sought expertise from outside the organization. In the latter part of 1996, they engaged the services of Arthur Andersen Consulting to help them in the buying process. It is with Arthur Andersen that they planned the various tasks and milestones (ESC had a very tight timetable to follow) that would be needed to choose the financial package that would best meet the various needs of ESC. In October 1996, a high-level planning meeting was scheduled (this is when Arthur Andersen was brought in). At subsequent planning sessions, the list of requirements that would go into the request for information (RFI) was drawn up, the schedule for vendor demonstrations was set up and the various evaluation criteria and milestones were established for ESC. These planning sessions were completed by November 1996. In conjunction with Arthur Andersen, ESC also engaged the services of Meta Group to find out who were the major vendors of

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

financial systems in the marketplace and which of them would have a product more suited to the needs of ESC. Meta Group supplied the ESC planning group (formerly, research and development group) with the names of seven vendors, who were considered the best in the industry for financial package software ± Hyperion, Coda, SQL (pronounced Sequel) Financials, PeopleSoft, Oracle, Lawson, and Dunn & Bradstreet. This list was further reduced to a short-list of five vendors. At this point (January 1997), each of the vendors was invited to give a two-hour information session about their product. At approximately the same time, each of the vendors was sent a request for proposal (RFP). After each presentation, the vendor was evaluated, first, according to a preliminary set of criteria, which was established during the planning sessions. From the results of these evaluations and the evaluations of the vendors' RFPs, the final short-list was made consisting of two potential candidates ± Oracle and PeopleSoft. Each of these vendors was in turn invited to give a two-day demonstration based on the scripted scenarios that were provided by ESC. A group of 50 users was brought in to participate in both demonstrations, each of whom evaluated (scoring 1 to 5) the technology, based on the functionality of the system, and how it performed, based on the scripted scenarios. After these demonstrations, an addendum with additional questions and requirements was sent to each vendor. Following the replies from the vendors, the acquisition team completed their evaluation and made their final choice of vendor. A multi-voting technique was devised, where each team member had an equal vote. The evaluation scores from each of the 50 users were also factored into the final analysis. A technical evaluation was also conducted on the various architectural elements of the software and scored. Each of these evaluation techniques was assigned scores, which were then quantified. The final result clearly indicated Oracle as the packaged ERP solution of choice.

Analysis of ESC's ERP acquisition process This section presents a detailed account of the processes and activities that ESC completed for the acquisition of Oracle's software solution. The case of ESC provides an example of the rigor that needs to be given first to the planning process, with the determination of the organization's requirements and the establishment of

evaluation criteria and, subsequent to that, to the evaluation process for the vendors and the packaged ERP software solutions. This case also demonstrates the need to verify sources of information. As will be seen later in this paper, Oracle had been discounted as a possible supplier, based on information that ESC had obtained from what they considered to be a credible source. Later, though, Oracle was returned to their list for further consideration. Oracle's financial software solution was determined to be the best choice for the ESC organization.

Planning process

The initial stage of the acquisition process that was completed by ESC correlates with the planning process. For ESC, ``planning'' marked the beginning of the acquisition process. Planning encompassed all the activities that ESC deemed necessary to pursue this endeavor. In global terms, ``planning'' included meetings to determine schedules, priorities, participants, resources that would be required, activities and tasks that would need to be completed, types and sources of information to be sought; and so forth. As we see, within the case, a planning phase was completed by ESC's acquisition team. What can also be deduced from the case is that, while some high-level planning was done, it was not until the services of Arthur Andersen were engaged that a more detailed and extensive level of planning was conducted by ESC for every stage of the acquisition process. A review of the ESC's planning process shows that it covered a series of issues including: . Participants ± Who would participate in the different phases of the acquisition? . Acquisition strategies ± How would the organization approach/deal with the vendors? . Establishing evaluation criteria ± How would we evaluate the software and against what criteria? . Establishing requirements ± What are our organizational needs in each of the areas that would be affected by the software? . Present status assessment ± What resources do we currently have? Where are we deficient?

Participants

The manager of IT projects was responsible for the acquisition project. Responsibility of the overall process was given to the project manager ± financial system. Individuals were recruited to participate in the acquisition process from the functional areas (``lines of business'') within the organization that would be immediately affected by the new

[ 211 ]

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

technology (and that were identified during a previous project, when the decision to buy a packaged software solution was made). So, whether as members of the acquisition team, as sources of information for determining system requirements or for their input during the evaluation process, it was apparent in this case that user involvement in the process was important to ESC. By inference, user buy-in to the new technology was also important, since each functional area (line of business) either was represented or had some input into the process. By design, many of the individuals that were part of the acquisition team were also part of the implementation project. As the project manager ± financial system stated, it was ``not coincidental'' that ``a lot of the same people [that participated on the acquisition Team are those] we have on the implementation team''. Participant continuity (team members and users) for the acquisition through to full implementation would ensure user buy-in of the chosen solution. ESC's steering committee also had a role in this acquisition process ± they oversaw the project, providing direction as needed, and were the final authority for approval of the acquisition. The steering committee was composed of ``a cross-functional group of officers'' and ``a couple of additional officers were added to the group, just to make sure that we were fully represented'' (project manager ± financial system). The purchasing department, in this particular case, had a limited role in the acquisition process. According to the agent of the procurement group, they have a ``formal bidding process for everything including software'' and, as mentioned by the project manager ± financial system, ``in instances where we had specific procurement guidelines that had to be adhered to, I did follow them''. However, even the procurement guidelines were modified to accommodate the special considerations needed for the ERP solution. However, many of the standard practices within ESC that are ``normally'' followed were not adhered to for this acquisition.

Acquisition strategies

The acquisition strategies that ESC employed impacted on their selection and evaluation processes. One strategy that ESC used was to have their shorter long-list of five vendors (Computron, SQL Financials, PeopleSoft, Oracle, and Lawson) come in and do ``highlevel, half-day, overall `look `n' feel' demonstrations'' (project manager ± financial system). These high-level demonstrations

[ 212 ]

allowed ESC to narrow their shorter long-list to a short-list of three vendors. ESC also had their final two short-listed vendors do on-site scripted demonstrations over a two-day period of their proposed technological solutions. For their presentations, each vendor would be required to use pre-determined scenarios supplied by ESC.

Establishing evaluation criteria

Establishing evaluation criteria was very important to the acquisition process for ESC and much time and effort went into establishing the evaluation criteria for the technological solution. ESC's acquisition team established criteria for three distinct types of evaluation: vendor, functionality, and technical. Vendor evaluation criteria included size, financial stability, reputation of the vendor, etc. Functional criteria dealt with the features of the software and included functionalities specific to front-end interfaces, user-friendliness and so on. Technical criteria dealt with the specifics of systems architecture, integration, performance, security, etc. ESC established all the evaluation criteria (with very few exceptions) for all three areas early in the acquisition process (during the planning process), because the majority of it was needed for incorporation into the RFP that would be sent to the vendors. This document would inform the vendors of the criteria against which they and their software solutions would be evaluated. ESC also used these criteria to develop scripts for the in-house demonstrations that they prepared for the short-listed vendors to do.

Establishing requirements

Given the wide-sweeping range of areas that the software solution was expected to cover, ESC had to determine exactly what requirements would need to be met by the technology as well as what their own business requirements were. They looked at their current resources ± what they had, what was lacking. They determined what they wanted that was not being met by their current systems. In addition to looking at the requirements that would need to be met by the new technology, they also ascertained the resources that would be required in order to acquire and implement this technology. Hence, they assessed their staffing resources, they considered the time requirements, they looked at the financial requirements ± how much it would cost to add more staff; they examined their own systems architecture ± would it be sufficient to support the new technology? and so on. So, they covered all areas of the organization.

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

Present status assessment

As has already been presented, ESC closely examined their existing status prior to the acquisition to determine the staffing requirements, i.e. human resources, that were needed in order to successfully complete the acquisition process. They also looked at their information technology requirements, that is, their infrastructure from both a software and a hardware perspective, to assess what would be needed to support (and interface with) the new technology.

Information search

ESC obtained information from both internal and external sources for the acquisition process. As to the internal information sources, ESC availed themselves of information from various sources within the organization that included individual users, team members and internal consultants. These internal sources provided information primarily on the organization's requirements (existing) at all the levels and in all the areas that the technology would impact. As to external sources, these were sought to provide information about the software solutions that would best meet their needs. According to the project manager ± financial system, ESC engaged the services of two professional research groups, Meta Group and CSC Index, to conduct a marketplace search. In addition, ESC also gathered information from such varied sources as external consultants, publications, trade shows, conferences, references, and the Internet. One particularly interesting source of information that ESC used was their competitors (the reference being to companies in the same business as ESC, but not necessarily in the same geographical area). As references, ESC found them to be a useful source of information. According to the technical team leader ± financial system, it is worth noting that, for the information search process, the credibility of the source of information stood out as being very important to the acquisition team. For the amount of readily available and often unreliable information to which one has access, the credibility of the source can play a significant role by providing the seeker with a more reassured sense that the information that has been provided is both accurate and reliable. This process also involved the screening of information. Concurrent with the planning process, several iterations of screenings were done on information from all sources to determine the long-list of vendors. Using high-level selection and evaluation criteria pertaining to both vendors and technologies

that ESC's acquisition team had determined early in the planning process, vendors were screened to determine who could supply the type of software solution that ESC was seeking. Various levels of information screenings were done by the acquisition team throughout the ERP acquisition process and these corresponded to the stage of process at which the team found itself.

Selection process

ESC's selection process was conducted in two phases ± the first with high-level demonstrations by the vendors on their shorter long-list and the second upon receipt of the RFP responses from the vendors. The high-level demonstrations allowed ESC to narrow the shorter long-list of five vendors to a short-list of three vendors. Concurrent with these high-level demonstrations, as part of their planning process, ESC (with the assistance of the consultants from Arthur Andersen Business Consulting) were defining their list of requirements/criteria that they would use in their RFP. Then, working with the detailed list of requirements, ESC and the Andersen consultants put together an RFP document, which they sent to the three vendors on their short-list. Then, with the RFP responses in hand, an evaluation was done, during which ESC came up with additional questions to the vendors for clarification on certain items. Again, the three vendors were contacted and following their responses, ESC were able to narrow the list further, leaving just two vendors ± Oracle and PeopleSoft. For the most part, we see the selection process as having begun at the point when the acquisition team received the RFP responses back from the vendors. However, the sequence of activities that ESC performed during their selection process was somewhat unusual. While they only sent the RFP responses to the three vendors on their longer short-list near the end of the selection process, they did perform ``selection''-like activities earlier with all five of the vendors from their longer list. As for the tasks themselves that ESC undertook during the selection process, ESC evaluated the vendors' high-level demonstrations based on general criteria that they (ESC) had defined. ESC conducted a ``paper'' evaluation of the three short-listed vendors' packages based on their RFP responses. During their evaluation of the responses, more questions were formulated by ESC for clarification by the vendors. At this point, ESC asked the three vendors to re-submit certain parts of their responses,

[ 213 ]

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

requesting that clarification be made on some items. Once the responses were received from the vendors and ESC had reviewed them, ESC proceeded to invite the remaining two shortlisted vendors to do on-site presentations of their software solutions.

Evaluation process

Three distinct types of evaluation were conducted by ESC: vendor, functionality, and technical. Evaluation criteria for all three types were developed in the planning phase of the acquisition process.

Vendor evaluation

In this case, the vendor evaluation was conducted only after ESC had selected their short-list of three vendors. Criteria such as vendor strength and/or reputation, financial stability (based on the vendors' financial statements), long-term viability and the vendor's vision/corporate direction were factors that were considered during the vendor evaluation. While it is standard practice for ESC to evaluate vendors using Dunn & Bradstreet (D&B) reports, for this project they decided not to do so. Information for the vendor evaluation was also obtained from copies of the short-listed vendors' annual reports, SEC (Securities and Exchange Commission) filings, and lists of references. Also, as stated by the project manager ± financial system, ``both of them [Oracle and PeopleSoft] had a lot of information available in the public arena for helping us to evaluate them.'' Lastly, as part of the vendor evaluation and relative to the price of the software solutions, ESC's acquisition team also requested and received a cost proposal (an RFQ) from both shortlisted vendors. The information that they received in the RFQ was factored into the acquisition team's final recommendation to the steering committee.

Functional evaluation

Responsibility for the evaluation of each technology's functionality rested with the entire acquisition team and the users who attended the demonstrations, while responsibility for the evaluation of its technical aspects rested with the technical team leader ± financial system and his team. The functional evaluation proved to be an important process for ESC, carrying 42 per cent of the overall evaluation weighting. It was during the functional evaluation that users participated in the decision process. Functional criteria that were established, as well as questionnaires and scenarios that were developed during the planning phase of

[ 214 ]

the acquisition process, were implemented during this process. Short-listed vendors were invited to participate in a two-day demonstration of their technological solution.

Technical evaluation

In addition to the functional evaluation, ESC also had their technical team (led by the technical team leader ± financial system) look at the technical aspects of the software. Most of the technical criteria that had been established during the planning stage and included in the RFP were now tested with the technology. As part of their evaluation process, ESC developed matrices and assigned weights and scores to the various areas of evaluation. It is important to note that, though ESC used an external consulting group to assist them in evaluating the software (Arthur Andersen Business Consulting helped ESC develop the list of requirements, the evaluation matrices, etc.), they did not forfeit control of this process to them.

Choice process

The acquisition process culminates in the choice process and consists of the ``final choice'' or ``recommendation''. In ESC's case, a ``final recommendation'' of software solution was arrived at by the acquisition team. It was based on the sum of the weighted scores for the five main categories of criteria: functionality, integration with other applications, ease of implementation, vendor strength and/or reputation, and cost. For the last category, cost, the acquisition team requested and received a cost proposal (an RFQ) from both short-listed vendors. As explained by the project manager ± financial system, while referring to the scoring matrix that was used, the scoring of the functionality was based, in large part, on the two-day demonstrations of the software by the vendors, from which they (ESC) ``wound up getting to the choice on the functionality component.'' Evaluation of the technical aspects of the software, covering issues such as the ability of the software to integrate with other applications and the ease with which it could be implemented (both among the main categories of criteria), was also scored, and a final ``choice'' was arrived at for each of these criteria. A final ``choice'' was also arrived at regarding vendor strength and/or reputation. The choice process that was noted in the ESC case consisted of one element, a final recommendation or choice. This recommendation was subsequently conveyed to a body outside the acquisition team (the steering committee) for final approval. We noted within this case that, although ESC had previously acquired human resource and

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

payroll software from PeopleSoft and were considering the PeopleSoft ERP solution, the issue of PeopleSoft being a ``former'' supplier to ESC did not appear to have had much (if any) impact on their final choice of software solution. Additional information on this issue was supplied by the technical team leader ± financial system. As we can see in the following quotation, the technical issue of ``integration'' outweighed the influence that PeopleSoft, as a ``former'' supplier, might have had in the acquisition team's final recommendation.

.

Negotiation process

Two types of negotiations transpired during the course of ESC's acquisition process: business and legal. The business negotiations were informal, while the legal negotiations were very formal. As part of the business negotiations, the project manager ± financial system also felt it important to establish executive-level relationships between ESC and both shortlisted vendors. One of the reasons for this, he explains, is that in the event of problems that might arise during the acquisition process, those issues could be dealt with ``at the right level''. According to the project manager ± financial system, ESC entered formal negotiations with their vendor-of-choice, Oracle, after the final recommendation was approved by the steering committee. At that point in the acquisition process, the project manager ± financial system set up a negotiation team that consisted of individuals from three different departments (legal, procurement, and IT) within ESC. Together, they assisted the project manager ± financial system during the final stage of the negotiation process leading to the signed contract.

Lessons learned The acquisition process for complex packaged software was not a ``new experience'' for ESC as an organization. ESC had previously acquired packaged software for human resources and was in the midst of acquiring a packaged software solution for payroll. However, while the members of those acquisition teams had experience of buying packaged solutions, their experience does not appear to have been conveyed to the members of the acquisition team for the financial system. Thus, for the members of the financial system acquisition team, this was a new experience. Among the lessons that this experience taught was that:

.

they had to develop new procedures for dealing with ERP software acquisitions. As we can see for ESC, their consultants played a large part in the development of new procedures for dealing with ERP acquisitions. Some fundamental processes or guidelines were in place, however, that the acquisition team followed for proceeding with certain aspects of the buying task, such as some ``specific procurement guidelines''. In large part, though, various procedures had to be developed ad hoc or were ``borrowed'' from the Arthur Andersen consultants to deal with this ``new'' buying situation. Also, no formal process for acquiring complex ERP software appeared to be in place in the IT department at the time of this acquisition, because, if there had been, the technical team leader ± financial system would, in all probability, have brought it to the attention of the project manager ± financial system. Thus, it was necessary for ESC to engage the services of outside consultants to assist them with the task of acquiring a financial software package: ERP acquisition process is very complex. As noted by the technical team leader ± financial system, ``even with all the variables known, the magnitude of a project like this is complex. There is no way around it.'' The project manager ± financial system added the following comments on what he discovered about the complexity of this type of decision process. Hence, although the acquisition process was done in a ``rushed'' and ``abbreviated'' manner, the acquisition team still contributed a documented history (meeting minutes/agendas, RFP document, lists of requirements, final report and recommendation, etc.) of what transpired during this acquisition process to the organizational memory.

Conclusion This case demonstrated, among others, the need to verify and cross-check information that is obtained from various sources. While reputation and credibility may vouch for the accuracy and reliability of the information that is obtained, these should not always be taken at ``face value'' ± it does not hurt to inquire about the background of the consultants with whom you work. As we saw in this case, the consultant's former ties with one of the ERP vendors prejudiced the information that he provided to ESC's acquisition team and resulted in ESC

[ 215 ]

Jacques Verville and Alannah Halingten An investigation of the decision process for selecting an ERP software: the case of ESC Management Decision 40/3 [2002] 206±216

dropping the vendor (Oracle) from their longlist. Although ESC later chose Oracle's software package, the prejudiced information from the consultant could have resulted in a very costly mistake or a less than optimal choice for ESC. While PeopleSoft was among the acquisition team's final two choices, and its HR software already in use by ESC's human resources department, the acquisition team felt that Oracle's financial package, a ``best-of-breed'' software in the utilities industry, would provide them with the best fit for their needs.

Notes

1 The name ESC is fictitious; it is used to preserve anonymity. 2 H$ denotes hard dollars that will flow out of the organization. S$ indicates soft dollars expected to be incurred in the form of productivity losses and inefficiencies, labor spent on nonvalue-added activities, etc. However, some departments would have needed to employ temporary labor or pay overtime to absorb the incremental workload. Therefore, a mix of hard and soft dollars have been incurred to make the Focus programs Y2K-compliant and the mix was unknown at that time.

References

Al-Mashari, M. (2000), ``Construct of process change management in an ERP context: a focus on SAP R/3'', paper presented at the Americas Conference on Information Systems (AMCIS), Long Beach, CA, 10-13 August. Appleton, E.L. (1997), ``How to survive ERP'', Datamation, Vol. 43 No. 3, pp. 50-3. Best, C. (1997), ``Integrated system built on human foundation'', Computing Canada, Vol. 23 No. 25, p. 54. Bingi, P., Sharma, M.K. and Godla, J.K. (1999), ``Critical issues affecting an ERP implementation'', Information Systems Management, Summer, pp. 7-14. Boudreau, M.C. and Robey, D. (1999), ``Organizational transition to enterprise resource planning systems: theoretical choices for process research'', Proceedings ICIS, Charlotte, NC, pp. 291-9. Brown, C. and Vessey, I. (1999), ``ERP implementation approaches: toward a contingency framework'', Proceedings ICIS, Charlotte, NC, pp. 411-16. Caglio, A. and Newman, M. (1999), ``Implementing enterprise resource planning systems: implications for management accountants'', Proceedings ICIS, Charlotte, NC, pp. 405-10. Eckhouse, J. (1999), ``ERP vendors plot a comeback'', Information Week, No. 718, pp. 126-8. Esteves, J. and Pastor, J. (2001), ``Enterprise resource planning systems research: an annotated bibligraphy'', Communications of AIS, Vol. 7 No. 8, pp. 1-52.

[ 216 ]

Glover, P. and Romney, M. (1999), ``Implementing ERP'', Internal Auditor, Vol. 56 No. 1, February, pp. 40-7. Hedman, J. (2000), ``The CES framework for discussing ES'', paper presented at the America's Conference on Information Systems (AMCIS), Long Beach, CA, 10-13 August. Hill, S. Jr (1999), ``It just takes work'', Manufacturing Systems, Selecting and Implementing Enterprise Solutions Supplement, pp. A2-A10. Kerlinger, F.N. (1986), Foundations of Behavioral Research, 3rd ed., Holt, Rinehart & Winston, Inc., Austin, TX. Koh, C., Soh, C. and Markus, L. (2000), ``A process theory approach to analyzing ERP implementation and impacts: the case of Revel Asia'', Journal of Information Technology Cases and Applications, Vol. 2 No. 1, pp. 4-23. McNurlin, B.C. and Sprague, R.H. Jr (1998), Information Systems Management in Practice, 4th ed., Prentice-Hall, Englewood Cliffs, NJ. Maxwell, J.A. (1996), Qualitative Research Design: An Interactive Approach, Sage Publications, Thousand Oaks, CA. Miles, M.B. and Huberman, A.M. (1994), Qualitative Data Analysis: An Expanded Sourcebook, 2nd ed., Sage Publications, Thousand Oaks, CA. Miranda, R. (1999), ``The rise of ERP technology in the public sector'', Government Finance Review, Vol. 15 No. 4, pp. 9-17. Riper, K. and Durham, M.J. (1999), ``Phased ERP implementation: the city of Des Moines experience'', Government Finance Review, pp. 37-42. Robson, C. (1993), Real World Research: A Resource for Social Scientists and PractitionerResearchers, Blackwell, Oxford. Sieber, T., Siau, K., Nah, F. and Sieber, M. (1999), ``Implementing SAP R/3 at the University of Nebraska'', Proceeding, ICIS, Charlottes, NC, pp. 629-49. Sutcliffe, A. (1999), ``Towards a theoretical framework for engineering reusable components'', Proceedings of the 1st International Workshop on Enterprise Management Resource and Planning Systems (EMRPS), Venice, 25-27 November, pp. 103-17. Verville, J. and Halingten, A. (2001), Acquiring Enterprise Software: Beating the Vendors at Their Own Game, Prentice-Hall, Englewood Cliffs, NJ. Verville, J.C. (2000), An Empirical Study of Organizational Buying Behavior: A Critical Investigation of the Acquisition of ``ERP Software'', Dissertation, Universite Laval, QueÂbec. Wagner, G. (1999), ``Agent-oriented enterprise and business process modeling'', Proceedings of the 1st International Workshop on Enterprise Management Resource and Planning Systems (EMRPS), Venice, 25-27 November, pp. 329-46. Yin, R. K. (1989), Case Study Research: Design and Methods, Sage, London.