Yale University Incident Management Process Guide

2y ago
27 Views
2 Downloads
1.23 MB
17 Pages
Last View : 16d ago
Last Download : 2m ago
Upload by : Isobel Thacker
Transcription

Yale University Incident ManagementProcess GuideYale UniversityIncident Management Process1 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: Yale UniversityIncident Management Overviewo Incident Definitiono Incident Management Objectiveso Incident Management PoliciesIncident Management Process FlowIncident Management RolesIncident Management RACIIncident Management Procedure Flows and DescriptionsIncident Management Prioritization schemeIncident Management Service Categorization ModelIncident Management Process MetricsIncident Management Process2 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 UniversityIncident Management Process3 of 17

Incident Management Process FlowIncident IdentificationSources:Event Mgt, Email, Self-Service, PhoneCall, Tech Staff (Tier 2 / Walkup)HierarchicEscalationNeeded?9.0 cident LoggingNo4.0Initial sManagementEscalationProcess6.0Investigation est?YesNoYes7.0Resolution andRecoveryNoYes8.0Incident Closure5.0FunctionalEscalationTo RequestFulfillmentIncidentProcessOwnerService Desk AnalystIncident /FunctionalFunctionalGroup – Tier Group - Queue SituationManagerManager2 AnalystCaller /CustomerV3 Incident Management ProcessAccountable for the Incident Process and its Evolution/MaturationRolesThe following roles have been identified within the Incident Management Process.RoleDescriptionIncident Manager Oversee day to day process executionOften the Service Desk ManagerManages major incidents until the appropriate situation manager is identifiedSituation ManagerService Desk Manager Manages and owns major incidentsManages the service desk function, including staffing management activitiesProvides guidance to Service Desk AnalystsOwns the process end-to-end, including the RACI, process & procedural steps, role& definitionsAccountable for maturing and evolving the process, based onmonthly/quarterly/yearly review of process KPIsAdjusts the process to address performance or changing business needsResponsible for the operations of Service Desk Analysts that are geographicallydisperse, reporting to the Service Desk ManagerLogs incidentsProvides initial diagnosisResolve incidents at first point of contact if possibleEscalates incidentsIncident Process Owner Service Desk Site LeadService Desk AnalystYale University Incident Management Process4 of 17

RoleDescription Owns non-major incidentsCaller / Customer The end user having or reporting the service interruptionFunctional Group – QueueManager Functional Group – Tier 2 Analyst Assigns incidents to individual Tier 2 Analysts in the functional groupMonitors and manages support resolution performanceMay directly manage (reporting manager) the day to day activities of Tier 2 analysts outside of process activitiesGroup of technical support experts that will handle issues escalated by the ServiceDeskFor example, a Network EngineerReceive process direction for a functional group queue manager, staffmanagement from a reporting manager RACICaller /CustomerServiceDeskAnalyst1.0 IncidentLoggingCRAR2.0 IncidentCategorizationCRAR3.0 IncidentPrioritizationCRA, C, I4.0 InitialDiagnosisRA, C, I5.0 FunctionalEscalationRA, C6.0Investigation &Diagnosis7.0 Resolution& RecoveryIR8.0 IncidentClosureCR9.0 MajorIncidentProcessProcessMaturity andEvolutionYale UniversityServiceDeskSite LeadIncidentManagerSituationManagerFunctionalGroup –QueueManagerC, ICRIncidentProcessOwnerRARFunctionalGroup – Tier2 AnalystRARARARRRCRIncident Management ProcessCA5 of 17

Process ProceduresGroup––FunctionalGroupAnalyst/ /FunctionalDeskAnalystServiceDeskServiceAnalyst2 TierTier 2 Analyst1.0 Incident Logging1.1 Verify IssueExistsExistingIncident?Yes1.2 Update IncidentActivity Log &CommunicateStatusStatus ProvidedNo1.3 ValidateCaller / CustomerContact detailsand update ifrequired1.4 Capture andDocument IncidentDetails4.0Step1.1 Verify Issue Exists1.2 Update Incident Activity Log &Communicate Status1.3 Validate Caller / CustomerContact details and Update ifRequired1.4 Capture and Document IncidentDetails2.0ActivitiesTake steps to validate or replicate the interruption. Gather any data about the issue(screenshots, descriptions).Associate to any concurrent incident (e.g. major outage).If the Caller is inquiring about status of an existing incident, provide the caller withstatus as available in the incident record and update the record indicating that thecaller was inquiring and update with additional details if available.Complete caller data and ensure contact details are accurate and update if necessary.Complete the short and long description, ensuring they are clear and can beunderstood by others.Collect incident symptoms.DeskServiceDeskServiceAnalystAnalyst / /Group––FunctionalFunctional GroupAnalyst2 AnalystTier2 Tier2.0 Incident CategorizationYale University2.02.1Identify nt Management Process2.3Complete IncidentCategorization3.06 of 17

