Incident Mgmt Process Guideand Standards

Wedgewood,Inc.
Preparedby:
Project Sponsor(s):
ITIL Consultant:
Edward Pagsanhan
FouadJilani
Paul Volkman
Douglas Fernandes
Edward Pagsanhan
Date Created:
Date Last Modified:
07.08.2016
09.21.2016
IT Service Desk & Incident Management v4.0
Process Guide

Incident Management - Version 3.1
Process Guide
Wedgewood,Inc. 2 | P A G E
TABLEOF CONTENTS
DOCUMENT PURPOSE ............................................................................................... 3
VERSION HISTORY..................................................................................................... 3
DOCUMENT CONTRIBUTORS ...................................................................................... 4
1. OVERVIEW …………………………………………………………………………………………………………………………..5
1.1. PROCESS DESCRIPTION .………………………………………………………………………………………………………………………..5
1.2. PROCESS GOAL..…………………………………………………………………………………………………………………………………… 5
1.3. PROCESS SCOPE...………………………………………………………………………………………………………………………………….5
1.4. PROCESS OBJECTIVES ..………………………………………………………………………………………………………………………….6
1.5. RELATIONSHIPS WITH OTHER IT PROCESSES ...........................................................................................6
1.6. PRINCIPLES AND BASIC CONCEPTS ………………………………………………………………………………………………………..7
1.6.1 INCIDENT MODELS …………………………………………………………………………………………………………………. 8
1.6.2 INCIDENT STATES……………………………………………………………………………………………………………………..8
1.7. PROCESS ROLES.…………………………………………………………………………………………………………………………………….9
1.8. RACI MATRIX ……………………………………………………………………………………………………………………………………….10
2. SERVICE DESK INCIDENT MANAGEMENT ACTIVITY DESCRITPTION……………………………………12
2.1.. PROCESS ACTIVITY OVERVIEW DIAGRAM ..............................................................................................................11
2.2. PROCESS ACTIVITY OVERVIEW DESCRIPTION …………………………….………………………………………………………..13
2.3. INCIDENT IDENTIFICATION AND CLASSIFICATION .................................................................................................12
2.4. INITIAL SUPPORT PROCEDURE ...................................................................................................................................15
2.5. INVESTIGATION AND DIAGNOSIS ..............................................................................................................................19
2.6. RESOLUTION AND RECOVERY ....................................................................................................................................21
2.7. INCIDENT CLOSURE .....................................................................................................................................................23
3. PROCESS CONTROL ..............................................................................................24
3.1. KEY PERFORMANCE INDICATORS (KPI) ..................................................................................................................24
3.2. OPERATIONAL DATA ....................................................................................................................................................24
APPENDIX A: DOCUMENT CONVENTIONS......................................................................25
APPENDIX B: GLOSSARY OF TERMS AND ACRONYMS ......................................................27
APPENDIX C: INCIDENT CATEGORIZATION .....................................................................27
APPENDIX D: INCIDENT PRIORITIZATION ......................................................................29

