A six-stage model of the buying process for ERP software

Transcription

1 Industrial Marketing Management 32 (2003) A six-stage model of the buying process for ERP software Jacques Verville*, Alannah Halingten Department of MIS and Decision Science, College of Business Administration, Texas A&M International University, 5201 University Boulevard, Laredo, TX 78041, USA Received 1 October 2001; received in revised form 1 October 2002; accepted 1 November 2002 Abstract This paper presents a model of the Enterprise Resource Planning (ERP) software acquisition process that reflects the findings from the four cases examined in this study. This ERP acquisition process model includes six distinctive, yet interrelated, processes (planning, information search, selection, evaluation, choice, and negotiations). This paper depicts the principal processes and many of the constituent activities, issues, dynamics, and complexities that pertain to the acquisition of ERP software. The results from this study contribute to the identification of processes that are part of this type of acquisition. Further, this model also suggests complexities that are worthy of further investigation, in and of themselves, if for no other reason than that they could prove the limit of generalizability of the model. D 2003 Elsevier Science Inc. All rights reserved. Keywords: Enterprise Resource Planning (ERP) software; Acquisition; Planning; Evaluation; Negotiations 1. Introduction Since the early to mid-1990s, the Enterprise Resource Planning (ERP) software market has been and continues to be one of the fastest growing segments of the information technology (IT) industry with growth rates averaging from 30% to 40% per year (Eckhouse, 1999). With worldwide sales of ERP software estimated to exceed US$22 billion by the year 2001 (PricewaterhouseCoopers, 1999; Yankee Group, 1998), it has been further estimated that by the year 2002, packaged applications would represent a significant portion of most IT portfolios (Meta Group, 1998). With costs equaling several thousands, hundreds of thousands, and even millions of dollars, ERP packaged software purchases are high expenditure activities for organizations that consume significant portions of their capital budgets. While overall IT expenditures already represent a significant portion of ongoing capital expenditures for many organizations and will continue to increase, little is known about how these expenditures are made, or more precisely, what organizations have to go through when they buy IT such as ERP packaged software (Verville, 1998, 2000; Verville & * Corresponding author. Tel.: address: jverville@tamiu.edu (J. Verville). Halingten, 2001). Indeed, what processes do organizations use and what are the specifics involved in those processes? In recognition of the importance of this issue and of the sizable risk that organizations take when they decide to buy this type of technology, the study that is presented herein focused on how organizations go about the task of acquiring ERP packaged software applications. Taken beyond the bounds of studies carried out in organizational buying behavior (OBB) on the influencing factors mitigating the buying process, this study focused on the buying process itself and identified its (the process s) major components. It also revealed several issues relevant to the need and readiness of the organization both for the acquisition process as well as for the new ERP software. Further, it revealed issues relevant to the implementation of the ERP and brought to light the complexity of the process at the detail level. The results of the study prove, contrary to the wide-standing belief that IT acquisitions are done routinely and fairly simply, that acquisitions of this nature (for ERPs) are complex, involved, demanding, and intensive. Prior to proceeding with the study, a brief review of the literature on ERP from the field of management information systems (MIS) and OBB was carried out. A methodology was then selected, and other appropriate tools were used to carry out the analysis and draw conclusions, all as presented below /03/$ see front matter D 2003 Elsevier Science Inc. All rights reserved. doi: /s (03)

