Information System

article_2_cisco_erp_success.pdf

Home >Information Systems homework help >Information System

�� Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

ExECutivE suMMary

This case illustrates the importance of vendor selection, top management support, and team structuring in implementing a complex ERP system. While most organizations choose the de-facto brand as their prod- uct, Cisco and its consulting partner, KPMG, went against this perception and selected Oracle who was a newcomer in ERP business. For Oracle this was a golden opportunity to enter a market dominated by SAP and get its ERP modules litmus tested by an industry leader. Cisco on the other hand agreed to help Oracle to market its latest releases to potential customers, in lieu of the successful implementation. Oracle even allowed changing some of its modules to fit Cisco’s purposes. The implementation team comprised the best people from Cisco, KMPG and Oracle. To have the customized ERP up and running in nine months the team blended the robustness of sequential life cycle model with the flexibility of the iterative prototyping. [Article copies are available for purchase from InfoSci-on-Demand.com]

Keywords: Cisco; Contract Negotiation; ERP Implementation; Information Systems Project Manage- ment; Oracle; Systems Development Lifecycle; Top Management Support

orGanization BaCkGround

Cisco Systems, Inc. was founded in 1984 by two computer scientists from Stanford University. Their primary product was the “router” that controlled the flow of data between the complex TCP/IP1 networks that made up the Internet and corporate intranets. Demand for Cisco’s prod- ucts increased dramatically with the rise in the use of Internet after 1990. By 1993 Cisco was a $500 million company and in 1997 Cisco it ranked among the top five companies in return on revenues and returns on assets. In the same year, Cisco entered the Fortune 500 and reached a market capitalization of over $100 billion.

Don Valentine, partner of Sequoia Capital and vice chairman of the board of Cisco, was the first to take initiative and pave the path for the young company. He appointed John Morgridge as CEO in 1988, whose first effort was to build a professional management team. His management

Cisco systems: implementing “Customized” Erp in nine

Months and within Budget Avimanyu Datta, Washington State University, USA

IGI PUBLISHING

701 E. Chocolate Avenue, Hershey PA 17033-1240, USA Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.igi-global.com

ITJ 4874

Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009 ��

team clashed with the founders of Cisco systems, which resulted in departure of the founders after the company’s initial public offering in 1990. This eventually enabled CEO Morgridge to implement an extremely disciplined management structure within Cisco. He maintained a centralized functional organization that continued approximately the next 10 years.

setting the stage

Cisco’s IT infrastructure was supported by a UNIX-based software package to conduct its core transaction processing tasks. The package supported the three key functional areas of the company: finance, manufacturing, and order entry. Pete Solvik, CIO of Cisco, analyzed the UNIX-based software package and found that it did not provide the degree of redundancy, reliability, and maintainability that Cisco needed to keep up with their current business demands.

Unreliability and regular outages brought into question the soundness of trying to modify the current system to meet Cisco’s constantly growing needs. An upgrade was made available, which was a solution that offered more reliability and redundancy2 without maintainability or room for growth. An upgrade from their current software vendor could not suffice for their changing needs.

The management structure in 1993 was such that each functional business unit made its own decisions regarding the future of their IT systems. IT representatives from each department were asked to report the expenses to Slovik. Each department head knew that further “band-aiding” the current system was not going to be sufficient to keep up with the company’s rapid growth. However, no individual was willing to approach the board with a costly and lengthy proposal for replacement of the legacy systems.

Solvik’s initial intention was to avoid an ERP solution because of implementations and cost overruns. In addition, Cisco’s independent department structure was contrary to organizational structure supported by ERP system. Thus, Slovik planned to let each functional area within Cisco make its own decision regarding the software application that they wanted to use. How- ever, all functional areas were required to use a common architecture and database to maintain standardization within the company.

CasE dEsCription

failure of the Existing system

The year 1993 witnessed little change in the software support system at Cisco. None of the de- partments actually got itself a new and updated package. Instead, they kept operating by fixing the existing systems and somehow managed to carry on. In late 1993 Randy Pond, Senior VP of Operations at Cisco, confirmed that fixing the existing system was pointless as it would not serve the growing needs of the firm. Finally, in January of 1994, Cisco’s legacy environment entirely failed, resulting in companywide shut-down for almost 2 days. This was a shortcoming that could no longer be ignored. A number of managers at Cisco came to the conclusion that the autonomous approach to systems replacement would not suffice any longer.

