Investigating ERP systems procurement practice: Hong Kong and Australian experiences

Information and Software Technology 52 (2010) 1011–1022

Contents lists available at ScienceDirect

Information and Software Technology journal homepage: www.elsevier.com/locate/infsof

Investigating ERP systems procurement practice: Hong Kong and Australian experiences q Pak-Lok Poon a, Yuen Tak Yu b,* a b

School of Accounting and Finance, The Hong Kong Polytechnic University, Hung Hom, Hong Kong, China Department of Computer Science, City University of Hong Kong, Kowloon Tong, Hong Kong, China

a r t i c l e

i n f o

Article history: Received 24 June 2009 Received in revised form 15 April 2010 Accepted 17 April 2010 Available online 24 April 2010 Keywords: Enterprise resource planning Software acquisition Software procurement Software requirements Software selection

a b s t r a c t Context: Integration of information systems is now commonly recognized to be a powerful strategic weapon that sharpens the competitive edge of a firm in today’s highly volatile business environment. Such integration can be achieved by replacing the disconnected and incompatible legacy applications by enterprise resource planning (ERP) systems. Along with the remarkable growth of the ERP market, we have seen a number of failure cases of ERP adoption. Such failure cases indicate that not all firms know how to adopt an ERP solution effectively. Objective: To explore and identify crucial practices from real experiences in the Asia–Pacific region that may explain a firm’s success in ERP procurement, with an overt intention toward the formulation of useful lessons that inform practitioners and contribution to advances in software development practices in organizations. Method: A multiple-case design involving three Chinese firms based in Hong Kong and a local firm in Australia was employed. We collected, verified, and analyzed the information about the ERP procurement practice in each subject firm by means of semi-structured interviews, archive reviews, and member checks. Results: We summarized our results in the form of 10 lessons learned, together with observations of how culture seems to have played a part in shaping the practice. Conclusion: Our results offer practical guidelines originated from real cases that are of use for practitioners to improve the ERP procurement process. Ó 2010 Elsevier B.V. All rights reserved.

1. Introduction Many firms now realize that integration is a must for them to maintain a competitive advantage, by making corporate information available to any authorized user, anywhere, anytime. Numerous firms have achieved such integration by replacing their disconnected and incompatible legacy applications by enterprise resource planning (ERP) systems, which link back-office and frontoffice operations as well as internal and external supply chains [5,30,56,57]. Vendors offering ERP solutions are now plentiful. Among these vendors, the first-tier players include SAP, Baan, Oracle, and PeopleSoft, while the second-tier players include J.D. Edwards, QAD, and Lawson [5].

q The work described in this paper is supported in part by a general research fund (project number 1-ZV2H) from The Hong Kong Polytechnic University and a grant (RGC project number 123206) from the Research Grants Council of the Hong Kong Special Administrative Region, China. * Corresponding author. Tel.: +852 2788 9831; fax: +852 2788 8614. E-mail addresses: [email protected] (P.-L. Poon), [email protected] (Y.T. Yu).

0950-5849/$ - see front matter Ó 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2010.04.003

According to International Data Corporation (IDC) market analyses, the ERP market grew 6.5% to $28.3 billion in 2005 with some of the major vendors hitting twice the growth rates. The growth rate of the ERP market is expected to continue to be phenomenal, notably in the Asia–Pacific region [40], suggesting that ERP systems are becoming ‘‘the price of entry for running a business” [26]. Along with the remarkable growth of the ERP market, there have been many failure cases of ERP adoption (for example, FoxMeyer Drugs, Whirlpool, Volkswagen, and Dell Incorporated) [8,48,58,61]. These firms spent huge investment on ERP solutions but without getting what they expected. In some cases, the effect was more fatal, resulting in bankruptcy proceedings and litigation against software vendors. Such failure cases indicate that not all firms adopted an ERP solution effectively. In general, an ERP adoption life cycle consists of three major phases: pre-implementation, implementation, and post-implementation [54]. The pre-implementation (also known as procurement or acquisition) phase is typically kicked off once the idea of ERP adoption is initiated and gains management support, and ends when the firm completes the procurement of an ERP system from a chosen vendor. In the implementation phase, the selected ERP

1012

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

system is installed, customized, and tested until accepted for use. Major activities in this phase also include business process alignment, hardware/software compatibility resolutions, and user training. The post-implementation phase begins with the formal deployment of the ERP system for use and maintenance as part of the firm’s normal operations. A large portion of the published work on ERP adoption is directed to issues and problems encountered in the implementation and post-implementation phases [15]. To name but a few,1 Mabert et al. [31] empirically investigate and identify key differences in the approaches used by firms that managed their implementations ontime and/or on/under-budget versus the ones that did not, through a survey of US manufacturing firms that have implemented ERP systems. Dreiling et al. [14] introduce a method to increase the usability and usage of conceptual modeling for the purpose of ERP configuration. Nicolaou and Bhattacharya [38] empirically examine the longterm financial performance effects of ERP revisions (enhancements, upgrades, abandonments, and switches) in the post-implementation phase for firms that have previously reported ERP adoptions. However, focusing mainly on implementation and post-implementation phases may cause a mis-alignment between the ERP system and the business strategies that the system is originally expected to support [24,51,52,59]. Until recently, relatively few studies [1,43,46,49,50] in the literature have addressed the ERP pre-implementation phase, and even fewer are concerned with firms in the Asia–Pacific region, where the growth of ERP markets has become phenomenal in recent years. Indeed, in its report released in March 2009, the research house Gartner forecasted that while the global enterprise software market would stay ‘‘flat” (only 0.3%) in 2009, the Asia–Pacific region would at the same time continue to grow at 7.8% [20]. Furthermore, Gartner projected Asia’s growth to remain ‘‘well above” those of mature regions such as Europe, which was expected to go down by 5.6% in the same year [20], as firms in those fast-growing regions are moving ahead with their plans to overhaul their application frameworks with integrated solutions [40]. Experiences in ERP adoption practices in Asia–Pacific firms are certainly of interest and value to both researchers and practitioners. This paper focuses on the pre-implementation phase of the ERP adoption life cycle, and discusses the experience gained and lessons learned from the case studies of ERP systems procurement practices in three Chinese firms based in Hong Kong and a local firm in Australia (that is, all the subject firms reside in the Asia–Pacific region). Note that, in Hong Kong, the influence of Chinese culture and work styles permeates the business operations in most organizations, as the vast majority of employees are ethnic Chinese. On the other hand, the Australian firm we studied is owned and run by local Australians, whose culture is primarily originated from the West. In the literature, it has been found that the differences in culture between the East and the West did affect ERP implementations and operations in Hong Kong [12] and in Singapore [53]. Thus, even though all these firms are in the Asia–Pacific region, there could be significant differences in the management styles between firms in Hong Kong and in Australia.2 As such, we have also posed the research question on whether and how, in our cases, culture has played a part in shaping the ERP procurement practices. The remaining sections of this paper are structured as follows. Section 2 presents a conceptual model for ERP procurement process, which serves as a useful basis to frame our subsequent dis-

cussions. Section 3 describes our research methodology and process, and discusses the limitations of the study. Section 4 presents our observations and lessons of ERP procurement from the case studies in the subject firms. Section 5 discusses related work. Finally, Section 6 summarizes the paper and proposes some further work.