2 Literature review J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) Theoretical background 2.1. Enterprise Resource Planning ERP research has concentrated on implementation and postimplementation issues (Esteves & Pastor, 2001; Verville, 2000). The type 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 (Appleton, 1997; Benson & Rowe, 2001; Bingi, Sharma, & Godla, 1999; Glover, Prawitt, & Romney, 1999; Miranda, 1999; Sieber, Siau, Nah, & Sieber, 1999; Stafyla & Stefanou, 2000). While much attention is directed to implementation, postimplementation, and other organizational issues, the acquisition process for ERP software is for the most part being ignored. This issue is important, however, because as the stage proceeding the implementation process, it presents the opportunity for both researchers and practitioners to examine all of 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 Organizational buying behavior In addition to the above, a review of the literature from the field of industrial marketing and, more specifically, the area of OBB was also conducted. It revealed that little research has focused on the IT (or ERP) acquisition process (e.g., packaged software) itself. According to Geisler and Hoang (1992), whose study focused on the purchase of IT by service companies, most of the literature has not stemmed from research studies, but rather has been generated by practitioners who focused on the critical issues facing managers in the acquisition of IT and has been prescriptive in nature (e.g., research in the area of industrial purchasing or OBB has concerned itself with the development of integrated conceptual models and the empirical verification of hypotheses pertaining to specific aspects of industrial buying or OBB, Choffray & Lillien, 1980). While this literature is rich in its study of various aspects of purchasing behavior within organizations, none of these studies has focused on the actual acquisition process itself, not to mention the acquisition of IT or ERP packaged software. The current focus of OBB continues to be the same, largely ignoring the advent of IT. Neither the field of MIS nor the field of OBB has adequately considered the acquisition of ERP software. Hence, little insight has been provided from either of these areas. In the past 30 years, within the field of industrial marketing and more specifically the area of OBB, conceptual models such as Webster and Wind s (1972) General Model of Organizational Buying Behavior and Sheth s (1973) Model of Industrial Buyer Behavior have been developed to understand organizational buying. Webster and Wind s model incorporates the concept of the buying center whose response to purchase is analyzed as a function of four classes of variables: individual, interpersonal, organizational, and environmental. Sheth s model attempts to describe and explain all types of industrial buying decisions and is characterized by three main elements: (1) the psychological characteristics of the individuals involved; (2) the conditions that precipitate joint decision making; and (3) the conflict resolution procedures affecting joint decision making. Both the Webster and Wind and the Sheth models identify factors that influence the buying process. Both models also include a distinction as to whether the buying decision is a group/joint or individual/autonomous decision. However, neither model provides any hint as to the construct of even a general buying process that is used by organizations. Further to these models of OBB, Robinson, Faris, and Wind (1967) developed a buygrid framework, which incorporates buyphases or buystages. These stages represent the sequence of activities often performed in an organizational buying situation. These activities include: (1) recognition of need and a general solution; (2) determination of characteristics and quantity; (3) description of characteristics and quantity; (4) search for potential sources; (5) acquire and analyze proposal; (6) evaluate proposals and select suppliers; (7) select an order routine; and (8) performance feedback and evaluation. Another model proposed by Hillier (1975) concentrates on individual involvement in organizational buying, buyer supplier functional interrelationships, and industrial buying as a corporate process. Yet another model, developed by Choffray and Lilien (1980), addresses the issues of individual differences in choice formation and interorganizational differences in buying behavior. While many conceptual models of the buying behavior of organizations have been developed, there has been a lack of research to extend and test these models (Ward & Webster, 1991). According to these authors, the lack of specificity of these models is one of the reasons why researchers have not designed follow-up research. Another reason is their generality, which leads to their major strengths and weaknesses (Ward & Webster, 1991). According to Johnston and Lewin (1996, p. 2), these models having been developed during the early stages of theory development provided only general categories of constructs expected to influence organizational buying behavior, and as such, failed to capture all of the concepts, variables, and relationships involved. Theoretically, certain aspects of these models of OBB may reflect some of the buying realities for IT, while others may not.

3 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) One major assumption, that existing OBB models may be inadequate in their explanation of the IT (e.g., ERP software) acquisition phenomenon, is made for the following reasons: (1) OBB studies have focused mainly on buying behaviors and their influences; (2) the orientation of research conducted in the area of OBB has produced a tunnel vision effect with respect to the conceptualization of OBB research due to the limited focus of these studies (Wind & Thomas, 1990); and (3) they overly emphasize influences on the buying unit while neglecting the dynamics of the processes involved. A study of the buying process itself could serve two purposes: (1) to identify the construct of the buying process, in this case, for ERP software, and (2) to identify some influences and behaviors that, in effect, could lend corroboration to those identified in Webster and Wind s (1972) general model. The first of these two points is that which is the focus of this paper. 4. Research methodology Due to the nature of the study, the research strategy was a multiple-case design with four organizations that had recently completed the acquisition of an ERP solution. The rationale for the multiple-case design was that as a research strategy, the focus was to understand the dynamics and complexities present within each case; these being the processes, critical issues, and influences on the software acquisition within the organization (Miles & Huberman, 1994; Yin, 1989). Since the area of ERP acquisition is a relatively new area of research, the case study approach provided the means for an in-depth analysis of the construct of the ERP acquisition process. This approach was particularly well suited for this study because it unveiled a multitude of factors and dimensions that make the acquisition of ERP software such a complex process. Four cases from various sectors of industry were used for this study. Only four cases were chosen because of the complexities involved in studying the ERP acquisition process, the number and availability of individuals involved in the process for each case, personal financial constraints, and the time limitation to conduct the study. A comprehensive study of each case was done that involved conducting the interviews and collecting the data, writing up the data, and analyzing it. Once all of the individual case descriptions, analyses, and reports were completed, a cross-case analysis was conducted and the final cross-case analysis report prepared. Site selection for the study was made according to the following 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. Since the focus of this study was directed toward the process for acquiring ERP software, neither the type of software nor the source of the software was considered significant to this study. The main unit of analysis for this study was the ERP acquisition process of organizations and the individuals directly associated with it (most of the informants were part of the acquisition teams). In each of the cases, the technological solution that was acquired impacted the organization, not only on a financial level (the cost of the technology varied from US$1 million to US$86 million), but also on a strategic level (this was one of the primary reasons that they were acquiring the software) Data collection Data collection was conducted in two parts. The first part consisted of semistructured interviews. Interviews were conducted with 19 individuals, each lasting approximately 1 h and 15 min. The informants, all of whom were directly involved in the acquisition process, included for OMEGA, the Director of Information Technology, the Manager of Capital Equipment Purchasing, a Project Director, a Project Control Officer and a Technical Project Manager; for LIMA, the Global Network and Corporate Chief Information Officer (CIO), a Contract Administrator, a Technical Project Manager, a Senior Adviser of Information Systems (SA-IS) and the Director of Billing Services and Outsourcing; for GAMMA, 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 and Inventory System [MMIS]), and the Manager of Inventory Management (member of the Reengineering Group); for Keller, the VP of Information Systems, the VP of Personnel, the Corporate Materials Manager, and a Plant Manager. 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 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 ). Asitso 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: (for the evaluation) Describe in your own words what the various parts of the evaluation process. Following the informant s description, follow-up (probing) questions were used to clarify an issue

