IBM PSG: Implementing ERP

    College of Business Administration December
    6, 2000

    Florida
    International University

    IBM Personal
    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
    business model.

    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.
    .0/msohtmlclip1/01/clip_image001.gif”>

    1
    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.

    1

    Background

    Lou
    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.

    J.
    Bruce Harreld, Senior VP for Strategy, described the strategic imperative for
    IBM in 1993:

    ·
    Reduce costs

    ·
    Speed up product
    development cycles

    ·
    Go to market as one IBM, one integrated
    global organization

    ·
    Make it easier for
    customers to do business with IBM

    To
    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

    ·
    Human Resources

    ·
    Finance

    Nowhere
    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ä,
    Personal System/1ä,
    Personal System/2ä,
    Value Pointä,
    and Ambraä.

    1993
    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.

    Unfortunately
    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.

    2

    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.

    In
    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.

    By
    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.

    The
    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
    the Internet.

    One
    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,
    1999.

    Getting Started
    with SAP

    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
    quickly

    3

    zeroed
    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

    uncoordinated manner
    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.

    Over
    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.

    As
    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
    (PR1).

    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
    implement

    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.

    Half
    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.

    Stan
    Hankins, SAP Production Projects Manager, recalled:

    4

    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.

    The
    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
    implementation.

    ·
    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
    accommodated.

    ·
    Real-time
    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.

    Dick
    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.
    He recalled:

    5

    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.

    After
    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.

    The
    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.

    From
    the beginning of the PR2 project, the SAP implementation team was under
    pressure. Hankins recalled:

    We
    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,
    1999.
    We all agreed to make the commitment.

    Building
    the Implementation Team

    The project
    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

    6

    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.

    Plan
    teams were divided into development and deployment. The plans associated with
    development were:

    ·
    Process Plan

    ·
    Program Plan

    ·
    Data Conversion Plan

    ·
    Infrastructure Plan

    ·
    Group Model Plan and the Information
    Reporting Plan

    Senior
    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
    PR1.

    There
    were three plans associated with deployment:

    ·
    Organizational Change
    (designing a plan for how jobs will change and making the changes)

    ·
    End-User Education
    (designing a plan for educating the users of the system and offering training
    sessions)

    ·
    Deployment
    (providing a liaison from the project team to the user community) These plan
    owners reported to Billy Moran, RTP Site Deployment Manager. Moran

    reported
    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

    7

    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.

    An
    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

    everybody’s
    performance appraisal. We call them PBCs, personal business commitments, in
    IBM.

    RTP
    Production Ramp-Down

    Planning
    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
    .0/msohtmlclip1/01/clip_image002.gif”>
    2
    The management team was composed of John Corcoran, Tom Osterday (Manager of
    IT), and Stan Hankins.

    8

    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
    system.

    Corcoran
    recalls:

    Our
    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:

    There
    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.

    Production
    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.

    During
    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
    requirements

    Order for this paper or request for a similar assignment by clicking order now below

    Order Now

    Do NOT follow this link or you will be banned from the site!