Solvick, along with other managers, put together a plan to take on replacement of all faulty legacy applications in a single ERP project that would provide a common data architecture throughout each business unit. The analysis below will describe in detail the points of their implementation approach, why the project was successful, whether the success was “smart” or

�� Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

“lucky” (or a combination of both), and the possibility of other companies’ ability to replicate Cisco’s ERP implementation technique.

the system replacement

Carl Redfield, the senior vice-president of manufacturing, took the lead in getting a single inte- grated replacement of all the applications at Cisco instead of integrating separate projects in the different functional areas. Thus, a team was formed to investigate the best possible replacement for the existing software support system. The factors that would govern the implementation of the new system were decided to be less time, low customization3, and high priority. The company had two options available to it:

1. Purchase a single ERP system, which would be expensive to procure, time consuming to implement, and would replace each department’s autonomous structure.

2. Upgrade the existing legacy system, built to support a $300 million company, which Cisco no longer was. With the need for a much larger system for its growing needs, Cisco chose to purchase a single ERP system.

ChallEnGEs

selection of partnering Consultant and a vendor

Cisco’s management team realized that implementing an enterprise-wide system to meet the business needs would require heavy involvement from the business people and the people from the IT department. Such an involvement would be required from the beginning of the project. The most competent people from every department were handpicked to be a part of the ERP implementation team. The next step that Cisco took was to involve a consulting partner to aid in the implementation process. Consultants are thought to be able to use their previous ERP implementation experiences and act as knowledge providers who lower the knowledge deficiency existing within organizations (Grabski & Leech, 2006). A close working relationship between consultants and the organization’s project team can lead to a valuable skill transfer (Grabski & Leech, 2006), and control over the project. Cisco was looking for a partner who would, in addi- tion to providing consulting services, also help Cisco to choose the ERP vendor.

Only4 KPMG Consulting5 agreed to provide the support Cisco was looking for. KPMG’s portfolio in consulting combined technical and expert business knowledge. They appeared to be an ideal partner for Cisco because they were willing to give them the expert resources that Cisco required from selecting a vendor to completing the project in as short a time as possible. KPMG sent their best ERP Implementation program manager, Mark Lee. Under Lee’s leader- ship, a 20-member team from Cisco evaluated the available software packages in the market. Ten days were spent drafting the ERP Request for Proposal (RFP). Using research resources like Gartner and Forester, the team zeroed on two prime packages. Oracle was chosen in the end due to the following reasons:

1. Their better support for clients in manufacturing industry 2. The promises of long-term functionality development. 3. Geographical closeness of Oracle’s headquarters to Cisco.

Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009 �9

Oracle was particularly motivated to see the Cisco Project succeed. This would be a first major implementation of a new release of the Oracle ERP product. Thus, Oracle saw an oppor- tunity of promised success. A successful implementation at Cisco would launch the new product on a very favorable trajectory. With such an opportunity, Oracle decided to put a large amount of resources and some of their best people on the project to guarantee its success. The contract itself reflected Oracle’s commitment by promising capabilities, not simply a software package. In addition, Cisco agreed to help Oracle to market their latest newest releases to potential customers, in return of successful implementation within budget and time. This gave Cisco huge bargaining power, something it could not have had with established ERP vendors like SAP or PeopleSoft.6 Thus, Cisco went against the conventional wisdom of selecting the most popular brand of ERP.7 Table 1 shows a comparative analysis of SAP, PeopleSoft, and Oracle.

setting up the Budget and schedule

The Cisco team took only 75 days from analyzing the problem to the final selection the vendor and finalizing the schedule and budget. At this stage, the board of directors at Cisco was concerned with how long the project would take and how much it would cost. A gigantic project such as this often consumes a huge amount of resources, spins out of control, and delivers substandard results in the end. The Cisco team committed to do the entire process within 9 months and for $15 million. Cisco did not attempt to do a formal economic justification for the costs to be incurred in this project. They looked upon it to “institutionalize a business model for the organization.” It was the single largest capital project ever approved by the company.

Managing the implementation team

Cisco expanded its team from its core 20 to 100 members for the actual implementation process. Once again, the team consisted of only the best people, representing a cross-section of Cisco’s

Table 1. Comparative analysis of ERP vendors in 1994 People Soft SAP America Oracle