2. A conceptual model for ERP procurement process ERP adoption is a complex process in which multiple dimensions of factors play a part: strategic, organizational, and technical. It also involves a mix of business process redesign and software configuration to align the system with the business processes. Considering the complexity of ERP systems and the large variety of vendors, the decision to adopt ERP and the subsequent procurement process must be properly managed in order to reduce the risk of failure. In planning the study, we search the literature to identify the major activities and tasks involved in typical ERP procurement processes. We note from [16,43,54,56] that these activities and tasks include: (a) determining organizational, business, and user requirements, (b) formally describing the domain of ERP selection criteria, and (c) systematically evaluating the ERP selection criteria. Developing a business case and deciding the participants of the acquisition project are also recommended in [54,56]. Through the synthesis and extension of existing work [16,43,54,56], we develop a four-stage conceptual model for the procurement process (see Fig. 1) to frame our discussions. Running in parallel with the activities in these four stages is an information search process, whose activities are generally more intensive at the earlier than later stages. The information sources can be internal (for example, information from functional units of the firm about their requirements) or external (for example, information about threats brought about by the ERP adoption of the competitors). To focus our discussions on the research questions of this study, the stages of the ERP procurement process are presented in a linear fashion. This is based on a slightly simplifying description of software development projects in which planned management decisions are to be made first, followed by appropriate IT solutions. Some researchers, however, contend that many software development projects, including the procurement process, are often more complex in reality. However, it would be beyond the scope of this paper to delve into the issue here. Nevertheless, the process model is useful enough for structuring our experiences from the subject firms’ practices. In any case, most of our observations and lessons

(Stage 1) Formation of Acquisition Team

(Stage 2) Examination of Business Requirements and Constraints

(Stage 3) Formation of Evaluation Criteria

(Stage 4) 1

More discussions of related work can be found in Section 5 of this paper. 2 For example, it has been reported in [21] that: (a) people from a particular national background will prefer a particular organizational configuration because it fits their implicit model and (b) planning and control processes in organizations are strongly influenced by culture.

Evaluation and Selection of the “Best Fit”

Fig. 1. A conceptual ERP procurement process model.

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

1013

still apply to the activities even if a different procurement process model is adopted.

be taken into consideration and adapted for use at this stage [3,7,17,28,29,37].

2.1. Stage 1: formation of acquisition team

2.4. Stage 4: evaluation and selection of the ‘‘best fit”

Picking the right people for the acquisition team is very important. People who understand the firm’s business and strategies, together with people who possess competent IT knowledge should join the team [13]. Generally, qualified external consultants should be recruited to solve problems that are beyond the experience and expertise of the internal team members. A critical factor for successful ERP adoption is that it must be seen as an enterprise-wide project and not just ‘‘yet another” IT project. Thus, the project should be led by a senior executive who possesses the strategic business vision [51].

In reality, finding an ERP system to fit all the specified evaluation criteria is usually infeasible. Normally, the acquisition team needs to properly prioritize and weigh the criteria at evaluation. The evaluation may take the form of financial analysis, in which the benefits and costs of using a certain ERP product or vendor are weighed in monetary terms. This kind of analysis can provide a convincing justification to support the choice of a particular ERP product or vendor. However, ERP adoption typically brings about intangible benefits that are not easily assessed in monetary terms. For criteria associated with these intangible benefits, evaluation has to be more reliant on human judgment in non-financial terms.

2.2. Stage 2: examination of business requirements and constraints 3. Research methodology and process Since an ERP system will ultimately be integrated into a firm, it is essential to ensure that the system is acquired in accordance with the overall business vision and specific business requirements of the firm. Besides, the constraints affecting which ERP system to select should also be considered. Typically, these constraints fall into five major types: technical (such as the capabilities of the firm’s existing IT infrastructure), organizational (such as management structure), financial (such as budget limits), time (such as the deadline for having the ERP system in place), and human resources (such as the availability of qualified people for completing the ERP adoption process). 2.3. Stage 3: formulation of evaluation criteria The business requirements identified in the preceding stage are translated into detailed critical and non-critical functional requirements to be met by the ERP system, together with the organizational and technological changes necessary for successful implementation. The acquisition team should be aware of the individual strengths and weaknesses of different ERP solutions with respect to specific business requirements and industries. For instance, SAP is popular in chemicals and pharmaceuticals, Oracle in energy and telecommunications, and Baan in aerospace and defense [2]. Besides the above considerations, the acquisition team should further develop other evaluation criteria. Many criteria are concerned with the ERP products under evaluation, while other criteria are more related to the vendors that provide the ERP products. Some examples of common evaluation criteria are listed in Table 1. There are similarities between evaluating and selecting an ERP system for use by an organization and selecting software components for building a system. In this regard, the formulation of evaluation criteria and the corresponding assessment methods developed for commercial-off-the-shelf (COTS) components may

Runeson and Höst [45] argue that social and political questions are of important relevance to software development, since the development work is performed by individuals, groups, and organizations. As a multidisciplinary area, software engineering includes problems that are amenable to research by means of case studies. In particular, the case study approach [62,63] is pertinent to research problems when a strict boundary between the studied object and its environment does not exist, which is a common phenomenon in software engineering practice [45]. In addition, the approach lends itself a good candidate to explore a multitude of factors and dimensions that constitute a complex ERP procurement exercise [56]. Hence, we adopt the case study approach in this research, with reference to the methodology and terminology for case studies advocated by Runeson and Höst [45]. Our research also involves a flexible design process, with the intention to facilitate reflective practice, which encourages the analysis of a person’s (or a group of persons’) own actions as they happen [47]. Reflective practice facilitates one to: (a) query and explore the what, why, and how of one’s actions, (b) brainstorm the various options and possibilities, (c) compare and contrast results, and (d) understand underlying rationales [44]. 3.1. Research objectives, questions, and process The design and planning of this research study begins with the definition of research objectives and questions. Our primary research objective is to explore and identify crucial practices from real experiences in the Asia–Pacific region that may explain a firm’s success in ERP procurement, with an overt intention toward the formulation of useful lessons that inform practitioners and contribution to advances in software development practices in organizations. In essence, the lessons so derived pertain to critical

Table 1 Some common evaluation criteria for ERP acquisition. ERP vendor

ERP product

Reputation Financial position Track record of implementation Service quality of implementation Time required for implementation Implementation strategy Ability to meet future needs After-sales support

System functionality Anticipated organizational and technological changes Process improvement over existing systems Degree of transparency and fitness of information flow Extent of required customization Fulfilment of customer and supplier needs Flexibility and adaptability of product’s architecture Price Reliability Scalability

1014

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

success factors (CSFs) for ERP procurement. The idea behind CSF theory is that, in any organization, certain factors will be critical to the success of that organization, in the sense that if the purposes associated with the factors are not achieved, the organization will fail [41]. CSFs allow the managers, who often work under resource constraints, to direct their effort to aspects that really make the difference between success and failure. As the literature [4,21,27,34] has revealed potentially significant dissimilarity in management styles across firms due to cultural difference, our secondary objective is to explore evidence, if any, of such influence on ERP procurement. With the above objectives in mind, we hereby formulate the following two research questions: (RQ-1) What practices in an organization contribute to a successful ERP procurement exercise? (RQ-2) How do cultural differences play a part in influencing an ERP procurement exercise? To answer research questions RQ-1 and RQ-2, we employ a multiple-case design involving four subject firms. The multiple-case design directs our focus to understanding the dynamics and complexities present (namely, the processes and critical issues of ERP procurement in this study) within each case (that is, each firm) [45,62,63]. As the case of study and the frame of reference (which includes the conceptual model shown in Fig. 1 and CSF theory from the literature) are defined, we proceed to make principal decisions on the data collection methods and strategies (see Section 3.3), select the subject firms for study (see Section 3.2), and determine the information to be collected (see below). Furthermore, our case study consists of the following activities and tasks:

Study Design and Planning

Finally, we complete this work by structuring the results and findings for reporting, specifically to an expected audience of practitioners (aiming at the improvement of their practice) as well as

Review literature and define the frame of reference

Define the case and make principal

Determine information to be collected

Select subject firms

decisions on data collection methods and strategies

Prepare interview questions

Data Collection

Interview the acquisition teams (audio-taped)

Review archival information

Transcribe interview results Perform member checks

Data Analysis

Analyze adoption results

Identify similarities and differences of procurement practices

Reporting

