Change Management Procedure Global Information Technology

Information Technology Change Management Process CHANGE MANAGEMENT............................................................................................ 3 INTRODUCTION ................................................................................................................ 3 OVERVIEW ....................................................................................................................... 3 CHANGE MANAGEMENT OBJECTIVES .............................................................................. 3 SCOPE .............................................................................................................................. 4 CHANGE MANAGEMENT PROCESS ........................................................................ 6 GENERAL INFORMATION .................................................................................................. 6 ROLES AND RESPONSIBILITIES ......................................................................................... 7 CHANGE DEFINITION ....................................................................................................... 8 CHANGE TYPES ................................................................................................................ 9 CHANGE WINDOWS........................................................................................................ 12 RISK ASSESSMENT ......................................................................................................... 12 CR SUBMISSION........................................................................................................... 15 SUBMITTING A CHANGE REQUEST ................................................................................. 15 Requirement .............................................................................................................. 15 KEY PROCESS STEPS ...................................................................................................... 16 ACCESSING THE CR TEMPLATE IN MAGIC ..................................................................... 17 PROCESS STEPS FOR DOCUMENTING AND SUBMITTING A CHANGE REQUEST ................ 18 SECTION 1...................................................................................................................... 19 Request Number.................................................................................................... 19 CR Type ................................................................................................................ 19 Opened .................................................................................................................. 19 Status ID................................................................................................................ 19 Group Name.......................................................................................................... 19 SECTION 2...................................................................................................................... 19 Requestor ID ......................................................................................................... 19 Sponsor Name....................................................................................................... 19 Phone number ....................................................................................................... 19 Requestor Manager ............................................................................................... 19 SECTION 3...................................................................................................................... 20 Start and end time ................................................................................................. 20 Actual.................................................................................................................... 20 System................................................................................................................... 20 Platform................................................................................................................. 20 Y/E (Year End) ..................................................................................................... 20 Equip /System Affected ........................................................................................ 20 EDI........................................................................................................................ 20 Subject ID ............................................................................................................. 20 SECTION 4...................................................................................................................... 21 Business Unit Affected ......................................................................................... 21 Could change affect anything else? ...................................................................... 21 Describe the activity ............................................................................................. 21 Backout Plan ......................................................................................................... 21 Dependencies ........................................................................................................ 21

Revised 09/13/04

Information Technology Change Management Process Impact of not making the change.......................................................................... 21 Validation.............................................................................................................. 21 Who will validate, onsite person and phone number............................................ 21 Completion Status................................................................................................. 21 Risk Assessment ................................................................................................... 22 Approver Email Address....................................................................................... 22 Who can approve a CR ......................................................................................... 22 Delegation of approval authority .......................................................................... 23 SECTION 5...................................................................................................................... 23 Save the CR to Create a Ticket and Route to a Manager for Approval................ 23 Manager and Direct Report of CIO Approval Process ......................................... 23 CR Date/Time Change and CR Time Extension .................................................. 23 Change the date and/or time of the activity before the CR has been presented at the meeting............................................................................................................ 23 Change the date and/or time after receiving approval at the meeting, before the activity has been performed, and the date/time change is before the next weekly meeting.................................................................................................................. 24 Extend the CR while performing the activity ....................................................... 24 SECTION 6...................................................................................................................... 25 Contingency Plan in the event Magic is not available.......................................... 25 CR APPROVAL PROCESS .......................................................................................... 26 REQUESTOR MANAGER NOT AVAILABLE TO APPROVE A CR ................... 26 Submitting a CR to a Designated Manager........................................................... 26 RESUBMIT A CHANGE REQUEST TO A MANAGER FOR APPROVAL ......... 26 UNPLANNED AND EMERGENCY CR APPROVAL PROCESS........................... 26 ACCEPTED CHANGES................................................................................................ 27 CHANGE MANAGEMENT MEETING AGENDA .................................................................. 27 Change Management Meeting .................................................................................. 27 Change Management Meeting Minutes .................................................................... 27 CR Implementation and Ticket Closure.................................................................... 27 EXAMPLE COMPLETED CHANGE REQUEST TEMPLATE ................................................... 28 APPENDIX B .................................................................................................................. 29 EXAMPLE CHANGE REQUEST HELP DESK TICKET ......................................................... 29 APPENDIX C .................................................................................................................. 30 EXAMPLE EMAIL NOTIFICATION SENT TO APPROVING MANAGER ................................. 30 MANAGER AND DIRECT REPORT OF CIO APPROVAL PROCESS ...................................... 31 APPENDIX D .................................................................................................................. 33 EXAMPLE EMAIL NOTIFICATION SENT TO THE REQUESTOR ........................................... 33 APPENDIX E .................................................................................................................. 35 VISIO DIAGRAM OF MAGIC PROCESS ............................................................................. 35

