Sie sind auf Seite 1von 14

Int. J.

Production Economics 75 (2002) 8396

Successful implementation of ERP projects: Evidence from two case studies


Jaideep Motwania,*, Dinesh Mirchandanib, Manu Madanc, A. Gunasekarand
Department of Management, Seidman School of Business, Grand Valley State University, 401 W. Fulton, #409C, Grand Rapids, MI 49504, USA b Seidman School of Business, Grand Valley State University, 401 W. Fulton, #456C, Grand Rapids, MI 49504, USA c College of Business and Economics, University of WisconsinWhitewater, 5050 Carlson Hall, Whitewater, WI 53190, USA d Department of Management, University of Massachusetts, North Dartmouth, MA 02747-2300, USA
a

Abstract This research examines what factors facilitate or inhibit the success of ERP projects and what actions can be taken to bring troubled ERP projects under control. It uses a case study methodology grounded in business process change theory to compare a successful ERP implementation with an unsuccessful one. Data was collected by conducting interviews at various levels of the subject organizations and by examining their archived records when available. The study proposes that a cautious, evolutionary, bureaucratic implementation process backed with careful change management, network relationships, and cultural readiness can lead to a successful ERP project implementation as opposed to a revolutionary project scope mandated autocratically by top management without organizational readiness and proper change management. Some actions are also recommended that can help bring troubled ERP projects under control. r 2002 Elsevier Science B.V. All rights reserved.
Keywords: ERP systems; BPC; Project management

1. Introduction It is well known by now that improper implementation of Enterprise Resource Planning (ERP) software projects can cause considerable problems for companies [1]. For instance, Hershey Foods Corporation in 1999 reported a 19% drop in 3rd-quarter prots and a 29% increase in
*Corresponding author. Tel.: +1-61633-67467; fax: +161633-67445. E-mail addresses: motwanij@gvsu.edu (J. Motwani), mirchand@gvsu.edu (D. Mirchandani), madanm@uwwvax.uww.edu (M. Madan), Agunasekaran@umassd.edu (A. Gunasekaran).

inventories over the previous year due to orderprocessing problems caused by its faulty $112 million ERP implementation [2]. The city of Oakland too reported problems of missing or erroneous paychecks generated for city employees by its $21 million ERP project [3]. Miller Industries reported a $3.5 million operating loss in the 4th-quarter of 1999 due to the costs and ineciencies of its ERP system, while WW Grainger Inc. reported a $11 million reduction in operating earnings from its improper ERP implementation [4]. These numbers are startling but what is more a cause of concern is that these reported instances involve the software of all

0925-5273/02/$ - see front matter r 2002 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 5 - 5 2 7 3 ( 0 1 ) 0 0 1 8 3 - 9

84

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

primary ERP vendors. Thus fault cannot be attributed to only one vendor. On the other hand, McKesson HBOC has reported a successful implementation of its $50 million ERP back-oce system that now processes sales orders totaling 1.5 million line items and $100 million of business each day [5], whereas CaseBook Water & Power Technologies, a $30 million manufacturer of water purication systems has seen improvements in materials management, project management, and employee productivity due to its ERP system [6]. Given the large nancial commitment that an ERP project requires and the potential benets it can oer if successfully implemented, it is important to understand what is needed to ensure a successful ERP implementation. Thus, two research questions are central to this paper: (1) What factors facilitate or inhibit the success of ERP projects, and (2) what actions can be taken to bring troubled ERP projects under control? This paper attempts to answer these questions by examining the ERP implementation experiences of two companies one unsuccessful and the other successful. It draws on business process change (BPC) theory [7] as well as escalation theory [8] to identify what could have been done to turn around the rst project, and to explain the success of the second project.

each organizational subsystem and their interactions. Thus, in any examination of BPC outcomes, consideration should be given to (a) the environmental conditions for change and (b) the ability of the organization to manage change in these conditions. Kettinger and Grover [7] have proposed a model that considers both these aspects of BPC management. According to their model, any signicant business process change requires a strategic initiative where top managers act as leaders in dening and communicating a vision of change. The organizational environment, with a ready culture, a willingness to share knowledge, balanced network relationships, and a capacity to learn, should facilitate the implementation of prescribed process management and change management practices. Process and change management practices, along with the change environment, contribute to better business processes and help in securing improved quality of work life, both of which are requisite for customer success and ultimately, in achieving measurable and sustainable competitive performance gains. The individual components of the framework (shown in Fig. 1) are described below and applied to the subsequent case analysis to determine if they facilitate or inhibit the success of ERP projects.