1995 total Revenues $210 million $ 1.1 billion $291 million % from Software 57% 74% 54% % from services 43% 26% 46% 1994-1995 total revenue growth 94% 88% 81% Revenues outside United States 17% 67% 60% Headquarters Pleasanton, California Walldorf, Germany Redwood Shores,

California Strengths 1. Customer service

2. Excellent functionality 3. Growing network of partners

1. Broadest functionality in integrated product suite. 2. Size and market presence 3. Broad support from partners

1. Large installed base of Oracle Customers

2. Global presence 3. Link to other Oracle technologies

Weaknesses

1. 1. Aging Technology

2. Poor—cross product integration 3. credibility in non-HR products

1. Long complex implementation. 2. backlash against high cost 3. Inflexible

1. Limited to HR functionality. 2. Weak Service partner program 3. limited to Oracle database

�0 Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

business units. Cisco’s policy emphasized that this was a short term project and would not impact anyone’s career.

At the start of the implementation, the team members were split up into five “tracks,” or processes, each relating to a functional area Order Entry, Manufacturing, Finance, Sales/Report- ing, and Technology (Figure 1). Each track consisted of a Cisco information systems leader, a Cisco business leader, business and IT consultants from either KPMG or Oracle, and personnel from Cisco as team members. The five tracks were managed from a Project Management Office (PMO), which consisted of Cisco’s business project manager, and KPMG’s project manager. Monitoring the PMO was an Executive Steering Committee that consisted of the senior-most executives from Cisco, KPMG, and Oracle. The strategy behind using the steering committee was to relieve the development team of the need to intervene directly in the management of the project.

implementing oracle in iterative prototyping

Usually, an ERP is implemented in a sequential model as shown in Figure 2. But Cisco employed rapid iterative prototyping (Figure 3) as the development technique for the implementation of the ERP. This is because Cisco wanted to keep open the provision to change Oracle codes to suit its purpose. This customized coding was not offered by other vendors. Oracle, being new and promised with marketing assistance from Cisco, had no option but to agree with Cisco’s methodology.

Figure 1. Organizational structure of ERP implementation8

Executive Steering Committee Comprised

Management from Cisco, Oracle and KPMG

Monitored the Progress of project Management office (PMO)

Project Management Office (PMO) Responsible Implementation of the modules of Oracle

The team comprised of Mark Lee from KPMG, Slovick, Pond and Redfield from CISCO, and the Project

Management team from ORACLE

Order Entry • Cisco Business

Leader • Cisco System

Leader • 10-20 Personnel

from Cisco • 1 IT consultant from

KMPG • 1 IT consultant from

Oracle

Finance

• Cisco Business Leader

• Cisco System Leader

• 10-20 Personnel from Cisco

• 1 IT consultant from KMPG

• 1 IT consultant from Oracle

Sales/reporting • Cisco Business

Leader • Cisco System

Leader • 10-20 Personnel

from Cisco • 1 IT consultant from

KMPG • 1 IT consultant from

Oracle

Technology • Cisco Business

Leader • Cisco System

Leader • 10-20 Personnel

from Cisco • 1 IT consultant from

KMPG • 1 IT consultant from

Oracle

Manufacturing

• Cisco Business Leader

• Cisco System Leader

• 10-20 Personnel from Cisco

• 1 IT consultant from KMPG

• 1 IT consultant from Oracle

5 Modules of oracle

Focus Group for Customizing Oracle Modules to fit Cisco’s Business Processes when Oracle realized that the low customization was not a option.

Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009 �1

Figure 2. Sequential model of ERP implementation

Figure 3. RAD using iterative prototyping9

Strategy and Planning: Requirement Analysis

Design and Blueprint: Requires high interaction with end-users. The internal team and the consultant must work together

Software configuration

Application customization: Similar to Corrective, Adaptive, and Perfective maintenance

Data migration: involves populating the new ERP master file with data from existing system

Developers Conception

Customer’s Conception

Divergence

V E R S I O N

V E R S I O N 2

V E R S I O N

N- 1

Changes Defects Performance

Scope Concept Requirements

TOTAL PACKAGE

JAD Session Focus Group Sessions

2-6 months

JAD refers to Joint Application Development, where the end users and the developers meet to note a rough list of specifications. Usually it compromises 80% of the requirements requir- ing 20% of the effort. The remaining 20% customized solutions are generated through focused group sessions.