Revised 09/13/04

Information Technology Change Management Process

CHANGE MANAGEMENT
Introduction
This document describes the processes used to plan, coordinate, and implement changes to any production, test or development environment at Mattel, Fisher Price, and American Girl. It includes the roles and responsibilities IT staff members adhere to ensure that any modification to an environment does not interrupt user production and environment performance. All GIT locations operate by this process and adhere to the process guidelines. The Requestor and Approving Manager assume full responsibility for the scope of the change.

Overview
Change Management is designed to implement change into the IT environment with minimal disruption of service.. This includes changes in technology, tools, systems, and hardware. Change Management defines the documentation, processes, roles and responsibilities necessary to plan for and implement change. One of the key elements of Change Management is to ensure that IT staff, users and business units are aware of the change and understand the effect a change will have on any environment. Since many systems are dependent on others communication of pending changes is an essential step to identify and eliminate any risk associated to other environments. The documentation and approvals process required are not intended to discourage change but to encourage planning and consideration of the impact of the changes.

Change Management Objectives

The objectives of Change Management include: Control, manage, and monitor the change process. Communicate the activity. Plan the implementation. Communicate a backout process. Ensure proper authorization has been received for each change Focus on impact, assessment, and feasibility of implementing changes Establish each participants role and area of responsibility Manage and coordinate all changes with potential to impact the production environment and minimize disruptions to customers and production systems.

Revised 09/13/04

Information Technology Change Management Process Fast Track the approval process for low impact and development and test environment changes and changes that will not result in system downtime, loss in user productivity, limited user access to an application, or have significant impact to a projects timeline. Eliminate the number of change back-outs caused by ineffective change planning or implementation Provide proper notification of change activities. Ensure that proper authorization has been received prior to implementation of production Change Requests Ensure that any possible interruption to the production environment is minimized Ensure (and enforce) that everyone adheres to the Change Management process Hold weekly Change Management meetings to ensure that GIT and management are aware of and in agreement with all Change Requests. Discuss unsuccessful CRs during the weekly Change Management meeting to review cause of failure and production impact. Provide an audit trail of all changes Consolidation of changes where possible.

Scope
The following is a guideline to help determine the types of changes, which are considered a change to the production environment. This is not an all-inclusive list. Technical System software installations related to new versions, releases, or modification levels System software maintenance which provides new functionality or resolution of known or potential problems Parameters which control the operation of any software product Database software installations related to new versions, releases, or upgrades Major security / access changes Database re-organizations IPLs/reboots

Desktop Management Services LAN file servers and storage devices Network operating systems LAN database, FAX, and mail servers Global changes to PC operating system software Communication servers Application software residing on each file server

Revised 09/13/04

Information Technology Change Management Process Telecommunications Network software changes, maintenance fixes, or new software releases Network hardware moves, additions, or changes Network reconfigurations Network hardware upgrades Router reloads or restarts Voice software fixes, enhancements or installation of new products Voice hardware or software upgrades Connectivity devices such as intelligent hubs, switches, routers and multiplexors Global changes and changes that affect critical resources to wiring facilities which provide for data transport

Facilities Changes Cabling UPS modifications maintenance Building modifications Remote control changes Building Power and anything that could affect service

Application Services Changes to add, remove, or change functionality of any production application system or package. This encompasses changes to jobs, procedures, programs, recovery instructions, and production schedules Any data conversion, data load or implementation process(es) that may impact any aspect of the production environment or users Database Stored procedures

Revised 09/13/04

Information Technology Change Management Process

Change Management Process

General Information
1 Changes that result in database modifications, system downtime, loss in user productivity, limited user access to an application, have significant impact to a project timeline require a 5 working days lead time prior to the date of the activity. All Change Requests and associated documentation must have the opportunity to be discussed at the weekly Change Management meeting. Change Requests must be received in the Magic Change Request queue with appropriate approval prior to the close of business Monday to be included on the Wednesday meeting agenda. Change Requests received after 17:00 (5PM PST) and scheduled before the following weeks meeting would be considered Unplanned and would need a CIOs direct report approval. If Monday is a holiday then Change Requests submitted by 13:00 (1:00 PM PST) Tuesday to be included on the Wednesday meeting agenda. The Change Management Meeting Agenda will be distributed on Monday evening. If Monday is a holiday the agenda will be published Tuesday evening. Change Management meetings are held each Wednesday at 8:00 AM PST (11:00 AM EST). The Change Management Coordinator is the on-duty PTC supervisor. The Help Desk Manager is the process administrator. In the event of an Emergency Change Request, or an Unplanned Change Request, authorization from any of the CIOs direct reports is required. Emergency Change Requests are submitted for approval as the result of a SEV 1 event. A change can be declared an emergency when immediate repair services are required to a production environment and a Severity1 trouble ticket is opened in MHD. Unplanned and Emeregency Change Requests must be approved by a direct report of the CIO.

