Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
,hjg;iug - ,hjg;iug
Typology: Study notes
1 / 11
This page cannot be seen from the preview
Don't miss anything!
See discussions, stats, and author profiles for this publication at: http://www.researchgate.net/publication/
ARTICLE in INDUSTRIAL MARKETING MANAGEMENT · OCTOBER 2003
Impact Factor: 1.93 · DOI: 10.1016/S0019-8501(03)00007-
CITATIONS
Jacques Verville Skema Business School - United States 37 PUBLICATIONS 320 CITATIONS
SEE PROFILE
Available from: Jacques Verville Retrieved on: 24 August 2015
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
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 organiza- tions 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 &
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 proc- ess’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 imple- mentation 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 acquis- itions are done routinely and fairly simply, that acquis- itions 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.
0019-8501/03/$ – see front matter D 2003 Elsevier Science Inc. All rights reserved. doi:10.1016/S0019-8501(03)00007-
Industrial Marketing Management 32 (2003) 585 – 594
One major assumption, that existing OBB models may be inadequate in their explanation of the IT (e.g., ERP soft- ware) 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.
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 dimen- sions that make the acquisition of ERP software such a complex process. Four cases from various sectors of indus- try 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 individ- uals 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 signific- ant, 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 soft- ware).
4.1. 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 Tech- nology Development (Technical Team Leader for the Mate- rials Management and Inventory System [MMIS]), and the Manager of Inventory Management (member of the Reen- gineering Group); for Keller, the VP of Information Sys- tems, the VP of Personnel, the Corporate Materials Manager, and a Plant Manager. Open-ended questions were used throughout the inter- views. They allowed for flexibility and provided the ‘‘pos- sibilities 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. 442– 443). 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: (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
or to delve for more information. These follow-up questions also allowed for the development of ideas without constrain- ing the exploratory nature of the study. The same interview- ing 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 organ- ization 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.
4.2. 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 informa- tion, 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 indi- viduals who were independent of the study as an additional means of verification.
4.3. 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 acquisi- tion of ERP software, the minimal amount of research that has been conducted to date in this area, and the methodo- logy 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 pack- aged 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.
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 1996. 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 1997. 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
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, evalu- ation, 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 pro- cesses, with the exception of ‘‘choice,’’ are recursive, and (8) each process is causal and results in products (deliv- erables) 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 pro- cess’’ progression that takes the teams from the planning process to the information search, selection, evaluation, and choice processes, ending finally with the negotiations process.
6.1. 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 estab- lishment 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 estab- lished. 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. Con- sequently, there was concurrency of several processes with the information search process—planning, selection, evalu- ations, and negotiations. Also concurrent to the planning, information search, selection, and evaluation activities were the business nego- tiations 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 ‘‘gen- eral’’ 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
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 ‘‘informa- tion,’’ the information search process continued concur- rently 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 implementa- tion of the ERP software began. The processes were also iterative. The input of ‘‘new’’ information into the acquisition process during the selec- tion, 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 pro- cesses. 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.
6.2. 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.
6.2.1. 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 res- ponsibilities 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-area- specific 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
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.
acquisition team, and the creation of a short long list of vendors.
6.3. Information search process (MERPAP-I)
The MERPAP-I was found to be an iterative process since information was always feeding the acquisition pro- cess. 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 informa- tion 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.
6.4. 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: ‘‘Evalu- ate 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.
6.5. 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.
6.6. 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 (steer- ing 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 evalu- ation 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 respons- ible for the final choice in all of the cases, it seemed more appropriate to designate it as a separate process.
6.7. 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 negotia- tions 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.
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
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.
7.1. Managerial implications and future research
The results of this study may provide organizations with valuable knowledge that could prompt them to make sig- nificant changes in the manner in which they currently proceed with the acquisition of enterprise packaged soft- ware, 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 implementa- tion 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 implementa- tion 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), 50 – 53. 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, 47 – 66. Bingi, P., Sharma, M. K., & Godla, J. K. (1999, Summer). Critical issues affecting an ERP implementation. Information Systems Management, 7 – 14. 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. Informa- tion Week, 718 , 126 – 128.
Esteves, J., & Pastor, J. (2001). Enterprise resource planning systems re- search: an annotated bibliography. Communication of AIS, 7 (8), 1 – 52. Geisler, E., & Hoang, W. (1992, Summer). Purchasing information tech- nologies: behaviour patterns of service companies. International Jour- nal of Purchasing and Materials Management, 38 – 42. Glover, S. M., Prawitt, D. F., & Romney, M. B. (1999, February). Imple- menting ERP. Internal Auditor, 56 (1), 40 – 47. Hillier, T. J. (1975). Decision making in the corporate industrial buying process. Industrial Marketing Management, 4 , 99 – 106. Johnston, W. J., & Lewin, J. E. (1996, January). Organizational buying behavior: toward an integrative framework. Journal of Business Re- search, 35 (1), 1 – 15. 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 ap- proach. 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), 9 – 17. 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 , 50 – 56. Sieber, T., Siau, K., Nah, F., & Sieber, M. (1999). Implementing SAP R/3 at the University of Nebraska. Proceeding ICIS ( pp. 629 – 649). 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. 293 – 301). Dublin, Ireland. Verville, J. C. (1998, May). An exploratory study of how organizations buy ‘‘packaged’’ software. IRMA, 524 – 527. Verville, J. C. (2000). An empirical study of organizational buying behav- ior: a critical investigation of the acquisition of ‘‘ERP software.’’ Dis- sertation, Universite´ Laval, Que´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. 419 – 458). Englewood Cliffs, NJ: Prentice-Hall. Webster, F. E., & Wind, Y. (1972). Organizational buying behavior. Engle- wood Cliffs, NJ: Prentice-Hall. Wind, Y., & Thomas, R. J. (1990). Strategy-driven industrial marketing research. In V. A. Zeithaml (Ed.), Review of marketing ( pp. 411 – 453). Chicago: American Marketing Association. Yankee Group (1998, August). ERP software market: is the replacement cycle over? Enterprise Applications, 3 , 1 – 10. 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 re- search methods ( pp. 593 – 608). Boston, MA: Harvard Business School Research Colloquium. Yin, R. K. (1994). Case study research: design and methods (2nd ed.). London: Sage.
