CM Procedures

8/12/2019 CM Procedures

1/36

Change Management Procedure

Global Information Technology


2/36

Information TechnologyChange Management Process

CHANGE MANAGEMENT............................................................................................ 3

INTRODUCTION ................................................................................................................ 3

OVERVIEW ....................................................................................................................... 3

CHANGE MANAGEMENT OBJECTIVES .............................................................................. 3SCOPE .............................................................................................................................. 4

CHANGE MANAGEMENT PROCESS ........................................................................ 6

GENERAL INFORMATION.................................................................................................. 6

ROLES AND RESPONSIBILITIES ......................................................................................... 7

CHANGE DEFINITION ....................................................................................................... 8CHANGE TYPES................................................................................................................ 9

CHANGE WINDOWS........................................................................................................ 12

RISK ASSESSMENT ......................................................................................................... 12

CR SUBMISSION........................................................................................................... 15

SUBMITTING A CHANGE REQUEST ................................................................................. 15

Requirement .............................................................................................................. 15KEY PROCESS STEPS ...................................................................................................... 16

ACCESSING THE CRTEMPLATE IN MAGIC ..................................................................... 17PROCESS STEPS FOR DOCUMENTING AND SUBMITTING A CHANGE REQUEST ................ 18

SECTION 1...................................................................................................................... 19

Request Number.................................................................................................... 19CR Type ................................................................................................................ 19

Opened .................................................................................................................. 19

Status ID................................................................................................................ 19Group Name.......................................................................................................... 19

SECTION 2...................................................................................................................... 19

Requestor ID ......................................................................................................... 19Sponsor Name....................................................................................................... 19

Phone number ....................................................................................................... 19Requestor Manager ............................................................................................... 19

SECTION 3...................................................................................................................... 20

Start and end time ................................................................................................. 20

Actual.................................................................................................................... 20System................................................................................................................... 20

Platform................................................................................................................. 20

Y/E (Year End) ..................................................................................................... 20Equip /System Affected ........................................................................................ 20

EDI........................................................................................................................ 20Subject ID ............................................................................................................. 20

SECTION 4...................................................................................................................... 21

Business Unit Affected ......................................................................................... 21

Could change affect anything else? ...................................................................... 21Describe the activity ............................................................................................. 21

Backout Plan ......................................................................................................... 21

Dependencies ........................................................................................................ 21

Revised 09/13/04 1


3/36


Impact of not making the change.......................................................................... 21

Validation.............................................................................................................. 21Who will validate, onsite person and phone number............................................ 21

Completion Status................................................................................................. 21

Risk Assessment ................................................................................................... 22

Approver Email Address....................................................................................... 22Who can approve a CR ......................................................................................... 22

Delegation of approval authority .......................................................................... 23

SECTION 5...................................................................................................................... 23Save 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 .................................................. 23Change 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.................................................................................................................. 24Extend the CR while performing the activity ....................................................... 24

SECTION 6...................................................................................................................... 25Contingency 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.................................................................. 27Change Management Meeting .................................................................................. 27Change Management Meeting Minutes .................................................................... 27CR 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 EMAILNOTIFICATION SENT TO APPROVING MANAGER................................. 30MANAGER AND DIRECT REPORT OF CIOAPPROVAL PROCESS ...................................... 31

APPENDIX D.................................................................................................................. 33

EXAMPLE EMAILNOTIFICATION SENT TO THE REQUESTOR........................................... 33

APPENDIX E .................................................................................................................. 35

VISIO DIAGRAM OF MAGIC PROCESS ............................................................................. 35

Revised 09/13/04 2


4/36


CHANGE MANAGEMENT

Introduction

This document describes the processes used to plan, coordinate, and implement changesto any production, test or development environment at Mattel, Fisher Price, andAmerican 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.

OverviewChange Management is designed to implement change into the IT environment with

minimal disruption of service.. This includes changes in technology, tools, systems, andhardware. 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 otherenvironments.

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 productionenvironment and minimize disruptions to customers and production systems.

Revised 09/13/04 3


5/36


Fast Track the approval process for low impact and development and testenvironment changes and changes that will not result in system downtime, loss in

user productivity, limited user access to an application, or have significant impactto 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 ofproduction 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 managementare aware of and in agreement with all Change Requests.

