Example: biology

Incident Management Procedures - Northwestern University

Incident Management Procedures November 22, 2013 Version Last Revised: 01/13/14 Page 2 of 31 Table of Contents document Control .. 3 Summary of Changes .. 3 document Change-Approver .. 3 document Approvals .. 4 document Review Plans .. 4 How to Find the Latest Version of this document .. 4 Overview .. 4 Description and Scope .. 4 Objectives and Performance Metrics .. 4 Incident Management Process Flows .. 6 Work Instructions .. 14 Roles and Responsibilities .. 22 Priority Classification .. 24 Overview .. 24 End User Knowledge of Priority .. 25 Assessment Process .. 25 End User Escalation Processes .. 25 Changing Priority (Impact and Urgency).

Jan 13, 2014 · Version Version Date Nature of Change Edited By 1.0 2009‐October‐15 Initial Document ... Document changes are made through the change management process. To initiate a change to this document, e‐ mail the document owner. ... Maximize service availability ...

Tags:

  Date, Management, Document, Procedures, Availability, Incident, Incident management procedures

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Transcription of Incident Management Procedures - Northwestern University

1 Incident Management Procedures November 22, 2013 Version Last Revised: 01/13/14 Page 2 of 31 Table of Contents document Control .. 3 Summary of Changes .. 3 document Change-Approver .. 3 document Approvals .. 4 document Review Plans .. 4 How to Find the Latest Version of this document .. 4 Overview .. 4 Description and Scope .. 4 Objectives and Performance Metrics .. 4 Incident Management Process Flows .. 6 Work Instructions .. 14 Roles and Responsibilities .. 22 Priority Classification .. 24 Overview .. 24 End User Knowledge of Priority .. 25 Assessment Process .. 25 End User Escalation Processes .. 25 Changing Priority (Impact and Urgency).

2 25 Urgency .. 25 Impact .. 26 Priority .. 27 Communication Timelines .. 28 Key Terms and Definitions .. 29 Last Revised: 01/13/14 Page 3 of 31 document Control Summary of Changes Version Version date Nature of Change Edited By 2009 October 15 Initial document 2009 October 20 Edited for Formatting Matt Gruhn 2009 October 21 Edited ARCI Definitions Aaron Mansfield Don Strickland 2009 December 08 Michael Satut 2009 December 10 Edited Don s suggestions; edited for formatting Lynne Jeffers 2009 December 17 Edited for formatting Matt Gruhn 2009 December 17 Edited definitions Aaron Mansfield 2009 December 22 Edited for formatting Lynne Jeffers 2009 December 23 Updated process flows and work instructions Matt Gruhn 2009 December 30 Updated and formatted communication timelines Matt Gruhn 2010 November 09 Updated formatting Aaron Mansfield 2011 March 28 Edited priority matrix Aaron Mansfield 2011 May 06 Updated priority 1 and 2 resolution goals and associated content Aaron Mansfield 2011 June 24 Updated timing related to Major Incident Management Aaron Mansfield 2011

3 August 04 Updated P2 Communication Guidelines Aaron Mansfield 2013 November 22 Updated priority 1 to include problem ticket information Aaron Mansfield document Change-Approver Title Name E mail TSS Associate Director ( document Owner) Aaron Mansfield Senior Technical Services Specialist Michael Jones Last Revised: 01/13/14 Page 4 of 31 document Approvals The document owner is responsible for the accuracy and integrity of this document . document changes are made through the change Management process. To initiate a change to this document , e mail the document owner. Proposed changes will be reviewed by the document change approvers listed above.

4 After approval from those listed above, the updated document will be presented to the Change Advisory Board (CAB) for final approval. document Review Plans This document is reviewed and updated as defined below: As required to correct or enhance information content Following an annual review How to Find the Latest Version of this document The latest and official version of this document may be obtained on the process documentation page of the NUIT wiki at Printed copies are for reference only and are not controlled. It is the responsibility of users of this document to ensure that they are using the most recent version. Overview The Incident Management process includes the coordination of service recovery, notification, escalation, and event review for all services as defined in the Northwestern University Information Technology (NUIT) Service Catalog.

