Yale University Incident Management Process Guide
1679731403
File Name: IncidentManagementProcessDocument_v02.pdf
File Size: 1.23 MB
File Type: Application/pdf
Last Modified: 1 year
Status: Available
Last checked: 2 days ago!
This Document Has Been Certified by a Professional
100% customizable
Language: English
We recommend downloading this file onto your computer
Summary
Yale University Incident ManagementProcess GuideYale University Incident Management Process 1 of 17 IntroductionPurposeThis document will serve as the official process of Incident Management for Yale University. Thisdocument will introduce a Process Framework and will document the workflow, roles, procedures, andpolicies needed to implement a high quality process and ensure that the processes are effective insupporting the business. This document is a living document and should be analyzed and assessed on aregular basis
ScopeThe scope of this document is to define the Incident Management Process, and process inputs from, andoutputs to, other process areas. Other service management areas are detailed in separatedocumentation. The following is a specific list of items that are in scope for this document. Other itemsnot listed here are considered out of scope for this document
In scope: Incident Management Overview o Incident Definition o Incident Management Objectives o Incident Management Policies Incident Management Process Flow Incident Management Roles Incident Management RACI Incident Management Procedure Flows and Descriptions Incident Management Prioritization scheme Incident Management Service Categorization Model Incident Management Process MetricsYale University Incident Management Process 2 of 17 Incident Management OverviewIncident DefinitionAn Incident is an unplanned interruption to a technology service or reduction in quality of a technologyservice. Failure of a Configuration Item or product that has not yet impacted service is also an incident(i.e. failure of one disk from a mirror set)
Incident Management ObjectivesThe goal of Incident Management is to restore service operations as quickly as possible. Timely andefficient resolution will minimize business impact and increase productivity
Incident Management PoliciesIncident reporting must go through the Service Desk, providing Users with a single point of contactAll incidents must be logged, prioritized and solutions recorded in the Incident Management SystemOne standard Incident Management Process is defined and used to support all IT Service usersThe Service Desk manages, tracks, escalates, closes and communicates status of all incident records and is responsible for allincident assignmentsThe Incident Management Process is the conduit of communication of any degradation of service, to the affected users andIT personnelClosure of incidents is dependent on validating with the user that the incident has been resolved and service is restoredThe Service Desk will own all incidents that they themselves log or that are assigned to them from a Tier 2 provider
Ownership will transfer to the Incident / Situation Manager for major incidentsOnce a major incident has been validated by the Service Desk, escalation and communication protocols for high-priorityincidents are initiated and managed by the Service DeskYale University Incident Management Process 3 of 17 Incident Management Process FlowV3 Incident Management Process Customer Caller / Incident Identification Sources: Event Mgt, Email, Self-Service, Phone Call, Tech Staff (Tier 2 / Walkup) Management Hierarchic Yes Escalation Escalation Process Needed? Incident / Manager Group – Tier Group - Queue Situation 9.0 Major No Functional Incident Manager Process Yes 6.0 Investigation & Diagnosis 2+ Analyst Functional 2.0 1.0 4.0 Incident Incident Logging Initial Diagnosis Categorization 7.0 Resolution and Recovery Service Desk Analyst Functional Escalation Required? Service 3.0 No Major Request? No Incident Incident? Yes Prioritization 8.0 Incident Closure Yes 5.0 To Request Functional Fulfillment Escalation Process Incident Owner Accountable for the Incident Process and its Evolution/MaturationRolesThe following roles have been identified within the Incident Management Process
Role DescriptionIncident Manager • Oversee day to day process execution • Often the Service Desk Manager • Manages major incidents until the appropriate situation manager is identifiedSituation Manager • Manages and owns major incidentsService Desk Manager • Manages the service desk function, including staffing management activities • Provides guidance to Service Desk AnalystsIncident Process Owner • Owns the process end-to-end, including the RACI, process & procedural steps, role & definitions • Accountable for maturing and evolving the process, based on monthly/quarterly/yearly review of process KPIs • Adjusts the process to address performance or changing business needsService Desk Site Lead • Responsible for the operations of Service Desk Analysts that are geographically disperse, reporting to the Service Desk ManagerService Desk Analyst • Logs incidents • Provides initial diagnosis • Resolve incidents at first point of contact if possible • Escalates incidentsYale University Incident Management Process 4 of 17 Role Description • Owns non-major incidentsCaller / Customer • The end user having or reporting the service interruptionFunctional Group – Queue • Assigns incidents to individual Tier 2+ Analysts in the functional groupManager • Monitors and manages support resolution performance • May directly manage (reporting manager) the day to day activities of Tier 2+ analysts outside of process activitiesFunctional Group – Tier 2+ • Group of technical support experts that will handle issues escalated by the ServiceAnalyst Desk • For example, a Network Engineer • Receive process direction for a functional group queue manager, staff management from a reporting managerRACI Caller / Service Service Incident Situation Functional Functional Incident Customer Desk Desk Manager Manager Group – Group – Tier Process Analyst Site Lead Queue 2+ Analyst Owner Manager1.0 Incident C R A RLogging2.0 IncidentCategorization C R A R3.0 IncidentPrioritization C R A, C, I4.0 InitialDiagnosis R A, C, I R5.0 FunctionalEscalation R A, C6.0Investigation & A RDiagnosis7.0 Resolution& Recovery I R A R8.0 IncidentClosure C R R A R9.0 MajorIncident A R RProcessProcessMaturity and C, I C R R C R C AEvolutionYale University Incident Management Process 5 of 17 Process Procedures 1.0 Incident Logging Group–– 1.1 Verify Issue FunctionalGroup Exists Analyst/ /Functional 1.2 Update Incident Existing Activity Log & Yes Status Provided Analyst Tier 2+ Analyst Incident? Communicate Status No 2+ 1.3 Validate DeskAnalyst Caller / Customer Tier Contact details and update if required ServiceDesk Service 1.4 Capture and 4.0 2.0 Document Incident DetailsStep Activities1.1 Verify Issue Exists Take steps to validate or replicate the interruption. Gather any data about the issue (screenshots, descriptions)
Associate to any concurrent incident (e.g. major outage)
1.2 Update Incident Activity Log & If the Caller is inquiring about status of an existing incident, provide the caller withCommunicate Status status as available in the incident record and update the record indicating that the caller was inquiring and update with additional details if available
1.3 Validate Caller / Customer Complete caller data and ensure contact details are accurate and update if necessary
Contact details and Update ifRequired1.4 Capture and Document Incident Complete the short and long description, ensuring they are clear and can beDetails understood by others
Collect incident symptoms
2.0 Incident Categorization Group–– Analyst Functional Group 2+Analyst Desk 2.2 ServiceDesk 2.1 2.3 Analyst / / 2.0 Associate 3.0 Identify Incident Complete Incident Analyst Configuration Type Categorization Functional Item(s) Service Tier2+ TierYale University Incident Management Process 6 of 17 Step Activities2.1 Identify Incident Type Capture the incident type based on the customer-reported symptoms
2.2 Associate Configuration Items(s) If a Configuration Management System (CMS) is If there is no CMS present, present, associate the incident to the capture the device name or ID, Configuration Item(s) (CI) diagnosed to have and based on the primary failed failed and are causing the incident. Note, IT device, capture the component Business and Provider Services may be captured categorization
as CI’s, if implemented
2.3 Complete Incident Capture IT Business Service categorization, as defined by the customer. Based on theCategorization symptoms and incident diagnosis, capture the IT Provider Service categorization
3.0 Incident Prioritization Analyst 2.0 3.1 Major 4.0 DeskAnalyst No Prioritize Incident Incident? Yes ServiceDesk Service 3.2 Escalate Incident to Incident Manager Manager Incident Manager Incident 9.0Step Activities3.1 Prioritize Incident Select the impact and urgency of the Incident according to guidelines if it is not present. This will determine the priority
If priority-based service level monitoring is enabled, the selected priority to define the response and resolution time service level targets for the incident
If service-based monitoring is enabled, the selected priority will only define the response time service level targets for the incident. If the reported service does not have any restoration service level targets defined, a generic priority-based restoration service level target may be used
3.2 Escalate Incident to Incident Determine if this is a major incident. If so, the service desk agent will escalate to theManager / Situation Manager incident manager accordingly
Yale University Incident Management Process 7 of 17 4.0 Initial Diagnosis Customer Caller / 4.3 Acquire Additional Information Functional Analyst/ /Functional 3.0 4.1 Perform Initial Yes 1.0 Diagnosis Analyst 2+Analyst DeskAnalyst 4.2 Search Tier2+ 4.4 4.6 Update Incident Knowledge Base, More 4.5 Incident Details linking to Known 5.0 Group––Tier Known Error Information No No Recurring No Error, Knowledge Article, Resolution Database and Required? Incident? Possible? Change as required Change Schedule ServiceDesk Group Yes Yes Service 7.0 Problem Management ProcessStep Activities4.1 Perform Initial Diagnosis Document all trouble-shooting steps within the incident record
4.2 Search Knowledge Base, Known Use initial diagnosis details to search the knowledge base for relevant knowledge
Error, Database and Change Also check the known error database to see if a workaround exists and the changeSchedule schedule to see if this is issue could be related to a recently implemented change
Ensure the incident record is coded appropriately
4.3 Acquire Additional Information If additional information is required, contact the customer. If the customer cannot be reached, place the incident on hold
4.4 Incident Resolution Possible? If a resolution is possible, proceed to step 7.0 Resolution and Recovery. If resolution is not possible, the incident may need to be assigned to a functional group for resolution
4.5 Recurring Incident? Determine if other incidents of the same nature have been experienced. If others exist and no root cause has been determined, this may be a good candidate for problem management
4.6 Update Incident Details linking to Confirm that the incident record is updated and coded according to the diagnosisKnown Error, Knowledge Article, steps. Selection of a knowledge record may update (e.g. provider service, componentChange as required category, urgency) incident categorization and details
Yale University Incident Management Process 8 of 17 5.0 Functional Escalation 4.0 Analyst DeskAnalyst 5.1 5.3 Assign Monitor Incident Internal Yes Incident to (Incident Ownership Activity) Provider? Functional Group 6.0 ServiceDesk No 8.0 5.2 Dispatch to Service 6.0 Vendor and Monitor Incident 9.0 Provider PartyProvider Vendor/ /33rdrd Vendor Diagnosis 7.0 and Incident Vendor Resolution If Party PossibleStep Activities5.1 Internal Provider? If assignment is necessary, determine if the functional group that is equipped to resolve the incident is an internal support group or an established external partner that has a support agreement and process established for incident resolution
5.2 Dispatch to Vendor and Monitor If the functional group is an external group, ensure that the established incidentIncident process is followed
5.3 Assign Incident to Functional If the functional group is an internal group, determine the proper group forGroup assignment and assign it to the Group
5.4 Monitor Incident Optimally, the Service Desk owns the monitoring of incident to resolution and closure. Guidelines for ownership/monitoring include: - Providing customers with desk contact info for updates - Progress notifications originate from a desk monitored email account - Incidents that have not been accepted within response time targets should be initially escalated to the assignment group manager, and ultimately to the Incident Manager if required - Ownership of major incidents should be transferred to the incident manager/ situation managerYale University Incident Management Process 9 of 17 6.0 Investigation and Diagnosis Customer Customer Caller/ / 5.0 6.3 Contact Caller Requestor for Additional Information if required and update Activity Analyst 2+Analyst Log 6.2 5.0 Update Incident and Assign to Service Desk for Yes Tier2+ Re-Diagnosis and Re-assignment Group––Tier Functional 7.0 No No Escalation? FunctionalGroup 6.1 Perform Initial Yes Accept Incident Review Incident? 6.4 Tier 3 and Diagnosis Functional Diagnosis Functional Escalation to Tier and Incident 3 ResolutionStep Activities6.1 Perform Initial Review & Perform initial review to determine if the incident has been properly assigned
Diagnosis6.2 Update Incident and Assign to If the incident was improperly assigned, the Functional Group assigns it back to theService Desk for Re-diagnosis and Service Desk for further diagnosis and assignment
Re-assignment6.3 Contact Requestor for If assignment is proper, accept the incident (work in progress) and determine ifAdditional Information if Required further information is required contact the customer to obtain then proceed to step 7.0 Resolution and Recovery
6.4 Functional Escalation to Tier 3 if If the incident requires further assignment to Tier 3 or an external Vendor, therequired Functional Group is responsible to work with the external partners and maintain oversight of the incident record
Yale University Incident Management Process 10 of 17 7.0 Resolution and Recovery Desk 7.4 Service Desk ServiceDesk 4.0 Analyst Contact Analyst Analyst Functional Group 8.0 or Vendor for Service Additional 7.2 Work to Resolution Details Problem Management 7.1 Communicate Resolve Incident if Required Process - Document Known Workaround if Updating Incident No Error or Workaround (if 5.0 Appropriate with Necessary applicable) Details 2+ Tier2+ Group––Tier 6.0 Analyst Resolution FunctionalGroup Analyst Incident Yes requires Change No Resolved? Request? 7.3 Update Functional Yes Incident Change Resolution Details Management and Assign to Process Service DeskStep Activities7.1 Communicate Workaround if Investigate sources of information to see if a workaround exists. Check relevantAppropriate knowledge, known error database, problem records, etc. and provide the work around to the customer
7.2 Work to Resolve Incident If no workaround exists, begin resolution activities making sure to update the incidentUpdating Incident with Necessary record with all details related to resolution activities
Details If resolution requires that a change be introduced, a Request for Change must be submitted and flow through the Change Management Process
7.3 Update Incident Resolution Once the incident has been resolved it is good practice to review the solution andDetails and Assign to Service Desk determine if knowledge could be authored for future occurrences, or if there is a systemic issue that needs to be addressed through the Problem Management Process
Upon resolution, the incident is updated with the proper resolution information and coding, and is assigned to the Service Desk for final closure activities
7.4 Service Desk Analyst Contact In preparation for closure activities, review the incident details to ensure it isFunctional Group or Vendor for completed properly and has the appropriate resolution details
Additional Resolution Details ifRequiredYale University Incident Management Process 11 of 17 8.0 Incident Closure Customer Customer Caller/ / Caller 8.3 Trigger Incident Customer 9.0 Yes Incident Closed Resolved? Satisfaction Survey 8.1 No Analyst Validate Incident DeskAnalyst Resolution with Caller / Customer 7.0 8.2 Update 5.0 Incident for Re- ServiceDesk Diagnosis ServiceStep Activities8.1 Validate Resolution with Caller / Follow proper procedures to validate with the Customer that the incident has in factCustomer been resolved. If it has been resolved, the incident will be closed according to procedures
8.2 Update Incident for Re-Diagnosis If the Customer indicates that the incident has not yet been resolved, it must be sent back for further diagnosis before the incident is closed
NOTE: If the incident is in a closed state when the customer indicates it was not resolved, a new incident should be opened and associated to the original incident
8.3 Trigger Customer Satisfaction Once the customer has confirmed resolution and the incident is in process of beingSurvey officially closed, a customer satisfaction survey is to be provided to inform future improvement opportunities
Yale University Incident Management Process 12 of 17
Supporting the business. This document is a living document and should be analyzed and assessed on a regular basis. Scope The scope of this document is to define the Incident …
Documemt Updated
Popular Download
Frequently Asked Questions
Is the incident management process a living document?
This document is a living document and should be analyzed and assessed on a regular basis. Scope The scope of this document is to define the Incident Management Process, and process inputs from, and outputs to, other process areas. Other service management areas are detailed in separate documentation.
What is the role of an incident manager?
not present Role Description Incident Manager Oversee day to day process execution ... Situation Manager Manages and owns major incidents Service Desk Manager Manages the service desk function, inclu ... Incident Process Owner Owns the process end-to-end, including t ... 2 more rows ...
What to do after an incident has been resolved?
Once the incident has been resolved it is good practice to review the solution and determine if knowledge could be authored for future occurrences, or if there is a systemic issue that needs to be addressed through the Problem Management Process.
What are the steps involved in an incident management process?
Step Activities 4.1 Perform Initial Diagnosis Document all trouble-shooting steps within the incident record. 4.2 Search Knowledge Base, Known Error, Database and Change Schedule Use initial diagnosis details to search the knowledge base for relevant knowledge.