INFORMATION SYSTEMS

MANAGEMENT:

Solving Problems through Information

Systems

PROJECT REPORT

1

TABLE OF CONTENTS

Case Study 1- Human Resource Management System(HRIS) at Xerox ……………………….3

Case Study 2- Mercedes Benz: The Factory Delivery Reservation System…………………..9

Case Study 3- Supply Chain Management (SCM) System at Cisco………………………………..16

References……………………………………..27

2

Human Resource

Management System (HRIS)

at Xerox

"By eliminating unproductive uses of people's time, Xerox PeopleNet makes them more

efficient, allowing them to focus their efforts on the important aspects of their job."

- Karen Mihara, Development Manager, Xerox PeopleNet.

The Xerox PeopleNet Story

With revenues of $ 18.7 billion in the year 2000, Xerox is a global leader in the

document-management business. The company offers a vast range of document products,

services and solutions in association with its joint-venture partner, Fuji Xerox Co. Ltd. of

3

Japan. The products include digital printing and publishing systems; digital multifunction

devices and copiers; laser and solid ink printers; fax machines; document-management

software; supplies (toner, paper, ink cartridges, etc.); and comprehensive document-

management services such as running in-house production centers and developing online

document repositories.

In the early 1990s, Xerox saw media reports commenting that the functioning of the

company's HR department was 'hardly a model of efficiency.' The company realized that the

fully centralized functions of hiring, awarding bonuses and granting promotions were resulting

in the central HR department being over-burdened. More often than not, HR personnel were

tied up in paperwork that left them little time to use their skills elsewhere. As a result, tasks

such as counseling managers on ways to handle employee problems were frequently postponed

by HR managers. Xerox was not happy with its internal job posting process as well. In the

existing setup, hiring managers filled in job description forms and sent them to the HR

department, where the information was reentered on posting forms.

It often took a week before employees could view the job listings, thus delaying the

recruitment process considerably. In 1992, Xerox began to explore the possibilities of using a

computer system to release HR professionals from the monotony of administrative tasks. The

company decided to install an intranet application to act as a communication and productivity

tool for its 50,000 managers and employees. The idea was to deliver traditional human

resource information such as benefits, compensation, policy manuals, phone directory and

training as well as the ability to change personal information like name and address, to

minimize the HR administrative support needed by employees.

In early 1993, Xerox CEO Paul Allaire (Paul) began to put in place measures to achieve

the 'Xerox 2000' goals. Xerox wanted to bring about a paradigm shift in the company's human

resource arena and make the workforce much more empowered, productive, accountable and

satisfied. The empowerment aspect played a major part in Paul deciding to put basic HR

information and applications at the hand of all the personnel through a Human Resource

4

Management System (HRMS). Xerox already had a well-established legacy system of general

employee and personnel database systems, which it did not want to tamper with. Most of the

vendor solutions evaluated initially were designed for use by human resource managers rather

than the typical employee or manager, as planned by Xerox. It was thus decided to develop the

required HRMS in-house. This marked the beginning of the Xerox PeopleNet initiative.

Developing Xerox PeopleNet

Research work for the HRMS began in early 1993, and the overall concept of Xerox

PeopleNet was formalized by June 1993. Xerox began with an internal HR survey to identify

the desired objectives of the proposed system.

Suggestions regarding the priorities from which to develop an initial user interface were invited

from the employees. The company took the help of consultants Tridec Development Corp. for

this purpose.

The company's existing infrastructure comprised workstations and the basic networking

hardware under a mainframe environment.

Xerox had in the past tried several times to make basic HR information available to

employees. However, mainframe technologies were not user-friendly enough for the typical

manager/employee skillset.

Also, Xerox was shifting from the existing hardware setup to a personal computer (PC)

setup. Therefore, a client/server architecture was decided upon as the best choice. In the early

1990s, client/server technology was still very new and there were no applications being

developed on such a large scale. The development team along with the company's 'Global

Process and Information Management Group' (GP&IM) began establishing the basic

application/system standards for a technical framework. Prototyping was used to test different

development approaches and design the overall graphical user interface (GUI).

5

The infrastructure support was outsourced from a leading IT services company,

Electronic Data Systems. All the software developed was put through strict compatibility

testing to ensure that it complied well with other Xerox applications and standard

configurations.