Discuss unsuccessful CRs during the weekly Change Management meeting toreview 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 areconsidered 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 4


6/36


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 whichprovide 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 applicationsystem 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 impactany aspect of the production environment or users

Database Stored procedures

Revised 09/13/04 5


7/36


Change Management Process

General Information

1 Changes that result in database modifications, system downtime, loss in userproductivity, 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 theopportunity to be discussed at the weekly Change Management meeting.

2 Change Requests must be received in the Magic Change Request queue withappropriate approval prior to the close of business Monday to be included on the

Wednesday meeting agenda.

3 Change Requests received after 17:00 (5PM PST) and scheduled before thefollowing weeks meeting would be considered Unplanned and would need aCIOs direct report approval.

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

5 The Change Management Meeting Agenda will be distributed on Mondayevening. If Monday is a holiday the agenda will be published Tuesday evening.

6 Change Management meetings are held each Wednesday at 8:00 AM PST (11:00AM EST).

7 The Change Management Coordinator is the on-duty PTC supervisor. The HelpDesk Manager is the process administrator.

8 In the event of an Emergency Change Request, or an Unplanned Change Request,authorization from any of the CIOs direct reports is required.

9 Emergency Change Requests are submitted for approval as the result of a SEV 1event. A change can be declared an emergency when immediate repair servicesare required to a production environment and a Severity1 trouble ticket is opened

in MHD.

10 Unplanned and Emeregency Change Requests must be approved by a direct reportof the CIO.

Revised 09/13/04 6


8/36


Roles and Responsibil itiesRole and Responsibility Tasks

TheSponsor is the customer who

requested the change. Communicates requirements to Change Requester.

Verifies the change was implemented per their request

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

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 informationwhich 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

The Change Coordinator ensures the

change management process functions

smoothly and efficiently.

Facilitates the weekly Change Management meeting

Takes responsibility for ensuring timely approval of all changes from

support groups

The Change Implementeris the

person or group (Production Control

Group) that executes the change.

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 7


9/36


Change Defini tion

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

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 theoperating 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 ASPchanges that result in a content change, they do not go through the CR process.

Revised 09/13/04 8


10/36


Change Types

Type Description

Planned Reviewed and approved through the Change ManagementProcess. 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 tothe 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 theapproval 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.

Emergency A change can be declared an emergency when immediate

repair services are required to a production environment anda Severity1trouble 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 Fast Track changes do not require a 5 day lead time. They

are low risk, have no impact on production systems anddatabases, and do not result in server or system downtime to

production environments and the users production access

will not be interrupted.

Revised 09/13/04 9


11/36


ENVIRONMENT AND

CONDITION

RISK

LEVEL PLANNED UNPLANNED EMERGENCY

Production

No system downtime.

Change will notmodify database(s)

No impact to userproductivity or access

to the environment.

Access to theenvironment will be

not be interrupted or

limited.

Within the four wallsof the requestors

company or entire

location.

LOW Fast Track

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 fourwalls of the requestors

company

LOW

MODERATE

HIGH

5 Day Lead

Required

CIO Direct

Report

Approval

Required

SEV 1 Trouble

Ticket

CIO Direct

Report

Approval

Development/Test

Change inDevelopment/Test will

not impact a

production instance,

result in system

downtime or limit a

users access to the

environment.

LOW Fast Track

Development/Test

Change inDevelopment/Test will

result in system

downtime or limited

accessibility and will

have an impact on the

projects timeline.

LOW

MODERATE

HIGH

5 Day LeadRequired

CIO DirectReport

Approval

Required

SEV 1 TroubleTicket

CIO Direct

Report

Approval

Revised 09/13/04 10


12/36


ENVIRONMENT AND

CONDITION

RISK

LEVEL PLANNED UNPLANNED EMERGENCY

Web Application

Change does not

modify database.

Changes affectspresentation only and

involve HTML or ASP

changes that result in a

content change, they

do not go through the

CR process.

LOW NO CR

REQUIRED

NO CR

REQUIRED

NO CR

REQUIRED

Web Application

Change will modify

database(s)

LOW

MODERATE

HIGH

5 Day Lead

Required

CIO Direct

Report

ApprovalRequired

SEV 1 Trouble