4 588 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) 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 of the informants. The second part of the data collection consisted of gathering archival information from various sources within the organization and included documentation from the acquisition project, plans, designs, best practices, policies, standards, RFP/RFI/RFQ, matrices/grids, letters and memos, reports, etc. These documents, when available, allowed for a closer examination of what happened during the ERP acquisition process Validity The data from this study were validated using a triangulation method, first, within each individual case, and then for all four cases together. For this, a triangulation of sources (diverse range of individuals and organizations), methods (of data collection: interviews, archival information, and documents), and theories (theoretical base [OBB]) was done. For example, the triangulation of data sources within one case was repeated in each of the other three cases and then for all of 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, similar tasks were performed, similar influences impacted the process, and similar characteristics emerged. To guard against other possible validity threats, all of the interviews were audiotaped for subsequent transcription and for verification of accurate interpretation. Member checks were performed during which the informants were asked to review the transcription of their interviews for verification of the content therein and, if necessary, to amend or add to them. Follow-up questions were asked, when required, to further clarify ambiguities, discrepancies, or to reconfirm information. Feedback was also obtained from other individuals who were independent of the study as an additional means of verification 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 having been 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. Although the generalizability of the study s findings to a greater population is yet to be determined, there is no obvious reason not to believe that the results apply more generally (Maxwell, 1996, p. 97). This study appears to have face generalizability based on the similarity of dynamics and constraints on the organizations within this study to other organizations (Maxwell, 1996). Moreover, the outcome of this multiple-case design gives us confidence that [our] emerging theory is generic (Miles & Huberman, 1994, p. 29) and therefore applicable for the acquisition of packaged software by other organizations, in addition to those involved in this study. Since the generalizability of qualitative studies, according to Maxwell (1996), usually is based [...] on the development of a theory that can be extended (p. 97), the results of this study provide a step towards the generalization of the theory (model) to a larger population. 5. The cases Below is a brief summary of the cases from this study. The four organizations (pseudonymously named, with the exception of Keller) that participated in it were: OMEGA, a large international carrier, provides air transportation services for passengers and cargo both to domestic and international arenas. OMEGA purchased PeopleSoft s ERP solution (finance, human resources, and payroll applications) for the sum of US$86 million. The ERP acquisition process that OMEGA went through took approximately 9 months and was completed by the summer of Its subsequent implementation was completed in the scheduled timeframe and was regarded a success. GAMMA is a holding company for a gas and electric utility and nonutility energy business. GAMMA completed the purchase of Oracle s ERP solution (finance and related applications) at a cost of US$6.5 million in March of Its ERP acquisition process took approximately 6 months from start to finish. This case is especially significant because it highlights the need to verify sources of information. LIMA LIMA is a North American-based overseas carrier, which maintains commercial relations and operates facilities that allow domestic network operators