By the end of 1994, a pilot was developed, which was approved by the company and funds

were released for the production version. In January 1995, a read-only version was launched

with simple applications. Xerox opted for a phased launch because it was shifting from

mainframes to a PC based setup and the developers needed to understand the new

infrastructure well before going in for a full-fledged implementation.

The version included applications pertaining to personal employee data, the HR policy

manual, employee salary data and fund balances. Screens and queries were designed to help

keep the network traffic low. The second phase of the launch included letting the employees

change their name, home address and phone number. To build the software, developers

initially considered various vendors offering proprietary APIs available, which enabled the use

of PeopleNet's own proprietary interface. However, these APIs locked the software to specific

databases and middleware. Xerox then decided to go for Open Database Connectivity (ODBC),

because it was supported by almost every client application and database.

Several ODBC drivers were evaluated including InterSolv's DataDirect ODBC Pack,

Oracle' ODBC Driver, Microsoft's ODBC Desktop Database Driver and Intersolv's DataDirect

SequeLink. Xerox finally selected OpenLink Software's Object Broker as it was reportedly

very easy to install and it supported both TCP/IP and Novell's IPX/SPX protocols equally well.

Many other ODBC drivers tested (or the middleware on which they ran) worked better with

TCP/IP, but not IPX/SPX. Those that supported the latter were quite slow. Most importantly,

OpenLink worked out to be much more cost-effective than the other drivers available. The

server software, based on Oracle 7 Database, ran under Sun Solaris 2.4 on SPARCServer

1000s, with 512 MB of RAM and 10-GB disk arrays.

6

Server software also included OpenLink ODBC Request Broker, which communicated

with the ODBC driver on the client. The clients and servers communicated over local and

wide-area networks, using TCP/IP and Novell IPX/SPX. The client part of the software was

under the Microsoft Windows operating system (version 3.1 on a 386 processor or higher, with

8 MB RAM and 15 MB of available space on the hard drive), written in Visual Basic 3.0 with

a local Microsoft Access database (Refer Figure I).

The project followed a phased development approach of prototyping, testing, re-testing

and then rolling out on a continual basis. Visual Basic was selected as the client development

tool because of its ability to facilitate prototyping. The Microsoft Access engine acted as the

invisible middleware component, which tracked configuration and routing information and

stored cached data.

The ODBC Driver worked with a related component on the server to transmit and route

requests and data between the client and server. The ODBC driver also provided other

functionalities, including transmission-level encryption for data traveling over the network and

a query and transport vehicle for automatically updating client systems.

The Benefits

Xerox PeopleNet supported applications covering such areas as training, retirement

fund performance and a corporate phone directory (Refer Table I).

In addition, employees could check Xerox's stock price as well as those of its competitors.

The unique feature of Xerox PeopleNet was that unlike typical HRMSs, it did not restrict the

availability of information HR staff alone.

All employees could access information through any PC on the company's network.

7

TABLE I

Xerox PeopleNet MODULES

• Employee recognition programs

• Phone Directory

• Company-wide electronic bulletin

• Stock quotes

• Calendar-based reminder system for key HR activities

• Work group organization charts

• Total cash compensation

• Employee demographics

• Personal and salary information

• Training transcripts

• Training catalog

• Profit-sharing fund balances

• Retirement planner

• Benefits guide

• The human resources policy

manual

Source: Microsoft User Story "Xerox PeopleNet," www.webfrontier.tridec.com.

Xerox PeopleNet cost Xerox around $2 million. However, its benefits far outweighed

the investment. The solution helped Xerox accomplish its objectives of empowering its people,

increasing satisfaction and boosting productivity. In addition, online publication of the human

resources manual and other publications saved approximately $1.5 million annually in printing

costs.

Online transaction processing and electronic signature approval capabilities added later saved

another $1.1 million annually by eliminating manual forms and paper-based processing.

On the hiring front, managers could open the Xerox PeopleNet application on the desktop,

create a posting on an online form and post it immediately on a central electronic bulletin

board. Any interested Xerox employee could then print an application form and submit it to the

hiring manager in paper form. The paper element was to be completely eliminated over a

period of time and internal job applications were to be processed entirely online.

The system included a feedback feature that let employees suggest new ideas and

improvements. As a result, employees were able to monitor their profit sharing and retirement