Process Guide
DOCUMENT PURPOSE
This document defines the Wedgewood, Inc.’s Service Desk Incident Management (IM) process,activities,and accountableroles for the IT organization.
Planningand adoption of an agreed upon Incident management process (with supportingprocedures and tool enhancement) will assistin the identification and
timely resolution of incidents reported to Wedgewood, Inc.’s IT. This document is a livingguideto be updated as necessary to represent the current operational
practice.
VERSION HISTORY
Version RevisionDate Revisedby Description
1.0 7/8/2016 Edward Pagsanhan Initial Document Creation
1.1 7/12/16 Edward Pagsanhan IM/Service Desk Process GuideV1.10 (WIP Draft)
1.2 7/14/16 Edward Pagsanhan IM/Service Desk Process Guide– Entry & Exit Requirements defined
2.0 7/19/16 Edward Pagsanhan IM/Service Desk PROCESS GUIDE (v2.0)
7/24/16 Edward Pagsanhan Define additional requirements (roles& resp., record states
7/25/16 EP Service Desk/User Requests - Workflows & Process flows defined
2.1 7/26/16 EP Requirements, Workflows & Process flows defined.
2.2 EP Draft v2. –Technical review & approval logged (Fouad J)
3.0 8/1/16 EP Draft edits – Roles & Responsibilities
3.1 9/14 EP v3.1
4.0 9/16 EP v4.0 FINAL APPROVED DRAFT
Document Management and Distribution Procedures
Once implemented - edit changes will beapplied to this document accordingto the followingprocedure:
1. Direct all changerequests to the process owner.
2. Each change request will be considered. If accepted, the change will be incorporated into a new draft of this document.
3. The new draft of this document will be circulated for review by appropriatestakeholders.
4. Approval of the new draft will beby concurrence of those individualsparticipatingin thereview.
5. Once concurrence is achieved,the draftbecomes the new version of this document, replacingany existingand previous versions.
6. New versions of this document are to be distributed to appropriatestakeholders or made accessibleon-linefor reference. Notification of a new version will
be communicated.

Process Guide
DOCUMENT CONTRIBUTORS
Name Role
Paul Volkman CIO
Fouad Jilani Service Desk Lead/Manager/Technical Owner
Javier Chevez Service Desk Agent
Douglas Fernandes Program Director
Edward Paul Pagsanhan ITIL-ITSM Consultant
`

Process Guide
INTRODUCTION
The concepts described in this guide aligns with ITIL2011 and may reference capabilities,standardsand bestpractices. These references arenoted by blue
italicized font.
1 OVERVIEW
A process is defined as a set of linked activities thattransformspecified inputs into specified outputs,aimed at accomplishingan agreed-upon objective in a
measurablemanner. The ServiceDesk IncidentManagement process definition laid outin this document further breaks down these activities into actionsand
the role(s) responsiblefor their execution.
This document also describes how the current ticketing/request mechanism supports the incidentmanagement process with its abilitiesto log, categorize,
assign to appropriategroups,escalate,and manage incidents records through to resolution and reporting.
1.1. PROCESS DESCRIPTION
An incidentis defined as an unplanned interruption or a reduction in the quality of an IT serviceor a failureof a configur ation item (CI) that has not yet
impacted an IT service.Incidents can includefailures or degradation of services reported by users,technical staff,third-party suppliers and partners,or
automatically from monitoring tools. Incident management is responsible for managing the lifecycle of all incidents.
1.2. PROCESS GOAL
The primary goal of the incidentmanagement process is to restore normal serviceoperation as quickly as possibleand minimize the adverse impact of
incidents on business operations,thus ensuringthat the best possiblelevels of servicequality and availability aremaintai ned.Normal serviceoperation
is defined here as an operational state where services and CIs are performing within agreed service and operational levels.
1.3. PROCESS SCOPE
Service Desk IncidentManagement includes any event which disrupts,or which could disrupt,a service. This includes events which are communicated
directly by users, either through the Service (or Help) Desk or through an interface from Event Management to Incident Management tools. Incidents
can also be reported and/or logged by technical staff (if, for example, detect a potential problem with a hardware or network component - they may
report or log an incident and refer it to the Service Desk). This does not mean, however, that all events are incidents. Many classes of events are not
related to disruptions at all, but are indicators of normal operation or are simply informational.
Although both incidents and service requests are reported to the Service Desk, this does not mean that they are the same. Service requests do not
represent a disruption to agreed service, but are a way of meeting the customer’s needs and may be addressing an agreed target in an SLA. Service
requests are dealt with by the Request Fulfilment process.

Process Guide
1.4. PROCESS OBJECTIVES
Objectives of the incidentmanagement process:
• Ensure that standard methods and procedures are used for efficient and prompt incident response, analysis, documentation, ongoing management,
and reporting.
• Increase visibility and communication of incidents to business and support staff.
• Enhance business perception of IT through use of a professional approach in quickly resolving and communicating incidents when they occur.
• Align incident management activities and priorities with those of the business.
• Maintain user satisfaction with the quality of IT services.
1.5. RELATIONSHIP WITH OTHER IT PROCESSES
Process Relation Description Input Output
Change
Management
A request for change (RFC) can be submitted in order to implement a workaround or a resolution. X
 Can detect and resolveincidents that arisefromchanges.
Change management is responsiblefor keeping the Service Desk informed of all scheduled changes.
X
Service Level
Management
(SLM) TBD
 Defines measurableresponses to servicedisruptions.
 Provides historical data thatenables SLM to review servicelevel agreements (SLAs) objectively and
regularly.
 Assists SLMin defining where services areat their weakest so that SLM can define actions as partof the
serviceimprovement plan (SIP).
X
SLM defines the acceptablelevels of servicewithin which incidentmanagement works, including:
 Incidentresponse times
 Impact definitions
 Target fix times
 Service definitions
 Rules for requesting services
X

Process Guide
1.6. PRINCIPLES AND BASIC CONCEPTS
Policies
< … Add Wedgewood, Inc.’s Service Desk Incident Management policy statements here. WIP >
< … Create supporting documents in the Wedgewood, Inc.’s Knowledge Base – WIP > DELL’s KACE Knowledge Base
Incident management policies are required to guide all staff in the behaviors needed to make incident management effective. Policy statements will be
dependent on the culture of the organization, but typically address the following:
 Use of a single management system for all incidents.
 Incident management should be aligned with overall service levels and objectives.
 Hierarchical escalation for appropriate IT management notification.
 Routine audits of incident records to ensure correct incident prioritization and documentation.
Resolution Estimated Timelines
Timelines must be agreed for all incident-handling stages (these will differ depending upon the incident’s Category level), based on the overall incident
response and resolution targets within defined requirements.
Process Measurements
Category Requirement Engagement Activity Target Minimum Performance Target
(Recommended)/SLA
Report Log & Location:
(System ofRecord)
Incident Resolution Priority Critical Immediately <2 Hours KACE
Incident Resolution Priority High < 2 Hours <8 Hours KACE
Incident Resolution Priority Medium < 8 Business Hours <16 Business Hours KACE
Incident Resolution Priority Low Within 48-72 Business Hours Within 24 Business Hours KACE

Process Guide
1.6.1 INCIDENT MODELS
Many incidents arenot new; they involvedealingwith something that has happened before and may well happen again.An incidentmodel is a
way of predefining the steps that should be taken to handle a particular type of incident in an agreed manner.
Support tools can then be used to manage the required process.This will ensurethat‘standard’incidents arehandled in a pre-defined path and
within pre-defined timelines. Incidents which would require specialized handling can be treated in this way (for example, security-related
incidents can be routed to Information Security Management and capacity or performance related incidents would be routed to Capacity
Management).
o The Incident Model should include:
o The steps that should be taken to handle the incident
o The chronological order these steps should be taken in, with any dependences or co-processing defined
o Responsibilities; who should do what
o Timelines and thresholds for completion of the actions
o Escalation procedures; who should be contacted and when
o Any necessary evidence-preservation activities (particularly relevant for security- and capacity-related incidents).
These models can be input to the incident-handlingsupporttools in useand the tools can then automate the handling,management and
escalation of the process.
1.6.2 INCIDENT STATES
Incidents should be tracked throughout their lifecycle to support proper handling and reporting. The state of an incident indicates where it is in
relation to the lifecycle and helps determine what the next step in the process might be. The Incident Record state values to be used are:
o New: defaultvalue upon record creation.
o Open: assigned to resource, work is in progress.
o Closed:customer or user satisfaction has been confirmed; the record can no longer be updated.
o Re-Opened:to designate an existing known error, or incidentrecord(s) that are currently in-flight.*
* If separate records,record link functionality will beused.

Process Guide
1.7 PROCESS ROLES
Each roleis assigned to perform specific taskswithin the process. Within the process, there can be more than one individual associated with a specific
role. Additionally, a single individual can assume more than one role within the process, though typically not at the same time. Depending on the
structureand maturity of a process,all roles described may notexistin every organization.Thefollowingdescribes the typical rolesdefined for incident
management.
Role Description
Process Owner:
CIO
An executive or senior manager with the ability and authority to ensure the process is rolled outand used by the entire IT
organization.
Responsiblefor:
 Definingthe overall mission of the process.
 Establishingand communicatingthe process mission, goals,and objectives to all stakeholders.
 Resolvingany cross-functional (departmental) issues.
 Ensuringconsistentexecution of the process across theorganization.
 Reporting on the effectiveness of the process to executive management.
 Initiating any process improvement initiative.
Service Desk/Incident
Support (1st level):
Tier 1 Support
resource
Responsiblefor:
 Provideinitial supportand classification
 Assessment and classification of inbound records to their respective & appropriatequeues .
 Recording, ownership,monitoring, tracking,and communication about incidents.
 Investigatingand diagnosingincidents.
 Providingresolutionsand workarounds fromstandard operatingprocedures and existingknown errors.
 Escalatingincidents to incidentsupport.
 Closingof incidents.
Support (2nd level):
Tier 2 Support
resource
Responsiblefor:
** ALL functions of the Tier 1 Support in addition to the following –
 Escalatingincidents to incidentsupport.
 Investigatingand diagnosingincidents escalated fromthe Service Desk.
 Developing workarounds.
 Resolvingand recovery of assigned incidents.

Process Guide
Role Description
 Creating incidents after detecting a servicefailureor quality
1.8 RACI MATRIX
Roles and responsibilities are assigned to specific process activities. (Pending approval and sign-off from Service Desk Manager, CIO)
ID Activities
Caller Service Desk
Agent
Incident
Support
INC 2.1 IncidentIdentificationand Classification
INC2.1 - A Create NewIncident C R/A
INC2.1 - B Capture IncidentDetails C R/A
INC2.1 - C Categorize/Prioritize Incidents C R/A
INC 2.2 Initial Support
INC2.2 - A PerformIncidentMatching R/A
INC2.2 - B Apply DocumentedResolution I/C R/A
INC2.2 - C Associate incidenttorelatedrecord R/A
INC2.2 - D Assignincidenttoappropriate supportgroup R/A
INC 2.3 Investigationand Diagnosis
INC2.3 - A Acknowledgeincidentassignment R/A
INC2.3 - B Investigate anddiagnose C C R/A
INC2.3 - C Update/documentdetailsontoincidentrecord R/A
INC 2.4 Resolutionand Recovery
INC4.1 DocumentandsubmitRFC (appliesif Change Requestisneeded) R/A
INC4.2 Implementresolutionorworkaround I/C R/A
INC4.3 Ensure incidentisfullydocumented R/A R
INC 5.0 IncidentClosure
INC5.1 Sendincidentresolutionconfirmationemail I
INC5.2 ConfirmIncidentresolution C/R R/A
INC5.3 Close Incident I R/A

Process Guide
R: Responsible, A: Accountable, C: Consulted,
I: Informed
1 INCIDENT MANAGEMENT ACTIVITY DESCRIPTION
1.1 PROCESS OVERVIEW DIAGRAM

Process Guide
1.1.1 Process Activity Overview Description

Process Guide
ID Tasks Description
INC 2.1
Incident
Identification &
Classification
 Gathering information needed to facilitateservicedisruption analysisand assignment.
 Redirecting improperly routed servicerequests to QUEUE’s within the org’s other existing
external processes (i.e., Change Management, Facilities Management, New hire/Onboarding
Management, Request Fulfillment )
 Associatingtheincidentwith a relevant SLA.
 Determining the incidentpriority.
 Invokingthe major incidentprocedure where applicable.
INC 2.2 Initial Support
 Matchingthe incidentagainstother related calls,events, incidents,known errors,or changes
that are open or have been recently closed.
 Escalation to 2nd-level support,if necessary.
In many cases,correspondingworkarounds,known errors,or quick fixes documented in the
knowledge base allowincidents to be resolved at 1st-level support without recourse to further
resources.
INC 2.3
Investigation and
Diagnosis
 Performing full investigation and diagnosis of the assigned incident.
 Providingadviceon possibleworkarounds or temporary fixes.
 Usingstandard operational procedures and work instructions to ensure that servicecan be
restored as quickly as possible.
INC 2.4
Resolution and
Recovery
 Repairingor replacingthe faulty CI(s).
 Restoring the serviceso that it is availablefor use.
 Submitting a RFC when a change is necessary to achieveincidentresolution.
 Informingthe customers and users that the serviceis restored.
 Verifyingwith the customer or callersthatservicerestoration is satisfactory.
INC 2.5 Incident Closure
As far as practicable,confirmation thatthe serviceis truly restored should be obtained from the
affected caller(s) beforethe incidentis closed.

Process Guide
2 INCIDENT MANAGEMENT – STAGES WORKFLOW (1-5)
2.1 INCIDENT IDENTIFICATION AND CLASSIFICATION
Capturing sufficient and relevant detail at this stage is very important; it will aid in diagnosis if the incident requires escalation. A description of the incident in the
caller’s own words should be recorded so that future contact with the caller can be made in their terms.
NOTE: These steps are taken when the caller contacts the service desk. They are not valid when the incident is reported through an employee self-service
mechanism.

Process Guide
ID Tasks Procedure
Primary
Role
Input Output
INC 2.1 - A
Create New
Incident
From the Incidentapplication,createa new
incidentrecord in the record system KACE before
designatingthe event as an incident or service
request.
Service
Desk
 Email from caller
 Call
 Walk-in
 Event
 New
incident
record
INC 2.1 - B
Capture Incident
Details
Summarize the incidentsymptoms in the Short
Description field.
In the Notesand Additional comments sections,
describethe symptoms of the incident: **
 What the caller is tryingto do
 What is happening
 What actions were taken by the caller
 When the incidentoccurred
Service
Desk
 Incidentrecord
with identified
sourceand
accuratecaller
information
 Incident
with
detailed
symptom
information
INC 2.1 - C
Categorize /
Prioritize Incident
See Appendix C for categorization techniques.
Service
Desk
 Incidentwith
detailed symptom
information
 Categorized
Incident

Process Guide
2.2 INITIAL SUPPORT

Process Guide
ID Tasks Procedure Primary Role Input Output
INC 2.2 - A
Perform Incident
Matching
 Search opened incidents withthe same
categorization to determine if a duplicate
incident exists.
 If the affectedCI ** has beenidentified.
 Look for existing resolutionactionby
searching for existing problems and known
errors with correspondingcategoryand
symptoms.
Service Desk
PrioritizedIncident Identified:
 Duplicate incident
 RFCas the cause of
the incident
 Corresponding
active problem
 Corresponding
known error or
workaround
INC 2.2 - B
Apply Documented
Resolution
If a correspondingKnown Error (KE) exists, apply
the documentedworkaround or resolutionas
described.
Service Desk
Identifiedcorresponding
Known Error (KE) or
Workaround
Resolvedor
unresolvedIncident
INC 2.2 - C
Associate Incident
to Related Record
Associate the relatedrecord to the incident if:
 An identical active incident - same error on
the same Configuration Item (CI)**
Or
 The appliedworkaround, KnownError (KE),
or resolutioninformation resolve the
Incident
Or
 The incident was caused bythe
implementationof a Change
Service Desk
 Duplicate incidents
 Corresponding active
problemrecord
 IdentifiedRFCas a cause of
the incident
Or
 Resolution information
from knownerror or
workaround applied
successfully
Existingrelated
records associated
to the incident
INC 2.2 - D
Assign Incident to
Appropriate
Support Group
If no documentedknown error or workaround
exists, or if identifieddocumented resolution did
not resolve the incident, select the appropriate
assignment group.
Service Desk
 Existingrelatedrecords
associatedwith the
incident
Or
 Unresolved incident
Incident escalated to
Incident Support

Process Guide
2.3 INCIDENT INVESTIGATION AND DIAGNOSIS

Process Guide
2.3.1 Process Activity Overview Diagram
ID Tasks Procedure Primary Role Input Output
INC 2.3 - A
Acknowledge
Incident
Assignment
Each 2nd-level support groupis responsible for
monitoringtheir respective queues for assigned
incidents.
 Assignincident to specific support team
member.
Or
 Reassignto another support group, if
appropriate.
 Incident state is Active
Incident
Support
Incident escalated
to Incident Support
Active incident (under
investigation)
INC 2.3 - B
Investigate and
Diagnose
Each support groupinvolvedwith handling the
incident investigatesanddiagnoses what hasgone
wrong.
Incident
Support
Active incident
(under
investigation)
Investigationand
diagnosisfindings
INC 2.3 - C
Update Incident
Record
In the Work notes section, document all activities,
includingdetailsof anyactions takento tryto
resolve or re-create the incident, sothat a
complete historicalrecordof all activities is
maintained at all times.
Incident
Support
Investigationand
diagnosisfindings
 Identifiedsolution
or workaround
 Incident record
documentedwith
investigation and
diagnosisfindings

Process Guide
2.4 RESOLUTION AND RECOVERY

Process Guide
2.4.1Process Activity Overview Description
ID Tasks Procedure
Primary
Role
Input Output
INC 2.4 - A
Document and
Submit RFC
If a change is needed, initiatea new
Request For Change record and
establish linkagewith the Service Desk
incidentrecord.
Incident
Support
Identified solution
or workaround
requesting an RFC
Request For Change
submitted to
Change Management
INC 2.4 - B
Implement
Resolution or
Workaround
Followthe documented procedure and
implement the resolution or
workaround.
• If the serviceis restored,change the
incidentstate to Resolved. **
If the implemented resolution or
workaround does not restore the
service,return to INC 3.2 – Investigate
and Diagnose.
Incident
Support
Identified solution
or workaround
ready to be
implemented
Resolution or
workaround
implemented
successfully Or
Additional investigation
and diagnosis required.
INC 2.4 - C
Insure Incident is
Fully
Documented
Ensure the incidentcontains full historic
information ata sufficientlevel of detail.
If the incidenthas previously been
associated to a known error or problem,
set the incidentstate to Resolved.
Incident
Support
Active incident
properly
categorized
Fully documented
incidentset to the
Resolved state
Or
Fully documented
incidentwith no
identified root cause

Process Guide
2.5 INCIDENT CLOSURE

Process Guide
ID Tasks Procedure
Primary
Role
Input Output
INC 2.5 - A
Send Incident
Resolution
Confirmation
email
When an incidentis setto a CLOSED
incidentstate, a notification issentto
the caller (via outbound call and/or
email)
KACE
(System)
Fully
documented
incidentset to
the Resolved
state
Incident
resolution
confirmation
notification by
email
INC 2.5 - B
Confirm
Incident
Resolution
 If core issueis satisfactory resolved,no
additional action isrequired.The IT
Service Desk/Incidentresource
manually closesthe record.
 If not satisfied with the resolution,
record remains in “OPEN” state (or “Re-
Opened”) until issuehas been
remediated.
Caller
Incident
resolution
confirmation
notification by
email
Incident
reopened by
caller
Or
Incidentat the
Resolved state
for
X hours/days
INC 2.5- C Close Incident
SPICEWORKS (System) automatically
closes the incidentif the caller has not
disagreed with the resolution after 3
days.
KACE
(System)
Incidentat
CLOSED state
Closed incident
record and closed
incidentemail
notification

Process Guide
3 PROCESS CONTROL
3.1 KEY PERFORMANCE INDICATORS (KPI)
KPIs are best represented as trend lines and tracked over time. They provide information on the effectiveness of the process and the impact of continuous
improvement efforts.
KPI / Metric Purpose
Percentage of incidents resolved within target time, by
priority.
Measure of how well incidentSLAs areachieved.
Number and percentage of incidents resolved,by priority. Measure of the quality of IT services.
Number and percentage of incidents resolved,by support
level.
Measure of the efficiency of the incidentmanagement process.
Average user/customer survey score. Measure of customer satisfaction with ITservices.
3.2 OPERATIONAL DATA
Active incidents that require visibility, oversight and possible management intervention are best tracked on a dashboard or homepage that is monitored by
the Incident Manager.
Item Purpose
Pie chartof OPEN incidents,by priority. Shows priority distribution of currentworkload with ability to drill into detail records.
Listof all OPEN incidents events (non ServiceRequest) Provides high visibility to major incidentevents in progress.
Listof OPEN incidents thathave breached an SLA. Provides quick view of incidents thatneed immediate attention to prevent further
degradation of resolution time.
Listof incidents reactivated from caller feedback. Provides quick view of incidents thatneed immediate attention to meet resolution target
and customer satisfaction.

Process Guide
APPENDIX A: DOCUMENT CONVENTIONS
Symbol Description
Process start or end point: Represents the starting and ending point of the process.
Process activity or task:Presents an activity or task that needs to be accomplished to produce a specific outcome.
Predefined external process or organization:Indicates a contribution from an external process or organization.
Decision: Indicates that a question needs to be answered in order to identify the following activity or task in the
process. The answers are indicated on the different connectors attached to the decision box. Every answer is
linked to an associated activity or task.
System Action or Function: Indicates that an action is being performed in the system as an output of the previous
activity and an input to the next.
Off-page reference:Indicates a reference to another diagram within the same process. The number of the
referenced diagram is indicated in the shape.
On-page reference:Indicates a link to another activity within the same diagram.
Association: Indicates an association or a relation between the connected, processes, tasks, or activities. May be
represented by a dotted or dashed line.
Sequence flow: Shows the order in which the activities are performed. Represented by a solid line and arrowhead.

Process Guide
APPENDIX B: INCIDENT CATEGORIZATIONS
Incidentcategorization is commonly used to drive assignmentin the incidentmanagement process as well as establish trends (incidenttypes/frequencies) for use in
problem management, supplier management and other ITSM activities.
This method of categorization requires the creator of the incident to manually select the category and subcategory from predefined lists.
It is possibleto automatically categorizeand assign the incidentbased on the Configuration Item (or CI) that is identified in the incidentrecord. With this technique,
the incidentmanagement process inherits thesamecategorization schema as CIs maintained through the configuration management process and the category of an
incidentis automatically determined once the affected CI is identified in the incidentrecord. This technique ensures more accurateand consistentcategorization of
incidents and supports a CI-centric approach to IT service management.].
APPENDIX C: INCIDENT PRIORITIZATIONS
Incidentprioritization typically drives thetimescales associated with the handlingof the incidentand the targeted time to resolution.There are a couple of
methods that can be used to determine priority.
ITIL recommends that PRIORITY be considered a dependent on impactand urgency, where:
 IMPACT is the effect that an incidenthas on business.
 URGENCY is the extent to which the incident's resolution can bear delay.
PRIORITY is generated from urgency and impactaccordingto the followingtable
UrgencyHigh UrgencyMedium UrgencyLow
Impact High Priority 1 Priority 2 Priority 3
Impact Medium Priority 2 Priority 3 Priority 4
Impact Low Priority 3 Priority 4 Priority 5
** It is possible to automatically establish the priority of the incident based on the Configuration Item (or CI) that is identified in the incidentrecord. With this technique,
the business criticality value of the CI is used to determine the priority of the incident. This ensures a more accurate and consistent prioritization of incidents, as the
determination of impact and urgency can be a subjective call.

Process Guide
APPENDIX D: GLOSSARY OF TERMS & ACRONYMS
Terms and acronyms within this document may potentially be unknown or unfamiliar to reviewers, approvers or users of the information.
Term Acronym Description
Alert
A notification thata threshold has been reached, something has changed, or a failurehas occurred.Alerts areoften
created and managed by system management tools and are managed by the event management process.
Assessment
Inspection and analysisto check whether a standard or set of guidelines is beingfollowed, that records areaccurate, or
that efficiency and effectiveness targets are being met.
Attribute
A piece of information abouta configuration item. Examples are name, location,version number, and cost. Attributes
of CIs are recorded in the configuration management database(CMDB).
Back-out
An activity thatrestores a serviceor other configuration itemto a previous baseline.Back-outis used as a form of
remediation when a change or releaseis not successful.
Baseline
(ITIL Continual Service Improvement) (ITIL Service Transition) A snapshotthat is used as a reference point. Many
snapshots may be taken and recorded over time but only some will beused as baselines.For example:
▪ An ITSM baseline can be used as a starting point to measure the effect of a service improvement plan
▪ A performance baseline can be used to measure changes in performance over the lifetime of an IT service
▪ A configuration baselinecan be used as part of a back-out plan to enable the IT infrastructure to be restored to a
known configuration if a change or release fails.
A named group of things that have something in common. Categories are used to group similar things together.
Change The addition,modification,or removal of anythingthat could have an effect on IT services.
Change
Advisory
Board
CAB
A group of people who supportthe assessment,prioritization,authorization,and schedulingof changes.A change
advisory board is usually madeup of representatives from all areaswithin the IT serviceprovider,the business,and
third parties such as suppliers.
Change
Management
CHG
The process responsiblefor controllingthelifecycleof all changes,enablingbeneficial changes to be made with
minimum disruption to IT services.
Change Record
A record containingthe details of a change. Each change record documents the lifecycl eof a singlechange.A change
record is created for every Request For Change (RFC).
Change Request See Request For Change (RFC).

Process Guide
Configuration
Record
CI Record
A record containingthe details of a configuration item. Each configuration record documents the lifecycleof a single
configuration item. Configuration records arestored in a configuration management databaseand maintained as part
of a configuration management system.
Configuration
Type
CI Type
A category that is used to classify configuration items.The CI type identifies the required attributes and relationships
for a configuration record.Common CI types includehardware,document, and user.
Classification
The act of assigninga category to something. Classification isused to ensure consistentmanagement and reporting.
CIs,incidents,problems,and changes areusually classified.
Closed
The final status in the lifecycleof an incident,problem, or change. When the status is closed,no further action is
taken.
Closure The act of changingthe status of an incident,problem, or change to closed.
Configuration
Item
CI
Any component or other serviceassetthat needs to be managed in order to deliver an IT service.Information about
each configuration itemis recorded in a configuration record within the configuration management system and is
maintained throughout its lifecycleby serviceassetand configuration management.
Configuration
Management
Database
CMDB
A databaseused to store configuration records throughouttheir lifecycle.The configuration management system
maintains oneor more CMDBs. Each CMDB stores attributes of CIs and relationships with other CIs.
Configuration
Management
System
CMS
A set of tools,data, and information that is used to supportserviceassetand configuration management. The CMS is
part of an overall serviceknowledge management and includes tools for collecting,storing,managing,updating,
analyzing,and presentingdata aboutall configuration items and their relationships.TheCMS also includesinformation
about incidents,problems,known errors,changes,and releases.Itmay contain data aboutemployees, suppliers,
locations,business units,customers,and users.The CMS is maintained by serviceassetand configuration management
and is used by all ITservicemanagement processes.
Configuration
Record
A record containingthe details of a configuration item. Each configuration record documents the lifecycleof a single
configuration item.
Continual
Service
Improvement
CSI
Ensures that services arealigned with changingbusiness needs by identifyingand implementing improvements to IT
services thatsupport business processes.Theperformance of the IT serviceprovider is continually measured and
improvements are made to processes,ITservices,and IT infrastructurein order to increaseefficiency, effectiveness,
and cost effectiveness.
Customer
Someone who buys goods or services.The customer of an IT serviceprovider is the person or group who defines and
agrees to the servicelevel targets. The term is also sometimes used informally to mean user, for example, ‘This is a
customer-focused organization.’

Process Guide
Diagnosis
A stage in the incidentand problem lifecycles.The purpose of diagnosisisto identify a workaround for an incidentor
the root causeof a problem.
Effectiveness
A measure of whether the objectives of a process,service,or activity have been achieved. An effective process or
activity is onethat achieves its agreed objectives. See also Key Performance Indicator.
Efficiency A measure of whether the right amount of resource has been used to deliver a process,service,or activity.
Emergency
Change
A change that must be introduced as soon as possible,for example to resolve a major incidentor implement a security
patch. The change management process normally has a specific procedurefor handlingemergency changes.
Employee Self
Service
ESS
A module in ServiceNow that allows users to make requests, view articles,logincidents,and search the knowledge
basethrough a user-friendly website called the Employee Self-Service Portal (ESS Portal).
Event
A change of state that has significancefor the management of an IT serviceor other configuration item. The term is
also used to mean an alertor notification created by any IT service, configuration item,or monitoringtool.
Impact
A measure of the effect of an incident, problem, or change on business processes.Impactis often based on how
servicelevels will beaffected. Impact and urgency are used to assign priority.
Incident
An unplanned interruption to an IT serviceor reduction in the quality of an IT service.Failureof a configuration item
that has not yet affected serviceis also an incident.
Key
Performance
Indicator
KPI
A metric that is used to help manage an IT service, process,plan,project,or other activity.Many metrics may be
measured, but only the most importantof these aredefined as key performance indicatorsand used to actively
manage and report on the process,IT service,or activity.They should be selected to ensure that efficiency,
effectiveness, and costeffectiveness are all managed.
Known Error KE
A problem that has a documented root causeand a workaround. Known errors arecreated and managed throughout
their lifecycleby problem management. Development groups or suppliers may also identify known errors.
Major Incident The highest category of impactfor an incident.A major incidentresults in significantdisruption to the business.
Metric Something that is measured and reported to help manage a process,ITservice, or activity.
Policy
Formally documented management expectations and intentions.Policies areused to direct decisions and to ensure
consistentdevelopment and implementation of processes,standards,roles,activities,ITinfrastructure,and so on.
Post-
implementation
Review
PIR
A review that takes placeafter a change or a project has been implemented. It determines if the change or projectwas
successful and identifiesopportunities for improvement.
Priority
A category used to identify the relativeimportanceof an incident,problem, or change. Priority is based on impactand
urgency, and is used to identify required times for actions to be taken. For example, the SLA may state that priority 2
incidents mustbe resolved within 12 hours.

Process Guide
Problem
A causeof one or more incidents.The causeis not usually known at the time a problem record is created. The problem
management process is responsiblefor further investigation.
RACI RACI
A model used to help define roles and responsibilities.RACI stands for responsible,accountable,consulted,and
informed.
Release
One or more changes to in IT servicethat are built,tested, and deployed together. A singlereleasemay include
changes to hardware,software, documentation, process,and other components.
Request For
Change (RFC).
RFC
A formal detailed proposal for a changeto be made. The term is often misused to mean change record or the change
itself.
Restore
Takingaction to return an IT serviceto the users after repair and recovery from an incident.This is the primary
objective of incidentmanagement
Risk
A possibleevent that could causeharm or loss or affect the ability to achieveobjectives.A risk is measured by the
probability of a threat, the vulnerability of the assetto that threat, and the impactitwould have if it occurred.
Role
A set of responsibilities,activities,and authorities assigned to a person or team. A roleis defined in a process or
function. One person or team may have multipleroles.For example, a singleperson may carry out the roleof
configuration manager and change manager.
Root Cause The underlyingor original causeof an incidentor problem.
Root Cause
Analysis
RCA
An activity thatidentifies the root causeof an incidentor problem. Root causeanalysistypically concentrates on IT
infrastructurefailures.
Service
A means of deliveringvalueto customers by facilitatingthe outcomes customers want to achievewithout the
ownership of specific costs and risks.
Service Desk
The singlepointof contact between the serviceprovider and the users. A typical servicedesk manages incidents and
servicerequests, and also handles communication with the users.
Service Level Measured and reported achievement againstoneor more servicelevel targets.
Service Level
Agreement
SLA
An agreement between an IT serviceprovider and a customer. A servicelevel agreement describes the ITservice;
documents servicelevel targets, and specifies the responsibilities of the IT serviceprovider and the customer.
Service Request
A formal request from a user for something to be provided, for example, a request for information or advice;to reset a
password;or to install a workstation for a new user.

Process Guide
Stakeholder
A person who has an interest in an organization,project,or IT service.Stakeholders may be interested in the activities,
targets, resources,or deliverables.Stakeholders may includecustomers, partners,employees, shareholders,owners,
or others.
User
A person who uses the IT serviceon a day-to-day basis.Users aredistinctfromcustomers,as some customers do not
use the IT servicedirectly.
Workaround
Reducing or eliminatingtheimpact of an incidentor problem for which a full resolution is not yet available,for
example, by restartinga failed configuration item.Workarounds for problems are documented in known error records.
Workarounds for incidents thatdo not have associated problemrecords are documented in the incidentrecord.
Source: ITIL® glossary and abbreviations
© Crown copyright 2011.All rights reserved.
ITIL® is a registered trade mark of the Cabinet Office
Management v3.0
© 2016. All rights reserved.
This publication contains proprietary information not to be distributed outside of Wedgewood, INC. This document, in whole or in
part, must not be reproduced in any form without the express written permission of Wedgewood, INC.
SERVICE DESK INCIDENT MGMT PROCESS GUIDE
(IMPG v3.0)

Incident Mgmt Process Guideand Standards

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Incident Mgmt Process Guideand Standards

Similar a Incident Mgmt Process Guideand Standards (20)

Incident Mgmt Process Guideand Standards