(1) Collect and verify the information about the ERP procurement practice in each subject firm by means of semi-structured interviews, archive reviews, and member checks (see Section 3.3 for more details). In addition to finding out what have actually been done by the subject firms in their ERP procurement exercises, the following important information is also collected: (a) What tasks do the firms think they have done right in the procurement process? (b) What would the firms do differently if they have a chance to redo the exercises? With regard to (b) above, note that all the firms have gone through an experience curve since these were their first ERP procurement exercises. Thus, after adopting an ERP solution, the firms may realize that there are some issues they should have addressed to improve the process. This information is very useful for compiling our list of lessons. (2) Analyze the result of ERP adoption in each firm both quantitatively (using success indicators such as the amount of time spent to finalize the ERP procurement decision, time taken for the ERP system implementation, and the actual project’s expenditure) and qualitatively (for example, user feedback on the ERP system after implementation and the earning of adoption awards). (3) Based on the information obtained in activity (1) above, identify the similarities and differences of ERP procurement practices among the subject firms. Such similarities and differences provide useful indications of the impact of each individual task of the ERP procurement process on the outcome of adoption. This allows us to come up with a list of important observations and lessons, to be formulated and elaborated in Section 4.

Define research objectives and questions

Formulate lessons

Determine how these similarities and differences affect adoption results

Determine the audiences for report

Write up the report

Fig. 2. Methodology and process of our case study.

fellow researchers (for understanding the CSFs of ERP procurement and possibly extending our work further to address the follow-up research questions discussed in Section 6). The activities we have performed in this research, as outlined above, can be neatly organized into four phases and depicted in Fig. 2. In particular, we shall present more details of our selection of subject firms in Section 3.2 and collection of data in Section 3.3 below, respectively. Note that as our case study methodology adopts a flexible design process, even though Fig. 2 shows that the move from one process step to another is unidirectional, there is in fact a significant amount of iteration over the steps (for example, data collection and analysis may be conducted incrementally). 3.2. Selection of subject firms We adopted three criteria in selecting the four subject firms for our study as follows.  The firm’s management and control basis must be co-located with the firm (that is, in Hong Kong or Australia, respectively) so that it possesses full autonomy and discretion in the ERP procurement exercise.  The ERP adoption subsequently has a significant impact on the firm’s operations, and it is the first ERP procurement by the firms. This ensures that they have strong incentives to evaluate the candidate ERP systems comprehensively prior to their final procurement decisions.

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

 The ERP adoption exercise was completed not long ago and was adequately documented so that the procurement team could recall accurately and in detail what decisions and actions it has made during the adoption process. To preserve anonymity, the four firms will be referred to as Beverage, Electronics, Optics, and Stationery, respectively, based on the primary products or services involved. Their background is briefly described below.

3.2.1. Beverage A publicly listed firm in Hong Kong, it provides contract catering and management services, and manufactures foods and beverages that are distributed and sold to various parts of the world (including Hong Kong, Mainland China, North America, Europe, and Australia). Before adopting an ERP system, Beverage suffered from system disintegration that caused other problems such as operational inefficiency, inability to fulfil customers’ demand, and unavailability of information for management and forecast. The Finance Director suggested replacing all the legacy applications by an ERP system as a long-term solution. The suggestion was supported by the Board of Directors, and finally iRenaissance (from Ross Systems) was adopted as the firm’s ERP solution. Beverage took about a year to make the ERP procurement decision and another 3.3 years to complete the implementation.

3.2.2. Electronics This firm provides innovative automation and control solutions to its customers in the industrial, commercial, and consumer markets. Headquartered in Hong Kong, Electronics operates more than a dozen design, manufacturing and sales facilities in Asia, North America, and Europe. Electronics was established in Hong Kong in the 1970s, and it has expanded significantly to a total workforce of 3000. The original information system, developed by a software vendor, could no longer accommodate the firm’s expansion needs. Eventually, Electronics adopted QAD MFG/PRO as its ERP solution. The whole adoption project took about 11 months to complete, including 3 months for procurement and 8 months for implementation.

3.2.3. Optics A publicly listed firm in Hong Kong, it designs, manufactures, and sells optical frames and sunglasses. Optics now employs about 120 staff in Hong Kong and 4000 staff in Mainland China. Along with the growth of the firm, its senior management experienced difficulties in retrieving and consolidating the information from assorted, uncoordinated application systems. SAP R/3 was finally adopted to alleviate the problems. The procurement and implementation phases took, respectively, about 3 months and 2 years to complete.

3.2.4. Stationery This firm in Australia is a large retailer and direct supplier of quality office and technology products for students, home offices, and businesses. Today it has about 100 physical stores nationwide and is continually opening new ones to keep up with the demand. Before adopting SAP R/3 as its ERP solution, Stationery was not satisfied with the functionality and scalability of its inventory, store, and purchasing systems, which were fairly uncoordinated and primitive applications. Stationery took about 6 months to make the ERP procurement decision and another 12 months to complete the implementation.

1015

3.3. Data collection In our study, data were collected from each firm mainly in three ways: (a) by interviewing the acquisition teams; (b) by reviewing archival information; and (c) subsequent member checks. We conducted semi-structured interviews with each subject firm. Every interview was conducted by two or more interviewers (to achieve observer triangulation [45]) and lasted about an hour. All interviews were audio-taped for subsequent transcription and verification of accurate interpretation. All the respondents are key members of the ERP acquisition teams, including Finance Director, General Manager (GM), Factory GM, IT Director, Head of IT, and Manager (IT Architecture). As we adopted a flexible design process, while a questionnaire has been carefully prepared in advance as a basis for the semistructured interviews, the contents and sequence of questions are not designed to be followed in the strictest sense during the interviews. The questionnaire consists of open-ended questions so as to allow for adequate flexibility and to encourage in-depth discussions. The questions also enabled the interviewers to clear up misunderstandings, 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 [25]. As it turned out, the respondents sometimes gave unexpected answers that indicated the existence of hitherto unanticipated relations (activities, tasks, and influences), which added to the richness of the cases. Our adoption of a flexible design process has helped to deal with these unexpected questions and answers from the respondents. We supplemented the interviews with the gathering of archival information from various sources within the firms, including procurement policies and plans, feasibility study reports, discussion reports, memos, and minutes of team meetings. These activities have provided supplementary information and allowed us to triangulate the data obtained through interviews. Furthermore, member checks were conducted. Respondents were asked to review the transcripts from the interviews in order to verify their content and, when necessary, amend or add to them. Follow-ups were also conducted by phone and e-mail to clarify ambiguities or discrepancies, or to confirm information. The use of more than one interviewer, audio-taping of interviews, cross-checking between the interview results and the archival information, together with subsequent member checks, help improve the validity and reliability of the collected data. 3.4. Limitations of the study The limitations of the study can be linked to the choices that were made regarding the research and specifically related to the newness of the research topic, that being the procurement of ERP software, the relatively small amount of research conducted to date in this area (compared to the implementation and post-implementation phases of ERP adoption), and the study methodology used. As our research methodology is mainly based on case studies in four subject firms, it is more limited than surveys in terms of generalizability. While surveys enable statistical extrapolation of results to a defined population, case studies are more restricted in focus. Case studies, however, are of value in refining theory and suggesting complexities for further investigation, as well as helping to establish the limits of generalization [62,63]. Runeson and Höst [45] argue that there exists a trade-off between level of control and degree of realism. Often, the reality (the ERP procurement process in this study) is complex and non-deterministic, thus creating difficulties in understanding what is happening. But if we increase the control in order to reduce the degree of realism, it may

1016

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

Table 2 Summary of some results of ERP adoption in the subject firms. Subject firm (location)

Adopted ERP system

Time taken for procurement

Time taken for implementation

Self-evaluation

Earning of external award

Beverage (Hong Kong) Electronics (Hong Kong) Optics (Hong Kong) Stationery (Australia)

Ross iRenaissance QAD MFG/PRO SAP R/3 SAP R/3

1 year 3 months 3 months 6 months

3.3 years 8 months 2 years 1 year

Merely satisfactory Successful Merely satisfactory Successful

No Yes (Rapid Achiever Award) No No

