ITS Service Management Operating Level Agreement

Version: 4.7 Date: January 3, 2011 Author: Andrea Stevens, Lisa Callihan

Table of Contents Objective.................................................................................................................................2 Service Description.................................................................................................................3 Definitions and Criteria............................................................................................3 Escalation and Communication................................................................................5 BMC ITSM Incident Resolution ............................................................................15 Expectations..........................................................................................................................17 The Service Desk Will: ..........................................................................................17 Support Groups Will: .............................................................................................17 BMC ITSM Reporting ...........................................................................................17 Revision History ...................................................................................................................19 Appendix A: BMC ITSM Incident Content Criteria ............................................................21 General Incident Content .......................................................................................21 Appendix B: Assigning Priority ...........................................................................................22 Appendix C: The Incident Lifecycle ....................................................................................24 Appendix D: Service Level Management Targets................................................................25

Page1of25

Objective
The objective of this agreement is to define the requirements and expectations for handling Service Restoration, Service Requests and Infrastructure Events for ITS production services. The ultimate goal is to restore normal service as quickly as possible, minimize the negative impact on the business operation and ensure good communication and tracking of each and every incident. This agreement is made between ITS Support Groups.

Scope
This agreement covers all ITS incidents, regardless of origin. It is understood that incidents recorded in the BMC ITSM tool will follow the Incident Management process and adhere to the expectations and guidelines outlined in this agreement.

Page2of25

Service Description
This agreement covers the working relationship and expectations between Support Groups for the purpose of handling BMC ITSM incidents including: Service Restoration Service disruption. Service Request User education, information, enhancements or Batch job requests. Infrastructure Event - Automated detection of an Incident.

Definitions and Criteria

Incident Lifecycle Incident Lifecycle: Details the various stages of an Incident from beginning to restoration. See Appendix B for details. Priority Priority is automatically calculated by BMC ITSM and is based on the impact and the urgency of the issue. The priority represents the sequence in which an incident needs to be resolved. The organization recognizes the four terms listed below when referencing Priority. In the event of a disagreement concerning Priority, it is expected that the issue will be escalated to the associated Incident Process Manager for discussion and resolution.

Priority CRITICAL

Description There is a significant risk to the business or exposure to the organization for not restoring the users ability to perform their vital business function. Including an Incident of Extensive impact with Critical or High urgency or an Incident of Significant impact with Critical urgency. There is a higher level of risk to the business or exposure to the organization for not correcting the service. Including an Incident of Extensive impact with Medium urgency, Significant impact with High urgency, Moderate impact with Critical or High urgency or Minor impact with Critical urgency. There is an acceptable level of risk to the business or exposure to the organization for either restoring the service within a short period of time. Including an Incident of Significant or Moderate impact with Medium urgency, or Minor Impact with High or Medium urgency. There is minimal risk to the business or exposure to the organization for either restoring the service (or not) within a short
Page3of25

HIGH

MEDIUM

LOW

period of time. Including an Incident of Extensive, Significant, Moderate or Low impact with Low urgency. *See Appendix B for BMC ITSM Priority assignment values. ITS Significant Incidents A Significant Incident is one that has a major impact on university operations by bringing a business process to a complete stop or potential stop. Incidents of this nature have a high impact and urgency value. When it is determined a Critical or High priority incident will not be resolved within ITS Service targets and a plan for resolution is not know, or business impact is such that the incident requires significant escalation, the Significant Incident Process should be invoked. *See the ITS Service Management Significant Incident Guide for additional information. Impact Impact, when used in referencing priority, is a representation of the number of users affected by the issue. The organization recognizes the following terms and definitions when referencing Impact: Impact 1-Extensive/Widespread ITS Definition
The majority of users of the service are, or have the potential to be, affected by the issue

2-Significant/Large

25-50% of overall users, or the majority of users in a single central office are, or have the potential to be affected by the issue. No workaround is available.

3-Moderate/Limited

25-50% of overall users, or the majority of users in a single central office are, or have the potential to be affected by the issue. A workaround is available.

4-Minor/Localized

Minimal number of users of the service are, or have the potential to be, affected by the issue