The implementation was broken into a series of phases called “conference room pilots” (CRPs). The purpose of a CRP was to build on previous work in order to develop a deeper understanding of the software and how it functioned within the business environment and to better configure the software to suit the company’s needs. (Figure 4 shows how Cisco blended

�2 Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

Table 2. Deliverables for each of the CRPs

Stage/ Prototype Deliverables and tasks

CRP 0

Training Cisco’s Employees on Oracle Package

Spelling out 80% of the requirements

Selection of Data settings of Oracle System for Cisco’s business needs.

Delivery of the first Prototype

CRP1 (Built on CRP 0)

Customization of CRP 0, according to the requirements of the departments, supported by Oracle’s 5 modules (Order Entry, Manufacturing, Finance, Sales/Reporting, Technology )

Modify Oracle’s coding to match exact requirements of Cisco.

CRP 2 Enhancements, Perfection, and Testing

Enhancement of CRP 1 to add the following features: 1. Incorporation the new after-sales support package 2. Building a data warehouse to view historical data and project future data

through data mining

Load testing the entire project

Figure 4. Blending of waterfall and iterative prototyping

the waterfall model with iterative prototyping from systems analysis to final delivery. Table 2 shows the deliverables and tasks associated with each CRP).

CRP0 began with training the implementation team and setting up the technical environ- ment for the implementation. Here, two parallel efforts were launched. The first effort involved

Analyze the problem in existing system

Evaluate Alternative Solutions and Zero into one

Select Consulting Make RFP

Select ERP Vendor Make Contract

Create the team Develop the system in Prototypes

CRP0: First Iteration

CRP1: second Iteration

CRP2: Third Iteration

Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009 ��

training Cisco’s team members on the Oracle applications through 2 days of intensive training. While most ERP implementation requires 6 months to analyze the system,10 CISCO with 40 people spent only 2 days for the same. In addition, the 5 day training session that was required to know the application suite was reduced to 2 16-hour days. At this stage, 80% of the require- ments were spelled out. The remaining 20% of customized requirements were identified later. Simultaneously, the second effort worked on setting up the Oracle applications. The training of the entire team was completed within a 2-week period. Following this, the team members spent 2 more days in intensive group meeting to decide on the appropriate data settings11 for the hundreds of parameters embedded within the Oracle software that were to be set according to their particular business needs. One week after this meeting, CRP0 was successfully completed. It implemented the capacity to take a Cisco order all the way through the company’s business process from its quotation to payment.

The implementation of CRP0 brought forward an important fact that the initial target of implementation with low customization of the Oracle software would not be successful. This made the process more time consuming. Thus, CRP1 was started, building on the lessons learned with CRP0. The goal of this phase was for each of the five tracks/modules (Figure1), to make the system work within their specific area. This was the focused group geared toward custom- izing the system. Oracle had to modify12 chunks of existing codes to match Cisco’s customized requirement. Cisco’s promise of future marketing partnership left Oracle with no option. Team members documented the purpose and procedures to complete every process, and problem issues were addressed in weekly 3-hour meetings with the PMO.

During CRP1, the team realized that there were many business processes that the software could not support. The implementation team developed a means for categorizing and evaluating each instance separately. All modifications were classified as red (extremely critical), yellow (critical), or green (moderate). In the end, 30 developers spent 3 months to modify Oracle to sup- port the Cisco business process. In addition, the implementation team understood that the Oracle package would not adequately support the after sales support needs of the company. So the team launched a parallel effort to evaluate and select a separate service support package. The service package was selected and implemented within the same schedule as the Oracle package.

The beginning of CRP2 saw the most difficult part of the implementation. Cisco’s initial target of low customization was given up, and a highly customized system was built in the end. It included major modifications in the Oracle software, inclusion of a new after-sales support package, and implementation of a new approach for data communication via a data warehouse. The feature included capability to report historical and future data in the integrated data ware- house.

The scope change involved further adjustments to Cisco’s resource structure for the project. The final goal of CRP2 was to begin testing the system, to see how well it could stand up to the processing load and transaction volumes required to support Cisco’s growing business. CRP2’s focus was on testing the system with full transaction load and assessing the date when the system could start operation. All these were accomplished within the initial schedule.

The Initial Instability and Its Correction

