Introduction

The failure rate of Customer Relationship Management (CRM) implementations is estimated to be greater than 65% (Davids, 1999). Lowering the failure rate and supporting the success of information systems (IS) are the ultimate goals of IS researchers and practitioners. However, most research so far has been based on variance theory, with the focus generally on finding factors associated with the successful outcome of IS development (Markus & Robey, 1988; Van de Ven, 1992). Accordingly, numerous critical success factors (CSFs) have been identified, giving a snapshot view of the phenomenon (Desai et al., 1998; Guimares et al., 1992; Reich & Benbasat, 1990; Wixom & Watson, 2001; Pan & Lee, 2003).

While variance research serves the purpose of identifying factors and explaining the direct effect of each factor on IS success, it is limited in showing interactions among the factors and the process of IS implementation (Markus & Robey 1988). IS implementation has been characterized as an ongoing process which includes the entire development of the system from the original suggestion through the feasibility study, systems analysis and design, programming, training, conversion, and installation of the systems (Lucas, 1981). It can be understood as a social action that develops a system through the social interactions of multiple actors within several related social environments rather than a mere technical process (Butler & Fitzgerald, 1999; Hirschheim et al., 1991). It has been argued that IS implementation is inherently a dynamic phenomenon; the state of a given factor can change or be changed in the course of the implementation process, and no snapshot view can possibly represent the entire process (Ginzberg, 1978). Understanding the implementation of IS thus requires consideration of a variety of factors and the interrelationships among them over time (Markus & Robey, 1988; Mohr, 1982).

However, the dynamics of CSF interactions, and how it leads to success remain unclear (Williams & Ramaprasad, 1996). In particular, the process by which IS are developed is not well understood (Myers, 1995), and further research is required on the relationship between the process of systems development and the consequences of that process (Orlikowski & Robey, 1991). The situation is analogous to cooking with a list of ingredients but without the recipe (Sabherwa! & Robey, 1993). One approach to the problem is to develop a process model (Markus & Robey, 1988; Van de Ven, 1992). The process approach allows us to examine implementation behaviors, and to determine patterns which are particularly effective or ineffective in achieving successful implementation. However, despite the usefulness of process theory, little research has been done to explore the process of IS implementation and its linkage to the consequences.

In this paper, we posit that a process perspective provides a platform for various interpretations of IS implementation activities and allows alternative paths and corrective actions to be taken in the pursuit of successful outcomes (Robey & Newman, 1996). Specifically, we examine the implementation process of Customer Relationship Management (CRM) systems. CRM is a long-term business strategy that enhances customer relationships based on the collection and analysis of customer information across all interaction channels. The popularity of CRM as a business strategy has been growing in recent years, and it is now considered the way forward for any business wishing to thrive in electronic business. A CRM system embodies the concept of CRM. In a CRM system, the approach is to combine strategy, process and technology to manage relationships with customers. We pose two research questions:

* How do various factors interact in IS implementation?

* How and why do interactions between factors lead to certain outcomes in IS implementation?

The remainder of this paper is structured as follows. We review the literature on process theory next. We then provide details of three CRM initiatives, followed by a process analysis and discussion of the initiatives. We conclude the paper with implications for future studies.

Process Theory

Theories can be classified, based on their logical structure, as variance theory or process theory (Markus & Robey, 1988; Mohr, 1982). Variance theory tries to explain variation in a dependent variable by studying its association with one or more independent variables. In contrast, process theory attempts to explain an outcome by identifying the sequence of events or states that precede it.

CSF research is a typical example of variance research. CSFs have received considerable attention since Rockart (1979) used the term 1CSF' in determining the key information needs of top executives. Rockart (1979) defined CSFs as "the limited number of areas in which results, if they are satisfactory, will ensure successful competitive performance for the organization" (p. 85). In a more recent study, CSFs are described as "being necessary and sufficient for success: each factor is necessary, and the set of factors are sufficient" (Williams & Ramaprasad, 1996, p. 251). According to Williams and Ramaprasad (1996), an individual factor may be identified as critical because it is frequently associated or highly correlated with success. From these two comments, it is apparent that any understanding of how CSFs lead to IS success requires that CSFs be considered as a set. However, little is known about how CSFs are interrelated and how they can sufficiently lead to successful consequences. Commenting on the knowledge gap, Shaw and Jarvenpaa (1997) posited that processes are more practical because they are easier to visualize than variance relationships are.

Process theory focuses on sequences of events (or states over time) to explain how and why particular outcomes are reached (Mohr, 1982). Three meanings of the term 'process' have been articulated (Van de Ven, 1992): (i) a sequence of events that describes how things change over time; (ii) a category of concepts or variables that refers to actions of individuals or organizations; and (iii) a logic that explains a causal relationship between independent and dependent variables. Depending on the terminology used, a theory of process consists of statements that explain how and why a process unfolds over time. Thus, a process model, the resulting "pictures of the processes", reveals a detailed story about the changes taking place within a target situation by explaining how objects interact, how they collectively lead to future courses of action, and the perceived constraints on their collective action (Newman & Robey, 1992; Robey & Newman, 1996). In this way, a process model complements the predictions provided for by a variance model.