Urgency The level of urgency, when used in referencing priority, is a representation of how quickly the issue must be resolved. It may be equated to the business criticality of the issue depending on
Page4of25

where the university is in the business cycle. The organization recognizes the following terms and definitions when referencing Urgency: Urgency 1-Critical ITS Definition The Incident has caused a work stoppage, or has the potential to cause a work stoppage of a vital business function or service. This includes a degradation of service to a point in which the user is unable to perform normal business operations. The Incident has not resulted in a work stoppage, but has significantly impaired the users ability to perform their normal business operation and a work around is not available The Incident has not resulted in a work stoppage, but has impaired the users ability to perform their normal business operation. A workaround is available. The Incident has not impeded or disrupted the service and is more of an incovenience, or all Incidents that dont fit the Medium, High or Critical designation.

2-High

3-Medium

4-Low

Escalation and Communication

NOTE: Business hours are defined as being 7:45am 5:15pm, Monday - Friday. Service Restoration (Incident) - Priority Timeframe and Initial Escalation:

Page5of25

PRIORITY Critical

1.

2.

3.

4.

5.

Service Restoration - Business Hour Procedures The Service Desk must escalate the BMC ITSM incident to the appropriate Support Group within 10 minutes of the Incident detection. The Support Group must take ownership of the BMC ITSM incident by placing their name in the Assignee field within 10 minutes of the Incident being escalated. As part of Service Level Management (SLM), if the Support Group has not responded to the Critical Incident within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. If the Support Group has not responded to the Critical Incident within 10 minutes, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached. If no response is received, the Incident or Service Desk Support Group Manager will utilize the OnCall/CallBack (OCCB) listing to page the appropriate Support Group Support Group.

Page6of25

PRIORITY High

Service Restoration - Business Hour Procedures 1. The Service Desk must escalate the BMC ITSM incident to the appropriate Support Group Support Group within 20 minutes of the Incident detection. 2. The Support Group must take ownership of the BMC ITSM incident by placing their name in the Assignee field within 20 minutes of the Incident being escalated. 3. As part of Service Level Management (SLM), if the Support Group has not responded to the High incident within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. 4. If the Support Group has not responded to the High incident within 20 minutes, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached. 5. If no response is received, the Incident or the Service Desk Support Manager will utilize the OnCall/CallBack (OCCB) listing to page the appropriate Support Group Support Group. 1. The Service Desk must escalate the BMC ITSM incident to the appropriate Support Group Support Group within 2 hours of the Incident detection. 2. The Support Group must take ownership of the BMC ITSM incident by placing their name in the Assignee field within 2 hours of the incident being escalated. 3. As part of Service Level Management (SLM), if the Support Group has not responded to the Medium incident within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. 4. If the Support Group has not responded to the Medium incident within 2 hours, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached.
Page7of25

Medium

PRIORITY Low

1.

2.

3.

4.

Service Restoration - Business Hour Procedures The Service Desk must escalate the BMC ITSM incident to the appropriate Support Group Support Group within 4 hours of the Incident detection. The Support Group must take ownership of the BMC ITSM incident by placing their name in the Assignee field within 4 hours of the Incident being escalated. As part of Service Level Management (SLM), if the Support Group has not responded to the Low incident within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. If the Support Group has not responded to the Low incident within 4 hours, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached.

Service Request - Priority Timeframe and Initial Escalation: PRIORITY Critical Service Request - Business Hour Procedures The Service Desk must escalate the BMC ITSM Service Request to the appropriate Support Group Support Group within 1 hour of the incident detection. The Support Group must take ownership of the BMC ITSM Service Request by placing their name in the Assignee field within 1 hour of the incident being escalated. As part of Service Level Management (SLM), if the Support Group has not responded to the Critical Service Request within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the Service Request, warning the timeframe is about to be breeched. If the Support Group has not responded to the Critical Service Request within 1 hour, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the Service Request has been breached.
Page8of25

1.

2.

3.

4.

PRIORITY High