On starting operation, the new system proved disturbingly unstable. On an average, it went down nearly once a day. The primary problem was with the hardware architecture, and secondarily with the software that could not handle the transaction volume required in the Cisco environ- ment. Cisco realized that their mistake was that they had not tested the system with a big enough database. They had run individual processes sequentially with only a partially loaded database.

�� Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

After “cutover,” when all the processes were running together over a fully converted database, the system lacked the capacity to process the required load.

The Hardware Contract

Correcting the inefficiency meant purchase of additional hardware, thus increasing the project expenditure for Cisco. Cisco pulled out an unusually attractive deal. The deal was to purchase a promised capability, rather than a specific configuration. In the end, all the pieces fell into place with the new system fulfilling the promise of supporting the rapid growth that Cisco was expecting in the years to come. As a result, the responsibility for fixing the hardware problems fell completely on the hardware vendor.

Stabilization

The technical problems associated with Oracle proved short lived. Strong vendor commitment from Oracle and the hardware vendor and experienced support from KPMG lead to an eventual stabilization and substantial improvement in performance, after 3 months.

Results

Cisco was extremely successful in terms of the overall performance of the system. With major customizations, the system was working well. The only trouble that had plagued the implementa- tion was the issue of hardware capacity, which was later rectified with a match winning contract with the hardware vendor. The complete system performance was worked out when the project team did its CRP design and testing. By building on the previous version of CRP, the team was able to optimize its functionality. At the end of the implementation, the cutover was successful because of strong coordination between each company involved. The overall cost expectancy was met. The goal of the project was to have the budget at or below $15 million. Cisco reached this goal and also decided to provide its hard working implementation team with a bonus pool of over $200,000.

disCussion

From the initial conception of the project, its leaders, Solvick, Pond, and Redfield, knew what they wanted: a large system in a short amount of time that contained the ability to adapt and grow concurrently with their business, and a provider that was going to be around to support their product well into the future. The decisiveness of the leaders on what they wanted pushed the selection process forward in a short amount of time. Senior management fully backed the project and was kept informed on every step. From the very beginning a strong schedule and the backing of the top management helped to insure success of the project. Because of top manage- ment support, the project team was not required to go through formal processes of management approval, which further sped up the implementation

DiMaggio and Powell (1983) argued that structural change in organization is driven less by considerations of effectiveness, innovativeness, but rather by structuration in organizational fields. This they termed Isomorphism and classified into two categories: competitive and insti- tutional. Further they identified three types of institutional isomorphism. While, Coercive Iso-

Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009 ��

morphism is based on political influence or the problem of legitimacy, normative isomorphism is based on professionalism and structuration of organizational fields and mimetic isomorphism that is based on standard responses to uncertainty. According to DiMaggio and Powell (1983), the majority of organizations are followers (reactive). Thus, most organizations do not sense a change in environment unless one of its competitors has adopted a technology. Following the conventional wisdom of reactive stance and address uncertainty, Cisco would have opted for SAP’s R3, which was the de facto industry standard. But they selected Oracle instead. From the very beginning till the end, Cisco did not lose sight of the project and were in full control of the ERP implementation. Since this was Oracle’s first major ERP account, they got maximum opportunity to test, retest, alter, customize, and standardize their modules.

Karimi, Somers, and Bhattacherjee (2007) mentioned the critical success factors to ERP implementation success are: top management support, project management resources, consul- tant resources, and training resources. Woo’s (2006) list of critical success factors included top management support, project team, and project management. Jones et al. (2004), in exploring knowledge sharing across during ERP implementation, listed eight factors, which were (a) orientation to change, (b) control, coordination, and responsibility, (c) orientation to collabora- tion, (d) basis of truth and rationality, (e)motivation, (f) orientation to work, (g) nature of time horizon (short term versus long term), and (h) orientation and focus. The long term vision of having a system that can sustain Cisco’s growth, choosing a consultant and a vendor who would be partner in Cisco’s success, and combining expertise spread across vendor, consultant, and the client helped sharing of knowledge and controlling of the project (Grabski & Leech, 2006; Jones et al., 2004; Woo, 2006; Xu et al., 2006), which enabled Cisco to have greater control and visibility during the implementation.

Bradford and Florin (2003) mentioned that ERP implementation success is driven by three factors:

1. Innovative characteristics of technical compatibility, perceived complexity, and business process reengineering.