Previous research on process theory in IS can be classified into three main groups, depending on the meaning of process adopted and the analytical approach taken. As Table 1 illustrates, the three groups are: (i) a process model based on sequences of events; (ii) a process model based on structuration theory; and (iii) a process model based on cognitive mapping.

In the first group, process is identified and analyzed based on the sequence of events (Abbott, 1990; Newman & Robey, 1992; Robey & Newman, 1996; Sabherwal & Robey, 1993). Events refer to instances of social action relating to the IS implementation (Hirschhein et al., 1991). The research in this group proposes a sequential (single linear) process model. This approach is useful in tracking one issue over time. However, a single linear sequential model is usually inadequate in dealing with the complexities of real-world situations (Van de Ven, 1992) because different events and multiple situations can occur simultaneously and affect each other concurrently. Thus, this type of research has its limitations in analyzing and explaining simultaneous relationships among multiple factors.

In the second group of process theory research, the process between institutional properties and human agents related to IS development is analyzed based on structuration theory (Jones & Nandhakumar, 1993; Orlikowski, 1992; 1993; 1996). Structuration theory (Giddens, 1979) posits that actors draw from established social relationships and reconstitute these relationships through their actions. Structuration is understood as a social process that involves the reciprocal interaction of human actors and structural features of the organization in the development and use of IS. Research in this group analyzes social processes in terms of interactions between organizational structure and actions of human agents. Simultaneous processes are taken into account and analyzed in terms of IS development within an organization (Jones & Nandhakumar, 1993; Orlikowski, 1992).

However, the separation of structure and action for the analysis of process is considered artificial and mainly an analytical convenience (Jones & Nandhakumar, 1993: Orlikowski & Robey, 1991). Structure and action are, in practice, intimately linked. The process model derived from structuration theory also presents too many iterative relationships between structure and action, especially in detailed case analysis.

In the third group of process theory research, process is analyzed by identifying influential relationships among factors (i.e., activities, events and states) using the cognitive mapping approach (Abdel-Hamid & Madnick, 1989; Akkerman & Helden, 2002; Butler & Fitzgerald, 1999; Monge, 1990). Cognitive mapping seeks out influential relationships among factors based on the cognitive understandings of interviewees and researchers. A cognitive map consists of a set of influential processes among multiple factors. It enables an understanding of simultaneous influential relationships among multiple factors over time. This approach involves no artificial separation of dimensions, unlike the structuration analysis approach. However, because of the multiple influences, a cognitive map can easily become complex with only a few factors. This is especially so if each influential link between any two factors is of positive or negative polarity.

Against this background, and with a view to understanding how interrelated CSFs can lead to various consequences of IS implementation, we aim to analyze relationships among critical factors and how they lead to certain consequences in the context of CRM systems development.

Research Methodology

A lack of existing empirically based models on the process of IS implementation, especially in CRM, prompts us to adopt a qualitative multiple case study approach (Yin, 1984; Klein & Myers, 1999). We select three cases to provide examples of polar types: one on successful implementation and two on failure. In our selection, we consider three common characteristics across the cases: (i) similar business context; (ii) similar scope of CRM systems involved (in terms of the extent of company-wide implementation across sales, service and marketing); and (iii) similar life cycle type in the development process. We draw our cases from the service industry because this sector, particularly the financial industry, has taken the lead in CRM implementation (Codington & Wilson, 1994), and because transactions in the industry are essentially based on information technology (IT). The firms that we examine therefore already hold a wealth of information about individual customers. Table 2 summarizes the profiles of the three selected cases.

Retrospective data were collected from interviews with informed employees. Table 3 describes the respondents in each case. Semi-structured personal and group interviews were conducted from November 2001 to June 2002. However, validation of the findings with informal interviews continued until June 2003.

The average time for each semi-structured interview was about 30 minutes for executives, one hour for managers, two hours for CRM project managers, one hour for project participants and vendors, and about 30 minutes for users. In addition to interviews, other data sources included system demonstrations and archival data in the form of reports and presentation documents. As part of data analysis, the main themes discovered from the analysis were presented to the informants for verification and validation.

An understanding of the implementation process can be achieved only by delineating the network of causal relationships among CSFs (Butler & Fitzgerald, 1999).

Thus, it is necessary to understand a complex IS implementation process in terms of preconceptions about meanings of its parts and their relationships. In viewing process as influential sequences among implementation factors, we adopt influence diagrams (Diffenbach, 1982) to represent influential relationships among factors in graphical form. In each relationship between two factors, the influences of external factors on the factors are assumed to be constant. However, not all factors are judged to be equally important, so the process model focuses only on those that are critical to the trajectory of the IS implementation project (Robey & Newman, 1996).