Service Request - Business Hour Procedures 1. The Service Desk must escalate the BMC ITSM Service Request to the appropriate Support Group Support Group within 2 hours of the incident detection. 2. The Support Group must take ownership of the BMC ITSM Service Request by placing their name in the Assignee field within 2 hours of the incident being escalated. 3. As part of Service Level Management (SLM), if the Support Group has not responded to the High Service Request within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. 4. If the Support Group has not responded to the High Service Request within 2 hours, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached. 1. The Service Desk must escalate the BMC ITSM Service Request to the appropriate Support Group Support Group within 4 hours of the incident detection. 2. The Support Group must take ownership of the BMC ITSM Service Request by placing their name in the Assignee field within 4 hours of the incident being escalated. 3. As part of Service Level Management (SLM), if the Support Group has not responded to the Medium Service Request within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. 4. If the Support Group has not responded to the Medium Service Request within 4 hours, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached.

Medium

Page9of25

PRIORITY Low

1.

2.

3.

4.

Service Request - Business Hour Procedures The Service Desk must escalate the BMC ITSM Service Request to the appropriate Support Group Support Group within 1 business day of the incident detection. Support Group must take ownership of the BMC ITSM Service Request by placing their name in the Assignee field within 1 business day of the incident being escalated. As part of Service Level Management (SLM), if the Support Group has not responded to the Low Service Request within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. If the Support Group has not responded to the Low Service Request within 1 business day, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached.

Infrastructure Event Initial Escalation and Medium Priority Default: PRIORITY Medium Infrastructure Event - Business Hour Procedures 1. The Service Desk must escalate the BMC ITSM Infrastructure Event to the appropriate Support Group Support Group within 2 hours of the incident detection. 2. The Support Group must take ownership of the BMC ITSM Infrastructure Event by placing their name in the Assignee field within 2 hours of the incident being escalated. 3. As part of Service Level Management (SLM), if the Support Group has not responded to the Medium Infrastructure Event within 75% of the target timeframe, BMC ITSM will send notification to the appropriate Assignment based on information available in the incident, warning the timeframe is about to be breeched. 4. If the Support Group has not responded to the Medium Infrastructure Event within 2 hours, BMC ITSM will send notification to the appropriate Assignment and Process Manager advising the Service Level for the incident has been breached.
Page10of25

Service Restoration - Status Communication PRIORITY Critical Service Restoration - Business Hour Procedures The Support Group will update initial status in the BMC ITSM incident within15 minutes during which time the diagnosis is unknown. Additional updates will be provided every 30 minutes unless previous notations in the BMC ITSM incident specify a time in which to expect the next update. Once the diagnosis is known, the Support Group will provide an estimated timeline of repair and recovery. The Support Group will provide a final update once the service has been restored. If additional information is requested from the Service Desk, they must respond to the request within 30 minutes. All information and updates must be logged in BMC ITSM Work Info.

1.

2. 3. 4. 5. High

1. The Support Group will update initial status in the BMC ITSM incident within 1 hour and provide additional updates every 2 hours. It is acceptable for the Support Group to enter an estimated time of the next update rather than use of the 2 hour expectation. 2. Once the diagnosis is known, the Support Group will provide an estimated timeline of repair and recovery. 3. The Support Group will provide a final update once the service has been restored to normal service operation. 4. If additional information is requested from Service Desk, they must respond to the request within 1 hour. 5. All information and updates must be logged in BMC ITSM Work Info.

Page11of25

PRIORITY 1. Medium

2. 3. 4.

5. Low

Service Restoration - Business Hour Procedures The Support Group will update initial status in the BMC ITSM incident within 1 business day during which time the diagnosis is unknown. Additional updates must be provided within 2 day increments. Once the diagnosis is known, the Support Group will provide an estimated timeline of repair and recovery. The Support Group will provide a final update once the service has been restored to normal service operation. If additional information is requested from the Service Desk, they must respond to the request within 1 business day. All information and updates must be logged in BMC ITSM Work Info.