2. Organizational characteristics of top management support, organizational objectives, and consensus training.

3. Environmental characteristic of competitive pressure.

Cisco, being an innovative company with high technical capability, propelled the success factors. Being in the IT and telecom manufacturing industry, IT investments were not seen as a sunk cost as were seen by organizations of other industry verticals. Further, the project not only received top management support from Cisco, also got the best personnel from Oracle and KPMG. The importance of top management support was also studied in detail by Ehie and Madsen, (2005), Karimi et al. (2007), and Woo (2006). Last, the exponential rate at which Cisco was growing justified the need for the system.

Hong and Kim (2002), Iivari (1992), and Kanellis, Lycett, and Paul (1999) researched and stated that the fit between the organization and the ERP system is integral to implementation success. The fit was tested through the CRPs and with each stage. Codes were modified and the system was customized making the system fit for the business processes. Combining the stability of Iterative nature of ERP implementation and the dynamics of Rapid Application Development (Figure 4), Cisco was able to get its system operational by 9 months and within its budget. Such blending was possible mainly for two reasons. First, Cisco received top management support (the key to successful ERP implementation, Figure 5; Bradford & Florin, 2003) from the very beginning of the project. The quick and concise execution of selection and planning partnered

�� Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

with strong backing by senior management were the success drivers of the entire project. Sec- ond, the teams from Cisco, KPMG, and Oracle blended as one. Such a blend of expertise spread across helped sharing of knowledge and control the project (Grabski & Leech, 2006; Jones et al., 2004; Woo, 2006; Xu et al., 2006).

Cisco’s success can also be attributed in part to a combination of luck factors and key tim- ings that facilitated the fast implementation within budget. The most important was the timing of ERP implementation. Cisco’s need for a customized system, paralleled with Oracle’s need to establish its foothold in the ERP market. While Cisco wanted a system that could support its growth, Oracle needed a launching pad to test, correct, and perfect its modules. This was the perfect timing. Oracle had to prove its worth in a market dominated by SAP. This timing gave Cisco huge bargaining power over Oracle. Also, Cisco promoted Oracle with marketing assistance for Oracle’s upcoming products and its ERP. The timing put Cisco and Oracle in a positive sum situation. Another important aspect of this timing was Cisco modifying Oracle’s codes to match its customized requirements. Such timing is impossible to replicate. It can also be argued that Cisco, being in the telecom business, enabled its partners, Oracle and KPMG, to access the best technical resources for the project. This reduced the cost of the project. The lessons learned are:

1. Leadership—Formation of a cohesive team that was fast in its acting led to the success of the project. Besides, the team got indispensable support from the Top Management.

2. Planning—The initial planning and analysis of project scope, with the partner and vendor, was integral to the success of the project. Cisco found the best people for the job and what they received in return was the unsurpassed service from each of their partners.

3. Contract negotiation—Contract negotiation is always an underlying factor in any project’s success. In the Cisco case a great contract born of great opportunity saved the company thousands of dollars and perhaps months of system configuration during the late stages of the

Figure 5. Model for successful ERP Implementation13

Top Management Commitment and Support

Actual ERP Adoption

Favorable awareness response

Favorable Feelings Response

• Minimizing Adoption Cost • Involving Individuals and

groups • Enhancing ERP interface

quality • Hands on training

• Securing Support of Opinion Leaders

• Timing of ERP introduction General

Favorable Adoption Intention Response

• Communicating ERP Benefits • Communicating ERP General

operations

Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009 ��

implementation. The timing of the contract negotiation gave Cisco huge bargaining power over Oracle. Also, Cisco promoted Oracle with marketing assistance for Oracle’s upcoming products and its ERP.

4. Persistence—During the choosing of parameters and system configuration, the company decided to go 80-20 on parameter settings and cram months of research and choices into 2 days. Cisco was extremely persistent in meeting the deadlines. And because they were ahead of schedules, the massive customization did not eat away project time, delaying the delivery.

The methodology used by Cisco and Oracle confirmed the six-stage model proposed by Kwon and Zmud (1987). The six stages included:

1. Initiation: The first or initiation stage is characterized by the various exo- and endogenous factors that influenced the organizations to implement an integrated system like an ERP system. Here the outage of the existing system and the need for having a system that could support its growth would be the reasons.