To enhance clarity of the diagrams, we designate each factor in terms of its positive or negative direction, rather than indicating the polarity of each link. Such influence diagrams can be created based on the cognitive and intuitive thought processes of researchers during the case study. The diagrams do not indicate either the magnitude or timing of influence relationships. An influence of A on B could be strong or weak, continuous or intermittent, and could produce an immediate or delayed effect of A on B. The diagrams simply depict influential links between factors. This limited interpretation can still be a valuable and inexpensive aid for comprehending a complex situation. It facilitates linking pieces into a whole picture, and interpreting the influence of any one factor on others. This in turn facilitates an understanding of the chain of events that link the factors to success, and the laws governing them.

Case Studies

H-Bank

With the introduction of the CRM concept in the late 1990s, H-Bank perceived the need for coherent customer management across different functions and channels, and even across different information systems. Several teams with roles in customer relations (including the marketing team, the sales team, the call center, and the IT team) individually became CRM-ready with diverse CRM requirements. These developments became the basis for the overall CRM project implementation. The implementation project was carried out between October 2000 and January 2002. The company adopted a hybrid development approach - in-house development for operational CRM and package implementation for analytical CRM and Data Warehousing (DW).

We analyze the influential relationships among critical factors and consequences at ?-Bank, and summarize them in the influence diagram given in Figure 1. Organizational commitment to the project was strong: the chief executive officer (CEO) initiated and proactively supported the project; the chief information officer (CIO) explained:

"After visiting some banks and IS consulting companies in Europe, the CEO became convinced that CRM was essential for the company to remain competitive in the financial industry. Soon after that, he instructed the marketing and IT departments to implement a CRM system."

The CEO invested huge resources in the project. His championing role also meant strong management support for the project from the beginning, and high user participation.

In project management, a cross-functional team comprising members from the business and IT departments enabled the management of diverse requirements across different functions. The bank also invested financial resources in commissioning a consulting firm and systems development companies for the project. This resulted in rapid enhancement of project team skills. Thus, the project team had high and balanced skills in both IT and business to undertake the project.

The cross-functional project team interviewed executives and managers to analyze their strategic requirements. The team also interviewed users in the business and IT teams to collect functional and technical requirements for the CRM process. The information gathered covered the diverse requirements of the bank: from customer creation, to customer retention and development, and spanned the service, marketing and sales departments. With the data, the project team devised clear CRM strategies and a new CRM process for the bank. Prior to the development of the CRM system, the business process in the bank had already been redesigned into a customer-oriented model. However, there was no workflow supporting system for the redesigned process. Therefore, an integrated campaign process was developed with information feedback from service, marketing and sales. The new CRM process was then implemented with the development of the workflow management system and the CRM system.

In technology, the project team had sufficient technical skills. This facilitated effective design of the target system based on the business requirements of the CRM process and the IT requirements obtained from analysis. Effective design of the target IS became a basis for the efficient realization of the target CRM system. Here, IS realization includes the developing, testing and installing activities for the new system (Swanson, 1988). However, developing the new CRM system was not easy because of the fragmented source systems and redundant customer DBs.

The project team had to integrate the fragmented systems. The work covered source systems integration, channel integration, and integration between the new system and the legacy system. In source systems integration, differences in data attributes among redundant customer DBs had to be corrected. Fragmented channels were also integrated across branches, the call center, the relationship manager (RM), and private bankers (PB). With the integration work, effective functions and high performance of the CRM system were ensured.

The project team offered training sessions to users in the business and IT departments as part of change management. The training sessions were organized according to the various roles and tasks of users. For example, operational CRM sessions were held for sales and service teams (including branches and the call center) whereas analytical CRM sessions were held for marketing and IT teams. Because there were changes not only in IS but also in the processes for CRM, the training sessions covered technical issues as well as business and process issues. At least one representative from each branch participated in these training sessions, and all 550 branches participated in the sessions. Each session took four full days. One system user described the training he received:

"I came to know the concept of CRM and its necessity. And I learned the new process and new system functions for CRM. When I returned to my team, I offered the same training to my team members and helped them understand and adapt to the new process and system."

The IS manager said IS quality in the bank improved because of the CRM implementation:

"The new CRM system has useful system functions and it shows quick response time and flexibility to diverse requirements."

There was consensus among users and other interviewees that the CRM system enabled better understanding of each customer. One CRM system user said:

"The new system is very useful for customer consultation. For example, it provides me with a customer's interaction history, status of previous request, and individual characteristics. Also, it gives us some consultation tips and fresh sales opportunities about each customer. This information is valuable for customer consultation."

The users also felt that the CRM system was useful for diverse information analyses and campaign design. One user in the marketing team commented:

"Now we can analyze diverse aspects of customer transactions ourselves, using the new system. This enables us to find new insights for campaign design. Before the new system was developed, we had to ask the IT team to perform data analysis. That was very ineffective and inefficient."