5 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) and other service providers to exchange telecommunication traffic with 240 countries and territories. LIMA International was founded in 1995 and currently has 200 employees worldwide. Its headquarters are located in the Washington, DC area and it is the global carrier subsidiary of LIMA. LIMA started but did not complete the purchase of a proposed US$10 million packaged ERP solution (international billing system). Owing to the strategic nature of the intended purchase, an impasse on the issues of code ownership and cost brought the business negotiations to a halt. The ERP acquisition process that the organization went through was, nevertheless, quite rigorous and presents some interesting insights and lessons that would be of value to other organizations, among them, the influence of new management on the overall process. Keller Manufacturing was established in 1895 as a manufacturer of farm wagons and did so until 1943 when it began manufacturing household furniture. Today, this organization has over 700 employees in three manufacturing plants in the United States (two of them located in Indiana [Corydon and New Salisbury] and one in Culpepper, VA) and manufactures over 2000 different oak and maple legs, seats, and other components (with over 100 separate procedures) that are required in the assemblage of its products. Keller Manufacturing purchased an ERP solution (manufacturing execution system) from Effective Management Systems (EMS) for approximately US$1 million. Keller s ERP acquisition process took approximately 11 months and was completed in August of Regarded as a great success, the implementation of EMS software was completed within the scheduled timeframe with only a few minor problems. that was developed for the acquisition process. A comparative or cross-case analysis of the cases highlighted both similarities and principal differences between the approaches that were used by the organizations presented above. As per Miles and Huberman s (1994) suggestion, data from the four cases were compiled, by theme, into matrices that represented the cases and enabled us to view important similarities and differences between them. This last point is particularly relevant because a high incidence of similarities in the data supports theoretical replication across the cases, which in the end, is the purpose of multiple-case design (Miles & Huberman, 1994; Robson, 1993; Yin, 1989, 1991, 1994). While a few differences were noted (at the detail level) between the four cases, the high incidence of similarities between the cases, when taken together, provided strong evidence to support the notion of six distinguishable principle themes (processes). In addition, many of the variables (elements) that were laid out in the study came through in the data. Several similar characteristics about the acquisition process were also noted between all of the cases as well as several influences that impacted on the process. Together, these findings revealed a picture of the buying process for ERP software. The buying process, as derived from the data, will be modeled in the following section. As mentioned, six major themes were readily identifiable across all of the cases and were supported by the data (Fig. 1): planning, information search, selection, evaluation, choice, and negotiations. While the themes (processes) are interdependent, with some embedded in whole or in part in other themes, for analysis purposes, each of the themes was analyzed as an independent and distinct process. While each of the cases was different, most notably with regard to the industry and the type of software they purchased, similar approaches were used nevertheless to acquire the ERP software solutions. These approaches varied somewhat depending on the type, impact and cost of the software solution; the sensitivity of the requirements; the nature of the organization; and the schedule 6. Model of the ERP acquisition process (MERPAP) This section presents a model that was developed from the findings of four case studies. While all of the cases were different with regard to the type of ERP software solution that was being acquired, an overview of the findings Fig. 1. MERPAP. The dotted lines in the diagram indicate the flow of information between the processes. The solid recursive arrows between the processes and the planning process indicate the ongoing nature of activity/feedback/adjustment/input between them.

6 590 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) presented in the cross-case analysis shows that all went through the same process and performed similar tasks to reach their acquisition objectives. The model that will be presented shows how four organizations in today s complex IT environment proceeded with the buying process. Based on a comparative analysis of the individual cases, a high-level model of the ERP acquisition process, which is referred to as MERPAP, was developed. Fig. 1 shows the interrelated and iterative nature of each of the individual processes that constitute MERPAP. The MERPAP consists of six distinct and iterative processes: planning, information search, selection, evaluation, choice, and negotiations. The structure of the process is as follows: (1) the MERPAP begins with planning, (2) the MERPAP ends with negotiations, (3) the MERPAP is nonlinear, (4) some of the processes are done concurrently, (5) some of the processes are embedded, (6) all of the processes, with the exception of choice, are iterative, (7) all of the processes, with the exception of choice, are recursive, and (8) each process is causal and results in products (deliverables) that are used by another process. The dotted lines in the diagram indicate the flow of information between the processes. The solid recursive arrows between the processes and the planning process indicate the ongoing nature of activity/feedback/adjustment/input between them, i.e., between information search and planning. For example, as new information is fed into the MERPAP, plans for the information search process or for the other processes are subsequently adjusted or changed. Activity between the processes is highly iterative and for the most part, not sequential in a linear fashion. However, at certain points in the MERPAP, there is a sequential next process progression that takes the teams from the planning process to the information search, selection, evaluation, and choice processes, ending finally with the negotiations process The concurrent and iterative nature of the processes within MERPAP Across all four cases, the majority of the time spent during the acquisition process was in the planning process with planning and preparations being done for the other parts of the acquisition process. For all of the acquisition teams, planning began very shortly after the decision was made to purchase an ERP. Then, shortly thereafter, once some initial meetings had occurred to get things underway and the acquisition teams had been formed and had met to do some planning, etc., then the search for information began. The search for information included the gathering of information on the organization s requirements and following that, the establishment of selection and evaluation criteria. At the same time, the acquisition team was developing its acquisition strategies, setting its acquisition project time frame, and looking at issues that were pertinent to the acquisition. While still in the planning phase, and as a planned task of the information search process, organizational and systems requirements were defined and various criteria were established. Some of this information was subsequently used for the marketplace analysis during which information on vendors and their solutions was screened using high-level vendor, functional and technical criteria, the end result of which was a long list of vendors/solutions. Beyond this, the teams put together their RFPs and sent them out to the vendors on their long lists. This brings us to the end of the planning process. Information was the lifeblood of the acquisition process and its flow was ongoing. As a result, the information search process was continuous from almost the very start of the acquisition process. While the flow of information was for the most part ongoing, there were pockets of concentrated information searching and gathering activities. Some of these pockets occurred during the planning process proper. Other sporadic spurts of information input occurred during the selection process when new information was received from the vendors in their RFP responses as well as with the incoming flow of other information from referrals, etc. Other spurts of information also fed the evaluation and negotiations processes. Consequently, there was concurrency of several processes with the information search process planning, selection, evaluations, and negotiations. Also concurrent to the planning, information search, selection, and evaluation activities were the business negotiations that were in the midst of happening with the back and forth interactions between the teams and the vendors. With only minor variations, this pattern was apparent in all four cases. The same holds for the selection process proper which began following the return of the RFI/RFP/RFQ responses from the vendors. A review of the RFI/RFP/RFQ responses (using detailed criteria to evaluate the vendors and the ERPs functionalities and technical dimensions) occurred and the vendors deemed most likely to meet each organization s needs were retained. A more intense evaluation of the vendors also occurred at this point using Dunn & Bradstreet reports, among others (see Table 1). The evaluation process was highly intensive and involved both an evaluation of the ERP software on two fronts and an evaluation of the vendors. Again, there was concurrency of this process and the planning, information search, selection, and negotiation processes. This process was also revisited several times during the course of the acquisition process, three of which occurred using three different levels of information: first, using high-level general information/criteria and requirements for screening available vendors and ERP products during the information search process; second, using a more detailed level of information/criteria and requirements during the selection process; and lastly, with an even more refined level of