plans and change their contributions from their desktops itself.

8

Interestingly, Xerox PeopleNet seemed to have had certain undesirable results as well.

Commenting on the massive layoffs by Xerox during the 1990s, analysts said that so long as

software such as Xerox PeopleNet continued to render personnel redundant, the trend of

manpower trimming was likely to continue.

However, Mihara seemed to be rather pleased with Xerox PeopleNet, "We now have a vehicle

for accomplishing our objective of empowering managers and employees.”

Mercedes Benz : The Factory Delivery Reservation System

"One of our most fundamental goals in developing the system was to strengthen and market the

Mercedes-Benz brand in the United States. The fact that we would be one of the first car

manufacturers in the United States to have a factory delivery program would be seen as a very

positive thing in this regard."

- William Engelke, Assistant Manager, IT Systems, Mercedes Benz US International,

commenting on the FDRS.

Linking Customers

By 2000, Mercedes Benz United States International (MBUSI), builder of the high-

quality M-Class sports utility vehicle (SUV), established itself as a company that also delivered

superior customer services. One such service was the delivery option where by the customer

could take delivery of the vehicle at the factory in Alabama, US.

9

The program called the Factory Delivery Reservation System (FDRS), enabled MBUSI

to create and validate 1800 orders per hour. FDRS also automatically generated material

requirements and Bills of Material for 35,000 vehicles per hour. The Customer Relationship

Management (CRM) solution that made FDRS possible was based on Lotus Domino and IBM

Netfinity server.

Analysts felt that with its innovative use of the new program, MBUSI not only managed to

improve its customer relations by providing the best service, but also demonstrated its

commitment to customers by making them an integral part of the process. Customers were, in a

way linked directly to the factory floor – which was a powerful sales tool.

Background: Mbusi and its Business Challenges

MBUSI was a wholly-owned subsidiary of DaimlerChrylser AG.5 In 1993, Daimler

Benz realized that the 'Benz' brand could be extended to wider market segments. Traditionally,

Mercedes Benz6 appealed to older and sophisticated customers only. Daimler Benz wanted to

attract customers below 40 years of age, who wanted a rugged vehicle with all the safety and

luxury features of a Mercedes.

Daimler Benz decided to develop a SUV known as the M-Class. It expected strong

demand for the new vehicle and therefore planned to build its first car-manufacturing facility –

MBUSI – in the (Tuscaloosa, Alabama) US. The MBUSI facility had many advantages. First,

labor costs in the US were almost half that of in Germany. Second, the US was the leading

geographic market for SUVs.

Third, as the vehicles were assembled in the US, they could be distributed to Canada

and Mexico more efficiently. In January 1997, the factory started production at partial capacity

and by the end of the year, it was producing at full capacity.

10

By 2000, the factory was rolling out around 380 vehicles per day. The new M-Class ‘all-

activity'vehicle represented a new concept for the company.

Also, mass customization required that each vehicle be treated as a separate project, with its

own Bill of Material. To deal with these challenges, Daimler Benz decided to implement an

enterprise wide Information Technology (IT) system, with the help of IBM Global Services.

To further strengthen the image of Mercedes Benz in the US, MBUSI planned to

deliver vehicles at the factory, becoming the first international automobile manufacturer in the

US to do so. MBUSI also wanted to enrich the customers'experience. Commented William

Engelke, “The factory delivery option gives Mercedes-Benz customers something that they do

not get from other automobile manufacturers which is why we think the program will resonate

with our customers. We think that having the factory delivery program available to Mercedes

customers adds to the overall experience of the customer.”

The Design of FDRS

The FDRS program was proposed in the first quarter of 1998. In the third quarter of

1998, MBUSI entered into a contract with IBM. A development team was constituted with

IBM Global Solutions specialists and IBM e-commerce developers, who worked closely with

MBUSI. The program became operational by the first quarter of 1999. The IT team at MBUSI

had a clear set of functional specifications for FDRS. However, they relied on IBM to

transform the concept into an e-business solution. The FDRS was designed in such a way that

customers buying the M-Class SUV could specify that will take delivery of their new vehicle at

the factory.

They could place the order at any of the 355 Mercedes Benz dealers in the US. An

authorized employee at the dealership entered the factory delivery order the web interface.