1. The Support Group will update initial status in the BMC ITSM incident within 2 business days during which time the diagnosis is unknown. Additional updates must be provided within 5 day increments. 2. Once the diagnosis is known, the Support Group will provide an estimated timeline of repair and recovery. 3. The Support Group will provide a final update once the service has been restored to normal service operation. 4. If additional information is requested from the Service Desk, they must respond to the request within 2 business days. 5. All information and updates must be logged in BMC ITSM Work Info.

Page12of25

Service Request - Status Communication PRIORITY Critical Service Request - Business Hour Procedures 1. The Support Group will update initial status in the BMC ITSM Service Request within 1 business day and provide additional updates every 1 business day. It is acceptable for the Support Group to enter an estimated time of the next update rather than use the 1 business day expectation. 2. If additional information is requested from the Service Desk, they must respond to the request within 1 business day. 3. All information and updates must be logged in BMC ITSM Work Info. 1. The Support Group will update initial status in the BMC ITSM Service Request within 2 business days and provide additional updates every 2 business days. It is acceptable for the Support Group to enter an estimated time of the next update rather than use of the 2 business day expectation. 2. If additional information is requested from the Service Desk, they must respond to the request within 2 business days. 3. All information and updates must be logged in BMC ITSM Work Info. 1. The Support Group will update initial status in the BMC ITSM Service Request within 3 business days and provide additional updates every 3 business days. It is acceptable for the Support Group to enter an estimated time of the next update rather than use the 3 business day expectation. 2. If additional information is requested from the Service Desk, they must respond to the request within 3 business days. 3. All information and updates must be logged in BMC ITSM Work Info.

High

Medium

Page13of25

PRIORITY Low

Service Request - Business Hour Procedures 1. The Support Group will update initial status in the BMC ITSM service Request within 5 business days during which time the diagnosis is unknown. Additional updates must be provided within 5 day increments. 2. If additional information is requested from the Service Desk, they must respond to the request within 5 business days. 3. All information and updates must be logged in BMC ITSM Work Info.

Infrastructure Event - Status Communication PRIORITY Medium Infrastructure Event - Business Hour Procedures The Support Group will update initial status within 1 business day during which time the diagnosis is unknown. Additional updates must be provided within 2 day increments. Once the diagnosis is known, the Support Group will provide an estimated timeline of repair and recovery. The Support Group will provide a final update once the service has been restored to normal service operation. If additional information is requested from the Service Desk, they must respond to the request within 1 business day. All information and updates must be logged in BMC ITSM Work Info.

1.

2. 3. 4.

5.

*See Appendix C for the Incident Lifecycle and clarification of detection, diagnosis, repair, recovery and restoration.

Page14of25

BMC ITSM Incident Resolution

Service Restoration - Resolution

PRIORITY Critical High Medium Low

Service Restoration Resolution 1. Service target for resolution of the BMC ITSM Incident is within 4 hours. 2. Service target for resolution of the BMC ITSM Incident is within 1 business day. 3. Service target for resolution of the BMC ITSM Incident is within 5 business days. 4. Service target for resolution of the BMC ITSM Incident is within 10 business days.

Service Request Resolution

PRIORITY Critical High Medium Low

Service Request - Resolution 1. Service target for resolution of the BMC ITSM Service Request is within 2 business days. 2. Service target for resolution of the BMC ITSM Service Request is within 5 business days. 3. Service target for resolution of the BMC ITSM Service Request is within 10 business days. 4. Service target for resolution of the BMC ITSM Service Request is within 20 business days.

Infrastructure Event - Resolution

PRIORITY Medium

Infrastructure Event - Resolution 1. Service target for resolution of the BMC ITSM Infrastructure Event is within 5 business days.

*See Appendix D for complete Service Target Agreement reference chart.

Page15of25

After Hours Procedures for Emergency Service Restoration

NOTE: After business hours are defined as anytime before 7:45am or after 5:15pm, Monday through Friday and on weekends. After Hours - Priority Timeframe and Initial Escalation PRIORITY Critical Serivce Restoration - After Business Hour Procedures 1. Operations must escalate the BMC ITSM incident to the appropriate Support Group within 30 minutes of incident detection. 2. Operations calls the primary on-call Support Group contact. 3. The Support Group must take ownership of the BMC ITSM Incident by placing their name in the Assignee field within 30 minutes of the Incident being escalated. 4. If the Support Group has not responded to the BMC ITSM incident within the established timeframe, Operations will escalate using the OnCall/CallBack (OCCB) listing to page the appropriate Support Group contact.