4 5 6 7 8 9

10

Revised 09/13/04

Information Technology Change Management Process

Roles and Responsibilities

Role and Responsibility The Sponsor is the customer who requested the change. The Change Requester is responsible for preparing the change for implementation and is responsible for the success of the change. A customer, vendor or supplier can initiate a change, but GIT personnel must submit all change requests. The Change Coordinator ensures the change management process functions smoothly and efficiently. The Change Implementer is the person or group (Production Control Group) that executes the change. Tasks Communicates requirements to Change Requester. Verifies the change was implemented per their request Ensures the changes are fully documented before submitting the request for review Ensures the impact of the change is fully understood by support groups and by the Change Coordinator Attends the weekly Change Management meeting to answer any inquiries about the changes as required Coordinates any client testing as required Ensures the Change Coordinator is involved in any change planning process Drafts customer notification to ensure customers are notified of approved changes and/or outages All CRs are required to include detailed back-out/contingency information which is available for customer review Upon completion, notifies the Sponsor that the change was completed Verifies with the Sponsor that the change was implemented to their satisfaction Documents the results and closes the ticket Does not implement any change without following proper procedures Facilitates the weekly Change Management meeting Takes responsibility for ensuring timely approval of all changes from support groups Receives, reviews, and understands the change request to be implemented Adheres to the dates and activities of the implementation schedule Executes back-out and fall-back procedures for responsible components, when required Documents any events that happen during change implementation Works with the Help Desk to create any problem tickets related to the change and notes them in the Change Request entry Notifies the Change Requester after the change has been implemented

Revised 09/13/04

Information Technology Change Management Process

Change Definition
Change - Any modification or addition to the production environment that is not a routine task. Most changes will go through the process with the Change Coordinator as the decision-maker on borderline cases. Examples of typical Changes that are not considered production environment changes: Addition of a new electronic mail user Routine security updates Password resets Report Distribution changes Desktop Changes (except for major installations, i.e. a new release of the operating system) Changes to test or development systems Web application changes that do not modify the database Web application changes that affect presentation only and involve HTML or ASP changes that result in a content change, they do not go through the CR process.

Revised 09/13/04

Information Technology Change Management Process

Change Types
Type Planned Description
Reviewed and approved through the Change Management Process. This set of activities can be abbreviated or very comprehensive to deal with the significance of the Change. The stakeholders determine the scope of the review that the Change requires. Requires a Managers approval. Must have the opportunity to be discussed at a Change Management Meeting.

Unplanned

An Unplanned Change is a change required to software, hardware, etc. that was not anticipated in the current change window. These changes must be implemented according to the business needs sooner than the scheduled weekly Change Management meeting and/or within 5 business days. A business requirement dictates it must be implemented as soon as possible with a quick approval process. Requires the approval of the CIO or any one of the CIO Direct Reports. All Unplanned Change Requests are, however, included in the weekly Change Management agenda and discussed (after-the-fact) at the next meeting. A change can be declared an emergency when immediate repair services are required to a production environment and a Severity1 trouble ticket is opened in MHD. The CIO or any one of the CIO Direct Reports may approve the change. In some instances, the approval will be after the fact if the required change is business impacting. Fast Track changes do not require a 5 day lead time. They are low risk, have no impact on production systems and databases, and do not result in server or system downtime to production environments and the users production access will not be interrupted.

Emergency

Fast Track

Revised 09/13/04

Information Technology Change Management Process

RISK LEVEL LOW

ENVIRONMENT AND CONDITION Production No system downtime. Change will not modify database(s) No impact to user productivity or access to the environment. Access to the environment will be not be interrupted or limited. Within the four walls of the requestors company or entire location.

PLANNED Fast Track

UNPLANNED

EMERGENCY

Production System will be down. Change will modify database(s) User productivity will be interrupted. Access to the environment will be interrupted or limited. Within or outside the four walls of the requestors company Development/Test Change in Development/Test will not impact a production instance, result in system downtime or limit a users access to the environment. Development/Test

LOW MODERATE HIGH

5 Day Lead Required

CIO Direct Report Approval Required

SEV 1 Trouble Ticket CIO Direct Report Approval

LOW

Fast Track

LOW Change in Development/Test will result in system downtime or limited accessibility and will have an impact on the projects timeline. MODERATE HIGH

5 Day Lead Required

CIO Direct Report Approval Required

SEV 1 Trouble Ticket CIO Direct Report Approval

Revised 09/13/04

10

Information Technology Change Management Process

ENVIRONMENT AND CONDITION Web Application Change does not modify database. Changes affects presentation only and involve HTML or ASP changes that result in a content change, they do not go through the CR process. RISK LEVEL LOW PLANNED NO CR REQUIRED UNPLANNED NO CR REQUIRED EMERGENCY NO CR REQUIRED