result in the exclusion of some real influential factors from the scope of the study. Case studies, being conducted in real world settings, have a high degree of realism, mostly at the expense of the level of control [45]. Our data collection is heavily reliant on semi-structured interviews. For this reason, our findings naturally center on respondents’ opinions, which were their view or perception of what occurred and, hence, could be somewhat biased. To a certain extent, though, such a bias had been compensated by our application of observer and data triangulation, as well as member checks. Notwithstanding the potential limitations concerning semi-structured interviews, opinions of the respondents are certainly vital. This is because their opinions represent the managers’ perception of what had happened, and it was on this perception that they based their decisions. It is the totality of these actions and interactions, arising from the respondents’ opinions, beliefs, and perceptions, that are central to this research.

4. Observations and lessons This section delineates our observations and lessons learned, presented according to the different stages of ERP systems procurement. These observations and lessons have been compiled by identifying the similarities and differences of ERP procurement practices among the subject firms, and by relating the findings with the ERP adoption results. To facilitate our discussions and for ease of reference, we summarize some results of ERP adoption in the subject firms in Table 2.

4.1. Stage 1: formation of acquisition team 4.1.1. Lesson 1: form a cross-functional acquisition team and organize regular project meetings The existence of a formal acquisition team and regular project meetings are two critical success factors for an adoption project. Generally, it is recommended to adopt a stakeholder process approach to team formation, that is, cross-functional stakeholders affected by the ERP system should be made part of the team. In this study, formal acquisition teams were formed in all the four firms, though in Beverage the team was small in size. Moreover, not all the firms held regular project meetings (see Table 3). In Beverage, the acquisition team basically consisted of the Head of IT Department, who assumed a leading role, and the Head of Business System Department. Furthermore, there was no formal representation from the functional areas affected by the ERP adoption, except for the Head of Business System Department, who was responsible for coordinating all other user departments to solicit their feedback. Although a prior questionnaire survey had been used to collect users’ views on the ERP adoption exercise, the approach was indirect and, hence, might not be effective in addressing users’ concerns and conflicts. These arrangements indicate that Beverage had not fully recognized the strategic importance of the project, as well as the need for full stakeholders’ involvement. This might explain why Beverage took the longest period for making the procurement decision (about a year) and implementing the system (3.3 years).

Table 3 Acquisition team and project meetings.

Cross-functional acquisition team Regular project meetings

Beverage

Electronics

Optics

Stationery

Yes (small in size) No

Yes

Yes

Yes

Yes

No

Yes

In contrast, the acquisition teams of Electronics, Optics, and Stationery consisted of representatives from the major functional areas affected by the ERP adoption. In particular, Electronics and Stationery claimed to have treated their ERP adoption exercises not merely as expensive IT projects, but rather as critical enterprise-wide projects. For example, the acquisition team of Electronics was composed of the IT Director, Finance Director, Marketing Director, Engineering Director, and Factory GM. Regular project meetings were held throughout the procurement process in Electronics (as well as in Stationery). In the end, Electronics had the overall shortest project duration, including both the procurement (3 months) and implementation (8 months) phases. (Another major reason contributing to the shortest overall project duration of Electronics is the prior knowledge of two key acquisition team members on the selected ERP software. See Section 4.1.3 for more details.) Electronics is followed by Stationery and then by Optics in terms of the overall project duration. In contrast to Electronics and Stationery, regular project meetings were not scheduled in Optics. Instead, the GM of Optics would call upon meetings with the Heads of major functional areas when the need arose. This might contribute to the longer project duration in Optics, when compared to Electronics and Stationery. Indeed, when asked to rate the degree of success of their ERP adoption projects, Electronics and Stationery considered themselves as having a ‘‘successful” adoption result, while Electronics earned the ‘‘Rapid Achiever Award” in the Asia–Pacific region from the ERP software vendor. In contrast, Beverage and Optics considered the adoption result as merely ‘‘satisfactory”. 4.1.2. Lesson 2: develop a formal project plan The project plans for all the three firms in Hong Kong were fairly informal, and the procurement process tended to be driven by people rather than tasks. Thus, the whole procurement process was rather fluid and unplanned. This phenomenon reflects a common Chinese practice, which differs from the ERP procurement practices in the West,3 where firms typically start their adoption exercises with well-thought project plans [48]. More Western firms have realized the importance of corporate governance [4,27], and are more inclined to establish a project plan to render the procurement process more manageable. This is the case in Stationery in 3 The implication of cultural difference to management practices has also been observed by many other authors. For example, Lai [27] argues in his paper that Western and Eastern corporations are different in terms of ownership and management. In the West, ownership is diverse, and control is in the managers, which are considered signs of good practice of corporate governance. In contrast, ownership and management in the East often rest with the same person, or through his/her appointed representative, which are considered signs of poor practice of corporate governance [27].

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

Australia – the entire firm, including the management, is primarily of the Western culture. This partly explains why Stationery has the second shortest adoption period (18 months) and it is one of the two firms which claim their adoption exercises as being successful. Had the project plans of the three Hong Kong firms been more formal, the adoption exercises could have been improved. A related issue is worth mentioning here. One may wonder why Electronics has the shortest adoption period and achieved a successful adoption result, despite the absence of a formal project plan. A plausible explanation is that Electronics has a well formed acquisition team (see Section 4.1.1) in which two members have prior hands-on ERP knowledge (see Section 4.1.3), which apparently compensates for any deficiency due to the lack of a formal project plan. 4.1.3. Lesson 3: involve people with prior ERP knowledge Among the four firms, Electronics was the only one whose acquisition team members (the IT Director and the Factory GM) possessed prior ERP knowledge. Specifically, the Factory GM had a favorable experience of using QAD products during his prior employment in the same industry. (Electronics eventually selected QAD MFG/PRO for adoption.) Electronics explicitly attributed its success largely to the prior ERP knowledge of the IT Director and the Factory GM, and the hands-on experience of the Factory GM in QAD products. Electronics also mentioned that the decision of acquiring QAD MFG/PRO had been a direct result of the Factory GM’s prior experience. The firm considered that the implementation risk for the choice would be low, even though the procurement decision had been admittedly somewhat biased. As mentioned before, possibly because of the prior ERP knowledge of some acquisition team members in Electronics, the firm has the shortest periods for procurement (3 months) and implementation (8 months), compared to the other three firms whose acquisition teams were inexperienced in ERP adoption. 4.2. Stage 2: examination of business requirements and constraints 4.2.1. Lesson 4: develop a business case In all the firms, the decision to adopt an ERP solution had been prompted by their own problems in meeting the business requirements and customer needs. The decision was not solely driven by the desire to acquire a sophisticated enterprise system, nor simply triggered by the successful ERP adoption of their competitors. For example, the ERP adoption exercise in Beverage was triggered by problems such as system disintegration, operational inefficiency, inability to fulfil customers’ demand, and unavailability of information for management and forecast. We also note that these business requirements and customer needs were examined and translated into the required system functionalities in stage 3. Thus, all the firms had taken measures to improve the chance that the business problems they were confronted with could be solved by the acquired ERP systems. 4.2.2. Lesson 5: avoid business process reengineering (BPR) The acquisition teams of all the firms have emphasized that BPR was not considered in their ERP adoption processes. (Pure BPR aims to design the optimal way of performing a business process with no constraints [19]. Under this premise, some issues can be ignored, such as the capabilities of the current legacy systems or the potential packages that may be implemented to support the reengineered process.) Otherwise, the adoption risk might have been substantially increased and the project could have been significantly prolonged. Indeed, by its very nature, BPR does not fit well with a strategy of using packaged applications to support business processes without substantially modifying the vendor’s software [51].

1017