After Hours - Status Communication PRIORITY Critical Service Restoration - After Business Hour Procedures 1. Operations will advise customer of Support Group escalation as soon as confirmation is received. 2. Operations will update initial BMC ITSM incident status within 15 minutes during which time the diagnosis is unknown. Additional updates will be provided every 30 minutes, unless previous communication specifies a time in which to expect the next update. 3. Once the diagnosis is known, the Support Group will provide an estimated timeline of repair and recovery. 4. The Support Group will provide a final update once the service has been restored to normal service operation. 5. All information and updates must be logged in BMC ITSM Work Info.

Page16of25

Expectations
In addition to the Objective, Service Description, Definitions and Criteria defined above, the following expectations are also known.

The Service Desk Will:

1. 2. 3. 4. Have Service Desk staff available onsite from 7:45am 5:15pm. Have Operations staff available onsite 24 x 7. Test all production services for availability as scheduled. Unless previously completed by Support Group, the Service Desk is responsible for providing all communication and follow-up with the end user or customer. This includes capturing additional details if needed as well as confirming restoration. Provide the agreed level of detail in BMC ITSM incidents as defined in Appendix A. Additional information will be provided as detailed in agreed and documented incident examples. Prior to escalation, the Service Desk will match the current BMC ITSM incident against the existing incidents and Knowledge Management Console. Supply all communication and follow-up within BMC ITSM. Provide reports, as defined in the reporting section of this agreement, to Support Groups on the first 10th calendar day of the month.

5.

6. 7. 8.

Support Groups Will:

1. Have staff available onsite (or OCCB) to respond to incidents from 7:45am 5:15pm, and oncall when scheduled. 2. Supply all relevant communications, status, diagnosis, repair, recovery and restoration notes related to an incident in BMC ITSM. The BMC ITSM incident is the authoritative source of information, e-mail notifications i.e., broadcast messages, prodnotify, and internal troubleshooting e-mails, etc. do not meet the requirement of incident tracking nor do they fulfill the expectation of entering relevant communication in the incident. 3. Respond to the BMC ITSM incident within the escalation criteria defined in this document. 4. Provide communication to the end user when the content is of a highly technical or complex nature. An example might include discussions that involve a unit system administrator.

BMC ITSM Reporting

The Service Desk will capture and report on the following statistics as it relates to BMC ITSM incidents escalated to the Support Groups identified in this document. The monthly reports are the responsibility of the Service Desk and will be generated by the 10th calendar day of the following month.
Page17of25

1. Number of incidents currently open broken down by priority, service and number of business days open 2. Number of incidents that did not comply with the expectations outlined within this OLA 3. Average response time 4. Average resolution times This agreement remains valid until it is superseded by a revised agreement mutually endorsed by the signatories below. The agreement will be reviewed annually but can be changed at any time as agreed upon by both the signatories.

Signatories
This Agreement was approved by the Directors at the MLT meeting held on May 25th, 2007. It is considered to be effective July 1, 2007. Official verification of approval is contained in the meeting minutes.

Page18of25