StepActivities2.1 Identify Incident TypeCapture the incident type based on the customer-reported symptoms.2.2 Associate Configuration Items(s)If a Configuration Management System (CMS) isIf there is no CMS present,present, associate the incident to thecapture the device name or ID,Configuration Item(s) (CI) diagnosed to haveand based on the primary failedfailed and are causing the incident. Note, ITdevice, capture the componentBusiness and Provider Services may be capturedcategorization.as CI’s, if implemented.Capture IT Business Service categorization, as defined by the customer. Based on thesymptoms and incident diagnosis, capture the IT Provider Service categorization.2.3 Complete IncidentCategorization2.03.1Prioritize IncidentMajorIncident?No4.0Yes3.2Escalate Incidentto stDeskAnalystServiceDeskService3.0 Incident Prioritization9.0StepActivities3.1 Prioritize IncidentSelect the impact and urgency of the Incident according to guidelines if it is notpresent. This will determine the priority.If priority-based service level monitoring is enabled, the selected priority to define theresponse and resolution time service level targets for the incident.If service-based monitoring is enabled, the selected priority will only define theresponse time service level targets for the incident. If the reported service does nothave any restoration service level targets defined, a generic priority-based restorationservice level target may be used.Determine if this is a major incident. If so, the service desk agent will escalate to theincident manager accordingly.3.2 Escalate Incident to IncidentManager / Situation ManagerYale UniversityIncident Management Process7 of 17

FunctionalAnalyst/ /FunctionalDeskAnalystServiceDeskServiceAnalyst2 AnalystTier2 Group––TierGroupCaller /Customer4.0 Initial Diagnosis4.3 AcquireAdditionalInformation3.04.1 Perform InitialDiagnosisYes4.2 SearchKnowledge Base,Known ErrorDatabase andChange roblemManagementProcess4.6 Update IncidentDetails linking to KnownNo Error, Knowledge Article,Change as required5.0StepActivities4.1 Perform Initial DiagnosisDocument all trouble-shooting steps within the incident record.4.2 Search Knowledge Base, KnownError, Database and ChangeScheduleUse initial diagnosis details to search the knowledge base for relevant knowledge.Also check the known error database to see if a workaround exists and the changeschedule to see if this is issue could be related to a recently implemented change.Ensure the incident record is coded appropriately.If additional information is required, contact the customer. If the customer cannot bereached, place the incident on hold.4.3 Acquire Additional Information4.4 Incident Resolution Possible?4.5 Recurring Incident?4.6 Update Incident Details linking toKnown Error, Knowledge Article,Change as requiredYale UniversityIf a resolution is possible, proceed to step 7.0 Resolution and Recovery. If resolutionis not possible, the incident may need to be assigned to a functional group forresolution.Determine if other incidents of the same nature have been experienced. If othersexist and no root cause has been determined, this may be a good candidate forproblem management.Confirm that the incident record is updated and coded according to the diagnosissteps. Selection of a knowledge record may update (e.g. provider service, componentcategory, urgency) incident categorization and details.Incident Management Process8 of 17

4.05.1InternalProvider?5.3 AssignIncident toFunctional GroupYesMonitor Incident(Incident Ownership Activity)6.0No8.05.2 Dispatch toVendor andMonitor Incident6.09.0Vendor/ AnalystServiceDeskService5.0 Functional EscalationVendorDiagnosisand IncidentResolution IfPossible7.0StepActivities5.1 Internal Provider?5.2 Dispatch to Vendor and MonitorIncidentIf assignment is necessary, determine if the functional group that is equipped toresolve the incident is an internal support group or an established external partnerthat has a support agreement and process established for incident resolution.If the functional group is an external group, ensure that the established incidentprocess is followed.5.3 Assign Incident to FunctionalGroupIf the functional group is an internal group, determine the proper group forassignment and assign it to the Group.5.4 Monitor IncidentOptimally, the Service Desk owns the monitoring of incident to resolution andclosure. Guidelines for ownership/monitoring include:Providing customers with desk contact info for updatesProgress notifications originate from a desk monitored email accountIncidents that have not been accepted within response time targets shouldbe initially escalated to the assignment group manager, and ultimately tothe Incident Manager if requiredOwnership of major incidents should be transferred to the incidentmanager/ situation managerYale UniversityIncident Management Process9 of 17