7 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) Table 1 Vendor evaluation criteria. Ability to assist the organizations with the implementation. Association with or the availability of third party vendor/partners. Vision (future plans and trends regarding the direction of the technology and or strategic positioning). Financial strength. Market share (sales volume, size). Annual growth rate. Customer support. Product recognition. Range of products. Ability to meet future needs. Ability to provide references. Reputation. Vision and/or strategic positioning of the vendor. Longevity of the vendor. Qualifications, experience, and success in delivering solutions to organizations of a similar size, complexity, and geographic scope. Quality of the vendor s proposal. Demonstrated understanding of requirements, constraints, and concerns. Implementation plan that properly positions the proposed solution to achieve the maximum level of business benefits. Implementation services. Implementation strategy. Support services. Etc. information/criteria and requirements during the evaluation process proper. The evaluation process proper was used to confirm the first-ranked vendor from each of the four teams short lists. There was also some concurrency between the end of the business negotiations process and the beginning of the choice process, which indicated the possibility of a last minute change in the choice of ERP vendor/solution that could occur due to an impasse in negotiations between the organization and the initial vendor-of-choice. The case of LIMA exemplified this scenario and brought LIMA s acquisition process to a halt. Since this involved information, the information search process continued concurrently to the choice process. For the most part though, the choice process occurred on its own. Lastly, the legal negotiations process, which began at the conclusion of the choice process. Although the majority of the issues that needed to be included in the final negotiations should have been covered during the business negotiations, the legal negotiations process was undoubtedly the recipient of new information as the final details were worked out for the contract. Once completed, delivery and implementation of the ERP software began. The processes were also iterative. The input of new information into the acquisition process during the selection, evaluation, or negotiations processes often called for the acquisition teams to revisit the planning process and adjust or modify their plans and/or tasks for those processes. This was seen in all of the cases with refinements being made to previously established (as in the early stages of the planning process) criteria and/or requirements, etc., based on the new information that was received by the teams. In the discussion that follows, a brief recap of each of the processes within the MERPAP is presented, their principal elements highlighted, and the data from the cases that supported these findings were summarily discussed Planning process (MERPAP-P) At the detail level of each process is identified the multiple issues, dimensions, and complexities, as well as the high level of risk and uncertainty that are inherent to the buying situation for packaged software. Given the numerous factors, issues, and dimensions that all contribute to the complexity of this type of acquisition, a priori reasoning could lead us to conclude that the best way to deal with it would be to include a step or phase in the buying process in which to address them, and this is precisely what was done in each of the cases. Hence, one of the major findings of this study is that the MERPAP, unlike the process(es) used for other types of organizational buying, includes a planning process during which the acquisition teams addressed as many issues as possible and planned the various activities and phases (processes) of the MERPAP. The planning process of the MERPAP (MERPAP-P) contains seven categories. Together, these elements and their constituent breakdown reflect a picture of what occurred in the planning process Acquisition team formation This first element played an important role in the success of each of the acquisition projects. In the formation of each acquisition team: a project leader was selected. The project leaders were not always from the organizations IT departments. In two of the cases, for example, the project leaders were from Finance (GAMMA) and Quality Control (Keller). the skills (user-area defined/function-specific; technical; leadership, managerial, organizational, problem solving, decisionmaking; administrative; negotiation; etc.) that were required for the acquisition team were identified. Each individual team member needed to have skills that enabled them to assume a specific set of tasks or responsibilities within the project. cross-functional/multidisciplinary team members were selected. each of the roles of the individuals that were on the team were identified and defined, some of which included the following: project leader; task-specific roles such as for the information search; the role of liaison between the vendors and the acquisition team; department/user-areaspecific roles such as for finance, human resources, manufacturing, etc.; the role of technical team leader; the roles of users on the team; the roles of departments like