Nevertheless, we note that whether a firm should consider redesigning its business processes in an ERP adoption has been controversial and two opposing views are in place. On one hand, some people support the ERP-driven approach (excluding the explicit consideration of BPR in an ERP adoption) due to three main reasons. Firstly, since an ERP system has already incorporated standard processes and ‘‘best” practices in the business world, a firm adopting such a system would mean that its business processes are ‘‘automatically” reengineered [55]. Secondly, doing BPR in an ERP adoption will trigger significant synchronization problems, which in turn cause high uncertainties and possibly great delays [6,51], making the acquisition team feel confused and unfocused [23]. Thirdly, it is advisable to maintain existing ERP functionality (or to keep customization to a minimum) and to change the business procedures to adapt to it [33,35]. Otherwise, software modification may result in code errors and difficulty in future software upgrade. Welti [60] argues that, if a firm decides to do BPR, this exercise should be postponed after the ERP adoption project, based on the rationale that system users will then have a better understanding of the functionality and potentials of the ERP system before redesigning the business processes. On the other hand, some people suggest doing BPR and ERP adoption in one go for two reasons. Firstly, subsequent process redesign may be highly constrained by the adopted ERP system. Secondly, in the ERP-driven approach, changing the firm’s business processes to adapt to the ERP system may bear the risk of abandoning some of its own good practices which give the firm competitive advantage over its competitors [11,39]. Despite the conflicting recommendations from the literature, we still put forward Lesson 5 as a result of our observation grounded on our case studies. What we observe is that the ERP-driven approach is preferred as the firms were heavily concerned with whether the adoption project can be finished on time and within budget, as well as the future maintainability of the adopted ERP system. All firms we studied did not want to bear the risks of additional uncertainties in exchange for the potential benefits achieved by performing BPR concurrently with the ERP adoption project. 4.2.3. Lesson 6: attend to constraints All the firms were fully aware of their own constraints in the ERP procurement process. One observation is worth mentioning here. For Beverage, Optics, and Stationery, a technical constraint that confronted them was that the existing hardware and software platforms did not fit with the shortlisted ERP systems. To overcome this constraint, the firms had prepared to increase the budget for upgrading the existing hardware and software. In contrast, the situation at Electronics was quite different. Its acquisition team found that the existing hardware and software were particularly fit for a candidate ERP system (QAD MFG/PRO). This compatibility advantage, together with the prior knowledge of the QAD products by the Factory GM, largely determined the team’s eventual decision to select QAD MFG/PRO. 4.3. Stage 3: formulation of evaluation criteria 4.3.1. Lesson 7: recruit external consultants Due to various reasons, none of the firms involved consultants in formulating evaluation criteria for ERP vendors and software. For the three firms in Hong Kong, we observed that they were very cost-conscious and reluctant to spend extra costs in hiring consultants. They also believed that consultants would generally not be familiar enough with the internal operations of the firms to offer apposite advice on ERP selection. Instead, they emphasized more on: (a) the judgment and experience of the acquisition teams and

1018

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

Table 4 Four most important criteria ranked by each firm. Beverage

Electronics

Optics

Stationery

Price System functionality Vendor’s financial position Customers’ reference

Price Customers’ reference Time required for implementation Implementation risk

Ability to meet business / user requirements Vendor’s established history Availability of interface in Chinese language Vendor’s reputation

Ability to meet business / user requirements System functionality System reliability System scalability