H-Bank managed to achieve both individual and organizational benefits from the project. The project team implemented a closed CRM process with a workflow management system across the sales, marketing and service areas. The new CRM process resulted in better customer service. In particular, it improved service quality in terms of responsiveness, assurance and empathy. From the perspective of internal users, the new process facilitated cooperation across functional areas and enhanced efficiency and consistency. The manager of the CRM team, a subunit of the marketing department, said:

"Previously, customers had to visit a branch to apply for loans, consult tellers, and get approvals for their loan applications. Now, customers can now start loan processes at the call center, consult the bank at the call center or by RM or PB, and complete their applications at a branch because all teams share a single customer DB and use the CRM application. Internally, our departments have become more cooperative because of the information feedback on customer service and sales. The business process across several teams has become more efficient. The internal cycle time of loan process has shortened by about twothirds."

H-Bank measures customer satisfaction four times a year. Before the project in 2000, customer satisfaction score was between 77.4 and 78.0. It rose to 82.8 in June 2003, after the CRM system was implemented. Loan customers were particularly more satisfied because tellers and telemarketers whom they had to consult were now equipped with ready information from the CRM system. The loan application process was also redesigned for better efficiency.

Thus, the efficient realization of the CRM system, the CRM processes, and the smooth adaptation of users to new processes and IS through change management have all been effective in achieving successful results for H-Bank.

L-Capital

The main business activities of L-Capital are consumer credit card financial services, including cash advances, loans, and international finance. Because of the huge number of its customers, it was not easy for L-capital to manage its active and inactive cardholders. The main reasons for L-Capital implementing a CRM system were to activate inactive cardholders and provide more customized service and marketing to existing customers. The CRM project, consisting of an operational CRM system and an analytical CRM system, was implemented between June 2001 and March 2002. The company adopted a CRM package solution.

We analyze the relationships among the critical factors at L-capital and illustrate them in Figure 2.

With regard to organizational commitment, the CEO decided to implement an IS for CRM based on the proposal from the IT department. Because the CEO and other executives had perceived the importance of CRM to their business, they were willing to allocate huge budgetary resources to the project relative to other systems development projects.

However, the CEO was unable to sustain his commitment to the project. The IT department then tried to obtain commitment to the project from other business executives and managers. However, the project failed to attract support from the senior management. An IS manager recalled:

"The project was perceived by business department managers as a typical systems development project of the IT department."

In project management, L-Capital outsourced the CRM project from the strategy development stage through to system implementation. The company invested financial resources to commission a consulting firm and two systems development companies for the project. The project team consisted mainly of staff members from the company's IT department (who were not very familiar with the adopted CRM technology) and outside system vendors (who had little business knowledge of the credit card industry). The project team thus had IT-oriented skills but low business skills. At the request of the project team, users from business departments were invited to participate in the project. However, the low support of the business management meant that business users were not motivated to contribute actively to the project. The manager of a systems development company which participated in the project recalled:

"The problem was that participants from business departments hesitated to decide on their requirements and confirm system design."

The project team also had difficulty managing the project and coordinating sub-project teams. The project manager observed:

"Because four different companies joined the project, even communication within the project team was not easy."

With regard to CRM strategy and process, the adopted CRM package incorporated best practices in CRM strategies and processes. The project team proposed CRM strategies and processes to business managers and users based on the best practices of the adopted CRM package and the accumulated knowledge of the consulting firm. However, the project team could not obtain consensus from among the business departments on what they would really like to have in the CRM system. One business manager who participated in the decision on CRM requirements said:

"It was difficult for business departments to decide on CRM direction and requirements. Most business managers and users were not ready to decide on them clearly."

The manager of a systems development company vendor which participated in the project recalled:

"The managers and users of the business departments kept changing their requirements. For this reason, system implementation was delayed."

Because of these difficulties, the project team could not make a definite decision on CRM strategies and processes at the initial stages of the project. The project team also had to customize the best practices of CRM processes to the L-Capital situation based on the business requirements which changed frequently. In the end, the project team focused on the current business process with the implementation of a workflow management system, rather than designing and implementing new CRM processes.

With respect to technological factors, effective design of the target system was hindered by unbalanced project team skills and by frequent changes in requirements and unclear project direction and scope. IS realization was similarly made difficult. Moreover, the project was the first application of the adopted package in the credit card industry, and required significant customization. However, the project team lacked the technical expertise needed for the task.

The project team developed several CRM functions based on the ineffective design; system functions suffered as a result. The manager of a systems development company which participated in the project noted:

"Although the project was to implement both analytical CRM and operational CRM, we developed only the operational CRM."

The systems integration aspect of IS realization fared better. The adopted CRM package had high compatibility with the existing systems. The project team also had sufficient IT skills to integrate redundant customer DBs. However, only two channels (branches and the call center) were integrated into the system, although there were three additional channels (the Internet, direct mail, and allied stores). A project team member noted:

"The real difficulty in this project was managing project direction and scope. We had to put in more effort to manage user requirements and communicate with business departments, rather than focusing on effective system design and successful implementation. Actually, our critical concerns were managing project direction and user requirements rather than technical concerns such as channel integration."