Timing was the most important aspect of the FDRS'functionality, as it was closely linked with

11

MBUSI's vehicle production schedule. Mercedes Benz United States of America (MBUSA),

based in Montvale, NJ, was the first link in the FDRS program.

It was the point where the dealer actually placed the order. MBUSA's role was to coordinate

the distribution of vehicles to dealers across the country. Later, it had to add the order to the

company's Baan Enterprise Resource Planning (ERP) system, which scheduled the order for

production.

About three months before the production date, the dealer could schedule in a window,

the date and time of arrival of the customer at the factory for delivery. The window was then

automatically computed by the FDRS to give the dealer, the possible delivery dates.

Apart from the delivery date, the customer could also specify the accessories for the car and

also request a factory tour. FDRS was based on Lotus Domino (Refer Exhibit I), Lotus

Enterprise Integrator and IBM Netfinity servers. It also interfaced with IBM S/390 Parallel

Enterprise Server, Model 9672-R45 located in Montvale, NJ (Refer Figure I). There were two

Domino servers – an IBM Netfinity 5500 and an IBM Netfinity 3000.

FIGURE I

12

SYSTEM ARCHITECTURE OF FDRS

Source: MBUSI

The former that acted as the ‘internal Domino server'was placed behind a firewall. It

replicated databases through the firewall to the external server. The replication, which was

encrypted, represented the primary means by which the FDRS system achieved security.

Netfinity 3000 acted as an ‘external Domino server.'It had public information and was also the

primary communication linkage for dealers. The back-end of the FDRS was equipped with an

Oracle database that updated the internal Domino server database with order information.

The updation was done using Lotus Enterprise Integrator. The data which was replicated to the

internal Domino server included lists of valid dealers and lists of order numbers.

When an order was placed by the dealer on the FDRS system, the data was first stored

on the external Domino server, after which it was replicated to the internal Domino server.

Then it was replicated to the back-end database via the Lotus Enterprise Integrator. Data

13

replication between the Lotus Notes servers happened every 15 minutes and data exchange

with the back-end database three times per day.

There was also a link between the back end database and an IBM S/390 mainframe

based system located at MBUSA via a T1 line. MBUSA managed the flow of vehicles to

Mercedes dealers across the United States.

This mainframe based system, received new vehicle orders (as opposed to factory delivery

reservation requests) from individual dealers. The orders were then sent to MBUSI's Baan

system and also to the back-end database.

The vehicle ordering and factory reservation data were coordinated with each other when the

back-end database uploaded the data to the internal Domino server. This coordinated the

production and delivery information.

FDRS Implementation

One of the most challenging aspects of the implementation seemed to be the complexity

of the Lotus and Domino scripts. The development team had to group all the information from

diverse systems. Commented William Engelke, “There was a substantial amount of very

complex coding involved in the FDRS solution. This application involves a lot more than

having our dealers fill out a form and submitting it. There are many things the servers have to

do for the system to function properly, such as looking at calendars and production schedules.

We built a solution with some very advanced communication linkages.”

IBM faced many technical challenges during the implementation of the program. One

of them was the different timing schemes of the Lotus Notes databases and backend databases

(ERP). This led to discrepancies in the data. Domino server was a Near Real Time (NRT)

Server, and MBUSI's backend activities were both real time and batch processing. Also, to get

the best results, the Domino server was an optimised subset of the ERP table set. However, the

14

development team achieved a balance between the two ‘sides'of the solution by focusing on

issues of timing, error detection schemes, and alerts.

Customer Satisfaction: FDRS'Primary Benefit

MBUSI seemed to measure FDRS'success in terms of increased satisfaction of its

customers. The company also believed that the marketing and customer satisfaction aspects

outweighed the significance of more traditional cost-based benefits. Apart from the factory

delivery experience, the program also offered the customer a factory tour and ride on the off-

road course at a low cost.

The company also seemed to gain strategic marketing benefits from the FDRS program,

as it was able to establish Mercedes-Benz as a premium brand. (Refer Table I for advantages of

FDRS in different areas). Customers could also visit the various tourist spots in Alabama after

picking up their M-class vehicles. The NRT Server System supports real time distribution of

near-real time data.

TABLE I

ADVANTAGES OF THE FDRS PROGRAM

AREA ADVANTAGES

Strategic Marketing

Benefits

