IT Services Transition IT Service Management Working Session

1. IT Services TransitionIT Service Management Working Session May 4, 2011 | Wednesday | 11:30am – 12:30pm

2. Introductions Definitions Objectives Consistent Incident / Service Request Escalation Paths Major Incident Communication & Response Consistent and Standardized Problem Report Single Published Change Calendar Next Steps Agenda 2

3. Definitions – Established Terms • Incident: • An unplanned interruption or reduction in quality of an IT Service. • An incident can impact from 1 person up to the entire campus. • Service Request: • A request from a user for information, advice, access, or a new service. • A service request is giving something new, and incident means something has failed (or is about to). • Problem: • A cause of one or more incidents. • Root cause is investigated by the Problem Management Process. • Change: • The addition, modification or removal of a service, application, or infrastructure component that will affect IT Services.

4. Objectives for this working group • Service Request Management Process • Document escalation paths for incidents and service requests to/from help desk • Incident Management Process • Establish a common definition of a major incident • Agree to a common “baseline” process (communications, escalations) • Create a single “wallet card” • Problem Management Process • Create a single post incident review form for all major incidents • Work towards a consistent review process and distribution list for all major incident reports • Change Management Process • Establish a single, published, forward schedule of changes • Define the mechanisms for adding and updating items on this calendar • Identify a liaison(s) between CABs

5. Service Request Management Process • Incident / Service Request Escalation Paths • How does the help desk escalate to you, how do you respond to the help desk? • Driven by the outputs of the BPR Documents developed over the last few weeks in your working groups.

6. Incident Management Process • Establish a common definition of a Major Incident: • An unplanned interruption or reduction in quality of a core IT Service. • A major incident has a significant impact on a large group of customers. • Response is typically coordinated by an Incident Manager What are the best tiers to distinguish between different Major Incidents? • Establish a common “baseline” process: • Initial alert / status update / resolution communications (internal and external) • Documented escalation paths / service owners (Who do I call when…?)ˆ • Create a single “wallet card” • One list of on-call numbers that spans the organization

7. Problem Management Process • Create a single post incident review form for all major incidents • Collect any existing reports that you have after a major incident • Submit them to the ITSM working group • These will be consolidated to a single form that can be used across all groups • Work towards a consistent major incident review process and reporting process • Establish a timeline of when these reports are submitted, and to whom.

8. Change Management Process • Establish a single, published, forward schedule of changes • Define the mechanisms for adding and updating items on this calendar • Define how to determine what changes get added to this calendar • Identify liaison(s) between CABs • Liaison will attend multiple CAB meetings to represent other CABs. • This role will be watchful for places where changes may cause conflict

9. Next Steps • By the close of business next Monday (5/9): • Email samples/templates of any post incident review forms you may have. • Submit list of existing major incident and change management contacts you know. • Identify any “on-call” lists you may have and forward them. • For the next meeting: • Review the existing services in your business area: • What are the on-call numbers for those services? • Is there an expectation of 24x7 availability, or business-hours only? • Identify the appropriate resources in your areas to attend these meetings. • Coordinate to make sure that your BPR docs are available to Client Svcs.