8 592 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) purchasing, etc. Each individual team member needed to perform a functional and/or advisory role based on their abilities or past experiences. Each team member also needed to understand each role as it belonged to each team member, as well as those roles, which were shared among members. an assessment was made as to whether outside experts/ consultants were needed to complement the acquisition team members skills. both users and IT staff were selected. Members of the acquisition team were drawn from the various departments that were to be impacted by the ERP. a representative from the Purchasing Department was selected to be on the acquisition team and they were involved right from the earliest stages of the acquisition process. the long-term availability of individuals was considered when they were being recruited for the acquisition team. the crossover involvement of many of the acquisition team s members from the acquisition project to the implementation project was also considered. The primary reasons for this were project memory and continuity Acquisition strategies The strategies that each team developed for the ERP acquisition helped reduce some of the uncertainty associated with this process. Among the strategies that were developed: OMEGA brought all of the vendors on their long list together in one location for an information session and as a weeding mechanism; LIMA had product demonstrations at the vendors sites; and Keller visited vendor referrals Requirements definition The acquisition teams defined the organization s requirements for the ERP solution. For this, the teams analyzed and/or defined: (1) their organization s existing technological environment; (2) the functional requirements; (3) the technical requirements; (4) the organizational (business, procedural, and policy) requirements; (5) the different user areas and functions; (6) existing processes in the areas that were to be affected by the new software; and (7) as many problems and opportunities as possible Establish selection/choice and evaluation criteria The teams also established their selection/choice and evaluation criteria prior to contacting any vendors or looking at ERP solutions. These criteria were based on information that was gathered from the users and other sources (see Table 2 for examples from the cases). They were used in part for the marketplace analysis, the selection process, and for the three different areas/types of evaluation that were performed during the acquisition process. They were also used to create questionnaires and grids/matrices that were used during the evaluation process. Table 2 Selection/choice and evaluation criteria (examples). Improvement over current systems. Customization. User interfaces. Is the platform that the organization intends for the proposed solution to operate on ideal for optimum performance?. Is the organization s existing DBMS compatible with the proposed solution?. Can the proposed solution integrate into the organization s existing hardware architecture?. What is the architecture of the proposed solution: client/server, two-tier, three-tier, or other?. What is the capacity (minimum and maximum) of the proposed solution?. Scalability of the system. Training (in-house or external to the organization; does vendor conduct the training or is outsourced?). Performance. Security features. Implementation. Etc Acquisition issues The acquisition teams considered as many issues, factors, and concerns as possible that could have affected the acquisition at hand, i.e., business process reengineering (BPR), technical issues such as Y2K, etc. In doing so, they planned for what to do in case potential problems arose later in the acquisition process. Since these issues could also have affected the implementation of the ERP, the acquisition teams approached these issues with an eye toward the implementation. For OMEGA and Keller, for example, one such acquisition issue was BPR and its ramifications. A major implication of buying an ERP solution is that it will require the redesign of existing processes in the areas in which the software will be applied. While on one hand, Keller was especially interested in significantly revising many of its existing processes, OMEGA was extremely cautious and hesitant about introducing changes, especially major ones, into their organization to the point that this issue influenced their final choice of ERP solution Marketplace analysis This category reflects a part of the information search process that occurred during (and was embedded in) the planning process. During this analysis, the acquisition team was able to determine who the major players were in the marketplace for the ERP that they were seeking. This analysis was conducted using high-level criteria to evaluate both the vendors and the functional and technical features of the software and resulted in a short long list of potential vendors and solutions Deliverables Various deliverables resulted from the execution of each of the foregoing elements. A few examples of the deliverables from the planning process included the construction of the RFP (the primary deliverable), the formation of the