Web Application Change will modify database(s)

LOW MODERATE HIGH LOW MODERATE HIGH LOW MODERATE HIGH

5 Day Lead Required

CIO Direct Report Approval Required

SEV 1 Trouble Ticket CIO Direct Report Approval SEV 1 Trouble Ticket CIO Direct Report Approval SEV 1 Trouble Ticket CIO Direct Report Approval

Software Installation or upgrade of software

5 Day Lead Required

CIO Direct Report Approval Required CIO Direct Report Approval Required

Hardware Installation or upgrade of hardware

5 Day Lead Required

Revised 09/13/04

11

Information Technology Change Management Process

Change Windows
Changes are implemented as requested with the following exceptions: All planned database changes will be performed during the weekend change window or unless the requestors Manager has approved the change during a weekday non-working hours and non-critical processing periods. Communication i.e..telecom and email changes will be performed during nonworking hours and non-critical processing periods. Changes that require a system outage or major upgrades will be scheduled during the weekend change window. There will be no changes allowed during the last week of each month or during the last two weeks of each quarter unless approved by a director report of the CIO. Unplanned and Emergency changes will be completed as needed to support critical business needs outside of normal change windows.

Risk Assessment
Every change has an associated risk. The person requesting the change should assess the risk level of the change. Modeling the change in a lab environment or with a modeling tool can also help assess the risk of a change. We recommend assigning one of the following risk categories to each change request:

High-risk These changes have the highest impact on user groups or particular environments, and may even affect an entire site. Backing out of the change is time consuming or difficult. You should research high-risk changes using the tools available, and implement the change in conjunction with necessary support personnel. Make sure management is aware of the change and its implications, and notify all users. Moderate-risk These changes can critically impact user environments or affect an entire site, but backing out of the change is a reasonably attainable scenario. You should research moderate-risk changes using tools available, and possibly review the change with support personnel. We recommend notifying all users of a moderate-risk change. Low-risk These changes have minor impact on user environments and backing out of the change is easy. Low-risk changes rarely require more than minimal documentation. User notification is often unnecessary.

Revised 09/13/04

12

Information Technology Change Management Process

Change Request Submission and Approval Flow Chart

Business communicates requirements to Change Requestor

Change Requestor submits CR via Magic

Requestor corrects and closes CR or resubmits for approval

MHD sends email to Approving Manager advising CR needs approval

Approving Manager responds to MAGICTSD with Approval

Approving Manager declines approval and emails Requestor

Return email to Change Requestor correction

Magic Buisness Rule Records Approval

Except for Unplanned CRs

Change Coordinator adds request to weekly agenda

CM Meeting

Approval obtained at CM Meeting

Requestor notifies Ops of CR start. REQUESTOR IMPLEMENTS Requestor notifies Ops of CR end. Ops updates and closes CR

Revised 09/13/04

13

Information Technology Change Management Process

This page left intentionally blank

Revised 09/13/04

14

Information Technology Change Management Process

CR Submission
Submitting a Change Request
Requirement
The Requestor must have a Magic user id, have access to Change Request link on their Magic navigation bar, and have a Mattel, Fisher Price or American Girl email address. Requestors who do not have a Magic user id will follow the former CR submission process defined in the Contingency Plan section of this document. The Change Requester fills out a Change Request form which details the necessary changes along with back-out procedures, who and what will be affected by the change, and contact information during the implementation process. The Change Request form is the most important piece of the Change Request process. The form contains a series of questions to assist the Change Requester in communicating the scope of the request, identifying the required participants, and noting the impact to the business unit(s). For Application changes it is important to document whether or not the change could affect any other system. The Change Requester is responsible for completing the Change Request form. The form may be returned to the Change Requester if the form is incomplete or lacking required detail.

Revised 09/13/04

15

Information Technology Change Management Process

Key Process Steps

There are key steps in the process that ensure Magics business automation rules perform as programmed: Generate email notifications to the Requestor and Approving Manager Correctly classify the activity as a Change Request Receive a response to an approval and assign the CR to the Change Coordinator Unplanned CR Approval Process If they are not followed the automation rules will not generate notification of creation and request for approval.

These key steps are highlighted with a traffic signal

Revised 09/13/04

16

Information Technology Change Management Process

Accessing the CR Template in Magic

Click on the Change Request link on your Magic navigation bar. The Change Request template will display.

Revised 09/13/04

17

Information Technology Change Management Process

Process Steps for Documenting and Submitting a Change Request

5 1 2 3

The following process steps describe the sections to be completed in the CR template. The steps correspond to the five template sections that must be completed. to obtain approvals. The data entered for any request will be published in the change management agendas and discussed in the weekly meeting. All fields are required to be filled in to obtain approval.

