Description Prepare a 2 page memo addressed to Corinne Ingall. In that memo, identify the positive factors that favor going live and the negative factors which favor not going live. Which two (2) items do you consider to be most important (and why)? Do not to make a go live/don’t go live recommendation. 1 attachmentsSlide 1 of 1attachment_1attachment_1.slider-slide > img { width: 100%; display: block; } .slider-slide > img:focus { margin: auto; } Unformatted Attachment Preview S w 9A99E031 Stéphane Marchak prepared this case under the supervision of Professor E.F. Peter Newson solely to provide material for class discussion. The authors do not intend to illustrate either effective or ineffective handling of a managerial situation. The authors may have disguised certain names and other identifying information to protect confidentiality. Ivey Management Services prohibits any form of reproduction, storage or transmittal without its written permission. Reproduction of this material is not covered under authorization by any reproduction rights organization. To order copies or request permission to reproduce materials, contact Ivey Publishing, Ivey Management Services, c/o Richard Ivey School of Business, The University of Western Ontario, London, Ontario, Canada, N6A 3K7; phone (519) 661-3208; fax (519) 661-3882; e-mail cases@ivey.uwo.ca. Copyright © 1999, Ivey Management Services Version: (A) 2010-01-15 AMP OF CANADA’S YEAR 2000 COMPLIANCE PROBLEM In the summer of 1997, management at AMP of Canada learned that its existing transactional processing system JBA was not year 2000 compliant. AMP of Canada had three options to becoming year 2000 compliant: upgrade JBA, implement the headquarters-recommended AMPICS system, or implement the very popular SAP system. AMP of Canada’s IS manager wanted to upgrade JBA, but Canadian management wanted to implement SAP. Headquarters in the United States wanted to implement AMPICS as a transition to AMP’s global SAP roll-out. The controller of AMP of Canada, Doris Puddington, had discussed the alternatives with both her IS manager and Canadian management, and concluded that AMP of Canada should implement SAP. Doris knew the most serious obstacle to implementing SAP was IS management in AMP’s headquarters of Harrisburg, Pennsylvania. She had several conference calls with American IS managers during which she told them about a rapid implementation she had seen presented by a Canadian business partner of SAP. The business partner used the new rapid implementation methodology called ASAP. After hearing about this new methodology, Harrisburg’s IS management became keenly interested in testing the ASAP methodology in Canada. AMP had been involved with SAP since 1996, but had only recently begun designing one global framework for how all AMP companies would use SAP. AMP had almost completed the global design of the financial template, and was scheduled to go-live with the financial modules of SAP (FI and CO) on January 1, 1998. The global design of the sales (SD), materials (MM), and manufacturing (PP) modules would proceed after the financial modules were implemented. Because process re-engineering was being done at the same time as systems design, senior management in Harrisburg thought the project was taking a long time. The Canadian situation presented an opportunity to test a faster implementation. In August 1997, Canadian management and Harrisburg compromised on a solution. AMP of Canada would implement the basic modules of SAP using a “big bang” approach, with no dual operation period of the old and new systems. AMP of Canada would implement the following SAP modules by October 1, 1998: Sales and Distribution (SD), Materials Management (MM), Production Planning (PP), Financial Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. AMP OF CANADA (B) 9A99E031 Accounting (FI), and Controlling (CO). Early in 1998 the Warehouse Management (WM) module was added to the project. Other non-critical modules including Quality Management (QM), Plant Maintenance, (PM), Project Systems (PS), and Workflow (WF) would be implemented after October 1998. Refer to Exhibit 1 for a list of SAP modules. Only basic “vanilla” functionality would be implemented to save time by not re-engineering business processes. The project would use SAP’s new Accelerated SAP implementation methodology called ASAP. The project team would be composed of full-time AMP of Canada employees who would be backfilled by temporary staff. The team would go on SAP configuration training and be responsible for the system configuration. The system box and technical support would be located in Harrisburg. AMP of Canada would adopt the global SAP project’s design as much as possible, but after February 1998 would be free to deviate from the design to meet go-live requirements. This allowed most of the global SAP project’s FI design to be used on the Canadian project, and parts of the CO design. Where design decisions had been finalized in other modules, they were also adopted by AMP of Canada. Harrisburg Information Systems had a few extra conditions. Because of AMP’s existing relationship with SAP, contracts for the Canadian project would have to be signed with SAP itself instead of a local consulting business partner. Although this increased the budget to about Cdn$9 million, the fit with the corporate strategy was better. SAP was much more knowledgeable about AMP’s requirements than any other vendor because it had already been working on re-engineering for AMP and had done implementations at other AMP sites. The team leader would have to regularly report progress, issues, and lessons learned to the U.S. project office. This was to ensure that Canada adopted global standards, and to enable the global team to learn the ASAP methodology for future AMP implementations. THE ASAP METHODOLOGY AND PROJECT PLAN The ASAP methodology had been used in several other projects, ranging in duration from six to twelve months. The methodology had five phases: Project Preparation, Business Blueprint, Realization, Final Preparation, and Cutover / Post Go-Live Support (see Exhibit 2 for the original project plan). The ASAP methodology called for Phase 1 to be completed by the end of October 1997. Tasks in this phase included selecting the project team, writing the project charter, selecting a team name, and hiring consultants. As project sponsor, Doris committed to having “no Show-Stoppers”, which meant that no single problem would be so grave that it would stop the October go-live. AMP would do whatever was necessary, including hiring temporary employees, asking full-time employees to work overtime, or manually processing transactions to work around any outstanding problems with SAP instead of delaying the go-live. Phase 2 was planned to end by December 1997. This phase involved documenting user requirements for the system, identifying which components of SAP were in scope for the project, and sending the project team on introductory SAP training. The 500-page Business Blueprint was completed by the end of December 1997 when user champions signed-off on the Business Blueprint. Phase 3 was the busiest phase, and was planned for completion by the middle of August 1998. Tasks in this phase included configuration of the system, testing and documenting of business processes in SAP, identifying data conversions and writing conversion specifications, testing interfaces to and from external systems, designing reports and forms, and developing enhancements. Enhancements were programs written to augment SAP functionality that did not change the source code. Unlike modifications, enhancements were supported by SAP. Having learned from the JBA experience, the project charter called Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. Page 2 Page 3 9A99E031 for no system modifications. In Phase 3 the project team would also go on configuration training and begin preparing the training materials, facilities, and schedule. Phase 5 was planned to last one month after go-live. The key task here was to identify and close post golive issues. Most consultants were scheduled to leave after Phase 5. The project team was supposed to return to their old jobs soon after this phase. THE PROJECT TEAM The project team would be structured with a core team and an extended team. The core team would work full-time on the project, while the extended team would assist part-time as required, particularly with conversion testing, business process clarification, etc. The core team would consist of two users from sales, two users from procurement, three users from manufacturing, two users from finance, and one technical person. A few of these people were on the JBA implementation team, including one user in sales, one in manufacturing, and one in finance. Other SAP core team members joined the JBA project near the end to help with testing and training. Corinne Ingall was an employee of AMP of Canada designing the product costing template for the global SAP project. Corinne had been on the JBA project and would be one of the SAP financial core team members, but also had the responsibility of AMP project manager, with the core team reporting to her. She would be responsible for managing the project, including issue resolution, budgeting, testing, and training. If an issue could not be resolved at the project team level, the issue would be raised at the project Steering Committee level for resolution in 24 hours. The Steering Committee was composed of AMP of Canada’s general manager, general sales manager, manufacturing manager, logistics manager, controller, quality manager, and human resources manager (see Exhibit 3 for a partial AMP of Canada organizational structure). Richard Stoveld would share the responsibilities of project management from the technical perspective. He would be responsible for programming resources and coordination with basis administration in Harrisburg. Scott Bechtel was a SAP consultant hired to assist Corinne Ingall as SAP project manager. He would be responsible for coordinating with consultants and SAP for project issues. One consultant would also be hired for each module being implemented: SD, MM, PP, FI, and CO. User champions were identified in the user community. They would be responsible for making decisions about how business processes would work in SAP. See Exhibit 4 for the Destiny 2000 project team. PROJECT EVENTS In August 1997 the core team was selected. The project officially began in September 1997, with the core team going on level 2 (introductory) SAP training. The project was also given a name: Destiny 2000. A mission statement and project charter were written: Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. In Phase 4, end users would be trained, data would be converted, and other final preparations for go-live would be completed. Phase 4 was planned to end with the cutover to SAP on October 5, 1998. The date was changed from October 1 because that date fell on a Thursday, whereas October 5 was a Monday. Page 4 9A99E031 • • • • No modification will be made to the software in order to preserve a path for future upgrades. AMP Global Standard configuration templates will be used in order to support the AMP Business Model. The primary focus of the team will be to go live with base functionality; incremental improvements will be made in future phases. Minor reengineering of AMP’s Business Processes may be required upon approval. When the core team was not on training, they interviewed the user champions to identify business process requirements. The results of these interviews were used to complete a list of SAP business processes inscope for AMP of Canada called the Business Blueprint. This document was completed on December 19, 1997. The Business Blueprint identified by module the number of conversions, interfaces, reports, forms, and gaps requiring enhancements. After the Business Blueprint was completed, the Business Process Master List (BPML) was generated. The BPML listed each SAP transaction in scope, and suggested a test plan that grouped related transactions. Business Process Procedures (BPPs) would have to be written for each transaction and unique AMP business process. A BPP explained in detail how a user performed a specific business transaction in SAP. For example, a BPP was written for the Create Sales Order transaction. Additional BPPs were written for the different kinds of sales orders that AMP used (such as a regular order, an EDI order, a sample order, etc.). BPPs were used as the basis for training material. Refer to the list below for a summary of the information in the Business Blueprint and BPML at the start of 1998. Unique Transaction Codes in Scope Conversions Interfaces Reports (see note below) Forms Gaps and Enhancements Business Process Procedures (BPPs) SD MM PP FI CO Total 96 91 42 99 143 471 5 20 58 (23) 8 3 11 14 34 (25) 3 0 6 0 44 (13) 1 0 4 5 49 (2) 3 1 2 2 52 (20) 0 3 28 41 237 (83) 15 7 118 98 95 140* 255 706 Note: In the Reports row, the first number represents the initial number of reports identified in each module. The number in brackets represents the final number of reports required. For example, FI started with 49 identified reports, but had only 2 written because many reports that could be generated using standard SAP functionality were no longer required because of how SAP worked, or were cancelled for other reasons. * Harrisburg had already written about 100 of the 140 FI BPPs. Harrisburg had not written most of the CO BPPs. Because there were so many business processes in finance, Corinne hired an extra CO consultant in January to assist with Product Costing and Profitability Analysis configuration. In February 1998, Todd Durnford was moved from the extended team to the core team to represent the warehouse for configuration and testing of the warehouse management (WM) module. A WM consultant was contracted to do the Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. AMP of Canada’s Destiny 2000 Team will implement a core set of SAP software by October 1, 1998 in order to gain Year 2000 compliance for the corporation. The project team will work according to these guiding principles: Page 5 9A99E031 By the end of March 1998, the core team had completed configuration training. As the consultants finished configuration of the system, the core team tested transactions and began writing BPPs. Harrisburg required weekly reporting on the number of completed BPPs to track the project’s progress. Both the configuration and BPPs were completed by the middle of the summer. The ASAP methodology employed four rounds of cycle testing, where transactions were tested within specific modules, and two rounds of integration testing, where transactions were tested across functional modules. The core team was separated into two testing teams based on similar business processes: Manufacturing and Distribution. These two teams conducted both cycle and integration testing of transactions relating to manufacturing and distribution processes. The configuration and testing of some functionality such as vendor evaluation and physical inventory counting were postponed until after go-live. By the beginning of September, application testing was complete. The project team began working on testing and refining the conversions, interfaces, forms, reports, and enhancements. End-user training material was also written and the training schedule was planned. BUSINESS EVENTS AMP globally had a difficult year in 1998. Results from the first quarter were disappointing. To address these results, AMP announced a series of American plant closures beginning in April. In June 1998, Canadian management decided to close the manufacturing facility in Montreal. All machinery and inventory would be transferred to the Markham plant. This required minor rework of SAP configuration, but took important extended team resources away from working on SAP issues, especially the manufacturing data conversions. On June 26, AMP Incorporated announced mandatory furloughs for American employees. Weakness in Asia was cited as the reason for worsening business results. Although this did not apply to Canadian employees, it worsened morale on the project team and throughout AMP of Canada. Some employees started to worry that Canada would also have to implement mandatory furloughs. AMP’s share price sank from its all-time high of above $50 to below $30 in response to these events. On August 6, Allied Signal made a hostile takeover bid for AMP. Allied Signal offered $44.50 for AMP’s stock. This created huge uncertainty for both AMP worldwide and the SAP project. Although there was support for Allied Signal’s offer in the marketplace, AMP was incorporated in Pennsylvania, which had very strong anti-takeover legislation. Harrisburg and Allied Signal management fought a public relations war over the takeover while AMP began searching for a white knight. THE GO-LIVE DECISION By September 1998, the project had reached a critical decision point. Although configuration, testing, and BPPs were completed, certain conversions and interfaces were not. The final preparations for go-live in Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. actual configuration. Configuration in SAP involved changing a series of table settings that controlled how transactions worked. For example, part of the pricing configuration controlled whether unit prices extended by order quantities were rounded up or down to the nearest penny. The consultants were hired to do the actual configuration, and also to transfer this knowledge to the core team by demonstrating and documenting how the system was configured. Page 6 9A99E031 APPLICATION AUDIT — SD (SALES AND DISTRIBUTION) By the middle of September 1998 the customer conversion had been completed. However, the pricing conversion had not been successfully completed. The pricing conversion was taking longer than expected because of the sheer volume of data (over one million records) and the complexity of the conversion logic. The interfaces for reporting sales information to Harrisburg had been completed, but the data feeds to and from AMP’s custom Pricing System were not complete. AMP of Canada’s Pricing System was a stand-alone Power Builder application written to analyse margins and quote customers special agreement pricing. When designing SAP, the project team determined that SAP could not handle AMP’s requirement for analysing the profitability of quotes at the management level (which excluded intercompany transfer pricing mark-ups). Standard SAP only supported analysing quotes at the statutory level, which included intercompany mark-ups. The Pricing System would have to be rewritten to use SAP pricing and costing information as well as AMP’s existing quote history. The Pricing System’s programmer estimated that it would take a few weeks to complete the interface of SAP pricing and costing data. The SD forms such as the customer invoice and credit memo were tested and completed. The SD enhancements of the Internet Price and Delivery screen, SAP Price and Delivery screen, and the commit date / rescheduling program were tested successfully. User training was completed except for the Pricing department. The customer EDI interfaces had been successfully tested. APPLICATION AUDIT — MM (MATERIALS MANAGEMENT) In Materials Management, the conversion of the material master had just been finished. This conversion had taken weeks longer than planned because of the tremendous complexity of the material master. One core team member was responsible for the conversion of 500,000 records with 50 fields. By the end of the conversion testing, all extended team members and some regular users were testing this conversion. Testing identified many data quality and specification problems from the Harrisburg data transmissions that could not be completely fixed until after go-live. The vendor conversion was completed successfully. Because of the great workload in MM, one member of the PP team was moved to the MM team to help with testing and training. The weekly and quarterly Material Master Send and Receive data interfaces had been completed, but the EDI transmissions of purchase orders, goods receipts, and vendor invoices had not been completed. Every day, AMP of Canada sent purchase orders using EDI to related AMP companies for nearly all the nonmanufactured product it sold. At night, Harrisburg sent AMP of Canada the goods it was shipping the following day by truck so that the physical receipt of the goods would take less time. Only the differences between what was sent electronically and what was actually received had to be entered in the system. Related AMP companies also sent invoices via EDI. Although this cycle of Purchase Order, Goods Receipt, and Invoice Receipt had been tested several times, each subsequent test solved the problem of the Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. Phase 4 began in late August. The part number, bills of material, routers, and activity price conversions were all completed on the first weekend in September for the standard cost conversion in SAP. However, certain interfaces such as the AMP Inc. EDI and Pricing System data feeds had not been finished yet. Corinne and the project team had to decide whether or not to go-live on October 5. To help make this decision, she reviewed the status of each module. Page 7 9A99E031 Users were starting to ask for new functionality to be configured. Now that they were learning about the system, planners wanted to configure the Sales and Operations Planning part of SAP to drive the manufacturing business. This functionality would allow forecasts to be entered at a material group level instead of an individual material level but still feed MRP. A core team member of PP thought this functionality was so important that the go-live date should be postponed until the beginning of November to configure and test this functionality. Training was not going well for material planners. Although they had practised the transactions in their lessons, the functional integration was not apparent to them. The core team had serious doubts about how well the planners would do their jobs in October. In Warehouse Management, the conversion of inventory quantities had been successfully tested. There were still some testing issues with bar coding for AMP Inc. and French labelling for one Quebec customer, but these were expected to be completed before go-live. User training was also progressing slowly in WM. During the course of training, warehouse users were being exposed to the system, and were beginning to realize that SAP required them to enter much more data, which would slow their work significantly. Before going live, a physical inventory count would have to be conducted to get inventory data at the bin level. Quantities could not be loaded into SAP without bin-level information. The count had been scheduled for months, but could not be easily rescheduled, because many people were required to work for two complete days counting materials. APPLICATION AUDIT — PP (PRODUCTION PLANNING) In Production Planning, the bills of material and routers conversions had been tested successfully and run for the standard cost conversion. Work centres had been manually loaded into SAP. The Production Order printout form and the reports such as the Factory Order On-Time report were completed. APPLICATION AUDIT — FI (FINANCIAL ACCOUNTING) In FI, the conversions had been successfully completed. Customer balances, credit limits, general ledger balances, and fixed asset data were all completed or expected to be completed before go-live. The interfaces except for the AMP EDI Invoice Receipt were completed. Although the Invoice Receipt was still being tested as part of AMP Inc. EDI, the outbound related-AMP Customer Invoice EDI interface was postponed until after go-live. The major enhancement in FI was the Credit Alert system, which had been successfully tested. The FI and CO reports were still being written by their primary user, who expected to be completed before go-live. User training was complete, with key users quick to learn the system. Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. previous test but revealed a new problem. The core team member testing EDI was the same person responsible for converting the material master, and she did not know if EDI would be ready by go-live. She wanted more time for testing. Page 8 9A99E031 The situation in Controlling had stabilized from the huge workload seen in January. The number of BPPs had been greatly reduced as the core team became more familiar with functionality in CO. All BPPs had been written, there were no conversions to test, and only one major interface. The yearly and quarterly standard cost SS40 interface had been successfully tested. The three enhancements written for product costing had also been completed. Users were also trained to do product costing and profitability analysis in SAP. GENERAL STATUS All remaining conversions would take two weeks to run using direct input. Direct input wrote data directly into SAP tables instead of using the standard SAP transaction to create the data. If the SAP transactions were used instead of direct input, the material master conversion alone was estimated to take months to complete. Like the regular transaction, direct input validated the data being loaded for required fields. The SAP project manager Scott Bechtel had initially projected the project would take 10 months, and Corinne used this estimate to budget the project. In June 1998 it became apparent that the early go-live date would not be possible to meet, and Corinne had to request an increase to the budget. Now that the target go-live date was in question again, Corinne wondered if she would be able to get another budget extension from Harrisburg. Although she was $200,000 under budget, she was concerned about problems that might arise after go-live that would require additional expensive consulting resources to solve. On the morning of September 21, Corinne had an emergency meeting with the core team. She asked each team member whether or not AMP of Canada should go-live on October 5, and whether AMP of Canada could continue to take orders, ship product to customers, and conduct normal business transactions. The vote was split six to four in favor of going live, not including Corinne (see list below). Richard qualified his vote by stating that although he thought AMP of Canada could take orders and ship product to customers, it should allow more time for testing. Several technical and application consultants thought that AMP should allow more time for testing. Corinne wondered whether or not SAP should go-live on October 5, and what action plan to present to the Steering Committee in her meeting later that morning. SD Core Team Suzanne —Yes Joyce — Yes MM Core Team Gail — Yes Jodi — No Janice — No Todd — Yes PP Core Team Ravi — No John — Yes FI/CO Core Team Steph — Yes Corinne — Not Yet Voted Technical Team Richard — Qualified No Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. APPLICATION AUDIT — CO (CONTROLLING) Page 9 9A99E031 Exhibit 1 SD – Sales and Distribution FI – Financial Accounting • • • • • • • • • Order Entry Pricing Shipping Billing Foreign Trade General Ledger Accounts Receivable Accounts Payable Fixed Assets MM – Materials Management CO — Controlling • • • • • • • • • • Forecasting Material Requirements Planning (MRP) Purchasing Inventory Management Warehouse Management Product Costing Profitability Analysis Cost Centre Accounting Internal Order Accounting Profit Centre Accounting PP – Production Planning PS – Project Systems • • • • • • Master Production Scheduling (MPS) Capacity Planning and Leveling Production Orders QM – Quality Management Project Accounting Project Logistics Cross-Application Timesheet WF – Workflow Note: Shaded modules were out of scope for the October 1998 go-live date. Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. SAP MODULES AND DESCRIPTIONS Page 10 9A99E031 Exhibit 2 ID 1 68 229 230 347 356 394 402 458 467 482 487 512 524 527 528 553 558 566 578 579 580 592 601 605 606 622 634 655 WBS 1 2 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 5.1 5.2 5.3 5.4 Task Name Phase 1: Project Preparation Phase 2: Business Blueprint Phase 3: Realization Project Management Project Team Training Baseline Configuration and Confirmation System Management Final Configuration and Confirmation Development Create Authorization Design Establish Archiving Management Integration Test End User Documentation and Training Materials Development Quality Check Realization Phase Phase 4: Final Preparation Project Management Final Preparation Phase Validate Systems Authorizations End User Training System Management LIS/SIS/ABAP Non Critical Reports Create End User Documentation (Cont.) Detailed Project Planning Cut Over Quality Check Final Preparation Phase Phase 5: Go Live and Support Project Management Final Preparation Phase Production Support Post Go-Live Activities Quality Check Go Live and Support Phase Dur 30 days 104 days 172.5 days 155 days 63 days 79 days 136 days 45 days 165 days 165 days 25 days 32.1 days 77 days 1.5 days 85 days 31 days 21 days 45 days 24.5 days 28 days 42 days 12 days 7 days 1 day 29 days 10 days 20 days 29 days 2 days Start Wed 10/1/97 Thu 10/9/97 Mon 1/5/98 Fri 1/16/98 Thu 2/5/98 Mon 1/26/98 Mon 2/2/98 Thu 5/14/98 Mon 1/5/98 Mon 1/5/98 Thu 7/16/98 Thu 7/16/98 Fri 5/15/98 Tue 9/1/98 Mon 8/3/98 Mon 8/17/98 Mon 8/24/98 Mon 8/3/98 Sat 8/15/98 Mon 8/24/98 Thu 10/1/98 Tue 8/25/98 Mon 9/28/98 Mon 10/5/98 Mon 10/5/98 Mon 10/5/98 Mon 10/5/98 Mon 10/5/98 Mon 11/2/98 Finish Tue 11/11/97 Tue 3/3/98 Wed 9/2/98 Thu 8/20/98 Mon 5/4/98 Thu 5/14/98 Mon 8/10/98 Wed 7/15/98 Fri 8/21/98 Fri 8/21/98 Wed 8/19/98 Mon 8/31/98 Mon 8/31/98 Wed 9/2/98 Wed 11/25/98 Mon 9/28/98 Mon 9/21/98 Fri 10/2/98 Fri 9/18/98 Wed 9/30/98 Wed 11/25/98 Wed 9/9/98 Sun 10/4/98 Mon 10/5/98 Thu 11/12/98 Fri 10/16/98 Fri 10/30/98 Thu 11/12/98 Tue 11/3/98 Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021. Use outside these parameters is a copyright violation. AMP OF CANADA DESTINY 2000 PROJECT PLAN Page 11 9A99E031 Exhibit 3 John Kohler General Manager Lenore Purvis Logistics Manager JoyceMacLellan Inside Sales Manager Terry Lawrence Purchasing Manager Dean McCreadie Warehouse Manager Suzanne Watson Inside Sales Representative Gail Fair Buyer Todd Durnford Receiving, Manufacturing Harland Ramsay Customs and Traffic Manager Jeff Lacher Material and Production Control Manager Jodi Burch Materials Planner Janice McKenzie Production Planner Doris Puddington Controller Tony Scappaticci Manufacturing Manager Warren Hamley General Sales Manager Corinne Ingall SAP Project Manager Ravi Verma Manufacturing Engineer Donna Holmes Telemarketing Business Unit Manager Richard Stoveld AS/400 Team Leader Wing Yip Manufacturing Engineer Kevin Earle Quality Manager John Wong Quality Assurance Wally Heard Quality Assurance Mauro Cappuccio LAN Team Leader Daniel Lee Pricing Team Leader Legend Bob Thivierge Credit Manager BonnieMayes Senior Credit Specialist Chris Timal Accounting Manager Sandra Pepin Costing Analyst Team Leader Steph Marchak Finance Systems Analyst Anahid Mahdessian Accounts Payable Specialist Employee Simon Wong Senior Financial Analyst Operations Committee SAP Team Member Peter Ferguson Human Resources Manger Authorized for us

