Download Report

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
Page 1 of 25 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.
Page 2 of 25 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 user’s 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.
HIGH
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.
MEDIUM
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.
LOW
There is minimal risk to the business or exposure to the
organization for either restoring the service (or not) within a short
Page 3 of 25 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
Page 4 of 25 where the university is in the business cycle. The organization recognizes the following terms
and definitions when referencing “Urgency”:
Urgency
1-Critical
2-High
3-Medium
4-Low
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 user’s 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 user’s 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 don’t fit the
Medium, High or Critical designation.
Escalation and Communication
NOTE: Business hours are defined as being 7:45am – 5:15pm, Monday - Friday.
Service Restoration (Incident) - Priority Timeframe and Initial Escalation:
Page 5 of 25 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.
Page 6 of 25 PRIORITY
High
Medium
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.
Page 7 of 25 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
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 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.
Page 8 of 25 PRIORITY
High
Medium
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.
Page 9 of 25 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.
Page 10 of 25 Service Restoration - Status Communication
PRIORITY
Critical
1.
2.
3.
4.
5.
High
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. 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.
Page 11 of 25 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.
Page 12 of 25 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.
High
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.
Medium
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.
Page 13 of 25 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
1.
2.
3.
4.
5.
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.
*See Appendix C for the Incident Lifecycle and clarification of detection, diagnosis, repair,
recovery and restoration.
Page 14 of 25 BMC ITSM Incident Resolution
Service Restoration - Resolution
PRIORITY
Critical
Service Restoration – Resolution
1. Service target for resolution of the BMC ITSM Incident
is within 4 hours.
High
2. Service target for resolution of the BMC ITSM Incident
is within 1 business day.
Medium
3. Service target for resolution of the BMC ITSM Incident
is within 5 business days.
Low
4. Service target for resolution of the BMC ITSM Incident
is within 10 business days.
Service Request – Resolution
PRIORITY
Critical
Service Request - Resolution
1. Service target for resolution of the BMC ITSM Service
Request is within 2 business days.
High
2. Service target for resolution of the BMC ITSM Service
Request is within 5 business days.
Medium
3. Service target for resolution of the BMC ITSM Service
Request is within 10 business days.
Low
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.
Page 15 of 25 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.
Page 16 of 25 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.
5.
6.
7.
8.
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.
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.
Page 17 of 25 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.
Page 18 of 25 Revision History
Document
Number
Revision ID
Description
Revision Date
OLA002
1
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.
October 11, 2005
OLA002
1.1
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.
October 11, 2005
OLA002
1.2
Modified communication for “Routine” to have a two step approach.
The follow up in 5 days provides enough information for vendor
contact if needed.
October 11, 2005
OLA002
1.3
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.
October 11, 2005
OLA002
1.4
Added the after hour procedures for escalation and communication.
The OLA will need to be reviewed upon any modification to the
MAIS Communication Protocol
October 18, 2005
OLA002
1.5
TIO and HD met to review. Slight modifications to timing and some
descriptions.
November 1, 2005
OLA002
1.6
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.
November 16, 2005
OLA002
1.6
Approved for signing
December 14, 2005
OLA002
1.7
Added Scope, removed after hours procedures, Added requirement
of TIO to provide nightly operations report to HD by 8:00am. Sent
out for resigning.
April 7, 2006
OLA002
2.0
Changed agreement between Technical Infrastructure Operations
(TIO) and the MAIS Help Desk to MAIS Divisions and MAIS Help
Desk.
October 2, 2006
OLA002
2.1
Added MAIS Division Directors and Project Manager RES to
Signatories.
October 2, 2006
OLA002
2.2
For Critical Incidents, added Help Desk Manager will utilize the
OCCB Listing and Division contact list to page the appropriate
Support Group Support Group.
October 2, 2006
OLA002
2.3
Added Routine Priority also includes high impact with low urgency
and low impact with high urgency.
October 3, 2006
OLA002
2.4
Added FIN, HRMS & SA Issue Ticket Content Information
October 3, 2006
OLA002
2.5
Added Support Group will provide communication to end user when
the content is of a complex nature
October 3, 2006
OLA002
2.6
Changed # to Number incidents under Reporting
November 6, 2006
OLA002
2.7
Added of the service are under Low Impact Description to match
High Impact Description.
November 6, 2006
OLA002
2.8
Added OnCall/CallBack definition for (OCCB) under Critical
Priority Business Hour Procedure because not everyone is familiar
with the acronym.
November 6, 2006
OLA002
2.9
Changed page to contact the appropriate Tier 2 Support Group under
Critical Priority Business Hour Procedure because not all groups
November 6, 2006
Page 19 of 25 carry pagers.
OLA002
2.10
Specified 2 under Support Group will provide Operations Nightly
Report ,applies to TIO only
November 6, 2006
OLA002
2.11
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.
November 6, 2006
OLA002
2.12
Added supply all relevant communications under Support Group will
at the request of Tier 2 staff.
November 6, 2006
OLA002
2.13
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.
November 6, 2006
OLA002
2.14
Removed Support Group member uniqname, date and time at the
start of each entry, system now automatically adds this information
to the ticket.
November 6, 2006
OLA002
2.15
Removed Examples of Specific Ticket Content under Appendix A.
Information will be kept up to date in a separate working document.
November 6, 2006
OLA002
2.16
Added OCCB to Tier 2 Staff Availability from 7:45am – 5:15pm
November 6, 2006
OLA002
2.17
Updated table of contents
December 4, 2006
OLA002
2.18
Added HD Staff available onsite from 7:45am – 5:15pm
February 5, 2007
OLA002
2.3
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.
May 2007
OLA002
2.3
Approved by MLT
May 25, 2007
2.4
Added after hour procedures
June 24, 2007
OLA003
3.0
Priority, Urgency and Impact converted to 4 Tier Model. Updated
all references to ‘tickets’ to ‘incident.’
November 17,2007
OLA003
3.1
Added Service Management processes and terminology, including
tool name, MAIS Aid. Updated all references to ‘Help Desk’ to
‘The Service Desk’.
November 27,2007
OLA004
4.0
Added Service Level Management guidelines for Service Requests
and Infrastructure Events
March 20,2009
OLA004
4.1
Expanded to include Resolution targets.
March 23,2009
OLA004
4.2
Updated to reflect ITS org
September 8,2009
OLA002
th
OLA004
4.3
Reports due on 10 calendar day. Updated After Hours to reflect
Emergency and Critical Service Restorations.
September 27,2009
OLA004
4.4
Updated Service Targets to reflect calculation in Business Days
October 27,2009
OLA004
4.5
Added targets apply to Production Systems and business hours plus
targets for Infrastructure Events when priority is changed.
December 15,2009
OLA004
4.6
Replaced BMC ITSM with ITSM
October 27,2009
4.7
Replaced Tier One and Tier Two with Service Desk and Support
Groups.
January 3, 2011
OLA004
Page 20 of 25 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.
Page 21 of 25 Appendix B: Assigning Priority
The following system weight values are used when assigning incident “Priority”:
Priority
Priority Weight Range
From
To
Critical
24
35
High
16
23
Medium
10
15
Low
0
9
The following matrix is used when evaluating “Priority”:
Impact
1-Extensive/Widespread
Impact Urgency
Weight
9
1-Critical
Urgency Priority Priority
Weight
Weight
20
Critical 29
1-Extensive/Widespread
9
2-High
15
1-Extensive/Widespread
9
1-Extensive/Widespread
Critical
24
3-Medium 10
High
19
9
4-Low
0
Low
9
2-Significant/Large
5
1-Critical
20
Critical
25
2-Significant/Large
5
2-High
15
High
20
Page 22 of 25 2-Significant/Large
5
3-Medium 10
Medium 15
2-Significant/Large
5
4-Low
0
Low
5
3-Moderate/Limited
3
1-Critical
20
High
23
3-Moderate/Limited
3
2-High
15
High
18
3-Moderate/Limited
3
3-Medium 10
Medium 13
3-Moderate/Limited
3
4-Low
0
Low
3
4-Minor/Localized
0
1-Critical
20
High
20
4-Minor/Localized
0
2-High
15
Medium 15
4-Minor/Localized
0
3-Medium 10
Medium 10
4-Minor/Localized
0
4-Low
Low
0
0
Page 23 of 25 Appendix C: The Incident Lifecycle
Page 24 of 25 Appendix D: Service Level Management Targets
BMC ITSM Incident Response and Resolution Service Targets by Priority BMC ITSM Incidents Critical Service Restoration High Medium Low Critical Initial Escalation to Support Group 10 min 20 min 2 hrs 4 hrs Assignee Field Updated 10 min 20 min 2 hrs Initial Status Communication 15 min 1 hr Updated Status Communication 30 min 2 hrs Infrastructure Event Medium (Default) Service Request High Medium Low 1 hr 2 hrs 4 hrs 1 day 2 hrs 4 hrs 1 hr 2 hrs 4 hrs 1 day 2 hrs 1 day 2 days 4 hrs 1 day 2 days 5 days 1 day 2 days 5 days 1 day 2 days 5 days 10 days 2 days Resolution Timeframe Target 4 hrs 1 day 5 days 10 days 2 days 5 days 10 days 20 days 5 days Notes:  Service Targets not met will generate notifications to the Assignee and Support Group Manager at 75% of SLM and to the Incident and Support Group Managers when breached  All Service Targets are for Production Systems only  Times are calculated based on Business Days, Monday – Friday 7:45am – 5:15pm only  Additional status updates will be provided unless previous notations in the BMC ITSM incident specify a time in which to expect the next update  Service Level Targets can be placed on hold when necessary by using the Pending Status as appropriate  All information and updates must be logged in BMC ITSM Work Info  Priority changes to Infrastructure Events from the Medium Default will follow the Service Restoration targets Page 25 of 25