The project team offered training sessions to users at the branches and the call center. Each session lasted a full day. Because there was less change in business processes for CRM, and few analytical functions compared with operational functions, it was easy for users to become used to the new system.

Summing up the consequences of IS implementation at L-Capital, we can see that IS quality was characterized by low flexibility and low performance. This was a result of ineffective system design and incomplete channel integration, which may in turn be traced to problems in gathering and deciding user requirements. While the information quality afforded by the system was acceptable as redundant customer DBs were integrated during system implementation, it was not enough to salvage the overall low system quality. Users were clearly not satisfied with the system; one commented:

"The system does not support all the functions we need. Following system implementation, we requested some additional functions to be developed. But the IT department told us it would take some time."

As a change management program, the training sessions could not entirely ease user resistance against adoption of the new system. In fact, it became clear to users at the training sessions that the new system lacked functionality.

As for the CRM process, the project team failed to implement integrated campaign processes or closed CRM processes across sales, marketing and service. There was almost no change in process except for the implementation of a workflow management system for current business processes. The workflow system enhanced cooperation across teams but made little difference to the effectiveness of the process for CRM.

The case of L-Capital thus showed low level of IS quality, implementation of no CRM process, and ineffective change management. The results were less than successful.

P.net

P.net, established in 1999, is a typical infomediary online company. It provides various services to customers, including economic data gathering, investment strategies formulation, and advice on stock trading prices. Although P.net had many registered customers and a huge number of customers visiting its website, the company had no specific marketing system. The company therefore decided to develop a CRM system to enhance its earnings by providing a customized chargeable service. The CRM project took place between September 2000 and August 2001. The company developed the CRM system in-house and implemented a package for DW.

We analyze the relationships among critical factors and their consequences at P.net, and illustrate them in Figure 3. With regard to organizational commitment, the CEO decided to develop the CRM system in early 2000 and took on the role of project champion. Considering the size of P.net, a very large budget was assigned to the project. However, the CEO relinquished his role as champion soon after the project started. The manager of the IS team recalled:

"The CEO decided to develop a CRM system, and recruited some CRM experts. But they were marketing personnel rather than IT experts. They formed a CRM team which was a sub-unit of the marketing department. The CEO then delegated all responsibilities of systems development to the CRM team."

The absence of a champion meant that the management did not fully support the project. In addition, it was difficult for the newly recruited CRM project team to gain support across business and IT teams. User interest was also low; user involvement was passive observation rather than active participation. One business manager said:

"At the beginning of the project, we were not familiar with CRM. The CRM team members were known as CRM experts. So we trusted them with the CRM development."

In project management, the project team lacked the necessary skills as its members were marketing experts noted for their high business skills but not project management expertise. Exacerbating the problem, the project team did not clearly understand the characteristics of P.net's business. The project team also lacked the technical skills required for the development of a CRM system. Instead, it had to commission an outside systems development company for the task. As it turned out, the systems development company also had little experience in developing CRM systems because CRM systems were a new concept at that time. Management of project direction, scope, business needs and IT requirements floundered.

With regard to CRM process, the company had very simple but integrated processes at the beginning of the project. A manager in the IS team noted:

"Most employees knew the whole processes across the company. The processes were connected across teams by a single application system and a single DB."

The project team developed CRM strategies and CRM processes based on what it knew rather than on business requirements or IT management and user needs. The manager of the systems development company which participated in the project recalled:

"Since the CRM team was new in P.net, it did not know who the key informants were in the company, and had no informal networks there. It came to depend on itself and defined the requirements of CRM strategies and processes on its own. It could not get a consensus from other teams regarding the strategies and processes."

With respect to technology, the project team was handicapped by its low technical skills and inadequate understanding of the legacy systems. Working on its own to define system requirements, it failed to incorporate the IT requirements of P.net in the design. This resulted in deviation from the main project objective. As a user in the customer service team indicated, the aim should have been:

"How to implement individualized and value-added services for customers over the Internet through the new information system."

The work to be done was not as complex as other examples of CRM systems development: the legacy systems were already integrated and there was only one standardized customer DB; the two channels in use-the Internet and the call center-were already integrated as they shared a single DB and a common application system. Yet the project team developed two sub-systems, a customer management system and a DW system, which failed to function well. The IS manager commented:

"The project team did not perceive the importance of compatibility between the newly developed system and the legacy systems. Lack of compatibility resulted in several problems such as inflexibility and low responsiveness."

Regarding change, none in process was made through the CRM project, although customer information management and customer information and transaction analysis were done with the newly developed system. The project team offered system training sessions to business team users as part of change management. Each session was several hours long.

Turning to consequences of IS implementation, the overall IS quality achieved was low. In terms of response time and information quality, the CRM system yielded acceptable results. However, these were not enough to offset inadequacies in other quality aspects. The manager of the IT team gave this assessment of the system:

"The new system has so many problems and limitations. It lacks flexibility while our business requires a speedy and flexible information system. The main reason is that it is not fully integrated with the legacy systems. The newly developed OLAP (online analytical processing) functions for information retrieval were also very limited."

