OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT IT Initiator Training © 2006 IT Services Stanford...
-
Upload
ruth-hudson -
Category
Documents
-
view
219 -
download
0
Transcript of OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT IT Initiator Training © 2006 IT Services Stanford...
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 1
Change ManagementIT Initiator Training
http://www.stanford.edu/services/changemgt
March 6, 2006
Presented by John Klemm, Bill Heiser & Bill Bauriedel
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 2
Desired Outcomes for this Training Session
By the end of this training session, you will:
• Understand the basic concepts, definitions, and policies related to the new Change Management Process;
• Understand the scope and expectations related to the IT Initiator role; and
• Be prepared to initiate change requests via the web or via email.
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 3
Change Management Process Introduction to Basic Concepts
• The goal of Change Management is to ensure that standardized methods and techniques are used for efficient and prompt handling of IT changes to minimize the likelihood of disruption, unauthorized alterations, and errors.
• The Change Management process focuses on entering previously authorized change/implementation plans as a record into a system; obtaining approval for those changes; scheduling, implementing, and notifying key groups/staff/clients about those changes; and afterward reviewing changes.
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 4
What’s new or different about the new CM system?
• Modern web interface• Allows interaction via email (entering change notice, approving, closing)• Process has been formalized
– Lead-times of 3-10 days required for some categories of changes– New Change Advisory Board (tied into weekly Operations Review)– Buy-in from CM Steering Group and Executive Directors
• New application, relatively new vendor (Infra)• Complex application designed for a larger “change management process”• Still some issues: Missing features, login idiosyncrasies (mostly 1st time only),
unusual interface
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 5
Change Management Process Introduction to the IT Initiator Role
• The IT Initiator is the person who enters a Change Request into the Change Management System
• The IT Initiator submits and owns the Change Request
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 6
Change Management ProcessHigh-Level Process Flow
Change Planning Process
(includes approval from governance groups and business owners as well as design, development,
testing, etc.)
(optional)Emergency / FoOImplementation
Approval Implementation and Review
See Process Document for detailed process flows and detailed procedures
Initiate ChangeRequest (CR)
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 7
Change Management ProcessDefinitions: Change Management Terms
Change Request (CR) The request to implement an IT change that includes impact information, scheduling information, and Domain / Secondary Domain information
Change Categories
determined by the IT Initiator
• Major Change• Significant Change• Minor Change (General)• Minor Change (“Fixes of Opportunity / FOO”)• Standard Pre-Approved Change (SPA)• Special Category: Emergency Change
Change Priorities
determined by the IT Initiator
• Emergency (service is down)• Urgent (service is at risk)• Routine (service is not down; “business as usual” change request)
Note that Routine is the standard default priority.
In the new Change Management System, Change Request Category/Priority Combinations are called STENCILS
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 8
Change Management ProcessPolicy: Change Request Approvals and Lead-Times
Change Request STENCIL (Priority/Category)
Approval Required Recommended Lead-time
Emergency Retroactive approval (acknowledgment) required No minimum lead-time is required
Routine – Minor Domain / Secondary Domain authorization Three (3) business days (or as required by an existing SLA)
Routine – Minor FOO (“Fix of Opportunity”)
Retroactive Domain / Secondary Domain authorizations (acknowledgement) required
No minimum lead-time is required
Routine – Significant CAB AuthorizationDomain / Secondary Domain authorization
Five (5) business days (or as required by an existing SLA)
Routine – Major CAB MCR AuthorizationDomain / Secondary Domain authorization
Ten (10) business days (or as required by an existing SLA)
Urgent – Minor Retroactive approval (acknowledgment) required No minimum lead-time is required
Urgent – Minor FOO Retroactive approval (acknowledgment) required No minimum lead-time is required
Urgent – Significant Retroactive approval (acknowledgment) required No minimum lead-time is required
Urgent – Major Retroactive approval (acknowledgment) required No minimum lead-time is required
Standard Pre-Approved Change (SPA)
Pre-approved (SPA change requests have been previously reviewed and approved)
No minimum lead-time is required because no review is needed
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 9
Change Management ProcessDefinitions: Change Management Roles
Change Coordinator • Reviews and coordinates changes • Creates Standard Pre-Approved (SPA) Change Request Stencils• Creates compliance reports and performs ITS-driven audit reviews• Leads weekly CAB meetings; calls meetings of the CAB MCR
Change Advisory Board (CAB) • Meets weekly to review and gives final authorization to the Forward Schedule of Changes (FSC), which is the consolidated calendar of all authorized changes
• Reviews Standard Pre-Approved (SPA) requests and Significant Change Requests
• Conduct Post-Implementation Reviews (PIRs) of Significant and Major Changes, or any change that resulted in a service outage
CAB: Major Change Review Committee (CAB MCR)
• Subset of the CAB that meets as needed to review and give final authorization to Major Changes
Stakeholder(s) • Person (or persons) interested in changes to specific items; Stanford is using Mailman distribution lists (lists.stanford.edu) to manage notification mailings to stakeholders
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 10
Change Management ProcessDefinitions: Change Management Roles
Domain / Secondary Domain Authorizers (Approvers)
• Authorize (approve) Minor, Significant, and Major Changes in particular domains
IT Change Initiator • Uses the Change Management System to initiate a Change Request
Customer • Business User for whom the Change Request is being submitted
EQUIVALENT TERM IN THE CM SYSTEM:
Approver The person (or group of people) responsible for approving Change Requests.
EQUIVALENT TERM IN THE CM SYSTEM:
Officer or Request Manager
The person who submits and owns a Change Request. [an Infra term]
Continued from previous page
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 11
Scope of the Change Management Process
All production services, as well as all services with agreements that specifically state service levels and environment up-time (e.g., SLAs), are subject to the Change Management process and policies.
Change Management
Software
Application
Server
Operating System
Client
Hardware
See the OECM Process Document for a full list of the types of changes covered, including an expanded version of this diagram.
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 12
Additional Detail:Configuration Changes Covered by the CM Process
Any configuration change that can impact an existing SLA and/or is identified by a workgroup as having a significant negative impact on a service and affecting multiple users should be managed through the Change Management process.
A list of typical changes normally handled by each workgroup that require a change notice appears as Appendix B “Scope of the Change Management Process” including a list of configuration changes that do or do not require change notices.
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 13
Demo: Submitting a Change Request (Web)
Production Environment URL: http://cmr.stanford.edu (https://InfraAppProd.stanford.edu)Refer to QuickGuide for IT Initiators
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 14
Demo: Checking Status of a Change Request (Web)
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 15
Demo Result: Request Details Screen (Web)
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 16
Reference: Template for Submitting an Email Change Request
ADDRESS: [email protected] SUBJECT LINE: [createrequest]
REQUIRED FIELDS:[Stencil: ][Primary Domain: ][Change Title: ][Class: ][Type: ][Item:][Description: ][Schedule Date/Time:][Source: Email]
REQUIRED FIELDS:Note: do not use square brackets except as specified below
[Stencil: xxxxxxx] e.g. Routine - Minor[Primary Domain: xxxxxxx] e.g. Student & HR Systems[Change Title: xxxxxxx] up to 80 characters[Class: xxxxxxx] e.g. App-Student/HR - must be a valid
Class
[Type: xxxxxxx] e.g. HRSA-Technical - must be a valid Type
[Item: xxxxxxx] e.g. HRSA-Technical-CI - must be a valid Item
[Description: xxxxxxx] can span multiple lines
[Schedule Date/Time: mm/dd/yyyy hh:mm:ss] the hh:mm:ss is optional. If left out,
the time will be 00:00:00. Any part of the time may be left out. Eg. hh=17 becomes 17:00:00 and hh:mm = 17:30 becomes 17:30:00.
[Source: Email] required for email submissions
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 17
Reference: Template for Submitting an Email Change Request
OPTIONAL FIELDS:[Secondary Domains: xxxxxxx] e.g. Windows Systems, Unix Systems (each additional domain separated with a comma. Each must be a valid domain name.)[Secondary Item:xxxx,yyyy] specify here if the items aren't shown in the pick list[Activity: xxxxxxx] e.g. reboot or additional capacity or application upgrade,
etc. - must be a valid activity[Outage Start Date/Time: mm/dd/yyyy hh:mm:ss][Outage End Date/Time: mm/dd/yyyy hh:mm:ss][Install Plan: xxxxxxx] Install plan goes here[Backout Plan: xxxxxxx] Backout plan goes here[Impact Analysis: xxxxxxx] Impact Analysis goes here[Notes: xxxxxxx] Notes go here[Tested: xxx] Yes or No[Maintenance Window: xxx] Yes or No[Standard Pre-Approved Change Template: xxx] Yes or No[Cross Reference: xxxxxx] enter CPT number, otherwise leave out this line. It is for
system use only[Secure Information: xxxxxx] secure information goes here[Business Requestor: xxxxxx] name must be a business user defined in the system[Business Requestor (If not in CMDB): xxxxxxx] any name can be entered here[Requestor's Organization: xxxxxxx] must be a valid organization as
specified in the system
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 18
Demo: Submitting a Change Request (Email)
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 19
Should I initiate a Change Request via the Web App or Email?
Web Application• Easy to use• Choices in menus• No worries about typing labels• Instant feedback• Consider for infrequent or variable (different types of entries) use
Email• Templates can be made• Notes can be included• No login to web app required• Resubmit after correction (on initial entry failure, or on approver rejection)• Your sending email address must match your address in Infra database• Consider for frequent or repeated (same type of entries) use
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 20
What Happens After You Submit the Change Request?
• (Specific details depend on the Stencil you choose)
• Approvers receive email asking them to approve (via email or web app)
• Initiator receives a confirmation email
• Then, if/when all approvers approve, you receive email notification that the task of implementing the change and closing the change request record are yours to do
• If any approver disapproves, you receive email notification that the task of closing the change request record is yours to do
• You cannot change the change request record after submitting it. You cannot cancel it either. Solution: An approver can reject it, and you can submit a new change request.
• You can check the status/history of the change by going into the web application, finding the Request, going to the detail page (yellow arrow), and looking at the history section.
• Instructions for closing a change request record appear in the email you’ll receive - you can close it via email.
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 21
General Usage Tips for the New Change Management System
• Change Request = (Initiation Task + Notification Task (automatic) + Approval Task + Implementation Task)
IMPORTANT NOTE: tasks = requests
• Clicking for any Task or Approval means that you are actioning that Task or Approval and that you now own it - to “disown” it without taking action (if you need to), choose “forward” and send it back to your group
• When entering the date and time for a change request, specify time first, then select the date (if you select the date first, then the box closes having selected the date with the current time); note that date and time must be formatted in 24-hour/military time
• Avoid using the browser BACK button; instead use the application BACK button (if you use the browser BACK button, you will likely see undesirable results)
/
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 22
General Usage Tips, continued
• BOLD fields on the “Request Entry” and “New Task” web pages are required; all other fields are optional; the email template on (Page#) also specifies which fields are required as opposed to optional
• Two types of notification emails: a. Users can subscribe to a Mailman list to receive “all” notifications about changes
affecting a given domainb. Users can subscribe to another Mailman list to receive “limited” notifications about
changes for a given domain (i.e., user would receive notifications of Significant, Major, and Emergency changes only)
• Particularly when submitting email change requests, [square brackets], syntax, and spelling are critical; pulldown choices must be entered exactly as they appear in the web pulldown menu(s)
• IMPORTANT NOTE: It is not possible for a user to make changes or corrections (e.g., of spelling, to add another item) to a change request once it has been submitted; for critical correction, the Change Coordinator may make edits
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 23
General Usage Tips, continued
• Multiple concurrent sessions are not allowed: Due to the way the application’s licensing mechanism works, a single user can only have a single instance of the application in use at any given time. This includes logins via the web interface and via email submissions. This means if you are logged in to the web interface, and submit a request (or approval) via email, your web session will be logged out.
• Errors during request entry require re-selection of file attachment (if any)
If you select a file attachment while submitting a Change Request, and encounter an error (e.g. an incorrectly specified Schedule Date/Time), the file attachment selection is cleared. In this case you need to re-select the attachment. This is by design due to security concerns in the web application.
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 24
Some Frequently Asked Questions (FAQ)
Other Questions?
What happens when there is a scheduling conflict?The Change Coordinator or (more likely) the Change Advisory Board (CAB) will work with the parties requesting the conflicting date/time to resolve the conflict. Essentially this is a negotiation.
How do you delegate approvals during vacations, when someone’s out sick, etc.?There should be multiple approvers per domain. It is their responsibility to hand off approval responsibility if one is out.
How do you pick the right stencil?Use the Process QuickGuide to guide your decision-making.
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training
© 2006 IT Services Stanford University Page 25
Key Links
Web Site (w/ link to web application): http://www.stanford.edu/services/changemgt
Web Application: http://cmr.stanford.edu (for http://InfraAppProd.stanford.edu)
Email: [email protected]
Process Document (available at Web Site above): https://www.stanford.edu/services/changemgt/documents/OECM_Process_Document_v2.7.pdf
HelpSU (for issues reporting and help): http://remedy-prod.stanford.edu/cgi-bin/helpsu2?pcat=cms (Category=Administrative Applications, Type=Change Management, Item=*General)
Project Web page: http://www.stanford.edu/dept/itss/projects/OE/change-management.html