Description

Prepare a 2 page memo addressed to Corinne Ingall. In that memo, identify the positive factors that favor going live and the negative factors which favor not going live. Which two (2) items do you consider to be most important (and why)? Do not to make a go live/don’t go live recommendation.

1 attachmentsSlide 1 of 1attachment_1attachment_1.slider-slide > img { width: 100%; display: block; }
.slider-slide > img:focus { margin: auto; }

Unformatted Attachment Preview

S
w
9A99E031
Stéphane Marchak prepared this case under the supervision of Professor E.F. Peter Newson solely to provide material for class
discussion. The authors do not intend to illustrate either effective or ineffective handling of a managerial situation. The authors may
have disguised certain names and other identifying information to protect confidentiality.
Ivey Management Services prohibits any form of reproduction, storage or transmittal without its written permission. Reproduction of
this material is not covered under authorization by any reproduction rights organization. To order copies or request permission to
reproduce materials, contact Ivey Publishing, Ivey Management Services, c/o Richard Ivey School of Business, The University of
Western Ontario, London, Ontario, Canada, N6A 3K7; phone (519) 661-3208; fax (519) 661-3882; e-mail cases@ivey.uwo.ca.
Copyright © 1999, Ivey Management Services
Version: (A) 2010-01-15
AMP OF CANADA’S YEAR 2000 COMPLIANCE PROBLEM
In the summer of 1997, management at AMP of Canada learned that its existing transactional processing
system JBA was not year 2000 compliant. AMP of Canada had three options to becoming year 2000
compliant: upgrade JBA, implement the headquarters-recommended AMPICS system, or implement the
very popular SAP system. AMP of Canada’s IS manager wanted to upgrade JBA, but Canadian
management wanted to implement SAP. Headquarters in the United States wanted to implement AMPICS
as a transition to AMP’s global SAP roll-out.
The controller of AMP of Canada, Doris Puddington, had discussed the alternatives with both her IS
manager and Canadian management, and concluded that AMP of Canada should implement SAP. Doris
knew the most serious obstacle to implementing SAP was IS management in AMP’s headquarters of
Harrisburg, Pennsylvania. She had several conference calls with American IS managers during which she
told them about a rapid implementation she had seen presented by a Canadian business partner of SAP.
The business partner used the new rapid implementation methodology called ASAP. After hearing about
this new methodology, Harrisburg’s IS management became keenly interested in testing the ASAP
methodology in Canada.
AMP had been involved with SAP since 1996, but had only recently begun designing one global
framework for how all AMP companies would use SAP. AMP had almost completed the global design of
the financial template, and was scheduled to go-live with the financial modules of SAP (FI and CO) on
January 1, 1998. The global design of the sales (SD), materials (MM), and manufacturing (PP) modules
would proceed after the financial modules were implemented. Because process re-engineering was being
done at the same time as systems design, senior management in Harrisburg thought the project was taking
a long time. The Canadian situation presented an opportunity to test a faster implementation.
In August 1997, Canadian management and Harrisburg compromised on a solution. AMP of Canada
would implement the basic modules of SAP using a “big bang” approach, with no dual operation period of
the old and new systems. AMP of Canada would implement the following SAP modules by October 1,
1998: Sales and Distribution (SD), Materials Management (MM), Production Planning (PP), Financial
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
AMP OF CANADA (B)
9A99E031
Accounting (FI), and Controlling (CO). Early in 1998 the Warehouse Management (WM) module was
added to the project. Other non-critical modules including Quality Management (QM), Plant Maintenance,
(PM), Project Systems (PS), and Workflow (WF) would be implemented after October 1998. Refer to
Exhibit 1 for a list of SAP modules. Only basic “vanilla” functionality would be implemented to save time
by not re-engineering business processes. The project would use SAP’s new Accelerated SAP
implementation methodology called ASAP. The project team would be composed of full-time AMP of
Canada employees who would be backfilled by temporary staff. The team would go on SAP configuration
training and be responsible for the system configuration. The system box and technical support would be
located in Harrisburg. AMP of Canada would adopt the global SAP project’s design as much as possible,
but after February 1998 would be free to deviate from the design to meet go-live requirements. This
allowed most of the global SAP project’s FI design to be used on the Canadian project, and parts of the CO
design. Where design decisions had been finalized in other modules, they were also adopted by AMP of
Canada.
Harrisburg Information Systems had a few extra conditions. Because of AMP’s existing relationship with
SAP, contracts for the Canadian project would have to be signed with SAP itself instead of a local
consulting business partner. Although this increased the budget to about Cdn$9 million, the fit with the
corporate strategy was better. SAP was much more knowledgeable about AMP’s requirements than any
other vendor because it had already been working on re-engineering for AMP and had done
implementations at other AMP sites. The team leader would have to regularly report progress, issues, and
lessons learned to the U.S. project office. This was to ensure that Canada adopted global standards, and to
enable the global team to learn the ASAP methodology for future AMP implementations.
THE ASAP METHODOLOGY AND PROJECT PLAN
The ASAP methodology had been used in several other projects, ranging in duration from six to twelve
months. The methodology had five phases: Project Preparation, Business Blueprint, Realization, Final
Preparation, and Cutover / Post Go-Live Support (see Exhibit 2 for the original project plan).
The ASAP methodology called for Phase 1 to be completed by the end of October 1997. Tasks in this
phase included selecting the project team, writing the project charter, selecting a team name, and hiring
consultants. As project sponsor, Doris committed to having “no Show-Stoppers”, which meant that no
single problem would be so grave that it would stop the October go-live. AMP would do whatever was
necessary, including hiring temporary employees, asking full-time employees to work overtime, or
manually processing transactions to work around any outstanding problems with SAP instead of delaying
the go-live.
Phase 2 was planned to end by December 1997. This phase involved documenting user requirements for
the system, identifying which components of SAP were in scope for the project, and sending the project
team on introductory SAP training. The 500-page Business Blueprint was completed by the end of
December 1997 when user champions signed-off on the Business Blueprint.
Phase 3 was the busiest phase, and was planned for completion by the middle of August 1998. Tasks in
this phase included configuration of the system, testing and documenting of business processes in SAP,
identifying data conversions and writing conversion specifications, testing interfaces to and from external
systems, designing reports and forms, and developing enhancements. Enhancements were programs
written to augment SAP functionality that did not change the source code. Unlike modifications,
enhancements were supported by SAP. Having learned from the JBA experience, the project charter called
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
Page 2
Page 3
9A99E031
for no system modifications. In Phase 3 the project team would also go on configuration training and
begin preparing the training materials, facilities, and schedule.
Phase 5 was planned to last one month after go-live. The key task here was to identify and close post golive issues. Most consultants were scheduled to leave after Phase 5. The project team was supposed to
return to their old jobs soon after this phase.
THE PROJECT TEAM
The project team would be structured with a core team and an extended team. The core team would work
full-time on the project, while the extended team would assist part-time as required, particularly with
conversion testing, business process clarification, etc. The core team would consist of two users from
sales, two users from procurement, three users from manufacturing, two users from finance, and one
technical person. A few of these people were on the JBA implementation team, including one user in
sales, one in manufacturing, and one in finance. Other SAP core team members joined the JBA project
near the end to help with testing and training.
Corinne Ingall was an employee of AMP of Canada designing the product costing template for the global
SAP project. Corinne had been on the JBA project and would be one of the SAP financial core team
members, but also had the responsibility of AMP project manager, with the core team reporting to her. She
would be responsible for managing the project, including issue resolution, budgeting, testing, and training.
If an issue could not be resolved at the project team level, the issue would be raised at the project Steering
Committee level for resolution in 24 hours. The Steering Committee was composed of AMP of Canada’s
general manager, general sales manager, manufacturing manager, logistics manager, controller, quality
manager, and human resources manager (see Exhibit 3 for a partial AMP of Canada organizational
structure).
Richard Stoveld would share the responsibilities of project management from the technical perspective.
He would be responsible for programming resources and coordination with basis administration in
Harrisburg. Scott Bechtel was a SAP consultant hired to assist Corinne Ingall as SAP project manager. He
would be responsible for coordinating with consultants and SAP for project issues. One consultant would
also be hired for each module being implemented: SD, MM, PP, FI, and CO. User champions were
identified in the user community. They would be responsible for making decisions about how business
processes would work in SAP. See Exhibit 4 for the Destiny 2000 project team.
PROJECT EVENTS
In August 1997 the core team was selected. The project officially began in September 1997, with the core
team going on level 2 (introductory) SAP training. The project was also given a name: Destiny 2000. A
mission statement and project charter were written:
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
In Phase 4, end users would be trained, data would be converted, and other final preparations for go-live
would be completed. Phase 4 was planned to end with the cutover to SAP on October 5, 1998. The date
was changed from October 1 because that date fell on a Thursday, whereas October 5 was a Monday.
Page 4
9A99E031
•
•
•
•
No modification will be made to the software in order to preserve a path for future
upgrades.
AMP Global Standard configuration templates will be used in order to support the
AMP Business Model.
The primary focus of the team will be to go live with base functionality; incremental
improvements will be made in future phases.
Minor reengineering of AMP’s Business Processes may be required upon approval.
When the core team was not on training, they interviewed the user champions to identify business process
requirements. The results of these interviews were used to complete a list of SAP business processes inscope for AMP of Canada called the Business Blueprint. This document was completed on December 19,
1997. The Business Blueprint identified by module the number of conversions, interfaces, reports, forms,
and gaps requiring enhancements.
After the Business Blueprint was completed, the Business Process Master List (BPML) was generated.
The BPML listed each SAP transaction in scope, and suggested a test plan that grouped related
transactions. Business Process Procedures (BPPs) would have to be written for each transaction and
unique AMP business process. A BPP explained in detail how a user performed a specific business
transaction in SAP. For example, a BPP was written for the Create Sales Order transaction. Additional
BPPs were written for the different kinds of sales orders that AMP used (such as a regular order, an EDI
order, a sample order, etc.). BPPs were used as the basis for training material. Refer to the list below for a
summary of the information in the Business Blueprint and BPML at the start of 1998.
Unique Transaction
Codes in Scope
Conversions
Interfaces
Reports (see note below)
Forms
Gaps and Enhancements
Business Process
Procedures (BPPs)
SD
MM
PP
FI
CO
Total
96
91
42
99
143
471
5
20
58 (23)
8
3
11
14
34 (25)
3
0
6
0
44 (13)
1
0
4
5
49 (2)
3
1
2
2
52 (20)
0
3
28
41
237 (83)
15
7
118
98
95
140*
255
706
Note: In the Reports row, the first number represents the initial number of reports identified in each
module. The number in brackets represents the final number of reports required. For example, FI
started with 49 identified reports, but had only 2 written because many reports that could be
generated using standard SAP functionality were no longer required because of how SAP worked,
or were cancelled for other reasons.
* Harrisburg had already written about 100 of the 140 FI BPPs. Harrisburg had not written most of
the CO BPPs.
Because there were so many business processes in finance, Corinne hired an extra CO consultant in
January to assist with Product Costing and Profitability Analysis configuration. In February 1998, Todd
Durnford was moved from the extended team to the core team to represent the warehouse for configuration
and testing of the warehouse management (WM) module. A WM consultant was contracted to do the
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
AMP of Canada’s Destiny 2000 Team will implement a core set of SAP software by
October 1, 1998 in order to gain Year 2000 compliance for the corporation. The project
team will work according to these guiding principles:
Page 5
9A99E031
By the end of March 1998, the core team had completed configuration training. As the consultants
finished configuration of the system, the core team tested transactions and began writing BPPs. Harrisburg
required weekly reporting on the number of completed BPPs to track the project’s progress. Both the
configuration and BPPs were completed by the middle of the summer.
The ASAP methodology employed four rounds of cycle testing, where transactions were tested within
specific modules, and two rounds of integration testing, where transactions were tested across functional
modules. The core team was separated into two testing teams based on similar business processes:
Manufacturing and Distribution. These two teams conducted both cycle and integration testing of
transactions relating to manufacturing and distribution processes. The configuration and testing of some
functionality such as vendor evaluation and physical inventory counting were postponed until after go-live.
By the beginning of September, application testing was complete. The project team began working on
testing and refining the conversions, interfaces, forms, reports, and enhancements. End-user training
material was also written and the training schedule was planned.
BUSINESS EVENTS
AMP globally had a difficult year in 1998. Results from the first quarter were disappointing. To address
these results, AMP announced a series of American plant closures beginning in April. In June 1998,
Canadian management decided to close the manufacturing facility in Montreal. All machinery and
inventory would be transferred to the Markham plant. This required minor rework of SAP configuration,
but took important extended team resources away from working on SAP issues, especially the
manufacturing data conversions.
On June 26, AMP Incorporated announced mandatory furloughs for American employees. Weakness in
Asia was cited as the reason for worsening business results. Although this did not apply to Canadian
employees, it worsened morale on the project team and throughout AMP of Canada. Some employees
started to worry that Canada would also have to implement mandatory furloughs. AMP’s share price sank
from its all-time high of above $50 to below $30 in response to these events.
On August 6, Allied Signal made a hostile takeover bid for AMP. Allied Signal offered $44.50 for AMP’s
stock. This created huge uncertainty for both AMP worldwide and the SAP project. Although there was
support for Allied Signal’s offer in the marketplace, AMP was incorporated in Pennsylvania, which had
very strong anti-takeover legislation. Harrisburg and Allied Signal management fought a public relations
war over the takeover while AMP began searching for a white knight.
THE GO-LIVE DECISION
By September 1998, the project had reached a critical decision point. Although configuration, testing, and
BPPs were completed, certain conversions and interfaces were not. The final preparations for go-live in
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
actual configuration. Configuration in SAP involved changing a series of table settings that controlled how
transactions worked. For example, part of the pricing configuration controlled whether unit prices
extended by order quantities were rounded up or down to the nearest penny. The consultants were hired to
do the actual configuration, and also to transfer this knowledge to the core team by demonstrating and
documenting how the system was configured.
Page 6
9A99E031
APPLICATION AUDIT — SD (SALES AND DISTRIBUTION)
By the middle of September 1998 the customer conversion had been completed. However, the pricing
conversion had not been successfully completed. The pricing conversion was taking longer than expected
because of the sheer volume of data (over one million records) and the complexity of the conversion logic.
The interfaces for reporting sales information to Harrisburg had been completed, but the data feeds to and
from AMP’s custom Pricing System were not complete.
AMP of Canada’s Pricing System was a stand-alone Power Builder application written to analyse margins
and quote customers special agreement pricing. When designing SAP, the project team determined that
SAP could not handle AMP’s requirement for analysing the profitability of quotes at the management level
(which excluded intercompany transfer pricing mark-ups). Standard SAP only supported analysing quotes
at the statutory level, which included intercompany mark-ups. The Pricing System would have to be
rewritten to use SAP pricing and costing information as well as AMP’s existing quote history. The Pricing
System’s programmer estimated that it would take a few weeks to complete the interface of SAP pricing
and costing data.
The SD forms such as the customer invoice and credit memo were tested and completed. The SD
enhancements of the Internet Price and Delivery screen, SAP Price and Delivery screen, and the commit
date / rescheduling program were tested successfully. User training was completed except for the Pricing
department. The customer EDI interfaces had been successfully tested.
APPLICATION AUDIT — MM (MATERIALS MANAGEMENT)
In Materials Management, the conversion of the material master had just been finished. This conversion
had taken weeks longer than planned because of the tremendous complexity of the material master. One
core team member was responsible for the conversion of 500,000 records with 50 fields. By the end of the
conversion testing, all extended team members and some regular users were testing this conversion.
Testing identified many data quality and specification problems from the Harrisburg data transmissions
that could not be completely fixed until after go-live. The vendor conversion was completed successfully.
Because of the great workload in MM, one member of the PP team was moved to the MM team to help
with testing and training.
The weekly and quarterly Material Master Send and Receive data interfaces had been completed, but the
EDI transmissions of purchase orders, goods receipts, and vendor invoices had not been completed. Every
day, AMP of Canada sent purchase orders using EDI to related AMP companies for nearly all the nonmanufactured product it sold. At night, Harrisburg sent AMP of Canada the goods it was shipping the
following day by truck so that the physical receipt of the goods would take less time. Only the differences
between what was sent electronically and what was actually received had to be entered in the system.
Related AMP companies also sent invoices via EDI. Although this cycle of Purchase Order, Goods
Receipt, and Invoice Receipt had been tested several times, each subsequent test solved the problem of the
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
Phase 4 began in late August. The part number, bills of material, routers, and activity price conversions
were all completed on the first weekend in September for the standard cost conversion in SAP. However,
certain interfaces such as the AMP Inc. EDI and Pricing System data feeds had not been finished yet.
Corinne and the project team had to decide whether or not to go-live on October 5. To help make this
decision, she reviewed the status of each module.
Page 7
9A99E031
Users were starting to ask for new functionality to be configured. Now that they were learning about the
system, planners wanted to configure the Sales and Operations Planning part of SAP to drive the
manufacturing business. This functionality would allow forecasts to be entered at a material group level
instead of an individual material level but still feed MRP. A core team member of PP thought this
functionality was so important that the go-live date should be postponed until the beginning of November
to configure and test this functionality.
Training was not going well for material planners. Although they had practised the transactions in their
lessons, the functional integration was not apparent to them. The core team had serious doubts about how
well the planners would do their jobs in October.
In Warehouse Management, the conversion of inventory quantities had been successfully tested. There
were still some testing issues with bar coding for AMP Inc. and French labelling for one Quebec customer,
but these were expected to be completed before go-live.
User training was also progressing slowly in WM. During the course of training, warehouse users were
being exposed to the system, and were beginning to realize that SAP required them to enter much more
data, which would slow their work significantly.
Before going live, a physical inventory count would have to be conducted to get inventory data at the bin
level. Quantities could not be loaded into SAP without bin-level information. The count had been
scheduled for months, but could not be easily rescheduled, because many people were required to work for
two complete days counting materials.
APPLICATION AUDIT — PP (PRODUCTION PLANNING)
In Production Planning, the bills of material and routers conversions had been tested successfully and run
for the standard cost conversion. Work centres had been manually loaded into SAP. The Production Order
printout form and the reports such as the Factory Order On-Time report were completed.
APPLICATION AUDIT — FI (FINANCIAL ACCOUNTING)
In FI, the conversions had been successfully completed. Customer balances, credit limits, general ledger
balances, and fixed asset data were all completed or expected to be completed before go-live. The
interfaces except for the AMP EDI Invoice Receipt were completed. Although the Invoice Receipt was
still being tested as part of AMP Inc. EDI, the outbound related-AMP Customer Invoice EDI interface was
postponed until after go-live. The major enhancement in FI was the Credit Alert system, which had been
successfully tested. The FI and CO reports were still being written by their primary user, who expected to
be completed before go-live. User training was complete, with key users quick to learn the system.
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
previous test but revealed a new problem. The core team member testing EDI was the same person
responsible for converting the material master, and she did not know if EDI would be ready by go-live.
She wanted more time for testing.
Page 8
9A99E031
The situation in Controlling had stabilized from the huge workload seen in January. The number of BPPs
had been greatly reduced as the core team became more familiar with functionality in CO. All BPPs had
been written, there were no conversions to test, and only one major interface. The yearly and quarterly
standard cost SS40 interface had been successfully tested. The three enhancements written for product
costing had also been completed. Users were also trained to do product costing and profitability analysis
in SAP.
GENERAL STATUS
All remaining conversions would take two weeks to run using direct input. Direct input wrote data directly
into SAP tables instead of using the standard SAP transaction to create the data. If the SAP transactions
were used instead of direct input, the material master conversion alone was estimated to take months to
complete. Like the regular transaction, direct input validated the data being loaded for required fields.
The SAP project manager Scott Bechtel had initially projected the project would take 10 months, and
Corinne used this estimate to budget the project. In June 1998 it became apparent that the early go-live
date would not be possible to meet, and Corinne had to request an increase to the budget. Now that the
target go-live date was in question again, Corinne wondered if she would be able to get another budget
extension from Harrisburg. Although she was $200,000 under budget, she was concerned about problems
that might arise after go-live that would require additional expensive consulting resources to solve.
On the morning of September 21, Corinne had an emergency meeting with the core team. She asked each
team member whether or not AMP of Canada should go-live on October 5, and whether AMP of Canada
could continue to take orders, ship product to customers, and conduct normal business transactions. The
vote was split six to four in favor of going live, not including Corinne (see list below). Richard qualified
his vote by stating that although he thought AMP of Canada could take orders and ship product to
customers, it should allow more time for testing. Several technical and application consultants thought that
AMP should allow more time for testing. Corinne wondered whether or not SAP should go-live on
October 5, and what action plan to present to the Steering Committee in her meeting later that morning.
SD Core Team
Suzanne —Yes
Joyce — Yes
MM Core Team
Gail — Yes
Jodi — No
Janice — No
Todd — Yes
PP Core Team
Ravi — No
John — Yes
FI/CO Core Team
Steph — Yes
Corinne — Not Yet
Voted
Technical Team
Richard —
Qualified No
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
APPLICATION AUDIT — CO (CONTROLLING)
Page 9
9A99E031
Exhibit 1
SD – Sales and Distribution
FI – Financial Accounting
•
•
•
•
•
•
•
•
•
Order Entry
Pricing
Shipping
Billing
Foreign Trade
General Ledger
Accounts Receivable
Accounts Payable
Fixed Assets
MM – Materials Management
CO — Controlling
•
•
•
•
•
•
•
•
•
•
Forecasting
Material Requirements Planning (MRP)
Purchasing
Inventory Management
Warehouse Management
Product Costing
Profitability Analysis
Cost Centre Accounting
Internal Order Accounting
Profit Centre Accounting
PP – Production Planning
PS – Project Systems
•
•
•
•
•
•
Master Production Scheduling (MPS)
Capacity Planning and Leveling
Production Orders
QM – Quality Management
Project Accounting
Project Logistics
Cross-Application Timesheet
WF – Workflow
Note: Shaded modules were out of scope for the October 1998 go-live date.
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
SAP MODULES AND DESCRIPTIONS
Page 10
9A99E031
Exhibit 2
ID
1
68
229
230
347
356
394
402
458
467
482
487
512
524
527
528
553
558
566
578
579
580
592
601
605
606
622
634
655
WBS
1
2
3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
5
5.1
5.2
5.3
5.4
Task Name
Phase 1: Project Preparation
Phase 2: Business Blueprint
Phase 3: Realization
Project Management
Project Team Training
Baseline Configuration and Confirmation
System Management
Final Configuration and Confirmation
Development
Create Authorization Design
Establish Archiving Management
Integration Test
End User Documentation and Training Materials Development
Quality Check Realization Phase
Phase 4: Final Preparation
Project Management Final Preparation Phase
Validate Systems Authorizations
End User Training
System Management
LIS/SIS/ABAP Non Critical Reports
Create End User Documentation (Cont.)
Detailed Project Planning
Cut Over
Quality Check Final Preparation Phase
Phase 5: Go Live and Support
Project Management Final Preparation Phase
Production Support
Post Go-Live Activities
Quality Check Go Live and Support Phase
Dur
30 days
104 days
172.5 days
155 days
63 days
79 days
136 days
45 days
165 days
165 days
25 days
32.1 days
77 days
1.5 days
85 days
31 days
21 days
45 days
24.5 days
28 days
42 days
12 days
7 days
1 day
29 days
10 days
20 days
29 days
2 days
Start
Wed 10/1/97
Thu 10/9/97
Mon 1/5/98
Fri 1/16/98
Thu 2/5/98
Mon 1/26/98
Mon 2/2/98
Thu 5/14/98
Mon 1/5/98
Mon 1/5/98
Thu 7/16/98
Thu 7/16/98
Fri 5/15/98
Tue 9/1/98
Mon 8/3/98
Mon 8/17/98
Mon 8/24/98
Mon 8/3/98
Sat 8/15/98
Mon 8/24/98
Thu 10/1/98
Tue 8/25/98
Mon 9/28/98
Mon 10/5/98
Mon 10/5/98
Mon 10/5/98
Mon 10/5/98
Mon 10/5/98
Mon 11/2/98
Finish
Tue 11/11/97
Tue 3/3/98
Wed 9/2/98
Thu 8/20/98
Mon 5/4/98
Thu 5/14/98
Mon 8/10/98
Wed 7/15/98
Fri 8/21/98
Fri 8/21/98
Wed 8/19/98
Mon 8/31/98
Mon 8/31/98
Wed 9/2/98
Wed 11/25/98
Mon 9/28/98
Mon 9/21/98
Fri 10/2/98
Fri 9/18/98
Wed 9/30/98
Wed 11/25/98
Wed 9/9/98
Sun 10/4/98
Mon 10/5/98
Thu 11/12/98
Fri 10/16/98
Fri 10/30/98
Thu 11/12/98
Tue 11/3/98
Authorized for use only by SHURAN WANG in ACC 826 at Michigan State University from Jan 19, 2021 to Apr 29, 2021.
Use outside these parameters is a copyright violation.
AMP OF CANADA DESTINY 2000 PROJECT PLAN
Page 11
9A99E031
Exhibit 3
John Kohler
General Manager
Lenore Purvis
Logistics Manager
JoyceMacLellan
Inside Sales
Manager
Terry Lawrence
Purchasing
Manager
Dean McCreadie
Warehouse Manager
Suzanne Watson
Inside Sales
Representative
Gail Fair
Buyer
Todd Durnford
Receiving,
Manufacturing
Harland Ramsay
Customs and
Traffic
Manager
Jeff Lacher
Material and
Production
Control Manager
Jodi Burch
Materials Planner
Janice McKenzie
Production Planner
Doris Puddington
Controller
Tony Scappaticci
Manufacturing Manager
Warren Hamley
General Sales
Manager
Corinne Ingall
SAP Project Manager
Ravi Verma
Manufacturing Engineer
Donna Holmes
Telemarketing
Business Unit
Manager
Richard Stoveld
AS/400 Team Leader
Wing Yip
Manufacturing Engineer
Kevin Earle
Quality Manager
John Wong
Quality Assurance
Wally Heard
Quality Assurance
Mauro Cappuccio
LAN Team Leader
Daniel Lee
Pricing Team Leader
Legend
Bob Thivierge
Credit Manager
BonnieMayes
Senior Credit
Specialist
Chris Timal
Accounting Manager
Sandra Pepin
Costing Analyst
Team Leader
Steph Marchak
Finance Systems
Analyst
Anahid Mahdessian
Accounts Payable
Specialist
Employee
Simon Wong
Senior Financial
Analyst
Operations
Committee
SAP Team
Member
Peter Ferguson
Human Resources
Manger
Authorized for us