In terms of user satisfaction, users in the business and IT teams all agreed they were dissatisfied with the new system. A user in marketing said:

"The analytical functions were very limited and they were not enough for our marketing analysis and design."

The training sessions could not enhance users' acceptance of the new system because of the low quality of the new system. In particular, the new system had different user interfaces and required different data processing procedures compared with the existing systems. These factors increased resistance to the new system.

With respect to CRM process, P.net did not implement the CRM processes designed by the project team. There was no change in campaign process or closed-loop CRM process across functional areas. For this reason, no benefits resulted from any CRM process and use of the newly developed system.

In summary, the CRM system was unsatisfactory, and no CRM process and inadequate change management accompanied its implementation. The manager of the IT team made this final assessment of the project:

"Now all members of the CRM team have left our company. The company is now considering developing a new CRM system afresh."

Cross-Case Analysis

From the case studies, we identify 10 common factors and interactions. We compare the successful case at H-Bank against the unsuccessful cases at L-Capital and P.net (see Table 4).

In organization commitment, we can see that high management support was influenced by 'champion continuity' while low management support resulted from discontinuity of commitment. Resource investment was influenced by champion commitment in all three cases, regardless of whether the project enjoyed continued champion support. High user participation was influenced by strong management support; conversely, weak management support contributed to low user participation.

In project management, balanced management of business and IT requirements was influenced by strong management support, a high level of user participation, and balanced high skills in the project team. Balanced high business and IT skills in the project team were influenced by human resource investment, a cross-functional project team, and the hiring of consulting firms and systems development companies with the investment of the necessary financial resources. Management of changes in process, system and people was influenced by skills of the project team.

In CRM process, the design and implementation of effective CRM processes was influenced by requirements management. The lack of a specific CRM process in the two unsuccessful cases was influenced by unbalanced and poor management of requirements.

With respect to technology, effective system designwas influenced by a clear CRM process, an understanding of diverse requirements, and high skills in the project team. IS realization was influenced by design of the target system and project team skills. A skilful project team could efficiently realize the target system with high functionality based on effective IS design in the successful case. In the L-Capital case, the project team driven by IT personnel produced highly integrated systems whereas in the P.net case, the project team driven by business personnel produced low system integration. However, L-Capital had difficulties in customizing the CRM system because of the lack of skills in the project team as well as ineffective design. The P.net case also showed problems in realizing the target system, leading to issues such as low systems integration because of lack of technical skills in the project team and ineffective system design.

With respect to consequences, high IS quality was influenced by highly integrated systems and high system functionality. High system use was influenced by high IS quality and effective change management. Low system use was influenced mainly by low IS quality. Individual and organizational impact in the successful case was influenced by high IS quality and effective CRM processes. In the two unsuccessful cases, the company gained few benefits from the project, which was influenced by low IS quality and no implementation of any CRM processes.

Discussion

Process Model of IS Implementation

Based on the identified factors and the set of influential relationships among the factors, we develop a process model of IS implementation for CRM. Figure 4 illustrates. As the main components of the process model, we propose 17 statements based on the identified influential relationships.

We consider the process within the dimension of organizational commitment, and propose the first statement: (1) Champion continuity influences resource investment. One of the project champion's roles is to provide funding and resources to the project (Beath, 1991; Benjamin & Levinson, 1993). Resources include the money, time and people required to implement the desired system successfully. Reich and Benbasat (1990) stressed the importance of degree of champion continuity in achieving success with a customer-oriented strategic system. Our case studies reveal that champion continuity enable companies to invest sufficient financial and human resources in projects.

We also propose: (2) Champion continuity influences management support for a project. One of the project champion's roles is to bring the project to successful resolution by influencing critical stakeholders (Beath, 1991; Benjamin & Levinson, 1993). Indeed, leadership and influence are noted as the most important requirements for champions (Howell & Higgins, 1990). Champion discontinuities in the two unsuccessful cases led to a lack of management support for the project while champion continuity in the successful case promoted management support.

Our next proposition is: (3) Management support influences user participation in a project. Users can be selected and assigned to a project only by the management.

In the two unsuccessful cases, lack of management support led to users failing to participate in the project while high management support encouraged users to participate in the project in the successful case.

For the process from the dimension of organizational commitment to that of project management, we propose: (4) Resource investment influences project team skills. Project team skills refer to the technical, interpersonal and managerial abilities of the project team (Wixom & Watson, 2001). In all three cases, financial resources were committed to engage

outside consulting firms and/or systems development companies in the project, resulting in rapid enhancement of project team skills. However, the investment of both financial and human resources is required for enhancing overall project team skills as in the case of H-Bank.

We also propose: (5) User participation influences requirements management, especially with respect to CRM processes and functions. Requirements management refers to ascertaining the business and IT requirements of the management and users. Without user participation in the project, it is not easy to ascertain diverse requirements with any accuracy, as the two unsuccessful cases show. The successful case reveals that it is important for users from business and IT teams to participate in the project, and for the project team to be able to collect and manage diverse requirements across the business and IT areas.