Revised 09/13/04

18

Information Technology Change Management Process

Section 1
Request Number No entry required. This is a read only field. It will auto fill when you save the CR. CR Type The contents of this field will be determined by what the Requester has selected on the Change Request form. The recurring ticket defaults to PLANNED in this field, but if another Change Type is selected on the Change Request form, the field will have to be edited to reflect the correct type. From the drop down menu select Fast Track, Planned, Unplanned or Emergency. Opened No entry required. This is a read only field. It will auto fill when you save the CR. Status ID Do not change. The status id must be OPEN. Group Name No entry or group assignment is required. It will auto fill when you save the CR. The CR will be assigned to the requestors Magic group.

Section 2
Requestor ID The Requesters department and extension are required. MAGIC profiles may include this information, but if the appropriate areas do not fill, the information will need to be added. Click on the pop up list button to select your name. Sponsor Name No entry required. Phone number Requestor work phone number is required. Requestor Manager Click on the pop up list button. Select the Requestors Manager name.

Revised 09/13/04

19

Information Technology Change Management Process

Section 3
Start and end time Enter dates in US format (MM/DD/YY). Enter times in 24hour/military clock format. All start and end times must be entered as Pacific Standard Time (Los Angeles). Actual Leave this field blank. The Requestor will enter the actual time spent performing the CR after the activity is complete but before the help desk ticket is closed. System Enter the name of the system(s) and applications the CR activity is planned for. Platform Click on the pop up list button to select the platform type. Y/E (Year End) The default is NO so you can normally leave this field blank unless it is a year-end activity. Equip /System Affected Click on the pop up list button to select the equipment or system type affected by the CR activity. EDI For EDI activities click on the pop up list button to select the appropriate value. Subject ID

Click on the pop up list button. The support subject list will be presented. Place your pointer on subject id CR, left click once on the field to highlight in blue, click OK and the subject type will auto fill with CR. You may also type CR in the Subject ID field instead of using the pop-up list. If CR type is not used the business rule that generates the email request to the Approving Manager will not kick off. If a subject type id is not CR the business automation rules associated with this process will not perform as programmed. The Approving Manager will not receive the approval request. The Change Request will remain assigned to Requestor.

Revised 09/13/04

20

Information Technology Change Management Process

Section 4
Business Unit Affected Identify the business units and users directly and/or indirectly affected by the activity. Identify the number of users affected. Could change affect anything else? Identify the systems, hardware, and processes directly or indirectly affected by the activity. Describe the activity The Approving Manager, Change Coordinator, and IT peers will rely on the description is this field to approve a Change Request. To expedite approval a concise description is required. It should include the description of work to be performed including, but not limited to: 1. Actions and tasks you will take. 2. Reason why the activity will be performed. 3. Locations affected business units, divisions, and their geographical locations 4. Number of users affected. 5. Domain names and ip addresses. 6. Application name(s). Backout Plan Describe the process and procedure that you will follow in the event you have to back out of the CR. Include the point of time within the planned activities stop and start time in which you will stop all CR activities and return to a pre CR status. Dependencies Describe the people, processes and resources the CR depends on to be successful. Impact of not making the change Describe the consequences of not performing the planned activity. Validation Describe the tasks that will be performed to validate that the change is successful. Include when these tasks will be performed. Who will validate, onsite person and phone number Identify who will validate the success of the change and provide contact numbers. Completion Status Leave this field blank. The Requestor will select Successful, Unsuccessful, Caused Problem or Not Complete after the activity is complete but before the help desk ticket is closed.

Revised 09/13/04

21

Information Technology Change Management Process Risk Assessment Every change has an associated risk. The person requesting the change should assess the risk level of the change. Modeling the change in a lab environment or with a modeling tool can also help assess the risk of a change. We recommend assigning one of the following risk categories to each change request: High-Risk These changes have the highest impact on user groups or particular environments, and may even affect an entire site. Backing out of the change is time consuming or difficult. You should research high-risk changes using the tools available, and implement the change in conjunction with necessary support personnel. Make sure management is aware of the change and its implications, and notify all users. Moderate-Risk These changes can critically impact user environments or affect an entire site, but backing out of the change is a reasonably attainable scenario. You should research moderate-risk changes using tools available, and possibly review the change with support personnel. Make sure management is aware of the change and its implications, and notify all users.

Low-Risk These changes have minor impact on user environments and backing out of the change is easy. Low-risk changes rarely require more than minimal documentation. Make sure management is aware of the change and its implications, and notify all users. Approver Email Address Enter the email address of the Manager who will approve the CR. The email address must be entered in the following format for the Approving Manager to receive a request to approve email from MagicTSD. Example format: John.Doe@mattel.com Joe.Doe@Pleasantco.com Joe.Doe@Fisher-Price.com If the Approving Managers email address is not entered or accurate the business rules associated with this process will not perform as programmed. The Approving Manager will not receive the approval request. The Change Request will remain assigned to Requestor. Who can approve a CR The approval hierarchy requirement for CRs is: Revised 09/13/04 22