9 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) acquisition team, and the creation of a short long list of vendors Information search process (MERPAP-I) The MERPAP-I was found to be an iterative process since information was always feeding the acquisition process. It consists of two principal elements: information screening and information sources. Information sources, both internal and external sources, provided the acquisition process with differing types of information. This information was screened in accordance with the level of scrutiny warranted by the stage at which the acquisition team was at in the acquisition process. Several key factors regarding information came into play during this process and among them were: (1) the type or nature of the information that was to be gathered; (2) the credibility of the sources, whether internal or external; (3) the credibility of the information that was obtained; (4) the reliability of the sources, whether internal or external; (5) the reliability of the information that was obtained; (6) outside references; (7) client referrals from the vendors; and (8) the possibility of information overload and confusion Selection process (MERPAP-S) The selection process (MERPAP-S) was the intermediary stage between the planning process and the evaluation process. It consisted of only two principal elements: Evaluate RFI/RFP/RFQ Responses and Create Short list of Vendors/Technologies. The first one dealt with the review of the RFI/RFP/RFQ responses from the vendors, and the second pertained to the deliverable of a short list of vendors/ products. To a limited extent, some recursive activity was noted in all of the cases, between the MERPAP-S and both the planning and information search processes, and to a greater extent, between this process and the evaluation process. Subsequent to the acquisition teams review (a mid-level, moderately intensive evaluation) of the RFI/ RFP/RFQ responses, in all of the cases, there was recursive activity by the teams back to planning, with the acquisition teams revisiting their plans and refining their criteria. Decisions arising from adjustments in their plans led the teams to revisiting the information search process. This recursive activity had the teams recontacting the vendors with requests to resubmit in part or in full, their RFI/RFP/ RFQ responses according to the teams refined criteria. Then, when the amended responses were received from the vendors, the teams would conduct a second evaluation, thereby revisiting once again the evaluation process Evaluation process (MERPAP-E) The evaluation process of the MERPAP (MERPAP-E) consisted of three distinct areas of evaluation: vendor, functional, and technical. As to the vendor evaluation process, it was carried out, in part, during the planning process (embedded in the marketplace analysis) and was ongoing throughout the rest of the MERPAP during the selection (during the review of the RFP/RFIs), evaluation (with client referrals and input from other sources), and business negotiations (ongoing dealings with the vendors throughout the MERPAP) processes. As for the functional and technical evaluations, they were carried out, in part, during the selection process and then, more intensively, during the functional and technical evaluation processes. The criteria and strategies that were established during the planning process were used to implement all three types of evaluations Choice process (MERPAP-C) Choice (MERPAP-C), as a process, followed as a natural result of the abovementioned processes. In all cases, a final recommendation was presented to an outside group (steering committee or board of directors) who authorized the final choice. It could be argued that choice was the natural outcome of the evaluation process and should have been included as its end result (a deliverable of the evaluation process). This would have occurred had the final choice rested solely with the acquisition teams. However, since an outside body to the acquisition team was responsible for the final choice in all of the cases, it seemed more appropriate to designate it as a separate process Negotiations process (MERPAP-N) Lastly, the negotiation process (MERPAP-N) of the MERPAP is divided into two types of negotiations, business and legal, and it is the business negotiations process that was continuous throughout most of the MERPAP. As many issues as possible were addressed in the business negotiations phase. Then, once tentative agreements were reached, and the choice made, legal negotiations ensued that led to the completion and sign off of the final contract. 7. Summary Within this paper was presented a model of the ERP software acquisition process (MERPAP) that reflects the findings from the four cases examined in this study. The MERPAP includes six distinctive, yet interrelated, processes (planning, information search, selection, evaluation, choice, and negotiations). This high-level model depicts the principal processes that pertain to the acquisition of packaged software. It is not, however, without its limitations. First, the model is limited to the findings from the four cases in this study. Second, since the model is limited to the findings of this study, it is not generalizable to a larger population. While the model represents the ERP packaged software acquisition process