FDRS was expected to improve customer satisfaction and brand loyalty, as it

enriched Mercedes' customer's experience. The program also strengthened the

brand image of Mercedes in the US.

Cost Savings Development of a web-based solution enabled MBUSI to offer the factory

delivery program at substantially lower costs, due to less reliance on

15

administrative personnel.

Regional Economic

Development

“Package Marketing” the FDRS program with a ride to tourist sites, enhanced

the image of Alabama as a tourist destination.

DaimlerChrysler AG The creation of a similar – albeit smaller – factory delivery system to the

European Customer Delivery Center in Sindelfingen, Germany, reflected

favorably on the MBUSI business unit.

Source: MBUSI

Future of FDRS

In 2000, MBUSI planned to leverage FDRS'platform by adding a range of other

services. MBUSI built an advanced platform to create communication links to its suppliers.

Through the link, MBUSI provided them feedback on the quality of supplies it received. The

dealers and suppliers had a user-ID and password, which the system recognized.

It then routed them into the appropriate stage of the FDRS. The company also planned

to extend the innovative system to include transactional applications such as ordering materials

and checking order status on the Web. The company expected that the new system based on

FDRS, would be more cost-effective than the Electronic Data Interchange (EDI)18 system.

Supply Chain Management

(SCM) System at Cisco

16

"Networked manufacturing processes have enabled Cisco to manufacture new world products

with new world processes, resulting in a competitive advantage for Cisco and enhanced

satisfaction for Cisco customers."

- Carl Redfield, Senior Vice President, Manufacturing and Worldwide Logistics, Cisco

Systems, in 2000.

A Company in Trouble

In August 2001, the San Jose, California based, computer-networking company Cisco

Systems Inc (Cisco) surprised industry observers by announcing its first ever negative earnings

in more than a decade. In the third quarter of fiscal 2001, the company's sales had decreased by

30%. Cisco had to write off inventory worth $ 2.2 billion and lay off 8,500 people. By the end

of 2001, the market capitalization of the company was down to $ 154 billion and per employee

profit was $ 240,000 (down from $ 700,000 in 2000).

This was in sharp contrast to the situation in early 2000, when Cisco was one of the

most successful companies in the Internet world with a market capitalization of $ 579 billion

(It had become the world's most valuable company surpassing even Microsoft's market

capitalization of $ 578 billion).

According to John Chambers (Chambers), Cisco's CEO, neither the company's software

nor its management were to blame for the company's poor performance. Analysts were puzzled

that while other networking companies, with far less sophisticated information technology

infrastructure than Cisco, had begun downgrading their forecasts in the wake of the impending

downturn in the industry months earlier, Cisco did not lower its inventory like other

companies. What came however as the biggest surprise were the allegations by some analysts

that the company's 'highly regarded' systems were to be blamed for this situation. According to

17

analysts, over reliance on technology prevented Cisco from seeing the impending downturn

that was clear to everyone else and led the company down a disastrous path.

Cisco – The Networked Supply Chain

Cisco was founded in 1984 by a group of computer scientists at Stanford. They

designed an operating software called IOS (Internet Operating System) that could route

streams of data from one computer to another.

The software was loaded into a box containing microprocessors specially designed for

routing. This was the router, a machine that made Cisco a hugely successful venture over the

