ITS Service Management Operating Level Agreement
Transcription
ITS Service Management Operating Level Agreement
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