2. Adoption: Investment decisions and cost–benefit analysis related to implementation of ERP systems and choice of brand or vendor were carried out during the second or adoption stage as suggested by Cooper and Zmud (1990) and Rajagopal (2002). Identification of the vendor by Cisco and KPMG and choosing Oracle because of unique strengths is the adoption stage of this case.

3. Adaptation: The implementation of the ERP system requires changes in the way business is conducted, and the companies that were interviewed carried out BPR before implementing an ERP system (Rajagopal, 2002). In Cisco’s case however, business processes were not altered. Since it was Oracle’s first major implementation, chunks of codes were modified to match Cisco’s business process. It was also an acid test for Oracle’s system, as Cisco’s business process was one of the bench marks for the industry and Oracle got the opportunity to change the codes to reach closer to best practices.

4. Acceptance: The systems become increasingly available for use in the organization. The systems are modified in order to solve the problems reported by the end-users (Rajagopal, 2002). In this case, with every iteration CRP (0 through 2), codes were modified as per the needs of the users and the business.

5. Routinization: The process of using the system is routinized through usage. Because the system was developed with successive iteration, routinization was achieved faster than cutover approaches.

rEfErEnCEs Aladwani, A.D. (2001). Change management for successful ERP implementation. Business Process Manage- ment Journal, 7(3), 266-275 . Retrieved November 3, 2008, from http://web.njit.edu/~jerry/OM/OM- ERP-Papers/ERP-10-Success.pdf

Amoako-Gyampah, K., & Salam, A.F.(2004). An extension of the technology acceptance model in an ERP implementation environment. Information & Management, 41, 731-745.

Bradford, M., & Florin, J. (2003). Examining the role of innovation diffusion factors on the implementa- tion success of enterprise resource planning systems. International Journal of Accounting Information Systems, 4, 205-225.

�� Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

Bredt, K. (2005, April). Cisco ERP. Retrieved November 3, 2008, from http://www.wi.rwth-aachen. de/Lehre/Infosysteme/Files/Pr%E4sentation%20CISCO%20(ERP).pdf

Burgelman, R.A., Christensen, C.M., & Wheelwright, S.C. (2006). Strategic management of technology and innovation. New York: McGraw Hill Irwin.

Cooper, R., & Zmud, R. (1990). Information technology implementation research: A technological diffusion approach. Management Science, 36(2), 123.

Cotteleer, M. (1998). Cisco systems, inc.: Implementing ERP. In R.A. Burgelman, C.M. Christensen, & S.C. Wheelwright (Eds.). (2006). Strategic management of technology and innovation (p. 877). New York: McGraw Hill Irwin.

DiMaggio, P.J., & Powell, W.W. (1983, April). The iron cage revisited: Institutional isomorphism and col- lective rationality in organizational fields. American Sociological Review, 48(2), 147-160.

Duncan, W.M. (1997). Information systems management. London: University of London Press.

Ehie, I.C., & Madsen, M. (2005). Identifying critical issues in enterprise resource planning (ERP) imple- mentation. Computers in Industry, 56, 545-557.

Field, T. (1997). When bad things happen to good projects. CIO Magazine. Retrieved November 3, 2008, from http:// www.coi.com/acrchive/101597/bad_content.html

Frame, J.D. (1995). Managing projects in organizations. San Francisco: Jossey-Bass, A. Wiley Com- pany.

Grabski, S.V., & Leech, S.A. (2006, December). Complimentary controls and ERP implementation success. International Journal of Accounting Information Systems, 8, 17-39.

Harman, M. (1998). Software engineering and development (Vol. 2). London: University of London Press.

Hong, K.-K., & Kim, Y-G. (2002). The critical success factors for ERP Implementation: An organizational fit perspective. Information & Management, 40, 25-40.

Ifinedo, P, & Nahar, N. (2007, February). ERP systems success: An empirical analysis of how two orga- nizational stakeholder groups prioritize and evaluate relevant measures. Enterprise Information Systems, 1(1), 25-48.

Iivari, J. (1992). The organizational fit of information systems. Journal of Information Systems, 2, 2-29.

Information Technology Management. (1999). Modern RAD. ITMWeb Media Corporation. Retrieved November 3, 2008, from http://www.dep.state.pa.us/dep/deputate/oit/SDM/inHTML/HtmlFiles/ SDM/StyleGuide/RapidApplicationDevelopment.htm