Information Technology Change Management Process Fastrack and Planned CR Requestors Manager Unplanned and Emergency CR - Requestors Manager, Director, VP, Direct Report of the CIO Delegation of approval authority If a Manager, Director, VP, or CIO direct report with CR approval authority will be out of the office he/she can delegate approval authority to a peer or direct report. An email must be sent to the Change Coordinator identifying the start and end dates of the delegation period and the designees name.

Section 5
Save the CR to Create a Ticket and Route to a Manager for Approval Once all fields are complete click on the save icon. This will generate a ticket number and send the email notification from MagicTSD to the Requestor and Approving Manager. Example emails are displayed in Appendix C and D. Manager and Direct Report of CIO Approval Process To approve a request reply to the email without changing the Subject line. The request will be updated in the Magic system with your name and approval and route the ticket to Magic group CHANGE REQUEST for processing. See Appendix C for email example. CR Date/Time Change and CR Time Extension

Change the date and/or time of the activity before the CR has been presented at the meeting.
If the CR must be performed prior to the weekly meeting the Requestor will change the CR type to Unplanned and obtain the approval of their Manager, Director, and a direct report of the CIO. (All Unplanned CRs require the approval of a direct report of the CIO) If the CR will be presented at the next weekly meeting the Requestor will change the date and time on the CR. The Requestor/Representative will receive the CR agenda and is required to attend the next CM meeting. If the agenda has been published and the change is not shown on the agenda the Requestor/Representative will inform the Change Coordinator of the change at the meeting.

Revised 09/13/04

23

Information Technology Change Management Process

Change the date and/or time after receiving approval at the meeting, before the activity has been performed, and the date/time change is before the next weekly meeting.
Requestor will send an email to the Change Coordinator. Change Coordinator will modify the CR Requestor will notify the business unit and all affected users. Change Coordinator will discuss CR with date/time change at next meeting.

Extend the CR while performing the activity

Requestor is extending the CR end time by no more than 2 hours Requestor will email or call Phoenix Operations. Requestor will notify the business unit and all affected users Operations will document the request in the CR action notes.

Requestor is extending the CR end time by more than 2 hours but less than 4 hours. Approving Manager will notify Phoenix Operations they approve of the extension. Requestor will notify the business unit and all affected users Operations will document the request in the CR action notes.

Requestor is extending the CR end time by more than 4 hours Requestor will inform their Director of the extension request. Director will notify Phoenix Operations approving the extension. Requestor will notify the business unit and all affected users

Revised 09/13/04

24

Information Technology Change Management Process Operations will document the request in the CR action notes. The Requestors VP should be notified if the CR is considered high impact. CRs may not be extended beyond the next weekly change meeting, after which a new CR is required.

Section 6
Contingency Plan in the event Magic is not available In the event Magic is not available use the following process to submit a CR for approval: Obtain a Change Request Form from: http://is-r-us/IS-R-US/BusinessCenter/PhoenixDataCenter/CMhome.htm . The form fields are a replication of the Magic template only in MS Word format. Fill in all fields. Submit the form to the Approving Manager and required Users Instruct the Approving Manager to submit their approval via email to email address 7411 (the Phoenix Help Desk). When Magic is available the Help Desk will open a Change Request in Magic.

Revised 09/13/04

25

Information Technology Change Management Process

CR Approval Process
Email Received From MagicTSD - Reply to MagicTSD. If you receive an email from MagicTSD follow the approval instructions described in the email and reply to MagicTSD . Do not change the subject line when replying. When you reply the request will be updated in Magic with your name and approval status. Email Received From a Direct Report - Forward to MagicTSD If you receive an email from a direct report follow the approval instructions described in the email and forward your approval to MagicTSD. Do not change the subject line. When you forward the request will be updated in Magic with your name and approval status. Requestors who do not have a Magic user id Requestors who do not have a Magic user id will follow the former CR submission process and submit their request via a MS Word document. Submit your approvals to Customer Service -Phoenix.

Requestor Manager Not Available to Approve a CR

Submitting a CR to a Designated Manager If a Requestors Manager is not available to approve a CR the Requestor should forward the email notification they received (Example in Appendix D) to the designated Approving Manager. When doing so ensure the following instruction is sent to the designate and do not change the subject line:
To approve this request forward this email to email address MAGIC TSD. Please do not change the Subject line. This will ensure your approval will be processed by the Magic system.

Resubmit a Change Request to a Manager for Approval

