This project analyses data collected by a wave monitoring buoy…

/in /by

Question Answered step-by-step This project analyses data collected by a wave monitoring buoy… This project analyses data collected by a wave monitoring buoy anchored at Mackay (Queensland) in 2020. The data were made publicly available by the Queensland government.1 Wave monitoring data are used for example in the design and construction of coastal structures; the planning of fishing, small craft or port activities; and coastal and maritime weather forecasts. However, such applications are not in the scope of this project. The original data were slightly modified to simplify the analysis; the data to be used for this project are provided in the file Waves.csv together with this task sheet. The file contains the following variables, with each row giving data for a half-hour time period: Month – the month [integer 1, . . . ,12] Day – the year [integer 1, . . . ,31] Hour – the start of the time period [half integer 0 . . . ,23.5] MaxHeight – the maximum wave height in metres [decimal] Direction – the predominant direction of the waves [8 categories: N, NE, E, SE, S, SW, W, NW]  We want to investigate the probability that waves at Mackay come from east, using the 2020 data as a sample.  (a) Use bootstrapping to compute a 99% confidence interval for the proportion of half-hour time periods in which waves come predominantly from east.  (b) Compute a 99% confidence interval for the proportion of half-hour time periods in which waves come predominantly from east by using the Central Limit Theorem to estimate the standard error of the appropriate sampling distribution, and compare your result to the interval found in part (a).   We want to investigate the mean of the maximum wave heights that were recorded for each half-hour time period.  (a) Mean maximum wave height We want to test whether there is evidence that the mean maximum wave height is less than 1.65 m. (i)  Formulate an appropriate hypothesis test and use the function t.test to compute the p-value of the data in the test(ii) Use randomisation to compute the p-value of the data in the test. (iii) Compare the results from parts (i) and (ii) and state the test decision at a significance level of 5%.   (b) Mean maximum wave height: April vs. December We want to test whether there is evidence that there is a difference in the mean maximum wave heights between April and December. (i) Formulate an appropriate hypothesis test and use the function t.test to compute the p-value of the data in the test. (ii) Use randomisation to compute the p-value of the data in the test. (iii) Compare the results from parts (i) and (ii) and state the test decision at a significance level of 10%. DATA : https://drive.google.com/file/d/13bFpUJ8HX4a0JPWwQxQ0oW62_1QMNnf2/view?usp=sharing MUST BE COMPLETED USING R STUDIO  Computer Science Engineering & Technology Python Programming SCEM 300700 Share QuestionEmailCopy link Comments (0)

You might also like
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
9. When coding non-coronary bypass operations, the fourth character...
A 53 year old female with a history of sarcoidosis presents to the...
Identify 1-2 emergency response functions or roles and how they could
How can our current health care system keep us healthy? Identity...
What type of of hardship and adversity have you overcome that would...
Which statement by the RN demonstrates an external barrier to...
Prepare a concept map for a musculoskeletal disorder from your...