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 nations 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 couldnt 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 years 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, IBMs 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, IBMs 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 cant 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 didnt 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 didnt make our revenue numbers for the first month or we didnt 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
everybodys 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 weeks 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 werent 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