Analyst2 AnalystTier2 Group––TierFunctionalGroupFunctionalCaller/ /CallerCustomerCustomer6.0 Investigation and Diagnosis5.05.06.2Update Incidentand Assign toService Desk for YesRe-Diagnosis andRe-assignmentNo6.1 Perform InitialIncident Reviewand DiagnosisAcceptIncident?6.3 ContactRequestor forAdditionalInformation ifrequired andupdate nalEscalation to Tier3Tier 3Diagnosisand IncidentResolutionStepActivities6.1 Perform Initial Review &DiagnosisPerform initial review to determine if the incident has been properly assigned.6.2 Update Incident and Assign toService Desk for Re-diagnosis andRe-assignment6.3 Contact Requestor forAdditional Information if RequiredIf the incident was improperly assigned, the Functional Group assigns it back to theService Desk for further diagnosis and assignment.6.4 Functional Escalation to Tier 3 ifrequiredYale UniversityIf assignment is proper, accept the incident (work in progress) and determine iffurther information is required contact the customer to obtain then proceed to step7.0 Resolution and Recovery.If the incident requires further assignment to Tier 3 or an external Vendor, theFunctional Group is responsible to work with the external partners and maintainoversight of the incident record.Incident Management Process10 of 17

DeskServiceDeskServiceAnalystAnalyst7.0 Resolution and Recovery4.02 Tier2 lyst5.07.1 CommunicateWorkaround ifAppropriate7.2 Work toResolve IncidentUpdating Incidentwith NecessaryDetailsNoProblem ManagementProcess - Document KnownError or Workaround (ifapplicable)IncidentResolved?Yes7.4 Service DeskAnalyst ContactFunctional Groupor Vendor forAdditionalResolution Detailsif Required8.06.0Resolutionrequires ChangeRequest?NoYesChangeManagementProcess7.3 UpdateIncidentResolution Detailsand Assign toService DeskStepActivities7.1 Communicate Workaround ifAppropriateInvestigate sources of information to see if a workaround exists. Check relevantknowledge, known error database, problem records, etc. and provide the workaround to the customer.If no workaround exists, begin resolution activities making sure to update the incidentrecord with all details related to resolution activities.If resolution requires that a change be introduced, a Request for Change must besubmitted and flow through the Change Management Process.Once the incident has been resolved it is good practice to review the solution anddetermine if knowledge could be authored for future occurrences, or if there is asystemic issue that needs to be addressed through the Problem ManagementProcess.Upon resolution, the incident is updated with the proper resolution information andcoding, and is assigned to the Service Desk for final closure activities.In preparation for closure activities, review the incident details to ensure it iscompleted properly and has the appropriate resolution details.7.2 Work to Resolve IncidentUpdating Incident with NecessaryDetails7.3 Update Incident ResolutionDetails and Assign to Service Desk7.4 Service Desk Analyst ContactFunctional Group or Vendor forAdditional Resolution Details ifRequiredYale UniversityIncident Management Process11 of 17

AnalystDeskAnalystServiceDeskServiceCaller/ /CallerCustomerCustomer8.0 Incident ClosureIncidentResolved?9.08.1Validate IncidentResolution withCaller / Customer8.3 TriggerCustomerSatisfactionSurveyYesIncident ClosedNo8.2 UpdateIncident for ReDiagnosis7.05.0StepActivities8.1 Validate Resolution with Caller /CustomerFollow proper procedures to validate with the Customer that the incident has in factbeen resolved. If it has been resolved, the incident will be closed according toprocedures.If the Customer indicates that the incident has not yet been resolved, it must be sentback for further diagnosis before the incident is closed.NOTE: If the incident is in a closed state when the customer indicates it was notresolved, a new incident should be opened and associated to the original incident.Once the customer has confirmed resolution and the incident is in process of beingofficially closed, a customer satisfaction survey is to be provided to inform futureimprovement opportunities.8.2 Update Incident for Re-Diagnosis8.3 Trigger Customer SatisfactionSurveyYale UniversityIncident Management Process12 of 17

3.09.1 ValidatesMajor Incident9.4 Prepare Major Incidentdocumentation as defined& Perform Post ResolutionReview8.09.3 Trigger andexecutecommunicationsas required untilIncident ResolvedSituation ManagerIncidentIncidentManagerManager9.0 Major Incident Process9.2 EnsureAssignment ofIncident toFunctional Team5.0Consult withBusiness & IT toinvoke Business/ITService ContinuityPlans as definedStepActivities9.1 Validate Major IncidentIf an incident is escalated to a “Major Incident” status, the Incident Managermust first ensure that it should be treated as a Major Incident and be giventhe enhanced communication and management attention that a MajorIncident requires.Ensure that the incident has been assigned to the appropriate team forresolution and works with the management structure to coordinate a crossfunctional team to address the situation if needed and where the underlyingissue is unclear.Ensure that the communication is planned and executed according to internalprocedures and triggers. At a minimum communication is to be shared at thebeginning and end of a Major Incident and perhaps at specific intervalsthroughout the resolution process. This communication can be to eitherinternal IT stakeholders or Customers or a combination of both.Upon resolution of a Major Incident, documentation must be prepared thatsummarizes the issue, actions taken and resolution details. It should alsotrigger root case analysis if required and allow for improvements that can bemade to avoid the situation in the future.9.2 Ensure Assignment of Incident toFunctional Team9.3 Trigger and execute communications asrequired until Incident Resolved9.4 Prepare Major Incident documentationas defined & Perform Post ResolutionReviewYale UniversityIncident Management Process13 of 17