Jones, M.C., Cline, M., & Ryan, S. (2004). Exploring knowledge sharing in ERP implementation: An organizational culture framework. Decision Support Systems, 41, 411-434.

Kanellis, P. Lycett, M., & Paul, R.J. (1999). Evaluating business information systems fit: From concept to practical application. European Journal of Information Systems, 8, 65-76.

Karimi, J., Somers, T.N., & Bhattacherjee, A. (2007). The Impact of ERP implementation on business process outcomes: A factor-based study. Journal of Management Information Systems, 24(1), 101-134.

Kwon, T., & Zmud, R. (1987). Unifying the fragmented models of information systems implementation. In Boland & Hirschheim (Eds.), Critical issues in information systems research. New York: Wiley.

Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009 �9

Maner, W. (1997). Rapid application development. Bowling Green State University. Retrieved November 3, 2008, from http://odl-skopje.etf.ukim.edu.mk/UML-Help/html/01day3.html#67561

Rajagopal, P. (2002). An innovation—diffusion view of implementation of enterprise resource planning (ERP) systems and development of a research model. Information & Management, 40, 87-114.

Robson, W. (1997). Strategic management and information systems. London: Pitman Publishing.

Schach, S. (1999). Classical and object oriented software engineering: With UML and Java. USA: Mc- Graw Hill.

State Department of Pennsylvania. (2002, September 23). Rapid spplication development (RAD) Approach. Retrieved November 3, 2008, from http://www.dep.state.pa.us/dep/deputate/oit/SDM/inHTML/Ht- mlFiles/SDM/StyleGuide/RapidApplicationDevelopment.htm

Stratman, J., & Roth, A. (1999, November 20-23). Enterprise resource planning competence: A model propositions and pre-test, design-stage scale development. In 30th DSI Proceedings (pp. 1199-1201).

Woo, H.S. (2006, April). Critical success factors for implementing ERP: The case of a Chinese electronics manufacturer. Journal of Manufacturing Technology, 18(1), 431-442.

Wu, J., & Wang, Y. (2005). Measuring ERP success. The key user’s viewpoint of ERP implementation to produce viable IS in the organization. Computers in Human Behavior, 23, 1582-1596.

Xu, L., Wang, C. , Luo, X., & Shi, Z. (2006). Integrating knowledge management and ERP in enterprise information Systems. Systems Research and Behavioral Science, 23, 147-156.

EndnotEs 1 The most commonly used Network Architecture. TCP stands form Transmission Control Protocol. IP

Stands for Internet Protocol. The architecture was founded by the Department of Defense, USA.

2 Data redundancy and redundant servers and clients are required against outages.

3 We will see later in the case that the low customization would not be an option.

4 Other consulting partners considered then were Cap Gemini, Siemens, IBM, PriceWaterhouse Coo- pers.

5 The KPMG Consulting division now is named as Bearing Point.

6 On December 13, 2004, Oracle bought People Soft for $10.3 billion. Under the terms of the deal, Oracle would acquire PeopleSoft for $26.50 per

7 Grounded to the theory of Mimetic Isomorphism (DiMaggio & Powell, 1983 ), companies select the most established de facto product of the time.

8 Source: Cotteleer (1998); Burgelman, Christensen, and Wheelwright (2006).

9 Source: Maner (1997).

10 Systems Analysis is the first stage of the System Development Life Cycle (SDLC). It is also the most critical making the system correct for the business needs.

11 Data settings mainly refer to the domain of values a data is supposed to accept. For instance the data under item “Products” for Cisco would be routers, Switches, and so forth. For Amazon it would be books, CDs, DVDs, games, and so forth.

�0 Journal of Cases on Information Technology, 11(2), ��-�0, April-June 2009

12 Though code modification is uncharacteristic of ERP implementation, here Oracle had to do it for Cisco.

13 Source: Aladwani (2001).

Avimanyu Datta is a PhD student in the in Washington State University (WSU). He holds a bachelor’s degree in computing and information systems from the University of London, U.K. and a master’s degree in information systems from Hawaii Pacific University. His research interest focus on understanding the strategic use of IS and its transformational capabilities in altering industrial structures and boundaries, as well as IT mediated commercialization of innovations and firm performance. In 2007, he represented the business lead of the team that eventually won the best business plan for Material Research Society. Before joining WSU, he consulted with Frost & Sullivan and AMI Partners.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.