Revision History
Document Number OLA002 1 Revision ID Description Adjusted the 4 Priority levels to 3. This was done to keep them in line with the existing HD ticket structure. This will need to synch up with the Priority description in Change Management when tools allow. Similar adjustments were made in the Escalation and Communication tables. Removed specific numbers from the definition of high, medium and low impact. This was due to the fact that current tools do not allow for HD to know the specific number of users impacted. They rely on call volume to HD and gut check. Should specify numbers once configuration or service catalog allows. Modified communication for Routine to have a two step approach. The follow up in 5 days provides enough information for vendor contact if needed. Due to system restrictions on HD reporting, the reporting expectations were modified to remove MTTR, MTBF, MTBSI. These should be added back in once the toolset allows. Added the after hour procedures for escalation and communication. The OLA will need to be reviewed upon any modification to the MAIS Communication Protocol TIO and HD met to review. Slight modifications to timing and some descriptions. As a result of HD TIO meeting, the Status Communication for Urgent was revised. Also changed the expectation that Support Group will communicate to end user when content is of a highly technical nature. Approved for signing Added Scope, removed after hours procedures, Added requirement of TIO to provide nightly operations report to HD by 8:00am. Sent out for resigning. Changed agreement between Technical Infrastructure Operations (TIO) and the MAIS Help Desk to MAIS Divisions and MAIS Help Desk. Added MAIS Division Directors and Project Manager RES to Signatories. For Critical Incidents, added Help Desk Manager will utilize the OCCB Listing and Division contact list to page the appropriate Support Group Support Group. Added Routine Priority also includes high impact with low urgency and low impact with high urgency. Added FIN, HRMS & SA Issue Ticket Content Information Added Support Group will provide communication to end user when the content is of a complex nature Changed # to Number incidents under Reporting Added of the service are under Low Impact Description to match High Impact Description. Added OnCall/CallBack definition for (OCCB) under Critical Priority Business Hour Procedure because not everyone is familiar with the acronym. Changed page to contact the appropriate Tier 2 Support Group under Critical Priority Business Hour Procedure because not all groups Revision Date October 11, 2005

OLA002

1.1

October 11, 2005

OLA002

1.2

October 11, 2005

OLA002

1.3

October 11, 2005

OLA002

1.4

October 18, 2005

OLA002 OLA002

1.5 1.6

November 1, 2005 November 16, 2005

OLA002 OLA002

1.6 1.7

December 14, 2005 April 7, 2006

OLA002

2.0

October 2, 2006

OLA002 OLA002

2.1 2.2

October 2, 2006 October 2, 2006

OLA002 OLA002 OLA002 OLA002 OLA002 OLA002

2.3 2.4 2.5 2.6 2.7 2.8

October 3, 2006 October 3, 2006 October 3, 2006 November 6, 2006 November 6, 2006 November 6, 2006

OLA002

2.9

November 6, 2006

Page19of25


carry pagers. OLA002 OLA002 2.10 2.11 Specified 2 under Support Group will provide Operations Nightly Report ,applies to TIO only Removed the following: Start all Help Desk ticket entries with the date, time and unique name of the staff person making the entry. 5 under Support Group will because the Lotus Notes system now automatically includes this information. Added supply all relevant communications under Support Group will at the request of Tier 2 staff. Added the Help Desk ticket is the authoritative source of information, e-mail notifications i.e., prodnotify and mphdnotify, etc. are in addition to ticket updates. Removed Support Group member uniqname, date and time at the start of each entry, system now automatically adds this information to the ticket. Removed Examples of Specific Ticket Content under Appendix A. Information will be kept up to date in a separate working document. Added OCCB to Tier 2 Staff Availability from 7:45am 5:15pm Updated table of contents Added HD Staff available onsite from 7:45am 5:15pm Added priority disputes to be routed to Directors. Also added into line to #3 Help Desk Will to recognize that sometimes the communication is completed before the issue goes back to HD. Approved by MLT Added after hour procedures Priority, Urgency and Impact converted to 4 Tier Model. Updated all references to tickets to incident. Added Service Management processes and terminology, including tool name, MAIS Aid. Updated all references to Help Desk to The Service Desk. Added Service Level Management guidelines for Service Requests and Infrastructure Events Expanded to include Resolution targets. Updated to reflect ITS org Reports due on 10 calendar day. Updated After Hours to reflect Emergency and Critical Service Restorations. Updated Service Targets to reflect calculation in Business Days Added targets apply to Production Systems and business hours plus targets for Infrastructure Events when priority is changed. Replaced BMC ITSM with ITSM Replaced Tier One and Tier Two with Service Desk and Support Groups.
th

November 6, 2006 November 6, 2006

OLA002 OLA002

2.12 2.13

November 6, 2006 November 6, 2006

OLA002

2.14

November 6, 2006

OLA002 OLA002 OLA002 OLA002 OLA002

2.15 2.16 2.17 2.18 2.3