Ticket

CIO DirectReport

Approval

Software

Installation or upgradeof software

LOW

MODERATE

HIGH

5 Day Lead

Required

CIO Direct

Report

Approval

Required

SEV 1 Trouble

Ticket

CIO Direct

Report

Approval

Hardware

Installation or upgradeof hardware

LOW

MODERATE

HIGH

5 Day Lead

Required

CIO Direct

Report

Approval

Required

SEV 1 Trouble

Ticket

CIO Direct

Report

Approval

Revised 09/13/04 11


13/36


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 aweekday non-working hours and non-critical processing periods.

Communication i.e..telecom and email changes will be performed during non-working hours and non-critical processing periods.

Changes that require a system outage or major upgrades will be scheduled duringthe weekend change window.

There will be no changes allowed during the last week of each month or duringthe last two weeks of each quarter unless approved by a director report of theCIO.

Unplanned and Emergency changes will be completed as needed to supportcritical 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-riskThese 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 toolsavailable, and implement the change in conjunction with necessary support personnel.

Make sure management is aware of the change and its implications, and notify allusers.

Moderate-riskThese changes can critically impact user environments or affect anentire site, butbacking 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


14/36


Change Request Submission and Approval FlowChart

Business

communicates

requirements to

Change Requestor

Magic Buisness

Rule

Records Approval

Approving

Manager

responds to

MAGICTSD with

Approval

MHD sends email

to Approving

Manager advising

CR needs

approval

Change

Requestor

submits CR via

Magic

Change

Coordinator adds

request to weeklyagenda

CM MeetingApproval obtained

at CM Meeting

Requestor

notifies Ops of

CR start.

REQUESTOR

IMPLEMENTS

Requestor

notifies Ops of

CR end.

Ops updates and

closes CR

Return email to

Change

Requestor

correction

Requestor corrects and

closes CR or resubmits

for approval

Approving

Manager declines

approval and

emails Requestor

Except forUnplanned CRs

Revised 09/13/04 13


15/36


This page left intentionally blank

Revised 09/13/04 14


16/36


CR Submission

Submitt ing 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 communicatingthe 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 ChangeRequester if the form is incomplete or lacking required detail.

Revised 09/13/04 15


17/36


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


18/36


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


19/36


Process Steps for Documenting and Submitting a ChangeRequest

he following process steps describe the sections to be completed in the CR

pleted.

ll fields are required to be filled in to obtain approval.

5

T

template. The steps correspond to the five template sections that must be com

to obtain approvals. The data entered for any request will be published in the

change management agendas and discussed in the weekly meeting.

A

Revised 09/13/04 18


20/36


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 theChange 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 thisinformation, 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 ManagerClick on the pop up list button. Select the Requestors Manager name.

Revised 09/13/04 19


21/36


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

PlatformClick 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-endactivity.

Equip /System Affected

Click on the pop up list button to select the equipment or system type affected by the CR

activity.

EDIFor 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. Placeyour 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


22/36


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 locations4. 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 inwhich you will stop all CR activities and return to a pre CR status.

DependenciesDescribe 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. Includewhen 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, CausedProblem or Not Complete after the activity is complete but before the help desk ticket isclosed.

Revised 09/13/04 21


23/36


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, andmay 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 awareof 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 researchmoderate-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 notifyall 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 suremanagement 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 fromMagicTSD. Example format:

[email protected]

[email protected]

[email protected]

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 CRThe approval hierarchy requirement for CRs is:

Revised 09/13/04 22
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


24/36


Fastrack and Planned CR Requestors ManagerUnplanned and Emergency CR - Requestors Manager, Director, VP, Direct Report of the

CIO

Delegation of approval authorityIf 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 thedelegation 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 numberand send the email notification fromMagicTSDto 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 beenpresented at the meeting.

If the CR must be performed prior to the weekly meeting the Requestor willchange 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 approvalof a direct report of the CIO)

If the CR will be presented at the next weekly meeting the Requestor will changethe 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 theRequestor/Representative will inform the Change Coordinator of the change at the

meeting.

Revised 09/13/04 23


25/36


Change the date and/or time after receiving approval at the meeting,before the activity has been performed, and the date/time change isbefore 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 theextension.



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.


Revised 09/13/04 24


