College of Business Administration December
Systems Group: Implementing ERP1
There was an eerie quiet in the IBM
Personal Systems Group (PSG) plant in Research Triangle Park (RTP), North
Carolina. Hundreds of forklifts sat idle in the factory. The shipping docks,
usually filled with incoming supplies, were empty. The 2,500 employees who
normally worked in the plant each day were gone. The plant, which normally
produced 20,000 PCs a week, was shut down. The date was April 6, 1999. On this
date, the plant was to âgo liveâ with an implementation of the SAP R/3 system
known as Production Release 2 (PR2).
As John Corcoran,
Director, SAP Production Project, waited for the first transaction to be
processed by PR2 on April 6, he reflected on how PSG had come to this milestone
event. Several years before, PSG had recognized the need for an integrated
system that would allow better management of the supply chain across all of its
plants and quicker response to changes in the business environment. Most
recently, the success of Dell made clear to PSG the value of creating a CTO
(Configure-to-Order) business model in addition to its standard MTM (Machine
Type Model) business model. Having a set of autonomous plants, each with a
multitude of independent legacy systems that supported different business
processes was a significant obstacle to implementing this or any other new
On January 1, 1998, the first version of
an integrated production system based on SAP R/3, known as Production Release 1
(PR1), went live in the PSG plant in Guadalajara, Mexico. Given the experience
with implementing PR1 in the Guadalajara plant, the dedicated work of his
170-person international team, strong executive support, and an adherence to a
disciplined project management system, Corcoran was very confident of a
successful deployment of PR2 in the RTP plant. He was also very much aware of
the enormous risks involved. Failure to bring the plant back on line as
schedule d would be disastrous for the PSG group. PR2 was significantly more
complex than PR1. Imbedded in PR2 were over 300 new business processes and
subprocesses that would need to be executed by over 2,600 users.
Corcoran also knew that there would be
no time to rest and savor this major accomplishment. The project team would
have to quickly focus on the next system, PR3, which would be implemented at a
production facility in Greenock, Scotland. The team would also have to provide
upgrades to PR1 and PR2 in Guadalajara and RTP, respectively, so that all three
plants would be operating under a single âGroup Model.â The Group Model would
allow PSG to optimize its business across the plants by having common business
processes, a single development environment, and real-time access to
information from all PSG production and distribution facilities. As Corcoran
reflected on the work that would need to be completed during the next year, he
knew a solid foundation for success had been put in place, but there would still
be many challenges ahead.
This case was prepared by Professors Irma Becerra -Fernandez, Joyce Elam, Ken
Murphy, and Steve Simon, College of Business, Florida International University,
Miami, Florida, as the basis for class discussion rather than to illustrate
either effective or ineffective handling of an administrative situation.
Copyright 2000. The authors gratefully acknowledge the financial support
provided by the Ryder Center for Logistics for the research and preparation of
this case study.
Gerstner came to IBM as CEO in the spring of 1993. Big Blue lost $8 billion
that year, capping a three-year loss of nearly $16 billion. IBM was plagued
with high expenses, too many employees, and redundancies in manufacturing and
R&D. Whether IBM, one of the nationâs premier industrial giants, would be
able to make the changes necessary to survive was very much in doubt.
Bruce Harreld, Senior VP for Strategy, described the strategic imperative for
IBM in 1993:
Speed up product
Go to market as one IBM, one integrated
Make it easier for
customers to do business with IBM
accomplish this strategic imperative, IBM set out to transform the way it did
business by adopting five major, common, end-to-end business processes:
Integrated Product Development
Integrated Supply Chain
(Procurement, Production, Fulfillment)
Customer Relationship Management
was the need to transform the way it did business more evident than in the
Personal Systems Group (PSG). The PSG manufactured personal computers. Major
brands at the time included ThinkPadÃ¤,
was a difficult year for the PSG. In anticipation of strong PC sales, senior
PSG management convinced the business to authorize a significant expenditure to
buy more parts. In the past, PSG had been plagued by supply issues. This caused
the hottest products to often be out of stock. Dealers complained vehemently to
IBM executives and customers frequently wrote letter of disappointment about
out of stock products. PSG management wanted to avoid this situation and
provide high availability of its PC brands to meet market demand.
the sales failed to materialize as expected. Outdated and inadequate logistics
systems couldnât stop the parts that had been ordered from coming in. Parts
ordered for one model that was not selling could not be used in another model
that was selling. Technical problems with a new model, discovered just weeks
before its launch, meant that previously ordered parts sat on shelves.
Inventories increased dramatically and losses mounted.
Around the world, each manufacturing
plant had its own application systems and technologies for supporting the
various parts of the supply chain. This made it next to impossible to
coordinate a PSG-wide response to this problem. By yearâs end, the PSG had
missed their forecast âby several hundred million of dollarsâ and had over $3
billion remaining in inventory. The net loss was estimated to be $1 billion.
1994, Gerstner brought in a new management team for PSG. A massive
reengineering effort was launched to straighten out the manufacturing and
supply chain by removing inefficiencies caused by duplication and
fragmentation. The entire research and development operation was consolidated under
one roof in Research Triangle Park (RTP), North Carolina. Facilities in Boca
Raton, Florida; Lexington, Kentucky; and others around the world were shut
down. Most of the PC brands – PS/1, PS/2, Value Point, and Ambra – were
replaced. Only the ThinkPad brand was kept. Manufacturing continued to take
place around the world. The largest PSG manufacturing facilities were in RTP,
Guadalajara, Mexico and Greenock, Scotland. These manufacturing facilities
produced mainly (or solely) PSG products. Sites in Canada, Brazil, China,
Taiwan, Singapore, Japan, and Australia produced PSG products as well as other
products from other groups.
1999, IBM was vital and thriving again. The stock had reached its all-time
high. The balance sheet was cash-rich and its market capitalization had
increased more than fourfold to $169 billion. Since 1993, IBMâs reengineering
efforts had generated $9.5 billion in overall savings. Hardware development
cycle time had been reduced from 4 years to 16 months and for some products, it
had been reduced to as little as 6 months. Since 1993, IBMâs internal
information technology expenses had been reduced by nearly a third.
Personal Systems Group, however, continued to face a difficult competitive
environment. Fierce price wars had sharply reduced its profits. Its
competitors, most noticeably Dell, offered customers the ability to configure a
PC to order, while the PSG could only offer standard pre-defined models. The
PSG lost nearly $1 billion in 1998. In October 1999, IBM announced that up to
1,000 jobs were being cut in the PSG. IBM also announced that its Aptiva line â
the PC targeted for the consumer market – would now only be sold directly over
of the key factors for making PSG profitable again was getting in place a
single, worldwide-integrated system at its manufacturing sites. SAP R/3 had
been implemented at Guadalajara and RTP. Greenock, Scotland was scheduled to go
live in the summer of 2000. A high-level plan for deploying SAP in the
remainder of the manufacturing sites around the world was due late in the fall,
Jerry York was hired
from Chrysler Corporation as CFO in 1993. He had a reputation for turning
around poor performing businesses, having helped bring Chrysler back from near
collapse. With a mandate to aggressively search for ways to reduce costs, he
in on IT costs, which he felt were way too high. IBM, like many other Fortune
500 companies, had hundreds of duplicate, non-integrated systems that had
evolved in an
for decades. One way to reduce costs was to reduce the number of production,
logistics, and sales systems throughout the corporation. Corporate staff was
asked to investigate the situation and make a recommendation. Their
recommendation was that there was only one software solution that was big
enough and broad enough to
cover IBM across the board and that was
SAP. IBM Corporate decided to adopt SAP as the corporate enterprise resource
planning (ERP) solution in March 1995.
Once the SAP corporate
license was obtained, a corporate SAP project office was established. However,
groups were allowed to initiate their own SAP projects with little direct
involvement from corporate. Management within PSG decided to build a small,
pilot system for order fulfillment for the Aptiva line manufactured at RTP.
Aptiva was a low-end computer sold to big resellers like Best Buy, Circuit
City, and Wal-Mart.
time, a Corporate Blueprint was developed to try to bring some
standardization to the various SAP projects and to lay the groundwork for
integrating them. The Corporate Blueprintidentified four primary
process areas: Fulfillment, Production, Procurement,and Finance.
Fulfillment, Finance, and General Procurement would be corporate initiatives.
Production and Production Procurement would be left to the various hardware
groups. The Corporate Blueprint also defined corporate standards for
data, technical platforms, and SAP implementation methodology and tools.
a result of the Corporate Blueprint, a separate PSG system for
fulfillment for the Aptiva no longer made sense. The system was dismantled. A
decision was made to take the resources that had been allocated to the Aptiva
project and direct them toward creating an IBM Corporate Fulfillment SAP system
and a production system for the Guadalajara plant called Production Release/1
There were a number of
reasons for focusing on Guadalajara first. Guadalajara had a corporate sponsor.
Barbara Martin, Vice-President of Corporate Integrated Supply Chain and
Logistics, wanted to fund a pilot project that brought a major plant up on SAP.
The management of the Guadalajara plant very much wanted to be the first to
SAP. They were known
within Latin America as an innovative user of systems because of their
implementation of MAPICS, a relatively new integrated system developed by IBM.
The implementation at the Guadalajara plant was the least complex of all the
plants. The plant was at the time using MAPICS and only one other legacy
system. In addition, the Guadalajara plant was the smallest, making data
migration and deployment easier.
way through the Guadalajara project, Bob Moffat was put in charge of PSG
manufacturing and engineering worldwide. Moffat came from Finance and was very
concerned about all of the money being spent on SAP.
Hankins, SAP Production Projects Manager, recalled:
Moffat told us that we had fifteen days
to pull a business case together. He said that he was either going to stop the
project and disband the SAP project team or he was going to get 100% behind the
project. We took the approach of putting in as few benefits that we could and
still achieve the hurdle rate required for IBM. We took some very believable
items in terms of what the savings would be and then described some of the
functional benefits. We said: âHere is what we are doing today and here is how
we will do it tomorrow. Here is what you get in cycle time. Here is something
we have been trying to do but canât do in our legacy systems.â
The business case was
based on SAP implementations at the three major plants in Guadalajara, RTP, and
Greenock, Scotland. Part of the rationale built into the business case was that
the real savings would come from these three plants, since over 75% of
manufacturing would occur there. There would be less development and more
deployment costs as SAP was implemented in Asia-Pacific, Australia, and Brazil.
business case was also based on PSG implementing a âGroup Model.â The concept
of the Group Model for PSG included a common processing configuration, common
architectures, education and process documentation, and overall requirements
and release components. The Group Model embodied the following concepts:
Common Processes –
Business processes would be developed and configured in SAP to support common
processes worldwide. Although there are legal, financial, and operating
differences resulting in some sites, commonality was the cornerstone of the SAP
Common Development and
Support â Configuration and code development would be supported by a group of
programmers and analysts residing at RTP, while report development would be
supported from Guadalajara. The development groups would share one single
development environment. End-user support would be located in each site to
optimize responsiveness, but all fixes and enhancements would be managed
centrally to maintain commonality control.
Common Architectures â Production would
be run from one SAP production instance.
Common Education and
Process Documentation â Training materials would be developed centrally and
distributed to each manufacturing site. National languages would be
Access to Information from all PSG production and distribution facilities â
This will be accomplished through real-time integration within SAP, interfaces
to PSG decision support tools, and interfaces with complementary applications.
Joyce, the Program Director responsible for the strategy to develop and implement
SAP Worldwide within PSG, took the lead in putting the business case together.
We basically had three components to our
business case: infrastructure reduction associated with going from three different
IT organizations with different legacy systems to one, a one-time productivity
savings of 10% to occur in the second year of deployment, and a one-time
inventory improvement of between 5% to 10%. We created six pages of charts that
described about forty-one benefits of SAP. We were about half way through the
benefits and Moffat said âI give.â He saw the potential and how SAP favorably
compared to our legacy systems.
Moffat gave his approval to continue with the implementation, he took over as
Executive Sponsor. The SAP implementation at Guadalajara went live in January
1998, right on schedule, scope and budget.
Implementation of PR2
Following the successful implementation
of PR1, the SAP project team turned its attention to the RTP plant.
Implementing an integrated production system, Production Release 2 (PR2) at the
RTP site was considerably more complicated than Guadalajara. PR2 would embody
300 new business processes and subprocesses and replace several critical,
technologically obsolete systems. In addition, interfaces to numerous other
legacy systems would need to be developed so that they could exchange data with
PR2. Exhibit 1 shows the IT applications map that would exist after the
implementation of PR2.
the beginning of the PR2 project, the SAP implementation team was under
pressure. Hankins recalled:
put together the project plan for PR2. When Moffat saw it, he told us to take
$5 million off the cost and improve the delivery date by three months and not
reduce the scope. This was a huge request! We had to go back to the drawing
board and get creative. Buffer contingency in the schedule was taken out. Some
phases had to be overlapped rather than completed serially. I asked my team
leaders during a meeting in April whether they could commit to this new plan
for going live on April 6,
We all agreed to make the commitment.
the Implementation Team
organization chart is shown in Exhibit 2. The overall management structure for
the PR2 project consisted of a matrix with âprocess teamsâ and âplan teams.â
There were six process teams, each associated with one of the following modules
in SAP: manufacturing, sales and distribution, production planning, finance and
costing, procurement, and engineering change. The process teams had
responsibility for designing the new business processes to be implemented in
SAP. The process team
leaders owned the human resources from
the business side and were responsible for managing and allocating the human
resources to the âplan owners.â The process teams were composed of PSG
employees from RTP, Guadalajara and Greenock, Scotland as well as IBM Global
Services consultants and outside contractors. Process team leaders reported to
Stan Hankins. There were approximately 80 people in these teams. Many of these
individuals were also involved in the development and deployment of PR1.
teams were divided into development and deployment. The plans associated with
Data Conversion Plan
Group Model Plan and the Information
IT managers were the plan owners in each of these areas. Plan owners designed
an overall project plan that detailed all the activities for their assigned
area that had to occur between the start of the project and April 6. Plan
owners were responsible for ensuring that milestones defined in their plans
were met. In additional to the human resources from the process teams, these
plans owners had access to the IT organization. As part of the Process Plan, IT
employees configured in SAP the PSG business processes as defined by the
process teams. The Program Plan required IT employees to develop the code to
bridge SAP to the other âlegacyâ information systems supporting the business.
In addition to building bridges to the remaining legacy systems, the IT team
was responsible for extracting data from the systems being retired and placing
data into SAP in support of the Data Migration Plan. Lastly, the IT team was
also responsible for defining the Systems Architecture, which is the hardware
and software supporting the application, and the Group Model Plan, which is the
common architecture for a single system for all
plants. There were also
approximately 80 people in the IT organization. As with the process teams, many
of these individuals were also involved in the development and deployment of
were three plans associated with deployment:
(designing a plan for how jobs will change and making the changes)
(designing a plan for educating the users of the system and offering training
(providing a liaison from the project team to the user community) These plan
owners reported to Billy Moran, RTP Site Deployment Manager. Moran
to a site Vice President but was also responsible to Corcoran. Regular
communications were established with the user community to keep them informed
about the SAP project. A copy of a newsletter sent to employees is shown in
Exhibit 3. An example of a high-level deployment plan is given in Exhibit 4.
In addition, a project
office was established that had overall responsibility for the project deliverables.
John Kenniff was named Project Manager. The project office also had
responsibility for ensuring that the
Worldwide Solutions Assigned and Delivery Method (WSDDM) project management
methodology was used throughout the project. An overview of WSDDM is shown in
Exhibit 5. Weekly meetings were held between the plan owners, the project
manager, and the management team2to
review plan status and to redirect resources to problem areas as needed. A
summary of the PSG SAP PR2 Production Plan is shown in Exhibit 6.
incentive system was put in place for the project leaders, plan owners, and
process team leaders. Hankins explained the system:
We gave them targets.
If they made all of them, they each would get a bonus representing a
significant percentage of their annual compensation. If they didnât make them,
they received nothing. The targets were: achieving each milestone in a plan,
deploying on schedule, staying within the budget, and getting certified prior to
deployment. In addition, once we went live, we could not have any negative
business impact. In other words, if because of SAP we didnât make our revenue
numbers for the first month or we didnât meet our commitment on how we were
going to ramp the volume up, we would not make our overall goal. These targets
were communicated to everybody on the team and they were in
performance appraisal. We call them PBCs, personal business commitments, in
for PR2 deployment was begun in the 3rd
quarter of 1998 and continued until the go-live day. Weekly meetings were held
to define responsibilities for the management of functional areas, data
cleaning and migration, system testing and user support. An extremely detailed
âmove to production planâ was designed that defined hour-by-hour the activities
on the go-live date. The working strategy for the ramp-down/ramp-up of PR2 is
illustrated in Exhibits 7, 8, and 9.
To successfully accomplish PR2
deployment, manufacturing commitments for 2nd
quarter 1999 had to be greatly reduced. RTP volume for the entire month of
April was scheduled to be 20,000 boxes. This was equivalent to that of a
typical weekâs production. The difference was off-loaded to the plant in
Guadalajara. The decision to off load work to Guadalajara had to be made early
in the planning cycle, since all components and other materials had to be
delivered there. In addition, all suppliers to the RTP had to be informed of
the shut down. In some cases contracts had to be altered.
As the go-live
approached, there were still a number of serious unresolved issues. Four weeks
before going live, a major problem with the implementation of the DB2 database
being used by PR2 was encountered. There were also R/3 software modules that
were still being tested, and end-to-end system testing was still not complete.
A tricky business
The management team was composed of John Corcoran, Tom Osterday (Manager of
IT), and Stan Hankins.
process for third party orders that
required some special logic with respect to the returns of merchandise was
still not solved. Finally, many of the users still needed to be educated in the
desire to go live was intense. At the 30-day countdown you can only go forward.
It would be almost impossible to do anything else.
Carl Pelon, the
Deployment Plan Owner, reflected on the 30-day period prior to go-live:
was more stress than we have ever had in our careers. We realized that we were
committed at that point and it still looked like we had three months of work to
go. We had back-up strategies, but I would sure hate to live through one.
Nobody was going to say that we werenât going to make it but I think a lot of
the people thought it.
ramp down at RTP was completed on March 27. At this point the team had the task
of closing the books on the old legacy systems. This required working until
midnight to ensure that every drop of revenue was captured. The plant was taken
down on the 27th
to provide ample time to complete the final data migration from the legacy
systems. The legacy systems ran overnight batch bridges, so the team needed to
allow enough time to fix any potential bridge errors.
the shutdown period between March 27 and April 6, the focus was on data
migration. The process of data conversion had begun months earlier with
the data conversion managers working with the process team to define the data