In the event a Manager decides to approve a request after originally declining it and the Manager does not have the original email requesting approval follow the steps defined in the section above. When doing so do not change the subject line.

Unplanned and Emergency CR Approval Process

Requestors should submit Unplanned and Emergency CRs to their Manager. The Manager will forward the MagicTSD email (do not change the subject line) to a direct report of the CIO for approval. The direct report of the CIO will forward the email (do not change the subject line) to MagicTSD with their approval.

Revised 09/13/04

26

Information Technology Change Management Process

Accepted Changes
Once the proper approvals have been received all Planned Change Requests will be accepted and reviewed at the next Change Management meeting.

Change Management Meeting Agenda

The Change Management meeting agenda is a listing of all 'Accepted' change requests in the MAGIC system. The report will list the requests in order of the planned installation date and time. The Change Coordinator will generate an agenda on Monday to all requestors and all members of distribution list Change Management - Global IT. ALL Planned Change Request are due by close of business *Monday 1700hrs PST to make the next meetings agenda. *If Monday is a holiday CRs are due by 1300hrs PST on Tuesday.

Change Management Meeting

On Wednesday at 0800 PST/PDT of every week, the Change Management meeting will be held to discuss all of the Change Requests that appear on the agenda. The Requester must be present to answer any questions regarding their request. If the request is rejected for any reason in the Change Management meeting, the Change Coordinator will update the MAGIC ticket with the reason, change the status of the ticket accordingly ( REJECTED,). Only requests for the current 1-week cycle will be approved. If the request is approved in the weekly meeting, the MAGIC ticket will be updated to 'APPROVED' status.

Change Management Meeting Minutes

After the meeting the Change Coordinator will generate the minutes of the meeting listing all approved Planned requests to all the requestors and members of distribution list Change Management - Global IT.

CR Implementation and Ticket Closure

The Requester must call or email Phoenix Operations (701-3041) to advise the CR they are beginning the CR implementation. Another call or email must be made no later than the planned end time of the implementation to provide a closure status. If the request has been completed, the MAGIC ticket will then be assigned to the appropriate workgroup as indicated by the Requesters Manager on the MAGIC Ticket for final update on the success of the implementation. The Requesters Manager or Requester will then close the MHD ticket.

Revised 09/13/04

27

Information Technology Change Management Process

Appendix A
Example Completed Change Request Template

Accepted by Change Coordinator

Approval Received Approval Requested

Revised 09/13/04

28

Information Technology Change Management Process

Appendix B
Example Change Request Help Desk Ticket

Change Coordinator receives in Magic queue to process.

Manager Approved

Email sent by Requestor to Manager Requestor creates CR

Revised 09/13/04

29

Information Technology Change Management Process

Appendix C
Example Email Notification Sent to Approving Manager
-----Original Message----From: MagicTSD@Mattel.com [mailto:MagicTSD@Mattel.com] Sent: Wednesday, November 12, 2003 10:57 AM To: Richard.Tavilla@mattel.com Subject: Management Approval needed for: CR #(138473)

CR# 138473 has been submitted by Phone: (623)476-3042 EXT: Open Date: 11/12/2003 9:55:38 AM

James Beck

Your approval is necessary for this request to be processed by the Change Coordinator.

To approve this request reply to this email without changing the Subject line. The request will be updated in the Magic system with your name and approval. If you do not approve this request, please contact the requestor shown above, and do not reply to this email. A reply is considered an approval by the Magic application. *********************************************************** Risk Assessment: Request Type: Moderate

PLANNED Change Requests 11/22/03 12:00

Planned Start(PST): Planned End(PST): System: MagicTSD NT

11/22/03

15:00

Platform:

Equip/System Affected:

Applications Everybody using the MagicTSD system

Business Units Affected:

Could change affect anything else:

No

Description of Activity: Run a backup on the magic database on napdcm70a. Shut down MagicTSD to run the DBAdmin utility. Modify the HelpDesk view to add Client information. Modify forms for Help Desk to display new client information.

Revised 09/13/04

30

Information Technology Change Management Process

Reformat the Change Request Form to eliminate unnecessary fields. Reboot NAPDCM70A to recycle all services. Start and test MagicTSD to make sure changes are working correctly. Backout Plan: Dependancies: CR. Restore database Shutdown magicTSD. No access to application during this

Impact of not making change: Needed client information will not be available in the Help Desk ticket window. Validation Method: windows/data display correctly Who will validate: Onsite person: Start magic application and make sure the

Jim Beck

Jim Beck 6234763042

Onsite phone number: Onsite Cell/Pager:

Manager and Direct Report of CIO Approval Process