Our next proposition is: (6) Management support influences requirements management, especially with respect to the direction and strategies of CRM. CRM strategies need to be developed based on management consensus across various CRM areas (including sales, service and marketing). In the two unsuccessful cases, no management support was forged, and the project teams could not gather and manage requirements regarding CRM strategies.

For the process within the dimension of project management, we propose: (7) Project team skills influence requirements management. Even when users are involved with management support, poor specification of IS project (i.e., user needs and project scope) can result if the project team fails to adequately analyze user requirements and the organizational environment in which the system is to be used (Keil et al., 2003). The project team could manage both business and IT requirements only if it possesses a high level of skills in both business and IT as in the case of H-Bank.

For the process from the dimension of project management to that of process, we propose: (8) Requirements management influences CRM process development. The two unsuccessful cases show that the failure of the project team in gaining consensus from the management on the direction and strategies of CRM and other process related requirements hinders the development of effective CRM processes.

For the process from the dimension of process to that of technology, we propose: (9) The CRM process influences system design. The CRM process defines a sequence of activities across functional areas and CRM functions. In the two unsuccessful cases, unclear CRM processes hindered effective system design.

For the process from the dimension of project management to that of technology, we propose: (10) Requirements management influences system design. The strategy related requirements of the management and the process related requirements of users are reflected in system design through the development of CRM strategies and processes. Technical requirements from users should also be reflected in system design.

Our next proposition is: (11) Project team skills influence IS design. Management of user requirements regarding strategy, process, functions and technology does not guarantee effective system design. The project team should have a high level of IT skills to reflect those requirements in system design as in the case of H-bank.

For the process within the technology dimension, we propose: (12) /S design influences IS realization. IS realization includes developing, testing and installing activities for new IS (Swanson, 1988). Technological considerations are reflected in system design, and the design then affects IS realization such as systems integration. The two unsuccessful cases exhibit problems in realizing effective system functions because of the low quality of IS design.

We propose: (13) Project team skills also influence IS realization. IS realization includes several development activities such as programming of the new system. High quality in IS design alone does not guarantee IS realization. The project team should have the technical expertise and skills in realizing the IS design into a high quality information system.

For the process within the dimension of project management, we propose: (14) Project team skills influence change management. Change management refers to a process whereby organizations and employees meet new performance targets rapidly and effectively with the adoption of new IS (Worren et al., 1999). This is not confined to CRM projects; every IS project needs a process to manage changes as part of project management (Schmidt et al., 2001). The highly skilled project team in the successful case managed changes in strategy, processes and system by offering training sessions to users.

For the process from the dimension of technology to that of consequences, we propose: (15) IS realization influences IS quality. Even when IS design is effective, low IS quality can result if the project team fails to realize the target IS effectively. IS quality consists of information quality and system quality (DeLone & McLean, 1992; 2001). In the two unsuccessful cases, useful functions failed to develop, thus undermining system quality. It is known that an information system displaying high information quality and high system quality leads to user satisfaction and high use (DeLone & McLean, 1992; 2001; Rai et al., 2002; Seddon, 1997).

For the process from the dimension of project management to that of consequences, we propose: (16) Change management influences use of the new system. It has been argued that motivating employees through change management has an effect on achieving the goals of CRM (Rigby, 2002). In the successful case, the project team was able to lower users' resistance to the new strategy, processes and CRM system through change management.

For the process from the dimension of process to that of consequences, we propose: (17) The CRM process affects the achievement of individual and organization benefits from IS implementation. A CRM process requires the redesigning of existing business processes or the development of a new process for CRM. The new CRM process in H-Bank resulted in several benefits for the company, such as enhanced cooperation and information feedback between teams, shorter processing time across teams, and better customer satisfaction. It is known that user satisfaction and high system use enhance net benefits (DeLone & McLean, 1992; 2001; Rai et al., 2002; Seddon, 1997).

Implications for Theory

This research is of several academic implications. First, it demonstrates how process theory can be applied in examining IS implementation and how process-based research can complement the findings of variance-based research. Most previous research based on variance theory has focused on identifying and validating individual factors. In line with this, the concept of CSFs has been applied in a variety of settings for more than two decades (Desai et al., 1998; Guimares et al., 1992; Reich & Benbasat, 1990; Wixom & Watson, 2001). However, there has been a paucity of theory on how CSFs affect each other and how CSFs as a set of interrelated factors lead to consequences. Adopting process analysis, we have explained how and why critical factors affect each other and how the interactions among them lead to the consequences of IS implementation; the findings are not easily achieved with the variance research approach.