November 6, 2006 November 6, 2006 December 4, 2006 February 5, 2007 May 2007

OLA002 OLA002 OLA003 OLA003

2.3 2.4 3.0 3.1

May 25, 2007 June 24, 2007 November 17,2007 November 27,2007

OLA004 OLA004 OLA004 OLA004 OLA004 OLA004 OLA004 OLA004

4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7

March 20,2009 March 23,2009 September 8,2009 September 27,2009 October 27,2009 December 15,2009 October 27,2009 January 3, 2011

Page20of25

Appendix A: BMC ITSM Incident Content Criteria

General Incident Content

The Service Desk End user uniqname Summary and notes Complete description of incident Impact and urgency to establish priority Initial categorization Details of resolution techniques executed Results of matching activities Work around put in place (if available) Any relevant navigation and numbers Support Group Brief description of the status and expected resolution timeframe. Completed description of the resolution when appropriate Work around put in place (if available)

Reference Incident Management Process Flow Chart and OLA Specific Incident Content documents and ITSM scripts for incident requirements and specific information required for each ITS Service.

Page21of25

Appendix B: Assigning Priority The following system weight values are used when assigning incident Priority:

Priority

Priority Weight Range

From Critical High Medium Low 24 16 10 0 35 23 15 9

To

The following matrix is used when evaluating Priority:

Impact 1-Extensive/Widespread 1-Extensive/Widespread 1-Extensive/Widespread 1-Extensive/Widespread 2-Significant/Large 2-Significant/Large

Impact Urgency Weight 9 1-Critical 9 9 9 5 5

Urgency Priority Priority Weight Weight 20 Critical 29 15 Critical High Low Critical High 24 19 9 25 20
Page22of25

2-High

3-Medium 10 4-Low 1-Critical 2-High 0 20 15

2-Significant/Large 2-Significant/Large 3-Moderate/Limited 3-Moderate/Limited 3-Moderate/Limited 3-Moderate/Limited 4-Minor/Localized 4-Minor/Localized 4-Minor/Localized 4-Minor/Localized

5 5 3 3 3 3 0 0 0 0

3-Medium 10 4-Low 1-Critical 2-High 0 20 15

Medium 15 Low High High 5 23 18

3-Medium 10 4-Low 1-Critical 2-High 0 20 15

Medium 13 Low High 3 20

Medium 15 Medium 10 Low 0

3-Medium 10 4-Low 0

Page23of25

Appendix C: The Incident Lifecycle

Page24of25

Appendix D: Service Level Management Targets

InitialEscalationtoSupport Group AssigneeFieldUpdated InitialStatusCommunication UpdatedStatusCommunication

BMCITSMIncidentResponseandResolutionServiceTargetsbyPriority
BMCITSMIncidents ServiceRestoration High Medium 20min 20min 1hr 2hrs 2hrs 2hrs 1day 2days ServiceRequest High Medium 2hrs 2hrs 1day 2days 4hrs 4hrs 2days 5days Infrastructure Event Medium(Default) 2hrs 2hrs 1day 2days

Critical 10min 10min 15min 30min

Low 4hrs 4hrs 2days 5days

Critical 1hr 1hr 4hrs 1day

Low 1day 1day 5days 10days

ResolutionTimeframeTarget 4hrs 1day 5days 10days 2days 5days 10days 20days 5days Notes: ServiceTargetsnotmetwillgeneratenotificationstotheAssigneeandSupportGroupManagerat75%ofSLMandtotheIncidentandSupportGroup Managerswhenbreached AllServiceTargetsareforProductionSystemsonly TimesarecalculatedbasedonBusinessDays,MondayFriday7:45am5:15pmonly AdditionalstatusupdateswillbeprovidedunlesspreviousnotationsintheBMCITSMincidentspecifyatimeinwhichtoexpectthenextupdate ServiceLevelTargetscanbeplacedonholdwhennecessarybyusingthePendingStatusasappropriate AllinformationandupdatesmustbeloggedinBMCITSMWorkInfo PrioritychangestoInfrastructureEventsfromtheMediumDefaultwillfollowtheServiceRestorationtargets Page25of25