(b) the ‘‘words of mouth” and other information collected through their own networks in the same industrial sectors.4 The acquisition team of Stationery in Australia excluded consultants for a different reason. Stationery worried that consultants might specify some evaluation criteria which favor their companies but are not relevant to Stationery. (For instance, a consultant might recommend a particular ERP system for adoption solely because they have prior experience on that system, even though it does not suit the firm best.) Thus, Stationery has left the task of formulating evaluation criteria mainly with the acquisition team. It is worth mentioning that, during the interview with the IT Manager (Infrastructure) of Stationery, who has played a significant role in the firm’s ERP procurement exercise, admitted bluntly, ‘‘We will definitely not allow external consultants to get involved in the formulation of ERP evaluation criteria, system selection, and . . . .” In general, experienced consultants do have their merits in an ERP adoption project [51]. Should they be recruited, the firm should: (a) conduct reference checks with previous projects and clients; (b) prepare a letter of understanding or a formal contract specifying deliverables such as timeframes, fees, expenses, cancellation, staff turnover, and confidentiality; and (c) avoid allowing the consultants to make any major decision on behalf of the firm’s management. When asked whether the advice of experienced consultants would be sought if the consultants were able to understand the internal operations of the firms and care about the ERP adoption results from the perspective of the firms, all four firms gave an unanimous affirmative answer. This indicates that none of the firms disagreed in principle with the involvement of qualified consultants. 4.3.2. Lesson 8: prepare a comprehensive list of evaluation criteria All the three firms in Hong Kong did not formally compile a ‘‘comprehensive” list of criteria for detailed evaluation. They explained that the preparation of a formal evaluation list could have been quite difficult for them without prior ERP procurement experience and without the help of experienced external consultants.5 We, however, did observe that these three firms in Hong Kong had taken into account most of the criteria in Table 1 even though without using a formal evaluation list. In addition, these firms did rank some criteria as more important than the others for guiding their procurement decisions. Table 4 lists the four most important criteria actually used by each of the four firms. Note that, interestingly, the provision of a Chinese language interface was considered by Optics 4 With regard to (b) about the high reliance on personal / social networks in the Chinese culture, the President at Stand Talent International Limited, who possesses many years of headhunting experience in Mainland China, argues that one needs ‘‘a good network of business friends to be successful as a manager in China” (http:// www.stilasia.com.cn/neiye.jsp?column_id=49). Also, in his book [9], Chen argues that, whereas Western business culture is transaction-based, Chinese business culture is relationship-based. Whereas a successful business person is described as wealthy in the West, a successful Chinese business person would be described as well-connected. 5 During the interviews with the three Hong Kong firms, all the respondents confirmed that even though they had not prepared a comprehensive list of evaluation criteria this time, they would certainly do so in their next ERP procurement exercises, mainly for two reasons: (a) they have realized the contribution of the evaluation lists in selecting the appropriate ERP systems and (b) the experience and knowledge acquired in the past exercises make the preparation of the evaluation lists easier.

as one of its primary concerns because many users (particularly those at the lower ranking) did not have sufficient English proficiency. Price had never been a primary selection criterion in Stationery, as repeatedly emphasized by its acquisition team. Indeed, Stationery had allocated a budget of US $29 million, the highest among all the four firms. Instead, the main goal was to select an ERP system that is rich in system functions, scalable, reliable, and adequately supportive of the operational needs of the firm. Indeed, as the Manager (IT Architecture) of Stationery said frankly, ‘‘Cost was not the prime factor; system functionalities and reliability were more important”. Here we have two observations. Firstly, Table 4 seems to suggest that the selection process in Stationery was primarily based on the ‘‘objective” factors related to the ERP system itself. On the other hand, some of the most important criteria in all the three firms in Hong Kong are relatively subjective (such as customers’ reference and vendor’s reputation) and not specifically concerned with the ERP systems. Secondly, although Stationery (as well as Optics) had no prior ERP procurement experience and did not recruit external consultants, the acquisition team in Stationery did actually prepare a formal evaluation list (albeit not a very comprehensive one). Again we note that this difference could be due to culture influences – Westerns firms, such as Stationery, typically emphasize more on corporate governance and, hence, tend to prepare a formal evaluation list to make the evaluation process more systematic, manageable, and transparent.6 It is worth mentioning that both Stationery and Optics selected SAP R/3 for implementation, and they considered the adoption results as ‘‘successful” and ‘‘merely satisfactory”, respectively. 4.4. Stage 4: evaluation and selection of the ‘‘best fit” 4.4.1. Lesson 9: adopt an appropriate package selection approach Broadly speaking, there are three main approaches to selecting software packages: detailed requirements, key requirements, and proof-of-concept [51]. They are briefly discussed below:  Detailed requirements: This approach starts by identifying all packages that meet the needs of the firm. A relatively ‘‘long” list (10–20) of package vendors and a detailed list of functional and technical requirements for the new system are then prepared. The detailed requirements are prioritized and classified into categories such as mandatory, desirable, and optional. The detailed requirements list is then sent to each shortlisted vendor in the form of a formal Request for Proposal (RFP). When the RFP responses are received from the vendors, the acquisition team develops a numerical score to represent the overall fit of each package.  Key requirements: Compared to the first approach, the second one takes a more streamlined path toward making a package recommendation. Here the acquisition team rapidly gets to a 6 Transparency is said to be not the ‘‘second nature” of Chinese entrepreneurs [4]. See also Footnote 3 on the differences in corporate governance practices between the East and the West.

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

‘‘short” list of vendors, and makes a more focused attempt to determine the true discriminators that will drive the selection. Because the major vendors all have packages that support most of the traditional functions (such as financial, manufacturing, and human resources) equally well, this second approach aims to identify areas that the packages do not all do equally well and the impact that these differences have on the ability of the packages to address the key problems and opportunities which the firm is facing. These differences should drive the selection of one package over another.  Proof-of-concept: Compared to the above approaches, this one is usually the fastest. It is used when a firm believes that it already knows which package is apparently the right choice, and just needs to confirm its selection before entering into a contract with the vendor and starting the implementation. A firm must carefully decide the appropriate package selection approach to adopt, with reference to a number of factors, such as the type of industry and prior ERP knowledge. Initially, Beverage, Electronics, and Optics had picked nine, three, and eight candidate ERP systems, respectively, for preliminary considerations. Both Beverage and Optics further shortlisted two of the initial candidate ERP systems for final evaluation. In the shortlisting process, Beverage and Optics invited the software vendors to make presentations and demonstrations on their ERP products. These activities were followed by site visits to the software vendors. Thereafter, all the three firms used their primary evaluation criteria as listed in Table 4, and took into considerations other secondary criteria (which were similar to those listed in Table 1). Essentially, all the three firms adopted the detailed requirements approach for package selection. On the other hand, Stationery adopted the proof-of-concept approach to selecting SAP R/3 for implementation. This approach may involve substantial selection bias and, hence, should only be used with caution. It is particularly suited when a firm knows that the leaders within an industry have all selected and implemented the same package because it has unique functionality that supports the industry well [51]. In such a case, provided that the costs and benefits are in line, the risk is probably relatively low for the firm to settle on the package without evaluating other candidates or going through a full selection exercise. 4.4.2. Lesson 10: use appropriate decision-making strategies and styles The optimizing strategy assumes that decision makers seek the best alternatives to maximize the achievement of the goals and the objectives of the organization. The manifest assumption here is that there is one best solution to problems that can be discovered and implemented. The optimizing strategy, however, is too idealistic, because in practice decision makers virtually never have access to all the relevant information, nor can they generate all the possible alternatives and accurately anticipate all the consequences. A more realistic strategy, known as a satisficing strategy, is to look for a ‘‘satisfactory” or ‘‘good enough” solution [22]. In terms of a satisficing strategy, the ‘‘best fit” in stage 4 of the procurement model refers to the best of the satisfactory options. There are two decision-making styles involving group participation [22] which are applicable to our analysis of ERP systems procurement. In the group-consultative style, the team leader shares the problem with other members and solicits their ideas and suggestions. A decision is then made, which may or may not reflect the influence of the group members. On the other hand, in the groupagreement style, the team leader shares the problem with other members, and they together generate and evaluate alternatives in an attempt to reach consensus. Here, the leader will not forcefully impose or dictate his/her favorite solution to the group for acceptance. Instead, the leader is willing to accept and implement

1019

the collective decision of the group. Between these two styles, the group-agreement style for selecting an ERP package is generally more preferable, because this style induces a higher sense of involvement and collective responsibility to the entire acquisition team, which in turn helps to solicit the needed and genuine support of the team in the ERP adoption project. For the four firms concerned, the decision-making styles of the acquisition teams fall within a spectrum, with the group-consultative style and the group-agreement style as its two extremes. More specifically, the decision-making styles of the three firms based in Hong Kong are closer to the group-consultative style, particularly Electronics and Optics, where the leaders of the acquisition teams were the ‘‘real” decision makers and had a strong influence on the Chief Executive Officer or the Chairman of the Board, who ultimately endorsed the decision. On the other hand, the decisionmaking style of Stationery is closer to the group-agreement style. Again, this difference in management practice could have been influenced by the cultural differences between the East and the West.7 5. Related work While some previous studies on ERP adoption [14,31,38] have been outlined in Section 1, here we shall review some other recent literature to supplement and complete our discussion of related work. First, we start with a few studies that are directly related to the focus of this paper, namely, the pre-implementation phase of an ERP adoption life cycle. Abdinnour-Helm et al. [1] discover that, contrary to conventional wisdom, extensive investments by firms in shaping the pre-implementation attitudes of employees do not always achieve the desired effects. Instead, in terms of the attitudes of an employee of a firm towards the capabilities, value and acceptance of ERP, as well as the timing of ERP implementation, Abdinnour-Helm et al. [1] show, by statistical hypothesis tests, that the employees’ job tenure and position have greater impact than high levels of their involvement in ERP pre-implementation. S ß en et al. [49] present an integrated decision support system to assist decision makers in selecting an ERP system by allowing both qualitative and quantitative objectives to be considered in a multiobjective mathematical programming model. Sánchez et al. [46] develop a fuzzy evaluation model to assess the suitability of an ERP system based on a multi-expert decision-making process that is able to deal with heterogeneous information. In this regard, the work of Sßen et al. [49] and Sánchez et al. [46] concerns primarily with the activities in stages 3 and 4 (both related to the evaluation criteria and selection of ERP systems) of our conceptual ERP procurement process model as depicted in Fig. 1. The implementation phase of ERP adoption, in comparison, has been quite extensively studied. Here we just outline some of the more recent work. Ward et al. [58] synthesize a framework for analyzing and understanding how organizational issues (such as organizational culture, structure, governance, and communication and conflict between stakeholder groups) affect the success of ERP implementation. Nandhakumar et al. [36] explore the process of a large-scale ERP implementation project and the internal and external contextual issues (for example, the nature of technology and the power and cultural settings) that shape the process. Wang et al. [57] argue that successful ERP implementation depends on the cohesiveness of user groups in their goals, commitment, and 7 In their paper [34], Martinsons and Davison report that in Chinese-dominated societies (including Hong Kong, Mainland China, and other places), Chinese managers tend to be more hierarchical, shunning employee participation in the decisionmaking process. On the other hand, managers tend to allow more democratic and participatory decision making in American than in Japanese and Chinese workplaces.

1020

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

ability to work toward completion of the adoption project. They conjecture that such cohesiveness is built partly through the willingness of the team members to participate and commitment to learn the new system. They then perform a survey study in Taiwan to test their proposed relationships. Wu et al. [61] argue that ERP implementation should not be viewed as a static process. Rather, due attention should be paid to an ERP system as something that will meet the needs of a changing firm. Accordingly, they propose the application of the Real Options theory to ERP implementation so as to address uncertainties over time and take appropriate action to respond to the changing ERP implementation environment. Two important (technical) tasks in the implementation phase are to design and customize the ERP software to cater for the needs of the firm. In this regard, Dijkman et al. [13] observe that different stakeholders in the design of an ERP system have their own views on that design. To help produce a coherent design, they introduce a framework that aids in specifying relations and consistency rules between such views. In addition, Luo and Strong [30] develop a framework for supporting management decision-making about customization choices and the technical and process change capabilities required for system and process customization. With regard to the post-implementation phase of ERP software, Häkkinen and Hilmola [18] perform a study related to the so-called ‘‘shakedown” phase shortly after system implementation. Their study examines how user evaluations of ERP system success could be used to track the source of potential problems. Their results help maintain operational momentum and prevent possible problems from being escalated in the shakedown phase. Chou and Chang [10] examine ERP performance after system implementation, particularly from the perspective of managerial intervention. They find that both customization and organizational mechanisms affect intermediate benefits (including coordination improvement and task efficiency), which in turn influence overall benefits. When we present some of our lessons in Section 4, we also discuss how cultural differences may affect the ERP procurement process (see Footnotes 3,4,6 and 7 in Section 4). Two articles in the literature are specifically concerned with the influence of culture on ERP adoption. Soh et al. [53] argue that a common problem when adopting package software has been the issue of ‘‘misfits”, that is, the gaps between the functionality offered by the package and that required by the adopting organization. They further argue that there is a need to recognize the unique Asian context when adopting an ERP system, because the embedded business models typically reflect a bias toward Western practices. Similar arguments are made by Davison [12]. He suggests that awareness of cultural differences and preferences will improve the assessment of ERP suitability and any subsequent implementation. This implies that a ‘‘one-business-model-fits-all” approach is unlikely to be successful. Instead, developers and consultants must adapt their products and services for different cultural markets. Recall that we have begun this paper by mentioning some failure cases of ERP adoption [8,48,58,61]. Given that ERP adoption is a very costly and risky endeavor, it is highly desirable to have some means for a firm to estimate its chance of success of an ERP adoption project as early as possible. Toward this end, Magnusson et al. [32] discuss their effort to develop a conceptual framework to forecast ERP implementation success. Some IT practitioners and researchers, such as Botella et al. [7], consider that ERP systems are a category of COTS products that offers extensive support to the management of business processes in firms. In their paper [7], Botella et al. describe the construction of a quality model for a particular COTS domain – ERP software. This model allows an ERP software system to be evaluated and compared to user requirements during a selection process. Lawlis et al. [29] conclude from a case study that the simplest and most

widely used form of decision analysis, which relies on linear additive functions (weighted averages), would be effective in evaluating COTS products. They then develop a COTS product evaluation process, which helps an organization obtain valid quantitative indicators to assess product quality and suitability prior to purchase. Gashi et al. [17] take into account the uncertainty and incompleteness of the knowledge of COTS products and other aspects (for example, vendor’s credentials), and introduce a Bayesian approach for assessing COTS components. However, neither Lawlies et al. [29] nor Gashi et al. [17] have considered ERP evaluation, and whether their methods are applicable to ERP adoption projects remains to be confirmed.

6. Summary and further work Adopting an ERP solution is not solely a technical issue but also an important strategic one, as the selected ERP system will have profound business impact on the firm. Nevertheless, in a rapidly changing business environment nowadays, the rather complex ERP procurement process must be well planned and managed to ensure the right ERP system to be selected. We have described our cross-regional study of three Chinese firms and an Australian firm which have undertaken ERP adoption. We have reported the experiences of how they carried out the adoption exercises, with reference to an ERP procurement process model (Fig. 1). Based on the findings and observations from our study, we conclude 10 lessons pertinent to various stages of an ERP procurement process. We believe that our primary research objective has been met, as these lessons, observed from real experience, have answered our first research question (namely, RQ-1 in Section 3.1) by providing insights and pragmatic guidelines in practice to help firms conduct a successful ERP procurement exercise. With regard to our secondary research objective, we have identified some notable differences in the practices of ERP procurement between the Hong Kong firms and Australian firm. These observations have answered our second research question (namely, RQ-2 in Section 3.1) and provided further evidence in support of some other researchers’ findings that cultural differences do affect the ERP adoption process. Besides, our study has generated follow-up research questions to be addressed by further work. First, as explained in Lesson 5, despite opposing views in the literature on whether BPR should be performed at the time of ERP adoption, all of our subject firms have intentionally avoided BPR in order to ensure that the ERP adoption project could be completed on time and within budget. With regard to this issue, some open research questions remain. Some firms whose time and budget are less constrained may prefer to perform BPR concurrently with ERP adoption. Then two questions naturally follow. One question is how much extra effort is really required to perform BPR concurrently with ERP adoption. Another question is how a concurrent BPR affects the future maintainability of the adopted ERP system. Since BPR done with ERP adoption together can achieve tremendous benefits given the right context, it would be interesting and worthwhile to perform further case studies with a primary focus on these research questions. Secondly, we have not attempted to measure the success of an ERP implementation in the long run, such as considering the improvement of a firm’s internal and external performance after system implementation for an extended time period, which is beyond the scope of our present study. A longitudinal study is needed to investigate in what ways the ERP procurement practices affect the long term success of the adoption project. Finally, although we have observed evidence of the impact of cultural differences on some ERP procurement practices, this research has been limited by the number of subject firms studied

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

and the number of locations of the firms. It would be interesting to extend our study to compare the practice of firms in other places in the Asia–Pacific region, not only contrasting cultural differences between the East and the West, but also among different countries/cities such as Singapore, India, and Mainland China. At any rate, a case study involving more firms would certainly provide even richer information and further strengthen the validity and generalizability of the research results and lessons learned. Acknowledgments We are grateful to S.-F. Tang, F.-C. Kuo, C. Chan, F. Chan, B. Ho, N. Lau, and V. Leung for their help in this project. We are also grateful to the four anonymous firms involved in the studies. A preliminary version [42] of this paper was presented at the 28th International Conference on Software Engineering (ICSE 2006). References [1] S. Abdinnour-Helm, M.L. Lengnick-Hall, C.A. Lengnick-Hall, Preimplementation attitudes and organizational readiness for implementing an Enterprise Resource Planning system, European Journal of Operational Research 146 (2) (2003) 258–273. [2] Aberdeen Group, Vertical Industry Solutions: Baan Leads in Innovation, Market Viewpoint 10, July 1, 1997. . [3] G.B. Alleman, Agile project management methods for ERP: how to apply agile processes to complex COTS projects and live to tell about it, in: Extreme Programming and Agile Methods: XP/Agile Universe 2002, Lecture Notes in Computer Science, vol. 2418, 2002, pp. 70–88. [4] M. Backman, C. Butler, Big in Asia: 30 Strategies for Business Success, Palgrave Macmillan, Hampshire, UK, 2007. [5] P. Bingi, M.K. Sharma, J.K. Godla, Critical issues affecting an ERP implementation, Information Systems Management 16 (3) (1999) 7–14. [6] Boru Consulting, Business process re-engineering and ERP applications, App Topics 1 (2) (1999) 1–5. . [7] P. Botella, X. Burgués, J.P. Carvallo, X. Franch, J.A. Pastor, C. Quer, Towards a quality model for the selection of ERP systems, in: Component-Based Software Quality, Lecture Notes in Computer Science, vol. 2693, 2003, pp. 225–245. [8] I.J. Chen, Planning for ERP systems: analysis and future trend, Business Process Management Journal 7 (5) (2001) 374–386. [9] M.-J. Chen, Inside Chinese Business: A Guide for Managers Worldwide, Harvard Business School Press, Boston, MA, 2001. [10] S.-W. Chou, Y.-C. Chang, The implementation factors that influence the ERP (enterprise resource planning) benefits, Decision Support Systems 46 (1) (2008) 149–157. [11] T.H. Davenport, Putting the enterprise into the enterprise system, Harvard Business Review 76 (4) (1998) 121–131. [12] R. Davison, Cultural implications of ERP, Communications of the ACM 45 (7) (2002) 109–111. [13] R.M. Dijkman, D.A.C. Quartel, M.J. van Sinderen, Consistency in multiviewpoint design of enterprise information systems, Information and Software Technology 50 (7–8) (2008) 737–752. [14] A. Dreiling, M. Rosemann, W.M.P. van der Aalst, W. Sadiq, From conceptual process models to running systems: a holistic approach for the configuration of enterprise system processes, Decision Support Systems 45 (2) (2008) 189– 207. [15] J. Esteves, J. Pastor, Enterprise resource planning systems research: an annotated bibliography, Communications of AIS 7 (8) (2001) 1–52. [16] X. Franch, J.A. Pastor, On the formalisation of ERP systems procurement, in: Proceedings of ICSE Workshop: Continuing Collaborations for Successful COTS Development, June 2000. [17] I. Gashi, P. Popov, V. Stankovic, Uncertainty explicit assessment of off-the-shelf software: a Bayesian approach, Information and Software Technology 51 (2) (2009) 497–511. [18] L. Häkkinen, O.-P. Hilmola, ERP evaluation during the shakedown phase: lessons from an after-sales division, Information Systems Journal 18 (1) (2008) 73–100. [19] M. Hammer, J. Champy, Reengineering the Corporation: A Manifesto for Business Revolution, HarperBusiness Essentials, New York, NY, 2003. [20] V. Ho, Asia software market to see growth, ZDNet Asia’s News: Software, March 31, 2009. . [21] G. Hofstede, G.J. Hofstede, Cultures and Organizations: Software of the Mind, second ed., McGraw-Hill, New York, NY, 2005. [22] W.K. Hoy, C.J. Tarter, Administrators Solving the Problems of Practice. Decision-Making Concepts, Cases, and Consequences, third ed., Pearson Allyn and Bacon, Boston, MA, 2008. [23] M.S. Jayaraman, Implementing BPR and ERP, Business Line, May 3, 1998. .

1021

[24] J. Karimi, T.M. Somers, A. Bhattacherjee, The impact of ERP implementation on business process outcomes: a factor-based study, Journal of Management Information Systems 24 (1) (2007) 101–134. [25] F.N. Kerlinger, H.B. Lee, Foundations of Behavioral Research, fourth ed., Harcourt College Publishers, Fort Worth, TX, 2000. [26] K. Kumar, J. van Hillegersberg, ERP experiences and evolution, Communications of the ACM 43 (4) (2000) 23–26. [27] D.Y.H. Lai, Corporate governance in Malaysia: the underlying Chinese business culture, in: Proceedings of the 5th Asia-Pacific Journal of Accounting and Economics (APJAE) Symposium, January 2004. [28] R. Land, L. Blankers, M.R.V. Chaudron, I. Crnkovic´, COTS selection best practices in literature and in industry, in: Proceedings of the 10th International Conference on Software Reuse (ICSR’08), Lecture Notes in Computer Science, vol. 5030, 2008, pp. 100–111. [29] P.K. Lawlis, K.E. Mark, D.A. Thomas, T. Courtheyn, A formal process for evaluating COTS software products, IEEE Computer 34 (5) (2001) 58–63. [30] W. Luo, D.M. Strong, A framework for evaluating ERP implementation choices, IEEE Transactions on Engineering Management 51 (3) (2004) 322–333. [31] V.A. Mabert, A. Soni, M.A. Venkataramanan, Enterprise resource planning: managing the implementation process, European Journal of Operational Research 146 (2) (2003) 302–314. [32] J. Magnusson, A. Nilsson, F. Carlsson, Forecasting ERP implementation success: towards a grounded framework, in: Proceedings of the 13th European Conference on Information Systems (ECIS 2004), Paper 75, June 2004. [33] M.L. Markus, S. Axline, D. Petrie, C. Tanis, Learning from adopters’ experiences with ERP: problems encountered and success achieved, Journal of Information Technology 15 (4) (2000) 245–265. [34] M.G. Martinsons, R.M. Davison, Strategic decision making and support systems: comparing American, Japanese and Chinese management, Decision Support Systems 43 (1) (2007) 284–300. [35] F.F.-H. Nah, J.L.-S. Lau, J. Kuang, Critical factors for successful implementation of enterprise systems, Business Process Management Journal 7 (3) (2001) 285– 296. [36] J. Nandhakumar, M. Rossi, J. Talvinen, The dynamics of contextual forces of ERP implementation, Journal of Strategy Information Systems 14 (2) (2005) 221– 242. [37] C. Ncube, J.C. Dean, The limitations of current decision-making techniques in the procurement of COTS software components, in: Proceedings of the 1st International Conference on COTS-Based Software Systems (ICCBSS), Lecture Notes in Computer Science, vol. 2255, 2002, pp. 176–187. [38] A.I. Nicolaou, S. Bhattacharya, Organizational performance effects of ERP systems usage: the impact of post-implementation changes, International Journal of Accounting Information Systems 7 (1) (2006) 18–35. [39] N.A. Panayiotou, S.P. Gayialis, H. Domenikos, S.T. Ponis, A staged BPR approach driven by ERP information technology, in: Proceedings of the 3rd International Workshop on Supply Chain Management and Information Systems (SCMIS 2005), July 2005. [40] A. Pang, Worldwide ERP Applications 2004–2008 Forecast: First Look at Top 10 Vendors, IDC, May 2004, pp. 1–14. [41] Y.A. Pollalis, I.H. Frieze, A new look at critical success factors in information technology, Information Strategy: The Executive’s Journal 10 (1) (1993) 24–34. [42] P.-L. Poon, Y.T. Yu, Procurement of enterprise resource planning systems: experiences with some Hong Kong companies, in: Proceedings of the 28th International Conference on Software Engineering (ICSE 2006), May 2006, pp. 561–568. [43] M.A. Razi, J.M. Tarn, D.C. Yen, Exploring the pre-acquisition phase of ERP for small enterprises, Communications of the ICISA 5 (2) (2004) 26–37. [44] R.A. Roth, Preparing the reflective practitioner: transforming the apprentice through the dialectic, Journal of Teacher Education 40 (2) (1989) 31–35. [45] P. Runeson, M. Höst, Guidelines for conducting and reporting case study research in software engineering, Empirical Software Engineering 14 (2) (2009) 131–164. [46] P.J. Sánchez, L. Martínez, C. García-Martínez, F. Herrera, E. Herrera-Viedma, A fuzzy model to evaluate the suitability of installing an enterprise resource planning system, Information Sciences 179 (14) (2009) 2333–2341. [47] D.A. Schön, The Reflective Practitioner: How Professionals Think in Action, Basic Books, New York, NY, 1983. [48] J.E. Scott, I. Vessey, Managing risks in enterprise systems implementations, Communications of the ACM 45 (4) (2002) 74–81. [49] C.G. S ß en, H. Baraçlı, S. Sßen, H. Basßlıgil, An integrated decision support system dealing with qualitative and quantitative objectives for enterprise software selection, Expert Systems with Applications, Part 1 36 (3) (2009) 5272–5283. [50] M. Shakir, Decision making in the evaluation, selection and implementation of ERP systems, in: Proceedings of the 6th Americas Conference on Information Systems (AMCIS 2000), August 2000, pp. 1033–1038. [51] M.G. Shields, E-Business and ERP: Rapid Implementation and Project Planning, Wiley, New York, NY, 2001. [52] P. Soffer, B. Golany, D. Dori, Aligning an ERP system with enterprise requirements: an object-process based approach, Computers in Industry 56 (6) (2005) 639–662. [53] C. Soh, S.S. Kien, J. Tay-Yap, Cultural fits and misfits: is ERP a universal solution?, Communications of the ACM 43 (4) (2000) 47–51. [54] C.J. Stefanou, A framework for the ex-ante evaluation of ERP software, European Journal of Information Systems 10 (4) (2001) 204–215. [55] G. Tamotia, From ERP-Enabled BPR to BPR-Enabled ERP, February 8, 2000. .

1022

P.-L. Poon, Y.T. Yu / Information and Software Technology 52 (2010) 1011–1022

[56] J. Verville, A. Halingten, An investigation of the decision process for selecting an ERP software: the case of ESC, Management Decision 40 (3) (2003) 206– 216. [57] E.T.G. Wang, T.-C. Ying, J.J. Jiang, G. Klein, Group cohesion in organizational innovation: an empirical examination of ERP implementation, Information and Software Technology 48 (4) (2006) 235–244. [58] J. Ward, C. Hemingway, E. Daniel, A framework for addressing the organizational issues of enterprise systems implementation, Journal of Strategy Information Systems 14 (2) (2005) 97–119. [59] J.W. Weiss, D. Anderson, Aligning technology and business strategy: issues and frameworks, a field study of 15 companies, in: Proceedings of the 37th

[60] [61] [62] [63]

Hawaii International Conference on System Sciences (HICSS 2004), January 2004. N. Welti, Successful SAP R/3 Implementation: Practical Management of ERP Projects, Addison-Wesley, Reading, MA, 1999. L.-C. Wu, C.-S. Ong, Y.-W. Hsu, Active ERP implementation: a real options perspective, Journal of Systems and Software 81 (6) (2008) 1039–1050. R.K. Yin, Applications of Case Study Research, second ed., Sage Publications, Thousand Oaks, CA, 2003. R.K. Yin, Case Study Research: Design and Methods, fourth ed., Sage Publications, Thousand Oaks, CA, 2009.