To approve a request reply to the email without changing the Subject line. The request will be updated in the Magic system with your name and approval.
-----Original Message----From: Tavilla, Richard Sent: Wednesday, November 12, 2003 11:04 AM To: MagicTSD Cc: Beck, James E; Hartman, Lynn L; Brown, Alex; Calderon, Eddie; McCune, John M; Perez, Joe; Tavilla, Richard; Zeilinger, Jerry Subject: RE: Management Approval needed for: CR #(138473)

approved -----Original Message----From: MagicTSD@Mattel.com [mailto:MagicTSD@Mattel.com] Sent: Wednesday, November 12, 2003 10:57 AM To: Richard.Tavilla@mattel.com Subject: Management Approval needed for: CR #(138473)

CR# 138473 has been submitted by Phone: (623)476-3042 EXT: Open Date: 11/12/2003 9:55:38 AM

James Beck

Your approval is necessary for this request to be processed by the Change Coordinator.

Revised 09/13/04

31

Information Technology Change Management Process

To approve this request reply to this email without changing the Subject line. The request will be updated in the Magic system with your name and approval. If you do not approve this request, please contact the requestor shown above, and do not reply to this email. A reply is considered an approval by the Magic application. *********************************************************** Risk Assessment: Request Type: Moderate

PLANNED Change Requests 11/22/03 12:00

Planned Start(PST): Planned End(PST): System: MagicTSD NT

11/22/03

15:00

Platform:

Equip/System Affected:

Applications Everybody using the MagicTSD system No

Business Units Affected:

Could change affect anything else:

Description of Activity: Run a backup on the magic database on napdcm70a. Shut down MagicTSD to run the DBAdmin utility. Modify the HelpDesk view to add Client information. Modify forms for Help Desk to display new client information. Reformat the Change Request Form to eliminate unneccessary fields. Reboot NAPDCM70A to recycle all services. Start and test MagicTSD to make sure changes are working correctly. Backout Plan: Dependancies: CR. Restore database Shutdown magicTSD. No access to application during this

Impact of not making change: Needed client information will not be available in the Help Desk ticket window. Validation Method: windows/data display correctly Who will validate: Onsite person: Start magic application and make sure the

Jim Beck

Jim Beck 6234763042

Onsite phone number: Onsite Cell/Pager:

Revised 09/13/04

32

Information Technology Change Management Process

Appendix D
Example Email Notification Sent to the Requestor
-----Original Message----From: MagicTSD@Mattel.com [mailto:MagicTSD@Mattel.com] Sent: Wednesday, November 12, 2003 10:57 AM To: James.Beck@Mattel.com Subject: Management Approval needed for: CR #(138473)

APPROVAL REQUEST HAS BEEN SENT TO: Richard.Tavilla@mattel.com *********************************************************** CR# 138473 has been submitted by Phone: (623)476-3042 EXT: Open Date: 11/12/2003 9:55:38 AM James Beck

Your approval is necessary for this request to be processed by the Change Coordinator. To approve this request reply to this email without changing the Subject line. The request will be updated in the Magic system with your name and approval. If you do not approve this request, please contact the requestor shown above, and do not reply to this email. A reply is considered an approval by the Magic application. *********************************************************** Risk Assessment: Request Type: Moderate

PLANNED Change Requests 11/22/03 12:00

Planned Start(PST): Planned End(PST): System: MagicTSD NT

11/22/03

15:00

Platform:

Equip/System Affected:

Applications Everybody using the MagicTSD system No

Business Units Affected:

Could change affect anything else:

Revised 09/13/04

33

Information Technology Change Management Process

Description of Activity: Run a backup on the magic database on napdcm70a. Shut down MagicTSD to run the DBAdmin utility. Modify the HelpDesk view to add Client information. Modify forms for Help Desk to display new client information. Reformat the Change Request Form to eliminate unneccessary fields. Reboot NAPDCM70A to recycle all services. Start and test MagicTSD to make sure changes are working correctly. Backout Plan: Dependancies: CR. Restore database Shutdown magicTSD. No access to application during this

Impact of not making change: Needed client information will not be available in the Help Desk ticket window. Validation Method: windows/data display correctly Who will validate: Onsite person: Start magic application and make sure the

Jim Beck

Jim Beck 6234763042

Onsite phone number: Onsite Cell/Pager:

Revised 09/13/04

34

Information Technology Change Management Process

Appendix E
Visio Diagram of Magic Process
CHANGE REQUEST SUBMISSION USING MAGIC HELP DESK

Requestor logs into magic and Fills out the Change Request

Change Request is Saved in Magic

Business Rule 1 fires. Sends request for approval to specified address

Approver reviews Change Request

REJECTED

Approver works with Requestor to get approval

APPROVED

Approver replies to email with written approval

Magic updates Change Request with approval information, Assigns to Change Control group.

Change Coordinator reviews CR for proper approval

Change Request placed on the Agenda

Revised 09/13/04
END CHANGE REQUEST SUBMISSION

35