10 594 J. Verville, A. Halingten / Industrial Marketing Management 32 (2003) for these cases, testing is required to verify whether or not it can be applied to a larger population. While no deterministic model can be developed that is a definitive representation of all acquisition processes for packaged software, the MERPAP that has resulted from this study contributes to the identification of processes that are part of this type of acquisition. Further, this model is of value in that it serves to refine existing OBB theory. Whereas the focus of OBB was and continues to be on influences and buying behavior, this study yields evidence/ data on the buying process itself, specifically for ERP software. It also suggests complexities that are worthy of further investigation, in and of themselves, and for the reason that they could prove to limit the generalizability of the model Managerial implications and future research The results of this study may provide organizations with valuable knowledge that could prompt them to make significant changes in the manner in which they currently proceed with the acquisition of enterprise packaged software, which in turn could result in substantial savings in terms of economics (actual costs, time, and improved administrative procedures); it can serve as the basis for the development or amendment of a formal process policy for complex packaged software acquisition. Furthermore, this study may also provide some theoretically interesting issues upon which to base future research such as the possibility of a link between the acquisition process and the implementation process for ERPs; focus on the cause and effect relationship that activities/results of the acquisition process have on the implementation process. Another possibility for research might be to examine whether a failed implementation is doomed from the start by users simply choosing the wrong system for their organization with the focus being on the correlation between final choice of ERP and failure or success of its implementation. References Appleton, E. L. (1997, March). How to survive ERP. Datamation, 43(3), Benson, P., & Rowe, F. (2001, Fall). ERP project dynamics and enacted dialogue: perceived understanding, perceived leeway, and the nature of task-related conflicts. Database for Advances in Information Systems, Bingi, P., Sharma, M. K., & Godla, J. K. (1999, Summer). Critical issues affecting an ERP implementation. Information Systems Management, Choffray, J. M., & Lillien, G. L. (1980). Market planning for new industrial products. New York: Wiley. Eckhouse, J. (1999, January 25). ERP vendors plot a comeback. Information Week, 718, Esteves, J., & Pastor, J. (2001). Enterprise resource planning systems research: an annotated bibliography. Communication of AIS, 7(8), Geisler, E., & Hoang, W. (1992, Summer). Purchasing information technologies: behaviour patterns of service companies. International Journal of Purchasing and Materials Management, Glover, S. M., Prawitt, D. F., & Romney, M. B. (1999, February). Implementing ERP. Internal Auditor, 56(1), Hillier, T. J. (1975). Decision making in the corporate industrial buying process. Industrial Marketing Management, 4, Johnston, W. J., & Lewin, J. E. (1996, January). Organizational buying behavior: toward an integrative framework. Journal of Business Research, 35(1), Kerlinger, F. N. (1986). Foundations of behavioral research (3rd ed.). Chicago, Illinois: Holt, Rinehart and Winston. Maxwell, J. A. (1996). Qualitative research design: an interactive approach. Thousand Oaks, CA: Sage. Meta Group (1998, March 12). Trends: IT performance engineering and measurement strategies. Stanford, CT: Meta Group. Miles, M. B., & Huberman, A. M. (1994). Qualitative data analysis: an expanded sourcebook (2nd ed.). Thousand Oaks, CA: Sage. Miranda, R. (1999, August). The rise of ERP technology in the public sector. Government Finance Review, 15(4), PricewaterhouseCoopers (1999). Technology forecast. Menlo Park, CA: Author. Robinson, P. J., Faris, C. W., & Wind, Y. (1967). Industrial buying and creative marketing. Boston: Allyn & Bacon. Robson, C. (1993). Real world research: a resource for social scientists and practitioner researchers. Oxford, UK: Blackwell. Sheth, J. N. (1973, October). A model of industrial buyer behavior. Journal of Marketing, 37, Sieber, T., Siau, K., Nah, F., & Sieber, M. (1999). Implementing SAP R/3 at the University of Nebraska. Proceeding ICIS ( pp ). Charlotte, NC. Stafyla, A., & Stefanou, C. J. (2000). ERP Software selection: a study using cognitive maps. 7th European Conference on Information Technology Evaluation (ECITE) ( pp ). Dublin, Ireland. Verville, J. C. (1998, May). An exploratory study of how organizations buy packaged software. IRMA, Verville, J. C. (2000). An empirical study of organizational buying behavior: a critical investigation of the acquisition of ERP software. Dissertation, Université Laval, Québec. Verville, J., & Halingten, A. (2001). Acquiring enterprise software: beating the vendors at their own game. Upper Saddles River, NJ: Prentice-Hall. Ward, S., & Webster Jr., F. E. (1991). Organizational buying behavior. In T. S. Robertson, & H. H. Kassarjian (Eds.), Handbook of consumer behavior ( pp ). Englewood Cliffs, NJ: Prentice-Hall. Webster, F. E., & Wind, Y. (1972). Organizational buying behavior. Englewood Cliffs, NJ: Prentice-Hall. Wind, Y., & Thomas, R. J. (1990). Strategy-driven industrial marketing research. In V. A. Zeithaml (Ed.), Review of marketing ( pp ). Chicago: American Marketing Association. Yankee Group (1998, August). ERP software market: is the replacement cycle over? Enterprise Applications, 3, Yin, R. K. (1989). Case study research: design and methods. London: Sage. Yin, R. K. (1991). Research design issues in using the case study method to study management information systems. In J. I. Cash, & P. R. Lawrence (Eds.), The information systems research challenge: qualitative research methods (pp ). Boston, MA: Harvard Business School Research Colloquium. Yin, R. K. (1994). Case study research: design and methods (2nd ed.). London: Sage.