26/36



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 formfields 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 UsersInstruct 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
http://is-r-us/IS-R-US/BusinessCenter/PhoenixDataCenter/CMhome.htmhttp://is-r-us/IS-R-US/BusinessCenter/PhoenixDataCenter/CMhome.htm


27/36


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 requestwill be updated in Magic with your name and approval status.

Requestors who do not have a Magic user idRequestors 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 stepsdefined 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) toMagicTSD with their approval.

Revised 09/13/04 26


28/36


Accepted ChangesOnce 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 allrequestors 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 ticketaccordingly ( 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 listChange Management - Global IT.

CR Implementation and Ticket Closure

The Requester must call or email Phoenix Operations (701-3041) to advise the CR theyare 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 hasbeen completed, the MAGIC ticket will then be assigned to the appropriate workgroup as

indicated by the RequestersManager 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


29/36


Appendix A

Example Completed Change Request Template

Approval

Received

Accepted by

Change

Coordinator

Approval

Requested

Revised 09/13/04 28


30/36


Appendix B

Example Change RequestHelp Desk Ticket

Email sent by

Requestor to

Manager

Manager

Approved

Requestor creates

CR

Change Coordinator

receives in Magic

queue to process.

Revised 09/13/04 29


31/36


Appendix C

Example Email Notification Sent to Approving Manager-----Original Message-----

From: [email protected] [mailto:[email protected]]Sent: Wednesday, November 12, 2003 10:57 AMTo: [email protected]

Subject: Management Approval needed for: CR #(138473)

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

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

ChangeCoordinator.

To appr ove t hi s r equest r epl y t o t hi s emai l wi t hout changi ng t heSubj ect l i ne. The r equest wi l l be updated i n t he Magi c system wi t h yourname and appr oval .

I f you do not appr ove t hi s r equest , pl ease cont act t he request or shownabove, and do not r epl y t o t hi s emai l . A r epl y i s consi der ed anappr ovalby t he Magi c appl i cat i on.***********************************************************

Ri sk Assessment : Moderate

Request Type: PLANNED Change Request s

Pl anned St ar t ( PST) : 11/ 22/ 03 12: 00

Pl anned End( PST) : 11/ 22/ 03 15: 00

Syst em: Magi cTSD

Pl at f orm: NT

Equi p/ Syst em Af f ect ed: Appl i cat i ons

Busi ness Uni t s Af f ected: Ever ybody usi ng t he Magi cTSD syst em

Coul d change af f ect anyt hi ng el se: No

Descr i pt i on of Act i vi t y: Run a backup on t he magi c dat abase onnapdcm70a.Shut down Magi cTSD t o run t he DBAdmi n ut i l i t y.Modi f y t he Hel pDesk vi ew t o add Cl i ent i nf ormat i on.Modi f y f orms f or Hel p Desk t o di spl ay new cl i ent i nf ormat i on.

Revised 09/13/04 30


32/36


Ref ormat t he Change Request For m t o el i mi nate unnecessar y f i el ds.Reboot NAPDCM70A t o r ecycl e al l servi ces.St art and test Magi cTSD t o make sur e changes ar e worki ng cor r ect l y.

Backout Pl an: Rest ore database

Dependanci es: Shut down magi cTSD. No access t o appl i cat i on duri ng t hi sCR.

I mpact of not maki ng change: Needed cl i ent i nf ormat i on wi l l not beavai l abl e i n t he Hel p Desk t i cket wi ndow.

Val i dat i on Method: St art magi c appl i cat i on and make sure t hewi ndows/ dat adi spl ay cor r ectl y

Who wi l l val i dat e: J i m Beck

Onsi t e per son: J i m Beck

Onsi t e phone number : 6234763042

Onsi t e Cel l / 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, RichardSent: Wednesday, November 12, 2003 11:04 AM

To: MagicTSDCc: Beck, James E; Hartman, Lynn L; Brown, Alex; Calderon, Eddie;

McCune, John M; Perez, Joe; Tavilla, Richard; Zeilinger, JerrySubject: RE: Management Approval needed for: CR #(138473)

appr oved

- - - - - Or i gi nal Message- - - - -Fr om: Magi cTSD@Mat t el . com [ mai l t o: Magi cTSD@Mat t el . com]Sent : Wednesday, November 12, 2003 10: 57 AM

To: Ri char d. Tavi l l a@mat t el . comSubj ect : Management Appr oval needed f or : CR #( 138473)

CR# 138473 has been submi t t ed by J ames BeckPhone: (623)476- 3042 EXT:Open Dat e: 11/ 12/ 2003 9: 55: 38 AM

Your appr oval i s necessary f or t hi s r equest t o be processed by t heChangeCoor di nat or .

Revised 09/13/04 31


33/36


To appr ove t hi s r equest r epl y t o t hi s emai l wi t hout changi ng t heSubj ectl i ne. The request wi l l be updat ed i n t he Magi c syst emwi t h your nameandappr oval .





Pl anned End( PST) : 11/ 22/ 03 15: 00

Syst em: Magi cTSD

Pl at f orm: NT


Busi ness Uni t s Af f ected: Ever ybody usi ng t he Magi cTSD syst emCoul d change af f ect anyt hi ng el se: No

Descr i pt i on of Act i vi t y: Run a backup on t he magi c dat abase onnapdcm70a.Shut down Magi cTSD t o run t he DBAdmi n ut i l i t y.Modi f y t he Hel pDesk vi ew t o add Cl i ent i nf ormat i on.Modi f y f orms f or Hel p Desk t o di spl ay new cl i ent i nf ormat i on.Ref ormat t he Change Request For m t o el i mi nate unneccessar y f i el ds.Reboot NAPDCM70A t o r ecycl e al l servi ces.St art and test Magi cTSD t o make sur e changes ar e worki ng cor r ect l y.







Onsi t e phone number : 6234763042Onsi t e Cel l / Pager :

Revised 09/13/04 32


34/36


Appendix D

Example Email Notification Sent to the Requestor

-----Original Message-----

From: [email protected] [mailto:[email protected]]Sent: Wednesday, November 12, 2003 10:57 AMTo: [email protected]

Subject: Management Approval needed for: CR #(138473)

APPROVAL REQUEST HAS BEEN SENT TO: [email protected]***********************************************************

CR# 138473 has been submi t t ed by J ames Beck

Phone: (623)476- 3042 EXT:Open Dat e: 11/ 12/ 2003 9: 55: 38 AM

Your appr oval i s necessary f or t hi s r equest t o be processed by t heChangeCoor di nat or .

To appr ove t hi s r equest r epl y t o t hi s emai l wi t hout changi ng t heSubj ectl i ne. The request wi l l be updat ed i n t he Magi c syst emwi t h your nameandappr oval .





Pl anned End( PST) : 11/ 22/ 03 15: 00

Syst em: Magi cTSD

Pl at f orm: NT


Busi ness Uni t s Af f ected: Ever ybody usi ng t he Magi cTSD syst emCoul d change af f ect anyt hi ng el se: No

Revised 09/13/04 33


35/36


Descr i pt i on of Act i vi t y: Run a backup on t he magi c dat abase onnapdcm70a.Shut down Magi cTSD t o run t he DBAdmi n ut i l i t y.Modi f y t he Hel pDesk vi ew t o add Cl i ent i nf ormat i on.Modi f y f orms f or Hel p Desk t o di spl ay new cl i ent i nf ormat i on.Ref ormat t he Change Request For m t o el i mi nate unneccessar y f i el ds.Reboot NAPDCM70A t o r ecycl e al l servi ces.St art and test Magi cTSD t o make sur e changes ar e worki ng cor r ect l y.







Onsi t e phone number : 6234763042

Onsi t e Cel l / Pager :

Revised 09/13/04 34


36/36


Appendix E

Visio Diagram of Magic Process

CHANGE REQUEST

SUBMISSION USING

MAGIC HELP DESK

Requestor logs

into magic and

Fills out the

Change Request

Approver replies to

email with written

approval

Business Rule 1

fires. Sends

request for

approval to

specified address

Change

Request is

Saved in

Magic

Approver

reviews

Change

Request

APPROVED

Approver works

with Requestor to

get approval

REJECTED

Magic updates

Change Request

with approval

information,

Assigns to Change

Control group.

Change

Coordinator

reviews CR for

proper approval

CM Procedures

Documents

Transcript of CM Procedures