2. Theory Since ERP implementation has come to involve changing the business processes of companies that implement such software [9,10], we felt that business process change theory may prove useful in explaining the outcomes of our case studies. BPC is dened as organizational initiative to design business processes to achieve signicant (breakthrough) improvement in performance (e.g. quality, responsiveness, cost, exibility, satisfaction, shareholder value, and other critical process measures) through changes in the relationships between management, information technology, organizational structure, and people [11,12]. These initiatives may dier in scope from process improvement to radical new process designs depending on the degree of change undertaken in

2.1. Strategic initiatives Process change typically begins with strategic initiatives (often included in the corporate strategic plan) from the senior management team [13]. These could be a reaction to a need or a proactive push to leverage potential opportunities [14]. Evidence also exists that strategic change, and arguably process change, is often incremental, informal, emergent, and is based on learning through small gains [15] versus being revolutionary and radical. According to [16], strategic initiatives can be forced on the organization through mandate (autocratic) or pushed through consensus within existing systems of the organization (bureaucratic). Alternatively, champions of change could emerge to seek out creative ideas and make them tangible [17].

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

85

Fig. 1. Theoretical framework for ERP implementation management (adapted from Kettinger and Grovers model of BPC Management [7].

2.2. Learning capacity The major goal of learning is to provide positive outcomes through eective adaptation to environmental changes and improved eciency in the process of learning [18]. Adaptation involves making appropriate responses to technological changes and learning from other organizations that have achieved the best practices in the industry [19]. Increased eciency can come from learning by doing [20] and accumulation of knowledge through cross-functional interfaces [21]. Such knowledge accumulation is also called declarative knowledge (i.e., a body of organized information) and can facilitate learning in a collective fashion [22]. According to [23], higher level learning occurs when members reect on past learning experiences to discover new strategies for learning (which is also called as deutero learning). Learning can also be brought about by scanning

external information [18]. This can come from organizational employees who constantly review the environment for new developments and opportunities (technology gatekeepers), consultants who span the boundary between the environment and the organization (boundary spanners), and from customers. 2.3. Cultural readiness Organizational culture facilitates (or inhibits) the integration of individual learning with organizational learning by inuencing the organizations ability to learn, share information, and make decisions [24]. According to Guha et al. [18], leadership (top management) support or change agents (e.g., BPC team) may be considered important prerequisites for business process change. Further, [25] distinguishes between organizational cultures that are risk seeking and

86

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

aggressive versus those that are more cautious. Open communication and information sharing can promote a common culture and innovative behavior in the organization. So also can cross-functional training and personnel movement within the organization [18]. 2.4. Information technology leveragibility and knowledge-sharing capability The role of Information Technology (IT) in the business process change project could be either dominant or as an enabler. Evidence suggests that IT led projects often fail to capture the business and human dimensions of processes, and are likely to fail [26]. A case is often made for the sociotechnical design approach which suggests a mutual, bidirectional relationship between IT and the organization [27]. Such an approach recommends synergy between the business, human and IT dimensions of an organization and could be promoted through cross-functional teams. Communication technologies have also been proven to facilitate learning and knowledge development through a process of coordinated interaction among individuals. The ability to share knowledge enhances an organizations tendency to change [28] as transparent data access empowers individuals and knowledge workers to reinforce one anothers expertise. Thus, ITs communication infrastructure and the extent of knowledge sharing can create an environment that facilitates successful business process change. 2.5. Network relationships Research indicates that under most circumstances cooperative, interpersonal and group behavior results in superior performance [29]. However it is possible that competitive controversy within generally competitive groups can result in greater openness, knowledge and understanding [30]. In terms of inter-organizational processes, research indicates the benets of partnering with external suppliers [31]. Organizations that can manage these aspects of competition and cooperation continuously can benet from em-

ployee incentives and controls, as well as instill change more eectively [18]. 2.6. Change management practice Change management involves eectively balancing forces in favor of a change over forces of resistance [32]. Organizations, groups, or individuals resist changes that they perceive threaten them [18]. It has been suggested that corporate transformation require a general dissatisfaction with the status quo by employees who have to change (i.e. a readiness to change), a vision of the future, and a well-managed change process. Revolutionary and evolutionary change theorists propose contrasting tactics for accomplishing change [33] which vary depending on the type of employee involvement, communication about the change, and leadership nature. Thus, the pattern of change (formal versus informal), managements readiness to change (i.e. being committed to it, participative in the process, or resistant to it), scope of change (continuous improvement versus radical change), management of change (alleviation of dissatisfaction, top managements vision for change, well managed process of change, and use of evolutionary versus revolutionary change tactics) are the key constructs in practicing change management [7]. 2.7. Process management practice Process management is dened as a set of concepts and practices aimed at better stewardship of business processes [34]. It combines methodological approaches with human resource management to improve the outcome of BPC [18]. Successful process management uses process measurement (use of process metrics, process information capture, improvement feedback loop, and process audit), tools and techniques (e.g. quality control tools, data ow diagrams, CASE tools, and simulation) and documentation (e.g. process ow chart analysis, shbone and root cause analysis). Evidence also supports the use of team-based structures both for the implementing the project and for designing the new process [18].

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

87

3. Methodology Case study analysis was chosen to investigate two research questions that are central to understanding what makes one ERP implementation successful and another unsuccessful, i.e., (1) (2) What factors facilitate or inhibit the success of ERP projects? and What actions can be taken to bring troubled ERP projects under control?

Two criteria were used to select the sites for the case studies:
*

The sites should use ERP software from the same vendor. The sites should have dierent success experiences in implementing the ERP software.

Two such sites were identied. Both were willing to share information about their ERP implementations but requested condentiality. In the paper they will be referred to as Company A and Company B. Data collection methods included studying archival data and conducting interviews at various levels of the organizations. Literature regarding ERP and BPC projects, including data on company performance, was used as a backdrop to data collection. This approach enhanced the construct validity of the study. Given the exploratory nature of the research, explanation building and pattern matching were used to provide evidence of links between constructs. The qualitative data also provided content and discovery of elements that surround each construct to identify those facilitating and inhibiting factors that lead to ultimately successful or unsuccessful ERP projects. 3.1. Brief background 3.1.1. Company A (pharmaceuticals industry) Company A is one of the nations largest manufacturers of over-the-counter (non-prescription) pharmaceutical and nutritional products for the store brand market. Store brand products are sold by national and regional supermarkets, drugstore and mass merchandise stores under their own labels to advertise with nationally

advertised brands. The companys products include over-the-counter pharmaceuticals such as analgesics, coughs and cold remedies, antacids, laxatives, feminine hygiene, smoking cessation products, vitamins, nutritional supplements and nutritional drinks. Its customers include WalMart, K-Mart, Meijer, Rite-Aid, Albertson and Kroger. Customers have their own custom made labels and some even have additional custom components such as bottles, caps, or dosage droppers. Thus, in total Company A maintains about 30,000 stock keeping units (skus) for its dierent customers. Over the years, Company A has seen substantial growth with net sales now exceeding $900 million. To serve its customers better, the company recently decided to upgrade its inventory management process that ran on an AS/400 system. An ERP solution seemed to be the logical answer, providing the ability to integrate accounting, inventory, production planning and materials management. However, the company under-estimated the overall complexity of the implementation. For the rst quarter of the scal year immediately following the ERP implementation, the company showed a loss from operations of $14,075,000. The complexity of the ERPs inventory management applications necessitated the development of a completely new storage nomenclature system. Bugs in the software complicated the issue further. Finished goods from production were shipped to the logistical center for distribution as normal. However the ERP system was assigning bin locations for products that were either non-existent, already occupied, or could not be found. When orders were to be shipped to the customers, the problem compounded. Warehouse personnel would proceed to a bin location directed by the ERP system and nd the product not there, or a dierent product in its place. Often the wrong product would be shipped by mistake. Customer service touched an all point low. In one instance, a disgruntled customer visited the logistical center looking for Ibuprofen Suspension, a high margin childrens analgesic. Aided by customer service managers, the customer walked isle by isle, row by row searching the seven football eld long logistical center and found his product in the

88

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

wrong bin location. Eventually, a physical inventory was the only way to correct the errors of the ERP implementation. 3.1.2. Company B (footwear industry) Company B is a leading designer, manufacturer, and marketer of a broad line of casual shoes, work footwear, and constructed slippers and moccasins. The company employs approximately 6600 production, oce and sales employees. Products are distributed domestically to over 65,000 department stores, footwear chains, catalogs, specialty retailers, and mass merchant accounts. The products are also distributed worldwide in 134 markets through licensees and distributors. The company sold over 38 million pairs of its footwear in 1999. Prior to the implementation of ERP, the sales, marketing and operations functions of the company ran on an AS/400 system. The system required an extremely long time to complete a task, from shipping an order to entering a production schedule for the factory. To obtain even the most basic information, a 68 hour process was necessary. If a customer placed an order and asked if the inventory was available, customer service representatives would be able to answer the customer only the following day or provide an uninformed answer. The inventory reports would only show current on hand inventory unadjusted for orders already in the system. Promises were made to customers without knowing if the gross available inventory was earmarked for another customer. Production schedules were batched and run through the system each weekend. Thus if a customer placed an order on a Monday and wanted delivery at once, production would not begin for at least a week. The company realized that adding a week or even a few days to the lead time in the highly competitive footwear industry was unacceptable. The drawbacks of the legacy AS/400 system were the driving forces behind the implementation of the ERP system. The company chose to follow a phased implementation process. First the nance and marketing functions were converted to the new system, giving users time to get used to the new system. This was followed by converting the operations function to the ERP system. The

implementation process has been successful and Company B has started to realize the benets of the ERP system.

4. Research ndings This section covers each construct of the research model [7] with summative ndings for each case. Whenever appropriate, respondents statements are quoted to illustrate the construct. Consistent with the research objectives, specic questions were asked concerning each construct. The research ndings are summarized in Table 1. 4.1. Strategic initiatives 4.1.1. Stimuli Both the Companies (A and B) were strategically reactive to the environment and the needs of their customers. Company A realized that it needed a new inventory system to keep track of its more that 30,000 stock keeping units. Company B realized a need to reduce production lead times and to provide real time order information to customers. 4.1.2. Formulation scope Company A formulated and maintained a strategy of revolutionary change from the start. They envisioned a sweeping all-at-once approach of replacing the legacy system with the ERP system. Company B on the other hand started out by implementing the ERP system in only their Marketing and Finance functions on advise from the ERP vendor. They envisioned an incremental, phased approach of introducing the system into the company. 4.1.3. Decision making This construct indicates an important dierence in the top management styles of the two companies. Company As managerial style may be described as autocratic with the top management mandating initiative without taking into consideration the majority sentiment of the company. As one interviewee candidly remarked:

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396 Table 1 Comparison of approaches of Company A and B Construct Strategic Initiatives Stimuli (proactive or reactive) Formulation scope (incremental or revolutionary) Decision making (autocratic, bureaucratic, or champion emergence) Strategy led (from onset, eventually, or not) Learning capacity Adaptation (response to technology change, or learning from others) Improved eciency Declarative knowledge External information use (technology gatekeepers, boundary spanners, or customers) Company As approach Reactive Revolutionary Autocratic Not strategy led Company Bs approach Reactive Incremental Bureaucratic From onset

89

Response to technology change

Response to technology change Learning from others Learning by doing Developed knowledge base Technology gatekeepers Boundary spanners Customers. Deutero

Learning by doing Did not develop knowledge base Boundary spanners Customers

Learning type Cultural readiness Change agents and leadership Risk aversion (aggressive versus cautious) Open communications Cross-training IT leveragibility and knowledge-sharing IT role (enabling, sociotechnical, or dominant factor) Use of communication technology Network relationships Inter-organizational linkages Cross-functional cooperation Change management Pattern of change Management readiness to change Scope of change Management of change (alleviate employee dissatisfaction, vision for change, well-managed change process, evolutionary or revolutionary change tactics used) Process management Process measurement Tools and techniques Team based

Deutero

Senior management Aggressive Low Some

Senior management Change agents (teams) Cautious High Some

Enabling Medium

Enabling High

Low Medium

High (with vendor) High

Semiformal process Committed Radical Inadequate

Formal phased process Committed Improvement Adequate

Little High No

Use of process metrics High Yes

We (Company A) tried to prepare ourselves for the implementation in every means possible. Thousands of hours of training classes were completed and selected individuals were polled

for their opinion of readiness for the go-live date. However, upper management ultimately made the decision to throw the ON switch before the employees believed in or understood

90

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

the software. The result was extremely costly, not only in dollars, but also in lost customers and customer service. Many employees wondered why the switch was ever made from the legacy AS/400 system to the ERP. Employees were disturbed and frightened by the new and complicated ERP system. On the other hand, a team-approach was followed at Company B that eventually received a bureaucratic consensus to proceed as a corporate-level initiative. According to one manager: The stang of the project was the rst challenge at hand. A strategic thinking team was assembled to assess the benets and drawbacks of the ERP software. The crew attended seminars and spent countless hours discussing alternative systems. At least one representative from each function of the business was included in the group and at least one individual from each division. The group decided to implement the ERP in only the marketing and nance functions of the business. Only the basics of the ERP were implemented. The idea was to introduce the system, stabilize the system, and build upon the foundations to optimize the system.

units of product are produced every week during these months. There was not a worse time to switch to the new ERP system that September 1. Even though most end-users did not believe they had been adequately trained and did not feel comfortable with the new system, the decision was made by upper management to ip the switch and chaos ensued. Company B on the other hand devised a strategic plan tied in with its ERP and BPC eorts that focused on incremental improvements. They heeded the suggestions of the ERP vendor to have a phased implementation over a period of one and a half years. Adequate time was allowed for users to be ready for the new system. The project managers decided that the optimistic project completion date was January 10, 1999. They determined the critical path to be the process of customizing the system to the companys specications. Other than this, it was the training that most concerned the managers. As it turned out, the project completion date was the end of April. The proposed cut over date of January 10 was postponed because the managers were not comfortable with the operation of the system. Intense testing took place between January and April, which led to the cut over being a success. 4.2. Learning capacity

4.1.4. Strategy led Company As approach to implementing the ERP in retrospect seems to be hurried and not strategically thought out. The company tried to introduce a complex new system all-at-once within a time frame of only six months of preparation (January 1998 through July 1998). They did not take into account that disruptions to the information systems in their peak production season of September through December could prove fatal. As one manager described: Our demand patterns are seasonal, with a large portion of sales coming from the cough, cold and u season. Retailers generally begin to stock for this season in the fall. To meet demand, we begin heavy production schedules in late August and continue to run at near full capacity until December. Nearly 12 million

4.2.1. Adaptation Both the companies showed some tendency to create a learning environment based on appropriately responding to technological changes or learning from other organizations that had achieved best practices in the industry. Though company A was aware of the ERP mishaps of other companies they assumed that they would be easily able to adapt to the new technology with the help of ERP consultants, some training and a live system in place. But they seriously underestimated the complexity of the new technology. One end-user commented: Consultants and training experts were brought in-house to streamline the switch to the ERP system. Testing of the new system began in the spring of 1998 with 200 selected end-users

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

91

representing all aspects of the business. Along with this testing, those individuals were to gain some advance knowledge of using the ERP. However this testing/training was poorly organized and left many of the end-users frustrated and bemoaning the complexity of the new system. Processes that earlier could be completed in a single transaction now took several transactions, and departments that used to pass along information to another department were now forced to enter the information into the system themselves. When the formal training of all the end users began in the late spring, the confusion mounted quickly. Many of the endusers did not have strong computer skills to begin with and the complexity of the ERP system dumbfounded them. Even people with a strong understanding of computer processes could not understand the strange congurations of the ERP system. Company Bs management however chose to learn from the experiences of other companies that had implemented ERP unsuccessfully. They also responded to the new technology with adequate, self-motivated training. The project was very closely monitored and disruptions carefully ironed out. One manager described this process: With all the training, testing, system development, and assessment, every employee within the company was involved with the ERP to some degree. It took many hours to implement the system. Time constraints were evaluated and considered when this project began. Any disruption in daily operations was unacceptable. The training was designed to be very ecient. The trainers were responsible for walking the groups through the system and providing handouts. Each user had ERP training access at his or her desktop computer. Much of the learning process was left up to the individual.

into the new system, Company As employees gradually became more comfortable with the system. By February of 1999, they were starting to master the transactions needed to complete normal business operations, and production and shipment levels returned to normal levels. Company Bs employees were ready in time for Phase two of the implementation process. This involved bringing live additional features the ERP system had to oer that had not been fully recognized in Phase one. 4.2.3. Declarative knowledge Company As approach of bringing the ERP system live all-at-once did not allow for the building of a collective knowledge base (of experiences) for the company. On the other hand, Company Bs phased implementation of the ERP system into the Marketing and Finance areas in Phase one allowed for the Operations area to learn from their experiences in Phase two of the implementation. 4.2.4. External information use Both Company A and B made use of external information to enhance their learning capacity. While Company A used consultants, who acted as boundary spanners, they also listened to the voice of the customer. Company B made use of technology gatekeepers who were company employees aware of the advantages and pitfalls of new technology. They too widely used consultants (boundary spanners) and surveyed customers to assess gaps in customer service. 4.2.5. Learning type Both companies adopted a deutero type of learning, and were willing to adopt a strategy for learning based on past failures. An employee of Company A commented: In retrospect, the implementation should have been pushed back to January of 1999. In turn, customer service during the busy season would not have been as adversely aected. It also would have given more time for the employees to gain knowledge and become comfortable with the new applications. Upper management

4.2.2. Improved eciency Both Company A and B had a tendency to improve learning eciency through learning by doing. After the initial shock of being thrown

92

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

even admitted they were in error when they decided to go live in September and apologized to the employees.

4.3. Cultural readiness 4.3.1. Change agents and leadership Company As initiative for the ERP system came directly from the senior management and the chief executive ocer. The CEO commented: The implementation of the new software system is a key element in the long-term process improvements we have initiated to improve customer service and reduce costs...while the implementation challenges we have experienced have been frustrating and dicult for customers, suppliers and employees, I believe the long-range benets the new system oers remain appealing. The competitive advantage we gain from this sophisticated system will help us to continue to compete successfully in the dynamic market for store brand products. On the other hand, Company Bs initiative for the ERP system came from both senior management and middle management teams. Three crucial teams were assembled to ensure successful implementation a strategic thinking team, a business analysts group, and an operations group. 4.3.2. Risk aversion With respect to risk aversion, Company A was clearly more aggressive than Company B in deciding to implement the ERP system in a short time frame and also all-at-once. Company B cautiously chose to follow a phased implementation of a chosen few features of the ERP system. 4.3.3. Open communications Company B encouraged participation of its employees in the process of ERP implementation much more than Company A did. In fact, one of Company Bs managers commented:

Everyone, at all levels of the business, is encouraged to speak out about the systems performance and make suggestions. I believe the reason our company was able to pull o such a successful implementation is the high level of involvement of our employees.

4.3.4. Cross-training Neither company A nor B attached much importance to cross-training and personnel movement within the organization. In fact the redistribution of job responsibilities caused by the ERP system greatly confused Company As employees.

4.4. IT leveragibility and knowledge-sharing 4.4.1. IT role Both companies used their information technology departments as facilitators of the process of ERP implementation. Company B took steps to ensure that users and all functional areas were considered in the systems development process. A senior manager of Company B described this as follows: A business analyst group was formed to provide additional feedback to the ERP experts. This group was involved with piloting. They were given access to the ERP virtual screens. They would spend time entering orders and tracking them as they downloaded to the warehouse. Financial reports and transactions were also included in the dry run. This process began as soon as the ERP crew set up the system and continued through until two months before the go live date date. When the business analysts were comfortable with the system, trainers were brought on board from each divisions dierent functional areas. Team leaders were assigned to each area of the business and were responsible for coordinating training sessions. Hundreds of hours were spent on training the trainers. The trainers were responsible for teaching the other members of

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

93

their division. Again many hours were spent bringing all employees of the company up to speed with the ERP.

4.4.2. Use of communication technology Communications technology such as e-mail enabled eective communication and team work. Company B used teams eectively during the implementation, and thus leveraged communication technology better in the process. 4.5. Network relationships 4.5.1. Interorganizational linkages Company B worked very closely with the ERP vendor during the implementation process, even allowing vendor consultants remote access to their system. When any problems were discovered, managers would meet to discuss the same and contact vendor consultants for xes. One manager described this: The project managers would convene to discuss each problem. If they felt it was an issue they could remedy immediately, they would again call upon the vendor consultants. Vendor consultants could remotely access our ERP system to make the changes requested. Company A chose to rely on its own IT sta and hired external consultants to work in-house to correct problems. 4.5.2. Cross-functional cooperation Company Bs phased implementation plan mandated close cooperation between the functional areas that rst implemented the ERP system with those that implemented the system later. Company As all-at-once implementation led to lower cross-functional cooperation. 4.6. Change management 4.6.1. Pattern of change Company A showed little or no formality in the process of change whereas Company B followed a structured methodology recommended by the ERP vendor.

4.6.2. Management readiness for change The management of both Company A and B were committed and ready for the change process. However while Company As management underestimated the complexity of the process, Company Bs management had taken into consideration that glitches would occur in the process and were not alarmed when they did occur. 4.6.3. Scope of change The radical scope of the ERP project at Company A created expectations for immediate improved performance. When this did not happen, frustration and disappointment crept into the company. Company B, however was not prepared to make any radical changes to the organization and quickly found out that the best way to succeed was through incremental change. Credibility established with these small successes eventually paved the way for larger-scale changes. 4.6.4. Management of change Clearly, Company A inadequately managed the change process. They did not take into account employee readiness or satisfaction with the new system. Top management was unable to convey to the employees their vision for change. Most employees did not understand the need for change from the legacy system. The process of change too was not well managed with the aid of a formal methodology. The revolutionary change scared the employees and left them confused. Company B followed just the opposite approach and management was able to take all employees in their fold. Employees were willing to allocate a large amount of their time to the project. They were aided by training sessions that were available both day and night. The open communication encouraged by management gave users a sense of ownership of the system. 4.7. Process management 4.7.1. Process measurement Company A used some process mapping and diagnosis techniques to study the as-is process as well as measurements of process performance. Company B used formal techniques and process

94

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

metrics successfully for process measurement. Business analyst teams would regularly measure changed processes and articulate their value to management and functional groups. 4.7.2. Tools and techniques Techniques and methods such as DFD, CASE tools, and simulation were successfully used by both Company A and B for process analysis and design. 4.7.3. Team basis Company A did not choose to use a teamapproach for implementing or for designing new processes. This however was fundamental to Company B which used three core teams: a strategic thinking team, a business analysts group, and an operations group.

mentations. On the other hand a revolutionary project scope that is mandated autocratically by top management without cultural (organizational) readiness and proper change management is likely to lead to troubled and unsuccessful ERP projects. 5.2. What actions can be taken to bring troubled ERP projects under control? The case analysis described above traces the dierent approaches of Company A and B for implementing their ERP systems. What perhaps is not clear is the way Company B monitored its project and what actions it took to ensure success. These actions are described below and summarized in Table 2. Eight categories of actions classied as either project management or resource management are described below that can potentially bring troubled ERP projects under control. These are derived from software project escalation theory [8]. The project management category includes ve actions. Among these are: redenition of the project, an improvement in project management, a change in project leadership, subdivision of the project into manageable portions, and resolving specic problems. Project redenition includes reducing the scope of projects, re-justifying them nancially, and focusing on the most important features and deliverables. Improvement in project management includes more regular meetings and

5. Discussion of research questions 5.1. What factors facilitate or inhibit the success of ERP projects? The above case study analysis reveal that an incremental, bureaucratic, strategy led cautious implementation process backed with cultural readiness, inter-organizational linkages (with the vendor), and careful change management are factors that contribute to successful ERP imple-

Table 2 Actions to take to bring troubled ERP projects under controla Actions that can be taken to bring troubled ERP projects under control Project management Redene the project Improve project management Change in project leadership Subdivide the project Resolve specic problems Resource management Adding and/or removing resources Layo and hiring Training
a

Company A s approach No change |

Company Bs approach | | No change | |

| | |

| | |

Note: |: Action was performed, : Action was not performed.

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396

95

reviews, more precise scheduling of delivery for system modules, and other means for exercising tighter control over projects. Change in leadership involves the replacement of project leaders associated with the escalation of the project with new leadership, either from inside or from outside an organization. In many cases, this means replacing the project manager, while in some instances, project management responsibilities are handed over to an external consultant. Subdivision of the project into manageable portions involves identifying pieces of a larger project that can be worked on separately from the entire project. The nal project management category is resolving specic problems. Most often, such problems involve external relationships or technical issues. External issues could involve software licensing issues or other problems with software vendors. Technical diculties include the resolution of hardware or software problems and the diculties that are frequently associated with migration to new hardware and software architectures. The resource management category includes three actions. The rst action, adding and/or removing resources can bring troubled projects in control if the additional resources are more carefully managed. Similarly, layo and hiring involve a change in human resources (e.g. bringing in external consultants). Finally, training is an action that enhances existing resources but also requires additional investment. As seen in Table 2, Company B chose to redene the ERP projects scope based on the recommendation of the ERP vendor. Not all features of the system were included from the start. The project was subdivided into manageable phases. The company followed the practices of eective project management to resolve specic problems, using techniques such as PERT/CPM, cross-functional teams that met regularly, and close cooperation with the vendor. As one manager commented: Only days after cut over, users discovered some problems with the system. The availableto-promise inventory system of the ERP was not functioning, as it should. Orders were being found stuck in the system with no apparent reason. Contract orders were not functioning

properly. Perhaps the most dangerous problem was the disconnection of uploads from the distribution centers. There was a period of time where the invoicing function was cut o. The project managers would convene to discuss each problem. If they felt it was an issue they could remedy immediately, they would again call upon the vendor consultants. If Company A had followed an approach similar to that of Company B, perhaps it may have been able to turn around its project to be eventually successful. Thus Company Bs approach could serve as a guideline for other companies contemplating an ERP implementation.

6. Conclusion This research attempted to answer two questions: (1) What factors facilitate or inhibit the success of ERP projects? and (2) what actions can be taken to bring troubled ERP projects under control? Through a case study comparison of a successful ERP implementation with an unsuccessful implementation, it was determined that a cautious, evolutionary, bureaucratic implementation process backed with careful change management, network relationships, and cultural readiness can lead to successful ERP implementations. On the other hand, a revolutionary project scope that is mandated autocratically by top management without organizational readiness and proper change management is likely to lead to a troubled ERP implementation. Some actions are recommended to bring troubled ERP projects under control. Primary among these are redening or subdividing the project, improving project management through the use of formal tools and techniques, and using a team-based approach to solving specic problems.

References
[1] C. Soh, S. Tien, J. Tay-Yap, Cultural ts and mists: Is ERP a universal solution? Communications of the ACM 43 (4) (2000) 4751.

96

J. Motwani et al. / Int. J. Production Economics 75 (2002) 8396 [19] C. Freeman, C. Perez, Structural crisis of adjustment: Business cycles and investment behavior, in: G. Dosi et al., (Eds.), Technical Change and Economic Behavior, Pinter, London, 1988. [20] K. Arrow, The implications of learning by doing, Review of Economic Studies 29 (1962) 166170. [21] P. Adler, Shared learning, Management Science 36 (8) (1990) 938957. [22] R. Corsini, Concise Encyclopedia of Psychology, Wiley, New York, 1987. [23] C. Argyris, D. Schoen, Organization Learning: A Theory of Action Research, Addision-Wesley, Reading, MA, 1978. [24] R. Kilman, M. Saxton, R. Serpa, Issues in understanding and changing culture, California Management Review 28 (2) (1986) 8794. [25] M. Klempa, Understanding business process reengineering: A sociocognitive contingency model, in: V. Grover, W. Kettinger (Eds.), Business Process Change: Reengineering Concepts, Methods and Technologies, Idea Publishing, Harrisburg, PA, 1995. [26] M. Markus, M. Keil, If we build it they will come: Designing information systems that users want to use, Sloan Management Review 35 (1994) 1125. [27] E. Mumford, New treatment or old remedies: Is business process reengineering really sociotechnical design? Journal of Strategic Information Systems 3 (4) (1994) 313326. [28] I. Nonaka, The knowledge-creating company, Harvard Business Review 69 (1991) 96104. [29] D. Johnson, R. Johnson, Cooperation and Competition: Theory and Research, Interaction, Edina, MN, 1989. [30] D. Tjosvold, D. Deemer, Eects of controversy within a cooperative or competitive context on organizational decision making, Journal of Applied Psychology 65 (1980) 590595. [31] P. Crosby, Completeness: Quality for the 21st Century, Plume Books, New York, 1994. [32] P. Stebel, Breakpoints: How Managers Exploit Radical Change, Harvard Business School Press, Boston, 1992. [33] D. Stoddard, S. Jarvenpaa, Businesss process reengineering: Tactics for managing radical change, Journal of Management Information Systems 12 (1) (1995) 81108. [34] T. Davenport, Will participative makeovers of business processes succeed where reengineering failed? Planning Review 23 (1) (1995) 2429.

[2] C. Stedman, Failed ERP gamble haunts Hershey, Computerworld 33(44) (1999a) 12. [3] C. Stedman, ERP Project problems plague city payroll, Computerworld 33(50) (1999b) 38. [4] A. Gilbert, ERP installations derail, Informationweek 22 (1999) 77. [5] C. Stedman, Flash! ERP works if youre careful, Computerworld 33(50) (1999c) 12. [6] L. Wah, Give ERP a chance, Management Review 89 (3) (2000) 2024. [7] W. Kettinger, V. Grover, Toward a theory of business process change management, Journal of Management Information Systems 12 (1) (1995) 130. [8] M. Keil, D. Robey, Turning around troubled software projects: An exploratory study of the deescalation of commitment to failing courses of action, Journal of Management Information Systems 15 (4) (1999) 6387. [9] M. Kremers, H. van Dissel, ERP system migrations, Communications of the ACM 43 (4) (2000) 5256. [10] A. Scheer, F. Habermann, Making ERP a success, Communications of the ACM 43 (4) (2000) 5761. [11] W. Kettinger, S. Guha, J. Teng, The process engineering lifecycle methodology: A case study, in: V. Grover, W. Kettinger (Eds.), Business Process Change: Reengineering Concepts, Methods and Technologies, Idea Publishing, Harrisburg, PA, 1995. [12] J. Papinniemi, Creating a model of process innovation for reengineering of business and manufacturing, International Journal of Production Economics 6061 (1999) 95101. [13] J. Kotter, Leading change: Why transformation eorts fail, Harvard Business Review 73 (2) (1995) 5967. [14] M. Earl, Viewpoint: New and old business process redesign, Journal of Strategic Information Systems 3 (1) (1994) 522. [15] H. Mintzberg, J. Waters, Of strategies deliberate and emergent, Strategic Management Journal 6 (1985) 257272. [16] P. Shrivastava, Strategic Management: Concepts and Practices, South-Western Publishing, Cincinnati, OH, 1994. [17] M. Tushman, D. Nadler, Organizing for innovation, California Management Review 28 (3) (1986) 7492. [18] S. Guha, V. Grover, W. Kettinger, J. Teng, Business process change and organizational performance: Exploring an antecedent model, Journal of Management Information Systems 14 (1) (1997) 119154.

Das könnte Ihnen auch gefallen