Second, it has been argued that the process by which information systems are implemented is not well understood (Myers, 1995; Orlikowski & Robey, 1991), especially in the context of several related social environments (Butler & Fitzgerald, 1999). Although it has been argued that the different factors in the social and technical dimensions affect each other and that the correlations between them are of potential effects on the results of IS implementation (Bostrom & Heinen, 1977), there has been little research to explain explicitly how they are related, and how and why they lead to IS success or failure. The present research contributes to filling this gap in the extant research by developing the process model of IS implementation. The proposed process model explains what factors are associated with CRM implementation, as well as how and why the factors influence each other. The model also explains how the relationships lead to certain outcomes in CRM implementation.

An understanding of the sequential influential patterns in IS implementation can also serve as a platform for other interpretations (Robey & Newman, 1996). Thus, the proposed process model provides a theoretical structure for future research. In particular, future research could examine the sub-processes of IS realization and change management. While most other factors in the developed process model have been examined in previous variance research, little is known about IS realization and change management (i.e., key activities, sequence of activities, critical factors, and relevant impacts). Since both IS realization and change management are the last stage of IS implementation, they exert direct effects on IS quality and use. Further study on these could make good contributions to the IS literature and IS implementation projects.

The developed process model can be compared with previous research on process theory. As discussed in the theoretical background section, previous research on process theory in IS can be classified into three main groups: (i) a process model based on sequences of events; (ii) a process model based on structuration theory; and (iii) a process model based on cognitive mapping. The process models in the first group focus on a single linear sequential relationship. The process models in the second group separate structure and action for the analysis of process, and the separation has been noted to be artificial and an analytical convenience (Jones & Nandhakumar, 1993: Orlikowski & Robey, 1991). Our process model, belonging to the third group, has its advantages in analyzing and explaining simultaneous relationships among multiple factors without the forced separation of factors. Compared to other process models in the third group, ours is the first attempt in examining the process of IS implementation.

implications for Practice

This research is also of practical implications. In project planning, if an information system is to be successful, the influential sequence among implementation factors in the process should be considered, regardless of each factor's individual criticality and its direct or indirect effect on outcomes. The case of L-Capital is a typical example of such a sequence. The project faced serious problems in managing project direction and scope, and in defining user requirements with respect to CRM strategy and processes. This indicates that project management issues and process issues were the problem rather than technology issues.

The process model also reveals the importance of champion continuity, rather than just the presence of a champion at the beginning stage of a project. The successful case shows a champion who provided sustained strong leadership and ensured financial and human resources to the project. The sustained role of the champion also encouraged high management support and high user participation in the project. In the unsuccessful cases, the champion provided funding to the project, but then left the scene after the project started. The three case studies demonstrate that for an IS implementation project to succeed, it needs continuity of champion activity, and strong leadership and influence from the champion till project completion.

The sequence revealed in our proposed process model also shows the relative importance of CRM strategy and process over technology. Technology is a powerful facilitator of CRM but it is not an overriding factor. Many firms make the mistake of equating CRM technology with marketing strategy and an application system (Rigby et al., 2002). From the analyses we have presented, it is apparent that customer strategy and process dominate technology factors, not the reverse.

Our proposed process model also demonstrates that project team skills is a core factor in estimating the likely success of the target system. It affects other critical factors, such as requirements management and change management (the project management dimension), the CRM process (the process dimension) through requirements management, and IS design (the technology dimension). A project team should therefore strive for a balance between business-oriented activities and IT-oriented activities. One way of doing so is to ensure cross-functional membership in the team as a successful IS project requires cross-functional operations (Desai et al., 1998; Rigby et al., 2002; Ryals & Knox, 2001). Our analysis also shows that conflict between business and IT departments is a risk factor in IS implementation (Schmidt et al., 2001). For IS success, the management of the implementing organization should assign the best of its skilled members to such a cross-functional project team.

IS implementation requires not only application systems development but also business process changes, especially in enterprise systems. Enterprise systems require the restructuring of an organization's portfolio of transaction-processing application systems to achieve integration of business processes, systems and information (Markus & Tanis, 2000). Thus, IS implementation requires changes not only in systems but also in process and other social dimensions. One of the problems of large-scale IS implementation is resistance from people who are unprepared for the changes associated with the implementation of new technology (Davenport, 2000). To ensure successful consequences of IS implementation, the management of the implementing organization should put effort into change management, which directly impacts user satisfaction and IS use.

Conclusions

By adopting process theory, this study has extracted common factors and their interactions which are associated with the outcomes of IS implementation in three CRM cases. We have developed a process model of IS implementation, which is the main contribution of this study. The process model explains how and why a set of related factors influence each other and lead to certain outcomes over time in IS implementation. These results complement the findings of variance-based research. Our examination of the proposed process model has revealed a predictive capability for the IS implementation process. One change in any factor in the process model would set off ripples through all other related factors, thus affecting the outcomes of IS implementation. At any point in the course of an IS project, alternative paths or corrective actions can be taken. This study facilitates an understanding of how to reverse repeating patterns of IS failure. It also can be used to guide new IS implementation projects. Thus, the process model, as a pattern in IS implementation, can be translated into development strategies and tactics which organizations and developers can employ to improve the chances of success in their projects.