Prioritization schemeThe prioritization scheme is based on a combination of Impact and Urgency and used to: Generate a simplified value in order to drive escalation and notificationEstablish appropriate ‘order and extent of work effort to achieve resolutionImpact: Measure of scope and criticality to businessOften equal to the extent to which an incident leads to distortion of agreed or expectedservice levelsImpact is often measured by the number of people affected, critical systems, or financialloss as a result of the service interruptionUrgency: Measure of how quickly an incident needs to be responded to based on the businessneeds of the customerPrioritizes workload; incidents with higher urgency will be addressed before others,unless SLA breaches are imminentThe follow table shows the resulting priority based on impact and urgency.Service Categorization ModelA Service Categorization model is an important aspect that: Yale UniversityRecognizes need to capture service vs. technology detailsFuture-proofed for introduction of Service Asset and Configuration ManagementEnhances value of reporting by defining IT service view in terms the business shouldunderstandIncident Management Process14 of 17

The following shows the 2 Service Categorization levels that enable views from both Customer/Businessand Provider perspectives:Process MetricsThe

R 3.0 Incident Prioritization C R A, C, I 4.0 Initial Diagnosis R A, C, I R 5.0 Functional Escalation R A, C 6.0 Investigation & Diagnosis A R 7.0 Resolution & Recovery I R A R 8.0 Incident Closure C R R A R 9.0 Major Incident Process A R R Process Maturity and Evolution C, I C R R C R C A

Related Documents:

Yale Yalelift 360 Yale VS /// CM Series 622 Yale Yalelift ITP/ITG Yale Yalelift LHP/LHG Coffing LHH Table of Contents 1-2 3-4 5 6-7 8-9 10-11 Hand Chain Hoist Ratchet Lever Hoist Trolleys Beam Clamps Specialities 12 13 14-15 16 17 Yale Yalehandy Yale UNOplus Yale C 85 and D 85 Yale D 95 Yale AL 18 19-20 CM CB

Incident Management Process Map 1. Incident Management Process Map 1. Incident Management Description and Goals 9. Incident Management Description and Goals 9. Description 9. Description 9. Goals 9. Goals 9. Incident Management RACI Information 10. Incident Management RACI Information 10. Incident Management Associated Artifacts Information 24

the Yale Access App The Yale Access App is needed to control your Yale products from your mobile device. The Yale Access App is available for iPhone and Android. Download the Yale Access App from the App Store or Google Play depending on your device. Once you have downloaded the Yale Access App, log in to

Yale Law School 2019-2020 Yale Law School 2019-2020. BULLETIN OF YALE UNIVERSITY Series 115 Number 11 August 10, 2019 (USPS 078-500) is published seventeen times a year (one time in May and October; three times in June and September; four times in July; five times in August) by Yale University, 2 Whitney

1 Yale University Press, “Books from Yale at Christmas” (print advertisement), Yale Daily News, 10 December 1958, 9. 2 Gideon Gordon, “From the Couch: Study of Yale Mind Published,” Yale Daily News, 22 October 1958, 1. 3 Bryant M. Wedge, preface to Psychosocial Problems of College M

Yale Smart Lift can reduce cycle times by up to 25%. Exclusive Yale Smart Slow Down To further ensure that every load remains stable, the Yale MPB-VG truck features optional Yale Smart Slow Down technology. When the operator turns the truck to change direction, the Yale Smart Slow Down feature intuitively reduces the truck's speed,

planning, incident mitigation, and resource availability. The Incident Management Program is structured to assist the system entities, as well as provide a well- rounded incident management platform. e. System Incident Management Oversight and Authorities The System Incident Management staff is comprised of a Division of the Corporate Security

Incident*Management*Process - Investigate*&*Diagnose Process: Incident Management Activity: 3.0 Investigate & Diagnose Predecessors Incident Coordinator Incident Support Data Inter/Intra Process Annotation INC 3.1 Accept assignment INC 2.9 Escalate INC 3.2 Acknowledge Assignment INC 3.3 Acquire additional information if required