next two decades (Refer Table I for details of Cisco's growth).

In 1985, the company started a customer support site through which customers could

download software over FTP and also upgrade the downloaded software. It also provided

technical support through e-mail to its customers. In 1990, Cisco installed a bug report

database on its site. The database contained information about potential software problems to

help customers and developers.

The system allowed customers to find out whether a specific problem was unique, and if not,

how other customers had solved that problem. By 1991, Cisco's support center was receiving

around 3,000 calls a month. This figure increased to 12,000 by 1992. In order to deal with the

large volume of transactions, the company built a customer support system on its website.

TABLE I

CISCO – THE MILESTONES

YEAR EVENTS

1984 Founded in a living room by the husband-wife team of Sandy Lerner and Len Bosack. Router used

for the first time to move information from one network to another.

18

1990 Cisco goes public.

1992 Plans a global supply network; outsources manufacturing and distribution.

1993 Acquires Crescendo, a low end LAN switch maker for $ 100 million.

1994 Launches Cisco Connection Online website.

1995 John Chambers becomes the CEO and accelerates the acquisition strategy by acquiring four

companies in the same year.

1996 Cisco moves into the WAN switch market, acquires Startcom for $ 4.5 billion

1997 Cisco starts its global direct fulfillment system. Products are directly shipped by third party

logistics partners from the manufacturer to the customer

1998 Cisco prepares to become a single vendor servicing the network arena. Enters into alliances with

integration partners like KPMG and IBM to provide solutions.

Source: ICMR

In 1993, Cisco installed an Internet based system for its large customers, usually

multinational enterprises. The system allowed customers to post queries, about their software

problems. Cisco also installed a trigger function called 'Bug Alert,' which sent emails

containing information on software problems within 24 hours of their discovery. Encouraged

by the success of its customer support site, Cisco launched Cisco Information Online in 1994.

This online service offered not only company and product information but also technical and

customer support to Cisco's customers.

By 1995, the company introduced applications for selling products or services on its

website. The main idea behind this initiative was to transfer paper, fax, e-mail and CD-ROM

distribution of technical documentation and training materials to the web, thus saving time for

employees, customers and trading partners and besides broadening Cisco's market reach. In

1996, the company introduced a new Internet initiative called the 'Networked Strategy' to

leverage its network for fostering interactive relationships with customers, partners, suppliers

and employees. Cisco wanted to ensure enhanced customer satisfaction through online order

entry and configuration. Customers' order information flowed through the supply chain

19

network, which consisted of Cisco employees, resellers, manufacturers, suppliers, customers

and distributors.

Orders from customers were stored in Cisco's enterprise resource planning database and

sent to contract manufacturers over the virtual private network (VPN). Cisco's suppliers could

clearly see the order information as their own production schedule was connected to Cisco's

ERP system.

According to the requirements, the suppliers shipped the needed components to the

manufacturers and replenished their stocks. The business model aimed at enabling Cisco's

contract manufacturers to start manufacturing built-to-order products within 15 minutes of

receiving an order.

Cisco gave top priority to order fulfillment and project management to achieve on-time

delivery to customers.Third party logistics providers were plugged into Cisco's database via the

Internet. As a result, Cisco could, at any time provide customers with information regarding the

status of their order.

Direct fulfillment led to a reduction in inventories, labor costs and shipping expenses. Through

direct fulfillment, Cisco saved $ 12 million annually.

Cisco's Internet linked supply chain network enabled the automatic testing of products from

any of its locations worldwide.

While earlier prototyping used to take weeks, Cisco engineers were now able to do the

same within a matter of days. This was because prototyping could take place at the

manufacturer's site itself. After manufacturing, the product was connected to one of Cisco's

700 servers worldwide. For a faulty product, the system would not print a shipping label. This

prevented an invoice from being generated and consequently blocked payment.

20

Because of rapid sharing of demand information across the supply chain, customers could

receive products faster. To sum up, this networked supply chain:

o Ensured shorter engineering-to-production cycle times in order to increase market

share.

o

Ensured flexibility in designing, revamping and retiring products in response to

market demand.

o

Ensured product quality though major portions of the fulfillment process were

outsourced.

Even though Cisco dealt with technically complex products like routers, it did not hesitate

to hand over the manufacturing to a set of contract manufacturers.

In order to ensure the quality of its products, Cisco relied on automatic testing. The

company developed test cells on supplier lines and ensured that the test cells automatically

configured test procedures when an order arrived. Cisco defined its core competence as

product designing and delegated the rest - manufacturing, assembly, product configuration, and

distribution – to its partners. In August 1996, Cisco launched transactional facilities like

product configuration and online order placement. These facilities were connected to its ERP

systems. In the same year, Cisco upgraded its network infrastructure to better handle the

increasing number of transactions. In mid-1997, it introduced dial-in access from desktop

computers that allowed customers to place orders without accessing the Internet.

In the same year, it also introduced customized business applications for its large

customers. These applications resided inside the customers' corporate intranet and automated

the ordering process by linking directly to Cisco's internal systems. By the end of 2000, more

than 75% of the orders for Cisco's products were being placed over the Internet. Aided by

Cisco's Internet initiatives, the company's net sales grew at an impressive 78% compounded

21

annual growth rate (CAGR), from $ 2 billion in 1995 to $ 9 billion in 1998. The company's

fourth quarter revenues in 2000 were $ 5.7 billion, up 61% from the same period in 1999.

Operating profits also went up from $ 710 million in 1999 to $ 1.2 billion in 2000.

According to many analysts, the company's networking strategy had played a major role in its

success over the years. Industry observers noted that ever since its inception, Cisco had

demonstrated the power of networking and the benefits it could offer. Cisco owned just two of

the 40 facilities that manufactured its products.

It did not own the distribution system that delivered the products to its customers, but through

its network of suppliers, distributors, partners, and resellers and customers, it successfully

coordinated all the activities necessary to provide products to its customers on time. In spite of

an efficient supply chain network, Cisco ran into some problems.

Cisco's partners typically worked out their supply-and-demand forecasts from multiple

points in the company's supply chain. Transactions between suppliers and contract

manufacturers were not always smooth. There were time lags in delivery and payment, and

thus greater opportunity for error. As a result, suppliers were plagued by long order-to-payment

cycles. In June 2000, Cisco discovered, to its alarm, that it was running short of some key

components for some of its equipment. Due to the shortage of components, shipments to

customers were delayed by 3–4 weeks. Though demand for Cisco's products remained healthy,

the revenues of customers who were used to delivery within two weeks were affected badly.

Analysts felt that above experiences of customers were rather 'out of character' for a company

that prided itself on its relationships with customers and even compensated many of its

executives the basis of on customer satisfaction.

The Cco & Ics Initiatives

In order to address the above problems, Cisco revamped its supply chain management

to reduce the long ordering cycles. The company launched Cisco Connection Online (CCO),

22

which connected Cisco with all its suppliers and contract manufacturers online. As a result,

when a customer placed an order, it was instantly communicated to all its suppliers and

manufacturers.

In most cases, a third party logistics company shipped the product to the customer.

CCO ensured increased co-ordination and connectivity between supply partners, thus reducing

the operating costs of all constituents. Automated processes within the supply chain removed

redundant steps and added efficiencies. For instance, changes in market demand were

communicated automatically throughout the supply chain.

This enabled the networked supply chain suppliers to respond appropriately. CCO

reduced payment cycles for suppliers and eliminated paper based purchasing. As a result,

suppliers agreed to charge lower product markups. Consequently, Cisco saved more than $ 24

million in material costs and $ 51 million in labor costs annually.

CCO enabled Cisco's contract manufacturers to find out the exact position of demand and

inventory at any given point of time. As a result, they could manage replenishment of

inventory with ease. This resulted in a 45% reduction in inventory (Refer Figure II) and a

doubling of the inventory turnover. Cisco slashed the inventory holding of its suppliers and

manufacturers and brought it down from 13,000 units (approx) to 6,000 units within 3 months.

To get the most out of CCO, Cisco used intranets and extranets extensively. The

extranet was used for communicating with suppliers, manufacturers, customers and resellers,

while employees used the intranet for communicating about the status of orders. Thus, through

an online information and communication system, Cisco linked suppliers, manufacturers,

customers, resellers and employees seamlessly (Refer Figure III). However, some of Cisco's

large customers were not able to access CCO because it did not connect seamlessly to their

back-end or electronic data interchange systems.

23

These firms, typically telecom equipment distributors or network operators, lacked the

time to visit the supplier websites to order the equipment they needed. Cisco introduced the

Integrated Commerce Solution (ICS) for these customers.

ICS provided a dedicated server fully integrated into the customers' or resellers' Intranet and

back end ERP systems. It facilitated information exchange between Cisco and them, besides

speeding up transactions.

It had all the e-commerce applications of CCO, with the additional capability of pulling order

related data directly from Cisco's back end ERP systems online.

At the same time, as the server was integrated into the customers' and resellers' back-

end ERP systems, the end users needed to enter the order information only once; this order was

simultaneously distributed to both resellers and Cisco's back-end systems, eliminating the need

for double entry. With these new Internet initiatives and sound financials for fiscal 2000 (Refer

Exhibit I), Cisco seemed all set to register even higher growth figures. However in early 2001,

the global IT business slowdown and the dotcom bust altered the situation. Reportedly, Cisco

failed to foresee the changing trends in the industry and by mid 2001 had to cope with the

problems of excess inventory. As a result, the company had to write off inventory worth $ 2.2

billion in May 2001. Cisco blamed the problems on the 'plunge in technology spending', which

Chambers called as unforeseeable as 'a 100-year flood.' Company sources revealed that if its

forecasters had been able to see the downturn, the supply chain system would have worked

perfectly.

The Problem and the Remedy

Analysts felt that the flaws in Cisco's systems had contributed significantly to the

breakdown. During the late 1990s, Cisco had become famous for 'being the hardware maker

that did not make hardware.'

24

Its products were manufactured only by contract manufacturers and the company

shipped fully assembled machines directly from the factory to buyers. This arrangement led to

major troubles later on. According to analysts, Cisco's supply chain was structured like a

pyramid, with the company at the central point. On the second tier, there were a handful of

contract manufacturers who were responsible for final assembly.

These manufacturers were dependent on large sub-tier companies for components such

as processor chips and optical gear. Those companies in turn were dependent on an even larger

base of commodity suppliers who were scattered all over the globe. The communication gaps

between these tiers created problems for Cisco. In order to lock-in supplies of scarce

components during the boom period, Cisco ordered large quantities in advance on the basis of

demand projections made by the company's sales force.

To make sure that it got components when it needed them, Cisco entered into long-term

commitments with its manufacturing partners and certain key component makers. These

arrangements led to an inventory pile-up since Cisco's forecasters had failed to notice that their

projections were artificially inflated. Many of Cisco's customers had ordered similar equipment

from Cisco's competitors, planning to eventually close the deal with the party that delivered the

goods first. This resulted in double and triple ordering, which artificially inflated Cisco's

demand forecasts.

Cisco's supply chain management system failed to show the increase in demand, which

represented overlapping orders. For instance, if three manufacturers competed to build 10,000

routers, to chipmakers it looked like a sudden demand for 30,000 machines. As Cisco was

committed to honor its deals with its suppliers, it was caught in a vicious cycle of artificially

inflated demand for key components, higher costs, and bad communication throughout the

supply chain. Cisco's inventory cycle reportedly rose from 53.9 days to around 88.3 days.

According to analysts, Cisco's systems failed to model what would happen if one

critical assumption – growth – was removed from their forecasts. They felt that if Cisco had

25

tried to run modest declining demand models, then it might have seen the consequences of

betting on more inventory. They felt that Cisco should not have assumed that there would be

continuous growth. Having realized these problems, Cisco began taking steps, to set things

right. The company formed a group of executives and engineers to work on a 'e-Hub' remedial

program. Work on eHub began in late 2000. The project was intended to help eliminate

bidding wars for scarce components. According to Cisco sources, eHub was expected to

eliminate the need for human intervention and automate the flow of information between

Cisco, its contract manufacturers and its component suppliers.

eHub used a technology called Partner Interface Process (PIP) that indicated whether a

document required a response or not. For instance, a PIP purchase order could stipulate that the

recipient's system must send a confirmation two hours after receipt and a confirmed acceptance

within 24 hours. If the recipient's system failed to meet those deadlines, the purchase order

would be considered null. This would help Cisco to find out the exact number of manufacturers

who would be bidding for the order. According to the eHub setup, Cisco's production cycle

began when a demand forecast PIP was sent out, showing cumulative orders. The forecast went

not only to contract manufacturers but also to chipmakers like Philips semiconductors and

Altera Corp.

Thus, overlapping orders were avoided and chipmakers knew the exact demand figure. eHub

searched for inventory shortfalls and production blackouts almost as fast as they occurred.

However, work on eHub fell behind schedule due to its complexity and the costs involved.

According to Cisco sources, the company originally planned to connect 250 contractors and

suppliers by the end of 2001, but it could link only 60. It was reported that the number might

rise to around 150 by mid 2002. Company sources said that eHub was just the first stage of its

plans for automating the whole process of ordering and purchasing. Meanwhile, the company's

poor financial performance prompted analysts to comment that if the inputs were wrong, even

the world's best supply chain could fail. They added that only the next boom phase in the IT

business would prove the efficiency of eHub.

26

References

o www.cisco.com - Cisco

o wikipedia.com

o mbusi.com – Mercedes Benz

o Xerox.com – Xerox

o webfrontier.tridec.com - Xerox PeopleNet

27

28