5 This document is intended to provide high level overview of the Incident Management workflow. This document is to be used as reference for all NUIT staff to clearly understand the standards and Procedures put in place to manage an Incident through service restoration and Incident review. Description and Scope This document describes the process to be followed for assessing an Incident and determining the level of priority based on definitions of impact and urgency. Once priority is determined, the appropriate route for managing the Incident resolution process is followed. Objectives and Performance Metrics All processes must be measured to ensure compliance, effectiveness, and efficiency and to serve as a baseline for improvement.

6 Last Revised: 01/13/14 Page 5 of 31 The objectives and associated metrics of the Incident Management process are as follows: Ensure timely Incident resolution Measured by mean time to repair (MTTR) statistics, including performance against associated targets Maximize service availability Measured by Incident handle time, broken down by support tier Number of major incidents Effectively manage customer communications and notification Measured by the number of updates and customer communications distributed via the following channels: ACD emergency messages Emergency bulk mail messages End user feedback Service status web pages Improve communication between groups Measured by status updates in the service manager tool, including performance against SLA or OLA requirements Accurately assign incidents Measured by the percent of reassignments by the Incident controller Last Revised: 01/13/14 Page 6 of 31 Incident Management Process Flows Incident Management .

7 Interaction ManagementEnd UserTier 1 AnalystTimingInputsOutputsEnd user information and interaction description gatheredInitiate interactionContact NUIT Support(1)Screen Interaction(2)Valid Interaction?(3)ServiceRequest? (4)YesRequest for Change? (5)NoRequest FulfillmentYesChange MangementNoYesNoTerminate InteractionTier 1 Incident Management Last Revised: 01/13/14 Page 7 of 31 Incident Management : Tier 1 Incident ManagementTier 1 AnalystIncident ControllerTimingInputsOutputsIncident received from interaction Management or event managementKnow error database reviewedPreviously documented workarounds reviewedUrgency and impact determined; priority calculatedAttempted workaround documentedInteraction ManagementAssess Urgency and Impact(6, 7)KnownError(s)?

8 (8)Workaround Available? (8)YesApply Workaround(9)YesWorkaround Successful? (9)Ticket closed and end user updated if applicableUpdate Incident and Close TicketYesIncident ControlNoNoNoEvent Management Last Revised: 01/13/14 Page 8 of 31 Last Revised: 01/13/14 Page 9 of 31 Last Revised: 01/13/14 Page 10 of 31 Last Revised: 01/13/14 Page 11 of 31 Incident Management : Major Incident Management 1 End UserMajor Incident MgrTimingInputsOutputsTier 2 or 3 AnalystIncident ControllerSubject Matter ExpertPossible Priority 1 identifiedWithin 5 minutes of initial contactWhitin 15 minutes of initial contactWithin 5 minutes of major Incident manager s engagementStakeholder notification coordinatedIncident ticket downgraded; downgrade notification coordinatedIncident and problem ticket created.

9 Status call information distributed to participantsPriority 1 Declared? (21)Coordinate Downgrade Notification (22)NoTier 2 or 3 Diagnosis and ResolutionCoordinate Major Incident Management Communication (23, 24)YesEstablish Status Call(25)Troubleshoot and Update the Incident Ticket (26)Update the ACD Message, as Needed (27)2 Provide Information to Support Analysts, as NecessaryIncident ControlAcknowledge Receipt of the Incident (19)Open Stakeholder Bridge (20)Within 15 minutes of major Incident manager s engagement Last Revised: 01/13/14 Page 12 of 31 Incident Management : Major Incident Management 2 End UserTier 2 or 3 AnalystTimingInputsOutputsIncident ControllerMajor Incident ManagerSubject Matter ExpertResolution documentation composedTickets updatedVerification plan developedEnd user verification providedManage the Status Call (28a)2 Manage Incident Resolution (28b)Participate in Status Call (29c)Identify and Test a Resolution (29)Implement Resolution in Production (30)Resolution Successful?

10 (31)NoUpdate Incident Ticket (34)YesDetermine Verification Plan (32)Verify Resolution With End User(33)3 Update Problem Ticket(34a) Last Revised: 01/13/14 Page 13 of 31 Last Revised: 01/13/14 Page 14 of 31 Work Instructions Step Description OwnerARCI 1 End user calls, e mails, chats or self service reports an Incident to the service desk. End User A End User R End User C Tier 1 AnalystI 2 Gather end user information and interaction description. Verify that end user and service recipient information is available. If not, add relevant content. Tier 1 AnalystA Tier 1 AnalystR Tier 1 AnalystC End User I 3 Determine whether the interaction is valid.


Related search queries