IMPLEMENT E2E INCIDENT MANAGEMENT WITH SERVICENOW STANDARD OPERATING PROCEDURE | VERSION 1.0
SERVICENOW IMPLEMENTATION PROJECT BUSINESS PROCESS IMPROVEMENT
AL MAHA CONSULTING LTD.
NOVEMBER 7, 2019
Exported From: End-to-End Incident Management with ServiceNow BPMN Diagram
Title 13.1.2 Implement E2E Incident Management with ServiceNow
Author Maha Abu Ghoush | External BPI Consultant
Created 2019-07-30
Last Modified 2019-08-07
Level 1 Category 13.0 IT Operations
Level 2 Process Group 13.1 IT Operations Global Processes
Process Owner Director, IT Operations
Pillar / Workstream D – Technology
Pillar Owner Chief Information Officer (CIO)
Stakeholders Service Desk (IT Ops, IT Admin, Security, Tech Support), Caller – External Clients (Members & Service Providers), Internal Clients (All COMPANY BUs), Automated Tools) – Assigned Groups (1st, 2nd and 3rd Level Support Teams from Tech Support, IT Ops, IT Admin, Security, Architecture and Development)
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 1 www.almahaconsulting.ca
Contents Implementing E2E Incident Management with ServiceNow ................................................................. 4
What is Incident Management? ............................................................................................................ 4
Objectives of the Business Process ..................................................................................................... 4
The Scope .......................................................................................................................................... 5
Key Definitions .................................................................................................................................. 6
Regulatory, Risk and Legal References ................................................................................................ 7
Business Rules ................................................................................................................................... 8
Creating incident tickets ........................................................................................................................ 8
ServiceNow Self-Service Portal ......................................................................................................... 8
ServiceNow Incident Module ........................................................................................................... 8
Incident Management Lifecycle ............................................................................................................ 8
New .................................................................................................................................................. 8
In Progress ...................................................................................................................................... 10
On Hold .......................................................................................................................................... 11
Resolved ......................................................................................................................................... 12
Closed ............................................................................................................................................. 12
Canceled ......................................................................................................................................... 13
Incident Assignment ............................................................................................................................ 13
Incident Notifications .......................................................................................................................... 13
Roles and Responsibilities ................................................................................................................ 15
Caller .............................................................................................................................................. 15
Service Desk (1st Line Support) ...................................................................................................... 15
Assignment Group (1st, 2nd and 3rd Line Support) ....................................................................... 15
Incident Management Process Owner ........................................................................................... 16
Authority Matrix (RACI) .................................................................................................................... 17
Implement E2E Incident Management with ServiceNow ................................................................... 19
13.1.2.1 Create new incident via Self Service Portal ........................................................................... 20
13.1.2.2 Create new incident via Incident module ............................................................................. 20
13.1.2.3 Send confirmation to Caller that new incident ticket is created .......................................... 20
13.1.2.4 Notify Service Desk that new incident ticket is created ........................................................ 20
13.1.2.5 Send confirmation to Service Desk that new incident ticket is created ............................... 21
13.1.2.6 Review and verify Caller information .................................................................................... 21
13.1.2.7 Set incident state to “Canceled” ........................................................................................... 21
13.1.2.8 Send notification that incident is canceled ........................................................................... 21
13.1.2.9 Categorize incident ............................................................................................................... 21
13.1.2.10 Prioritize incident ................................................................................................................ 21
13.1.2.11 Set “Assignment Group” and “Assigned To” to most appropriate ..................................... 22
13.1.2.12 Send notification that incident is assigned ......................................................................... 22
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 2 www.almahaconsulting.ca
13.1.2.13 Review incident and confirm it is assigned correctly .......................................................... 22
13.1.2.14 Investigate potential causes ................................................................................................ 22
13.1.2.15 Update incident with latest progress and findings ............................................................. 22
13.1.2.16 Reassign to 2nd or 3rd line support ....................................................................................... 23
13.1.2.17 Set incident state to “Canceled” ......................................................................................... 23
13.1.2.18 Set incident state to “On Hold – Awaiting Caller” ............................................................... 23
13.1.2.19 Set incident state to On Hold – “Awaiting Vendor” ............................................................ 23
13.1.2.20 Set incident state to On Hold – “Awaiting Change” ............................................................ 23
13.1.2.21 Set incident state to On Hold – “Awaiting Problem” .......................................................... 23
13.1.2.22 Apply and test fix/workaround and confirm resolution ..................................................... 23
13.1.2.23 Notify “Work notes list” and “Watch list” of updates ........................................................ 24
13.1.2.24 Review incident ticket’s latest updates ............................................................................... 24
13.1.2.25 Update incident ticket with additional info ........................................................................ 24
13.1.2.26 Check that incident is resolved ........................................................................................... 24
13.1.2.27 Update incident ticket with resolution outcome ................................................................ 24
13.1.2.28 Set incident state to “Resolved” ......................................................................................... 24
13.1.2.29 Provide Resolution Information .......................................................................................... 25
13.1.2.30 Send notification that incident is resolved ......................................................................... 25
13.1.2.31 Click email link to enable ServiceNow to close the ticket ................................................... 25
13.1.2.32 Set incident state to “Closed” ............................................................................................. 25
13.1.2.33 Send notification that incident is closed ............................................................................. 25
Process Measures (KPI’s) .................................................................................................................. 26
Reports for Management ................................................................................................................. 28
List of Supporting Documents ........................................................................................................... 29
Process Improvement Recommendations ......................................................................................... 30
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 3 www.almahaconsulting.ca
Revision History VN Date Remarks Authored / Revised By Role
V0.1 11/07/2019 1st draft of the Implement E2E Incident Management with ServiceNow process | STANDARD OPERATING PROCEDURE.
Maha Abu Ghoush CONSULTANT
•
Contribution/Review List Name of person who reviewed and/or contributed to the deliverable
Role Contribution / Review Date:
Director, IT Operations 7 November 2019
Chief Information Officer (CIO) | Process Sponsor 7 November 2019
ServiceNow Administrator/Developer 7 November 2019
Senior Operations Support Analyst 7 November 2019
Business Analyst 7 November 2019
Technical Support Manager 7 November 2019
IT Admin Manager 7 November 2019
Approvals Name Role Original Approval Date:
Director, IT Operations | Process Owner 7 November 2019
Chief Information Officer (CIO) | Process Sponsor 7 November 2019
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 4 www.almahaconsulting.ca
Implementing E2E Incident Management with ServiceNow
What is Incident Management? Incident management is a defined process for logging, managing and resolving incidents. The goal of
incident management is to restore normal service operation as quickly as possible, while minimizing
impact to business operations and ensuring quality is maintained.
The Implement E2E Incident Management with ServiceNow process provides a detailed delineation and
breakdown of all activities involved in managing a standard incident (with assigned Priority 3 or 4) using
ServiceNow Incident Management system to maintain the best possible levels of service quality and
availability. This includes:
• Identify and log incidents
• Categorize and prioritize incidents—by determining impact and urgency
• Assign incidents to appropriate groups for troubleshooting and resolution
• Escalate (reassign) incidents as necessary for further investigation and resolution
• Resolve and close incidents
• Provide integration and interfaces with related processes
ServiceNow includes an audit trail that records an incident and tracks it until service is restored and the
incident is resolved and closed.
Objectives of the Business Process The Implement E2E Incident Management with ServiceNow process is designed to assist IT teams in
managing all aspects of the standard incident lifecycle, including efficient and prompt incident response,
analysis, documentation, management, and reporting. Specifically:
• Log and diagnose incidents
• Resolve incidents through resolution procedures, playbooks and known errors
• Define when incidents require further investigation and escalation
• Document and communicate incident updates throughout the incident lifecycle
• Integrate other processes with incident management
The Implement E2E Incident Management with ServiceNow process dramatically increases the
opportunity for customer service and satisfaction by reducing service downtime, reducing Incident
impact to business, aligning IT to business priority and increasing efficiency and staff productivity. This
includes defining clear decision gateways at various stages of the process implementation and
establishing clear communication channels and timelines.
Implement E2E Incident Management with ServiceNow process assists all process stakeholders in
understanding their respective roles and responsibilities within each phase of process implementation
through increased visibility and communication of incidents, which provides the foundational steps
towards facilitating and promoting a performance culture at the company.
Where improvement opportunities have been identified, these were recorded as either Key Business
Process Improvements (BPI) or Longer Term (LT) Improvement Opportunities.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 5 www.almahaconsulting.ca
The Scope The Implement E2E Incident Management with ServiceNow process applies to all Incidents that have
been assigned a Priority Level 3 and 4. The process includes the activities followed for:
• Identifying and reporting standard incidents through:
– automated tools (event monitoring and security)
– external client reporting (COMPANY’s members and service providers)
– internal client reporting (any COMPANY end-user)
• Logging, categorizing, prioritizing and assigning incidents to assignment groups and individuals.
• Diagnosing, investigating and resolving incidents, using:
– Defined resolution procedures and playbooks
– Known errors identified through problem management
– Potential errors identified from recent IT Changes
– New resolution activities identified through diagnosis and investigation
• Identifying incidents and groups of incidents that require further analysis through the problem
management process (“13.2.2 Define and execute problem management”) to eliminate them or to
reduce their resolution times.
• Identifying incidents and groups of incidents that require IT change through the “13.2.3 Define and
execute IT Change management” process.
• Documenting and communicating incident updates throughout the incident lifecycle, from incident
creation to incident resolution and closure.
For each of the process activities listed in the process, the process highlights who is responsible for
performing the activity, how the activity should be completed and the required documentation.
The Implement E2E Incident Management with ServiceNow interfaces with the following related
processes:
• 13.2.1 Define and execute major incident management
• 13.2.2 Define and execute problem management
• 13.2.3 Define and execute IT Change management
• 13.2.8 Define and execute knowledge management (KM)
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 6 www.almahaconsulting.ca
Key Definitions TERM MEANING • Standard Incident • Unplanned interruption to an IT service.
• Reduction in the quality of an IT service. • Failure of a configuration item (CI) that has not yet impacted an IT
service. – Example: Redundant component failure
• Assigned Priority Level 3 and 4. • Major Incident • An incident that results in significant disruption to the business and
demands a response beyond the standard incident management process.
• Assigned Priority Level 1 and 2. • Handled through the “13.2.1 Define and execute major incident
management” process.
• Workaround • It is not a permanent solution but something that is used to get the service up and running until the real (permanent) solution is found.
• Normal Service Operation • An operational state where services and configuration items (CIs) are performing within agreed service and operational levels.
• Service Request • Formal request for something to be provided. – Examples: request for information or advice; to reset a
password; or to install a workstation for a new user
• Does NOT lead to a disruption to the agreed service. • Handled through the “Manage service requests” process, which
manages the lifecycle of service requests. • Problem Management • A systematic approach to identifying the cause of an error in the IT
infrastructure, reported as occurrences of related incidents. • Handled through the “13.2.2 Define and execute problem
management” process.
• IT Change Management • A systematic approach to controlling the lifecycle of all IT changes. • Handled through the “13.2.3 Define and execute IT Change
management” process.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 7 www.almahaconsulting.ca
Regulatory, Risk and Legal References [Enter the applicable regulatory, risk and legal references here].
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 8 www.almahaconsulting.ca
Business Rules This summary highlights the business rules relevant to the implementation of the Implement E2E
Incident Management with ServiceNow business process:
Creating incident tickets Incidents are created through the following two channels:
SERVICENOW SELF-SERVICE PORTAL
• COMPANY end-users can make use of the Self-Service Portal to create an incident ticket. The Self-
Service Portal uses a record producer to generate an incident record rather than exposing the full
incident form to users.
NOTE: Incidents identified through walk-ups must be logged as a new incident via the Self-Service Portal.
SERVICENOW INCIDENT MODULE
• The Service Desk can create an incident directly in ServiceNow Incident Module as a result of a
reported incident by an external client (COMPANY member or service provider) via the Case
Management System (CSM) or by an automated tool (event monitoring and security automated
systems).
NOTE: Service Desk can create a child incident if it is the same type of incident that occurred for more
than one client.
Incident Management Lifecycle The incident has SIX states throughout its lifecycle. The states in ServiceNow indicate where an incident
currently resides in the process and display the incident progress. States represent a unique phase in the
incident management process where a specific set of related activities are grouped together and
designed to achieve a particular outcome in order to move to the next phase of the process
implementation. The SIX states are:
• New
• In Progress
• On Hold
• Resolved
• Closed
• Canceled
NEW
When an incident is first created, it is automatically assigned the “New” state. In this state, the Service
Desk or end-user creates the incident ticket and captures all known information about the incident.
Capturing all required and relevant details at this stage is very important as it helps with diagnosis and
with determining if the incident requires escalation.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 9 www.almahaconsulting.ca
If the incident is created via the Incident Module, the following mandatory fields must be completed:
FIELD ATTRIBUTES • Caller • Automatically populated with the name of the person who created the ticket.
• Category • Dropdown field that includes a list of predefined categories that identify what the incident is impacting. For example, an incident might be categorized as “network”.
• Sub-Category • Dropdown field that includes a list of predefined sub-categories based on the selected Category. For example, if an incident is categorized as “network”, a sub-category can be “network outage”.
• Environment • Drop-down field that lists the environments such as Prod, QA, UAT, etc.
• Business service • Reference field that allows the person creating the ticket to choose which business service is impacted.
• Short description • Free-text field that allows entering a short description of the incident.
• Description • Free-text field that allows entering a description of the incident. If the incident is created by the Service Desk, then this field should include a record of the incident as provided by the Caller’s own words so they can use those terms again as they work with the Caller.
• Contact type • Dropdown field that includes how the incident was reported – phone, email, etc.
• State • Dropdown field that includes SIX states: New, In Progress, On Hold, Resolved, Closed, Canceled.
• Impact • Dropdown field that includes THREE values: High, Medium, Low. Impact determines the effect that an incident has on business.
• Urgency • Dropdown field that includes THREE values: High, Medium, Low. Urgency determines the extent to which the incident's resolution can bear delay.
• Priority • Incident prioritization typically drives the schedule of the incident through its resolution. This will impact the service level agreements (SLAs)1 and the operational-level agreements (OLAs)2 associated with the incident.
• Priority is automatically calculated from the Impact and Urgency fields according to the following table:
1 – High 2 – Medium 3 – Low
PRIORITY PRIORITY PRIORITY
1 – High 1 – Critical 2 – high 3 – Medium
2 – Medium 2 – high 3 – Medium 4 – Low
3 – Low 3 – Medium 4 – Low 4 – Low
• If Priority is assigned a 1 or 2 calculation, the incident will be promoted to a Major Incident. In which case, the incident will be handled through the “13.2.1 Define and execute major incident management” process3.
• Assignment group • The IT team assigned to work on the incident.
1 Currently, no SLAs are associated with the incident management process. 2 OLAs are internally established and are not communicated to COMPANY’s clients (members and service providers). 3 Manually promoting an incident to a Major Incident opens a dashboard panel, which has its own reports running. This does
NOT create a new incident ticket. The standard incident ticket remains open and the Priority and other incident details stay unchanged. The Assigned IT Team continues to manage the incident from the standard incident ticket and manually changes the Priority to reflect the established SLAs / OLAs.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 10 www.almahaconsulting.ca
If the incident is created through the Self-Service Portal, the end-user only needs to complete the
following fields since they are unlikely to know or understand most of the remaining fields in the
incident form:
• Short description
• Description
• Category
• Sub-Category
The Service Desk then reviews the information provided and supplements it with further details. The
“Category” and “Sub-Category” fields determine who is the assigned group / IT Team. The Service Desk
may change the Category/Sub-Category entries that were selected by the Caller if those were deemed
incorrect.
IN PROGRESS
• During the “In Progress” state, someone is working on the incident. This state covers a large and
varied number of activities that are required in order to resolve the incident.
• The person assigned the incident begins by investigating and triaging to establish the incident’s
cause and how to fix it. To help them resolve the issue, they can:
– Refer to similar incidents and problem records. This would interface with the “13.2.2 Define
and execute problem management” process.
– Search recent IT changes for any potential causes. This would interface with the “13.2.3 Define
and execute IT Change management” process.
• During this investigation and triage, the assignee may discover that there is a better-suited group or
individual to address the incident. If so, they'll reassign the incident. To do this, they'll update the
“Assignment group” and “Assigned to” fields. This could involve passing the incident to second or
third-line IT Teams/SMEs. The new assignees receive an email notification to make them aware
they are now responsible for the incident.
An incident could be reassigned multiple times while it’s in the “In Progress" state since multiple
different teams may need to be involved. When reassigning an incident, the “Work notes” field is
mandatory because it explains why the incident is being assigned to the new group or individual
and what is expected of them.
NOTE: Reassigning an incident will not reset the OLAs/SLAs attached to the incident unless the OLA/SLA
is specifically tracking reassignment only. Therefore, if an OLA or SLA only has one hour remaining before
it breaches and is reassigned to a new team, that team still has only one hour.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 11 www.almahaconsulting.ca
• If the incident was created via the Self-Service portal, both the “Work notes” and the “Comments”
sections are used to communicate back with the Caller and other incident stakeholders. Updates to
these fields can be automatically sent to the Caller by adding the Caller’s name—as well as any
other pertinent stakeholder—to the “Work notes list” and “Watch list” respectively. This saves the
IT staff from having to update Callers and other incident stakeholders and the Callers / incident
stakeholders from having to chase down updates.
• When a fix is identified by the investigation, the individual assigned to the incident will apply the fix
to resolve the incident. The fix may be a permanent solution or a temporary workaround—either is
acceptable if it solves the incident at that time.
• The identified fix could be from:
– Diagnostic steps undertaken by the individual working on the incident
– Vendor support feedback
– A known error or JIRA bug fix
– Existing IT change to be implemented
The first three activities may result in needing to raise an IT change to resolve the incident. This
interfaces with the “13.2.3 Define and execute IT Change management” process.
• Once the fix or workaround is applied, the assignees test the fix to see if it resolves the incident. If
they believe it does, they request resolution confirmation from the Caller by updating the “Work
notes” and “Comments” fields accordingly.
ON HOLD
• The “On Hold” state is used to indicate when an incident isn’t resolved yet and work on it is
temporarily paused while the person assigned the incident waits for another group or person to
take some action.
• When the assignees change the incident’s state to “On Hold”, the “On hold reason” dropdown field
becomes mandatory and provides the following choices:
– Awaiting Caller
– Awaiting Change
– Awaiting Problem
– Awaiting Vendor
• Once the incident ticket is put on hold, ServiceNow sends email notification to the Caller and the
assignee. The notification includes the incident details with the subject line: Ticket put on hold.
NOTE: Putting something on hold (such as Awaiting Caller) typically acts as the pause condition for all
SLAs/OLAs.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 12 www.almahaconsulting.ca
RESOLVED
• An incident is considered resolved when restoration to normal service operation is obtained, after
receiving confirmation from the Caller that incident is resolved.
• The assignee sets the incident state to “Resolved”. In which case, the “Resolution Information”
section becomes mandatory. This section includes both mandatory and optional fields that provide
some further details, which explain what the problem was and how it was fixed. Some of the key
fields include:
– Resolution Code: A mandatory dropdown field that contains a list of choices focused on the
nature of the resolution provided, for example, whether it was a workaround or a permanent
fix. These choices are not intended to explain how the incident was resolved.
– Resolution Notes: A mandatory free-text field where the assignee can describe the incident
and how it was resolved.
– Knowledge: An optional checkbox. Clicking this checkbox will allow the creation of an incident
knowledgebase record. This will interface with the “13.2.8 Define and execute knowledge
management (KM)” process.
• During the “Resolved” state, the assignee can also raise a new problem or relate the incident to an
existing problem. This interfaces with the “13.2.2 Define and execute problem management”
process.
• Once the resolution information is provided, the Caller and the assignee receive email notification
that the incident is resolved. The Caller’s email notification includes a request to click on a link that
will enable ServiceNow to close the ticket automatically.
• If the Caller does not click on the link in the email, the incident remains in the “Resolved” state for
FIVE (5) calendar days, after which the “State” field automatically updates to “Closed”.
NOTE: If the Caller discovers that the incident is not resolved—after having confirmed that it was—while
the incident is still in the “Resolved” state, the Caller must explain why they believe the incident is not yet
resolved. In which case, the state for the incident returns to “In Progress” and clears the “Resolution
code” and “Resolution notes” fields. The person assigned the incident receives a notification containing
the Caller’s additional comments.
CLOSED
• No activities take place in the “Closed” state. Should the incident reoccur, a new ticket must be
raised.
• Once an incident is closed, it cannot be reopened. It also becomes read-only, i.e., it cannot be
edited or deleted. In addition, the associated SLAs / OLAs typically stop in this state.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 13 www.almahaconsulting.ca
CANCELED
• There are very few scenarios when an incident is genuinely canceled. This typically occurs when an
incident was raised in error—usually prematurely, before realizing there is no real issue.
NOTE: If a Caller creates an incident ticket but the incident is resolved before the IT team is assigned, the
Caller will add a note accordingly. The IT Team will then change the incident state from “Resolved” to
either “Closed” or “Canceled”.
• If an incident ticket has been created, but a service request is determined instead, Service Desk
raises a new Service Request—interfacing with the “Manage service requests” process—and sets
the incident state to “Canceled”.
• If more than one ticket was created for the same incident, the IT Team cancels the duplicate
incident and includes a note to explain the reason for the cancelation.
Incident Assignment • The incident is assigned to the respective IT Team based on the selected Category” and “Sub-
Category” fields of the incident form during the “New” state. Service Desk reviews incident details
and confirms that the incident is assigned correctly or reassigns the incident ticket to the proper IT
Team (Assignment Group), if applicable.
– If the Service Desk needs to investigate and perform triage on the incident, that occurs during
the “In Progress” state. At this point, they assign the incident to themselves using the
“Assigned to” field, which automatically sets the “State” field to “In Progress”.
• The assignment group reviews the incident that shows up in their work list and assigns it to one
person using the “Assigned to” field, which automatically sets the “State” field to “In Progress”.
This stops the clock on any response SLAs and OLAs that are running since changing the state to “In
Progress” means someone is responding to the incident.
NOTE: Populating the “Assigned to” field will automatically change the incident’s state from “New” to
“In Progress”. Otherwise, if an individual is not assigned, anyone with access to the incident ticket can
manually change the state to "In Progress".
Incident Notifications • ServiceNow sends email notifications on the incident state to both the Caller and the assignee.
NOTE: For externally reported incidents, Tech Support logs the ticket and notifies the external client of
the incident creation and state changes manually—outside of ServiceNow.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 14 www.almahaconsulting.ca
• If the individual who creates the ticket is also the assignee, then ServiceNow sends two
notifications, one to confirm that the incident was created and another as an assignment
notification. The assignment notification email contains a link, which takes the assignee directly to
the incident ticket.
• Email notifications to the Caller and the assignee—including individuals added to the “Work notes
list” and the “Watch list” fields—are sent on the following incident state changes:
– New
– On Hold
– Resolved
– Closed
– Canceled
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 15 www.almahaconsulting.ca
Roles and Responsibilities CALLER
The Caller is the person being impacted by degradation to a service or someone who has discovered an
impact or potential impact to a service. A Caller could be an internal client—i.e., any COMPANY end-user
/ staff member—or an external client—i.e., a COMPANY member or service provider. Alternatively, if
the issue has been discovered automatically through an automated system (event monitoring or
security system), the Caller may be captured against that system.
Responsibilities
• Log incidents through ServiceNow Self-Service Portal (if the Caller is a COMPANY end-user).
• Report incidents to the Service Desk (if the Caller is an external client or automated tool).
• Participate in the implementation of a solution or workaround.
• Confirm that the IT Team has successfully resolved the incident.
NOTE: External Clients confirm incident resolution to Tech Support, who records that in the “Work notes”
field of the incident form.
SERVICE DESK (1ST LINE SUPPORT)
This is a role that is shared by several IT Teams including Tech Support, IT Admin, Security Services, and
IT Ops.
The Service Desk acts as the 1st line IT support and attempts to deal with as many incidents as possible
themselves at the time they receive the incident (called a first-call or initial-contact resolution). Ideally,
they want to solve the Caller’s issue immediately without involving other support teams and without the
Caller having to contact them a second time.
Responsibilities
• Log incidents through ServiceNow Incident Module.
• Categorize and prioritize incidents.
• Set “Assignment group” and “Assigned to” fields to the most appropriate IT Team and individual.
NOTE: If the Service Desk needs to investigate and perform triage on the incident, then they assign the
incident to themselves using “Assignment group” and “Assigned to” fields respectively.
ASSIGNMENT GROUP (1ST, 2ND AND 3RD LINE SUPPORT)
This is a role that is shared by several IT Teams including Tech Support, IT Admin, Security Services, IT
Ops, Architecture and Development and represents 1st, 2nd, and 3rd line IT Teams.
Typically, Service Desk, as 1st line support, assigns the incident to themselves from the Assignment
group” and “Assigned to” fields respectively to diagnose and investigate the incident and provide
solutions and workarounds from standard operating procedures, playbooks and existing known errors.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 16 www.almahaconsulting.ca
If the Service Desk team is unable to resolve incidents on their own, the incident must then be
reassigned (escalated) to 2nd or 3rd line support IT Teams, as appropriate. The incident could also be
referred to an external 3rd party vendor, after all internal IT Teams have failed to resolve the incident.
Responsibilities
• Investigate and diagnose incidents as 1st, 2nd and 3rd line support.
• Develop workarounds.
• Resolve and recover assigned incidents.
NOTE: This role is engaged in the process when the “Assignment group” and “Assigned to” fields are set
to reflect the appropriate IT support group and individual respectively.
INCIDENT MANAGEMENT PROCESS OWNER
The incident management process owner’s primary objective is to own and maintain the incident
management process. The process owner role is filled by the Director, IT Operations with the authority
to ensure all stakeholders roll out and use the process.
Responsibilities
• Define the overall mission of the process.
• Establish and communicate the process’s mission, goals, objectives, and scope to all stakeholders.
• Document and maintain the process (BPMN diagram and Standard Operating Procedure).
• Resolve any cross-functional (departmental) issues.
• Ensure proper staffing and training for execution.
• Direct the incident management roles.
• Ensure consistent execution of the process across COMPANY.
• Monitor, measure, and report on the effectiveness of the process to senior management.
• Continually improve the process.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 17
www.almahaconsulting.ca
Authority Matrix (RACI)
4 Tasks highlighted in Green are automated tasks.
PILLAR / WORKSTREAM Technology and Operations Services
Cal
ler
Serv
iceN
ow
4
Serv
ice
Des
k (1
st L
ine
Sup
po
rt)
Ass
ign
men
t G
rou
p
(1st
, 2n
d a
nd
3rd
Lin
e Su
pp
ort
)
LEVEL 1 – CATEGORY 13.0 IT Operations
LEVEL 2 – PROCESS GROUP 13.1 IT Operations Global Processes
LEVEL 3 – PROCESS NAME Implement E2E Incident Management with ServiceNow
PROCESS REFERENCE 13.1.2
VERSION VERSION 1.0
R – Responsible Person who performs an activity or does the work
A – Accountable Person who is ultimately accountable and has Yes/No/Veto
C – Consulted Person who needs to provide input to the activity
I – Informed Person who needs to know of the decision or action
Reference Process Step / Activity
Implement E2E Incident Management with ServiceNow | STANDARD OPERATING PROCEDURE 13.1.2.1 Create new incident via Self Service Portal A 13.1.2.2 Create new incident via Incident module A 13.1.2.3 Send confirmation to Caller that new incident ticket is created R 13.1.2.4 Notify Service Desk that new incident ticket is created R 13.1.2.5 Send confirmation to Service Desk that new incident ticket is created R 13.1.2.6 Review and verify Caller information R 13.1.2.7 Set incident state to “Canceled” A 13.1.2.8 Send notification that incident is canceled R 13.1.2.9 Categorize incident R
13.1.2.10 Prioritize incident R 13.1.2.11 Set “Assignment Group” and “Assigned To” to most appropriate R 13.1.2.12 Send notification that incident is assigned R 13.1.2.13 Review incident and confirm it is assigned correctly R 13.1.2.14 Investigate potential causes R 13.1.2.15 Update incident with latest progress and findings A
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 18
www.almahaconsulting.ca
PILLAR / WORKSTREAM D – Technology
Cal
ler
Serv
iceN
ow
Serv
ice
Des
k (1
st L
ine
Sup
po
rt)
Ass
ign
men
t G
rou
p
(1st
, 2n
d a
nd
3rd
Lin
e Su
pp
ort
)
LEVEL 1 – CATEGORY 13.0 IT Operations
LEVEL 2 – PROCESS GROUP 13.1 IT Operations Global Processes
LEVEL 3 – PROCESS NAME Implement E2E Incident Management with ServiceNow
PROCESS REFERENCE 13.1.2
VERSION VERSION 1.0
R – Responsible Person who performs an activity or does the work
A – Accountable Person who is ultimately accountable and has Yes/No/Veto
C – Consulted Person who needs to provide input to the activity
I – Informed Person who needs to know of the decision or action
Reference Process Step / Activity
Implement E2E Incident Management with ServiceNow | STANDARD OPERATING PROCEDURE 13.1.2.16 Reassign to 2nd or 3rd line support R 13.1.2.17 Set incident state to “Canceled” A 13.1.2.18 Set incident state to “On Hold – Awaiting Caller” R 13.1.2.19 Set incident state to On Hold – “Awaiting Vendor” R 13.1.2.20 Set incident state to On Hold – “Awaiting Change” R 13.1.2.21 Set incident state to On Hold – “Awaiting Problem” R 13.1.2.22 Apply and test fix/workaround and confirm resolution A 13.1.2.23 Notify “Work notes list” and “Watch list” of updates R 13.1.2.24 Review incident ticket’s latest updates R 13.1.2.25 Update incident ticket with additional info R 13.1.2.26 Check that incident is resolved A 13.1.2.27 Update incident ticket with resolution outcome A 13.1.2.28 Set incident state to “Resolved” A 13.1.2.29 Provide Resolution Information A 13.1.2.30 Send notification that incident is resolved R 13.1.2.31 Click email link to enable ServiceNow to close the incident R 13.1.2.32 Set incident state to “Closed” R 13.1.2.33 Send notification that incident is closed R
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 19 www.almahaconsulting.ca
Implement E2E Incident Management with ServiceNow
The Implement E2E Incident Management with ServiceNow process includes the steps involved in
identifying, logging, categorizing, prioritizing, triaging and resolving incidents with assigned Priority Level
3 or 4 using ServiceNow application. Incidents with Priority Levels 1 and 2 are handled through the
“13.2.1 Define and Execute Major Incident Management”.
The goal of incident management is to restore normal service operation as quickly as possible, while
minimizing impact to business operations and ensuring quality is maintained. An incident can be
identified and reported by a Caller: (1) an external client via the case management system – CSM, or (2)
automated tools. Internally reported incidents – i.e., where the Caller is a COMPANY end-user / staff
member – should be logged using ServiceNow self-service portal. Incidents that are reported by external
clients or automated tools are logged by the ServiceDesk (a role that is shared by Tech Support, IT
Admin, Security Services and IT Ops) using ServiceNow Incident Module.
When a new incident is created, ServiceNow sends email notifications to the Caller (COMPANY end-user
who logged the ticket) as well as the assignee (IT team and individual assigned to fix the incident). The
incident state is set to “New”.
Once the incident has been logged, categorized, prioritized and assigned, the Assigned Group—
consisting of 1st, 2nd and 3rd line support IT Teams from Tech Support, IT Admin, Security Services, IT Ops,
Architecture and Development —including the assigned individual—performs diagnosis and
investigation and develops workarounds and fixes to resolve and recover the incident. The incident now
moves to the “In Progress” state. The Assigned Group continues to update the “Work notes” field of the
incident form with the latest progress and findings. Also, If the incident was created via the Self-Service
portal, both the “Work notes” and the “Comments” sections are used to communicate back with the
Caller.
An incident could be reassigned multiple times while it’s still in the “In Progress” state since different
teams may need to be involved. The new assignees receive email notification to make them aware they
are now responsible for the incident.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 20 www.almahaconsulting.ca
Once the necessary steps to fix the incident have been performed, the process moves to resolution and
recovery. This involves communicating and confirming the incident resolution with the internal and/or
external client, after which, the Assigned Group sets the incident state to “Resolved” and provides the
required Resolution Information. ServiceNow then sends an email notification to the Caller and the
assignee confirming that the incident is now resolved. The Caller’s email copy includes a request to close
the ticket by clicking on a link in the email, which enables ServiceNow to close the ticket.
If the Caller does not click on the link in the email, the incident remains in the “Resolved” state for FIVE
(5) calendar days, after which the “State” field automatically updates to “Closed”.
While the incident is still in the “Resolved” state, an incident knowledgebase record can be created. This
interfaces with the “13.2.8 Define and execute knowledge management (KM)” process. A new problem
can also be created and root cause analysis (RCA) performed via the “13.2.2 Define and execute problem
management” process. If an IT change is required, then this is done by interfacing with the “13.2.3
Define and execute IT Change management” process.
13.1.2.1 Create new incident via Self Service Portal Callers—COMPANY end-users—log new incidents using ServiceNow Self-Service Portal. The Self-Service
Portal uses a record producer to generate an incident record rather than exposing the full incident form
to users. In which case, only the following fields are mandatory:
• Short description
• Description
• Category
• Sub-Category
The “Category” and “Sub-Category” fields determine the IT Team who will be assigned to work on the
incident. The incident form’s state is automatically set to “New”.
13.1.2.2 Create new incident via Incident module Incidents reported to the Service Desk (1st line support) by external clients (COMPANY members or
service providers) via the case management system (CSM) or by automated systems (event monitoring
and security automated tools) are logged by the Service Desk using ServiceNow Incident Module.
The incident form’s state is automatically set to “New”.
13.1.2.3 Send confirmation to Caller that new incident ticket is created Automated task executed by ServiceNow, which sends a confirmation email to the Caller once a new
incident ticket is submitted via the Self-Service Portal.
NOTE: External clients are notified of incident creation and state changes manually by Tech Support –
outside of ServiceNow.
13.1.2.4 Notify Service Desk that new incident ticket is created Automated task executed by ServiceNow, which sends an email notification to Service Desk when a new
incident ticket has been logged by the Caller via the Self-Service Portal.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 21 www.almahaconsulting.ca
13.1.2.5 Send confirmation to Service Desk that new incident ticket is created Automated task executed by ServiceNow, which sends a confirmation email to the Service Desk once a
new incident ticket is submitted via the Incident Module.
13.1.2.6 Review and verify Caller information The Service Desk reviews the Caller information provided and supplements it with further details or
creates a Request if this is deemed not an incident.
13.1.2.7 Set incident state to “Canceled” If Service Desk determines that the reported incident is a request, then a new Service Request is
created. This interfaces with the “Manage service requests” process. The Service Desk also proceeds to
cancel the incident ticket by setting the incident state to “Canceled”. This results in process termination.
13.1.2.8 Send notification that incident is canceled Automated task executed by ServiceNow, which sends a notification email to the Service Desk and to
the Caller once the incident ticket state is set to “Canceled”.
13.1.2.9 Categorize incident Service Desk uses the “Category” and “Sub-Category” fields in the incident form to categorize the
reported incident and identify what the incident is impacting. For example, an incident might be
categorized as “network” with a sub-category selected as “network outage”.
Service Desk may also choose to change the Category/Sub-Category entries that were previously
selected by the Caller if those were deemed incorrect.
13.1.2.10 Prioritize incident Service Desk uses the “Priority” field in the incident form to determine the incident Priority Level 1 to 4,
in accordance with the Incident Management Policies & Procedures and the established service level
agreements (SLAs) and operational-level agreements (OLAs).
Incident prioritization typically drives the schedule of the incident through its resolution. Priority is
automatically calculated from the Impact and Urgency fields according to the following table:
1 – High 2 – Medium 3 – Low
Priority Priority Priority
1 – High 1 – Critical 2 – high 3 – Medium
2 – Medium 2 – high 3 – Medium 4 – Low
3 – Low 3 – Medium 4 – Low 4 – Low
If Priority is assigned a 1 or 2 calculation, the incident will be promoted to a Major Incident. In which
case, the incident will be handled through the “13.2.1 Define and execute major incident management”
process.
NOTE: Identifying an incident as a Major Incident does NOT create a new ticket. The assigned IT Team
continues to manage the incident from the standard incident ticket.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 22 www.almahaconsulting.ca
13.1.2.11 Set “Assignment Group” and “Assigned To” to most appropriate The Service Desk sets the “Assignment group” and “Assigned to” fields to the most appropriate IT Team
and individual respectively. The selected Category” and “Sub-Category” fields of the incident form
typically determine the IT team and individual who will be assigned to work on the incident. Service
Desk reviews the incident details and confirms that the incident is assigned correctly or reassigns the
incident ticket to the proper IT Team (Assignment Group), if applicable.
NOTE: Populating the “Assigned to” field automatically changes the incident’s state from “New” to “In
Progress”.
13.1.2.12 Send notification that incident is assigned Automated task executed by ServiceNow, which sends an assignment notification email to the assigned
IT Team.
13.1.2.13 Review incident and confirm it is assigned correctly The assigned IT Team reviews the incident and confirms that it is assigned correctly. This includes
confirming the “Assigned to” field. If this field is not populated, the Assigned Group manually changes
the incident’s state from “New” to “In Progress”.
This is a loop task as an incident could be reassigned multiple times. In which case, each IT Team who is
reassigned to the incident ticket reviews that the ticket has been assigned/reassigned correctly.
13.1.2.14 Investigate potential causes During the “In Progress” state, the assigned IT support individual begins investigating to establish the
incident’s cause and how to fix it. To help them resolve the issue, they can:
• Refer to similar incidents and problem records. This would interface with the “13.2.2 Define and
execute problem management” process.
• Search recent IT changes for any potential causes. This would interface with the “13.2.3 Define and
execute IT Change management” process.
This is a loop task that continues until the Caller confirms that the incident is resolved.
NOTE: This stops the clock on any response SLAs / OLAs that are running since changing the state to “In
Progress” means someone is responding to the incident.
13.1.2.15 Update incident with latest progress and findings The assigned IT support individual updates incident ticket with the latest progress and findings to
capture the actions they have taken and what they have learned.
This is a loop task that continues until the Caller confirms that the incident is resolved.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 23 www.almahaconsulting.ca
NOTE: If the incident was created via the Self-Service portal, both the “Work notes” and the “Comments”
sections are used to communicate back with the Caller.
13.1.2.16 Reassign to 2nd or 3rd line support During this investigation and triage, the assignee may discover that there is a better-suited group or
individual to address the incident. If so, they'll reassign the incident. To do this, they'll update the
“Assignment group” and “Assigned to” fields. This could involve passing the incident to 2nd or 3rd line IT
Teams/SMEs. The new assignees receive email notification to make them aware they are now
responsible for the incident.
This is a loop task as an incident could be reassigned multiple times while it’s in the “In Progress" state
since multiple different teams may need to be involved. When reassigning an incident, the “Work notes”
field is updated to explain why the incident is being assigned to the new group or individual and what is
expected of them.
13.1.2.17 Set incident state to “Canceled” The incident ticket may be canceled, if duplicate(s) were found for example, in which case, the assigned
IT support individual sets the incident state to “Canceled” and updates the “Work notes” and
“Comments” fields with the reason for the incident cancellation. This results in process termination.
13.1.2.18 Set incident state to “On Hold – Awaiting Caller” If additional information is required from the Caller, the assigned IT support individual sets the incident
state to “On Hold” and selects “Awaiting Caller” as the “On hold reason” then updates the “Work notes”
and “Comments” fields accordingly.
13.1.2.19 Set incident state to On Hold – “Awaiting Vendor” If vendor support is required, the assigned IT support individual sets the incident state to “On Hold” and
selects “Awaiting Vendor” as the “On hold reason” then updates the “Work notes” and “Comments”
fields accordingly.
13.1.2.20 Set incident state to On Hold – “Awaiting Change” If the incident is purely waiting for an IT change to be implemented, the assigned IT support individual
sets the incident state to “On Hold” and selects “Awaiting Change” as the “On hold reason” then
updates the “Work notes” and “Comments” fields accordingly.
13.1.2.21 Set incident state to On Hold – “Awaiting Problem” If a new problem needs to be raised or the incident needs to link to an existing problem, the assigned IT
support individual sets the incident state to “On Hold” and selects “Awaiting Problem” as the “On hold
reason” then updates the “Work notes” and “Comments” fields accordingly.
13.1.2.22 Apply and test fix/workaround and confirm resolution Once the fix or workaround is applied, the assigned IT support individual tests the fix to see if it resolves
the incident. If they believe it does, they request resolution confirmation from the Caller by updating the
“Work notes” and “Comments” fields accordingly.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 24 www.almahaconsulting.ca
13.1.2.23 Notify “Work notes list” and “Watch list” of updates Automated task executed by ServiceNow, which sends notification updates about the incident to the
“Work notes list” and “Watch list”. This saves the IT staff from having to update Callers and other
incident stakeholders and the Callers / incident stakeholders from having to chase down updates.
This is a loop task that continues until the incident is resolved.
13.1.2.24 Review incident ticket’s latest updates The Caller reviews the incident ticket’s latest updates. This may include:
• Updates that the incident is canceled
• Updates that additional information is required
• Updates that the incident is resolved, and confirmation is required
13.1.2.25 Update incident ticket with additional info If additional information is required, the Caller updates the “Work notes” and “Comments” fields
accordingly.
13.1.2.26 Check that incident is resolved If the incident’s update notes indicate that the incident was resolved and confirmation is required, the
Caller checks to confirm that the incident was indeed resolved.
13.1.2.27 Update incident ticket with resolution outcome After checking that the incident was resolved, the Caller updates the “Work notes” and “Comments”
fields with the resolution outcome.
13.1.2.28 Set incident state to “Resolved” If the incident was canceled, the assigned IT support individual receives an incident cancellation
notification from ServiceNow, indicating that the process is terminated.
If the Caller’s additional information is received, this routes back to process step 13.1.2.14 Investigate
potential causes and set state to “In Progress”.
If vendor support information is received and a fix / workaround is found, this routes back to process
step 13.1.2.22 Apply and test fix/workaround and confirm resolution, otherwise, the process routes
back to process step 13.1.2.14 Investigate potential causes and set state to “In Progress”.
If an IT change was raised to apply the fix and that change was approved, this routes back to process
step 13.1.2.22 Apply and test fix/workaround and confirm resolution.
If a problem / JIRA bug was fixed, then this routes back to process step 13.1.2.22 Apply and test
fix/workaround and confirm resolution.
If the Caller checks that the incident is resolved and they determine that it was not resolved, then this
routes back to process step 13.1.2.14 Investigate potential causes and set state to “In Progress”.
Otherwise, if the Caller confirms that the incident is resolved, the assigned IT support individual sets the
incident state to “Resolved”.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 25 www.almahaconsulting.ca
13.1.2.29 Provide Resolution Information When the assigned IT support individual sets the incident state to “Resolved”, the “Resolution
Information” section becomes mandatory. This section includes both mandatory and optional fields that
provide some further details, which explain what the problem was and how it was fixed.
If the assigned IT support individual checks the “Knowledge” checkbox in the “Resolution Information”
section, this will allow the creation of an incident knowledgebase record, interfacing with the “13.2.8
Define and execute knowledge management (KM)” process.
Also, during the “Resolved” state, the assigned IT support individual can raise a new problem or relate
the incident to an existing problem. This interfaces with the “13.2.2 Define and execute problem
management” process.
13.1.2.30 Send notification that incident is resolved Automated task executed by ServiceNow, which sends email notification to the Caller and the assignee
that the incident is resolved once the “Resolution Information” has been added.
The Caller’s email notification includes a request to click on a link that will enable ServiceNow to close
the ticket automatically.
13.1.2.31 Click email link to enable ServiceNow to close the ticket The Caller clicks on the link included in the email notification received from ServiceNow about the
incident resolution to enable ServiceNow to close the ticket automatically.
13.1.2.32 Set incident state to “Closed” Automated task executed by ServiceNow, which sets the incident state to “Closed” when either an
email is received from the Caller signaling ServiceNow to close the incident or after the passing of FIVE
(5) calendar days.
Once an incident is closed, it cannot be reopened. It also becomes read-only, i.e., it cannot be edited or
deleted. In addition, the associated SLAs / OLAs typically stop in this state.
13.1.2.33 Send notification that incident is closed Automated task executed by ServiceNow, which sends email notifications to both the Caller and the
assignee that the incident is now closed.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 26 www.almahaconsulting.ca
Process Measures (KPI’s) Below are some of the most common key performance indicators (KPIs) in ITIL incident management
process to evaluate the success of process implementation, towards meeting its critical success factors.
KPI NAME DEFINITION KPI NATURE FREQUENCY TARGET ACTUAL
• Mean time to identify (MTTI) / Mean time to detect (MTTD).
• Average time (e.g. in hours) between the occurrence of an incident and its identification / detection by IT service desk.
• MTTI and MTTD indicate how efficiently, on average, service desk can locate the point of failure and ultimately lead toward remediation.
Operational Excellence / Efficiency / Cycle Time
Weekly / Monthly / Quarterly
TBD N/A
• Mean Time to Repair (MTTR)
• Average time (e.g. in hours) between the occurrence of an incident and its resolution.
• This measurement includes the time it takes to identify the incident. MTTR is also a gauge of system or component resiliency: The lower it is, the more efficiently that component or system can be brought back online.
• This can be broken down by the following:
– Type – Category – Priority, impact,
urgency – Service
Operational Excellence / Efficiency / Cycle Time
Weekly / Monthly / Quarterly
TBD N/A
• Mean time between failures (MTBF):
• Sometimes referred to as incident recurrence rate, MTBF focuses on the system but can be influenced by the IT operations team's ability to manage it. The more time it can spend operational, the better off the environment -- and the environment's management team -- will be.
Operational Excellence / Efficiency / Cycle Time
Weekly / Monthly / Quarterly
TBD N/A
• % of outage due to incidents (unplanned unavailability)
• Percentage of outage (unavailability) due to incidents in the IT environment, relative to the service hours.
Operational Excellence / Efficiency
Weekly / Monthly / Quarterly
TBD N/A
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 27 www.almahaconsulting.ca
KPI NAME DEFINITION KPI NATURE FREQUENCY TARGET ACTUAL
• % of incidents solved within deadline/target (SLA) / (OLA)
• Number of incidents closed within the allowed duration timeframe agreed in SLA/OLA, relative to the number of all incidents closed in a given time period.
Operational Excellence / Efficiency / Compliance
Weekly / Monthly / Quarterly
TBD N/A
• Average incident response time / First-time resolution (FTR) rate and escalation rate
• The average amount of time (e.g. in minutes) between the detection of an incident and the first action taken to repair the incident.
• Also referred to as first-call resolution (FCR) rate, the FTR rate is the speed at which incidents are corrected at first notice, without further work required.
Operational Excellence / Efficiency / Cycle-Time / Compliance
Weekly / Monthly / Quarterly
TBD N/A
• % of incident reassignments
• The number of incident reassignment per ticket relative to the number of all incidents in a given time period.
• Incidents that are moved among support teams take longer to resolve. Moreover, an incorrectly routed incident wastes everyone’s time and delays time to resolution.
Operational Excellence / Efficiency / Cycle-Time / Compliance
Monthly TBD N/A
• Number of recurring incidents logged
• These can be broken down by the following:
– Number of incidents per priority, impact, urgency
– Number of incidents per type and category
– Number of incidents per person (i.e. top ten incidents per user)
– Number of incidents per configuration item type (i.e. top ten infrastructure incidents)
– Number of incidents per service
– Number of incidents per business area
Operational Excellence Weekly / Monthly / Quarterly
TBD N/A
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 28 www.almahaconsulting.ca
Reports for Management Management reports help identify trends and allow review of the health of the process, including
providing a sound answer to the question, “What decisions is this report helping management to
make?”.
Setting a level on certain reports may be appropriate as may be categorizing the report as strategic,
operational or tactical.
Management reports for incident management should include those in the following table:
REPORT DESCRIPTION
Standard Incidents logged and resolved. • As well as the numbers, a very concise view of reported and resolved incidents may also be included.
Summary of incidents that are still to be resolved.
• COMPANY’s SLT will be interested to see the number of higher priority incidents (Priority 3 and up) still awaiting resolution.
• Importantly, each outstanding incident should show how long it has been in this status. Incidents that have been waiting for resolution for long periods of time may be downgraded or even closed.
The number of incidents attributable to different business areas.
• This will help COMPANY’s SLT to understand which areas are in a state of continual disruption. Incidents can indicate fluctuating internal pressures and/or increasing pressures from external forces.
• The situation regarding the process staffing levels and any suggestions regarding redistribution, recruitment and training required.
• Audit reports should verify that any selected Incident contains all relevant and expected information.
Relevant financial information • To be provided in conjunction with financial management for IT services.
• This information will include a cost per incident summary.
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 29 www.almahaconsulting.ca
List of Supporting Documents • ServiceNow Incident Form
• Incident Email Notifications and Supporting Documentation
• Incident Management Established SLAs / OLAs
• IT Teams Resolution Procedures and Playbooks
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 30 www.almahaconsulting.ca
Process Improvement Recommendations Identification of Key Business Process Improvements (BPI) and Longer Term (LT) Improvement
Opportunities.
PROCESS REFERENCE RECOMMENDATIONS FOR TO-BE STATE KEY BPI LT
13.1.2 Implement E2E Incident Management with ServiceNow
• Automated alerts / notifications for engaging with internal and external clients as well as escalations.
➢ Currently, reporting and escalating incidents are all manual processes. When an incident occurs, the next steps are at times unclear.
➢ Currently, communications/updates on incident status cease when an incident is ongoing and at times information is not released when it should be.
• Need to establish and define incident communication criteria, timing and milestones for communications—specifying who should communicate what, when and to whom, to ensure that incidents and solutions are properly and effectively addressed with internal clients (all COMPANY) and external clients (members and service providers).
➢ Suggestion that for P1 and P2, all RMs are notified and for P3, the specific RM is notified. RMs do not need to be informed of P4s.
• Develop a dashboard for incident tracking and communication with notifications functionality when statuses change as well as sorting functionality. The incident should be sorted by the parent code.
☒ ☒
Incident Management Lifecycle
• For the current release of ServiceNow, the Assignee does not receive system reminders regarding the status of an active incident.
➢ Future release to include automated alerts / reminders on the status of the incident to be sent to the person actively assigned to the incident.
☐ ☒
Incident Management Lifecycle → Closed
• For the current release of ServiceNow, IT Teams are unable to link to Problem Management after an incident state is set to “Closed”.
➢ Future release to allow linking to the Problem Management module after the incident has been closed.
☐ ☒
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 31 www.almahaconsulting.ca
PROCESS REFERENCE RECOMMENDATIONS FOR TO-BE STATE KEY BPI LT
Incident Assignment • For the current release of ServiceNow, anyone with access to the incident ticket can manually change the incident’s state from “New” to “In Progress”.
➢ Future release to allow ONLY the “Assignment Group” the ability to change the incident’s state from “New” to “In Progress” if the “Assigned to” field is not populated as changing an incident’s state has direct implications on its established SLAs / OLAs.
☐ ☒
13.1.2.2 Create new incident via Incident module
• For the current release of ServiceNow, incidents reported by automated tools (event monitoring and security systems) are manually logged into ServiceNow by the Service Desk.
➢ Future release to allow automated alerts to be sent directly to ServiceNow who then creates the incident ticket.
• For the current release of ServiceNow, externally reported incidents, i.e., those reported by a COMPANY member or service provider, are logged into ServiceNow by Tech Support, who receives the email confirmation from ServiceNow once the ticket has been created, including all other incident updates.
➢ Future release to allow external clients to create / log incidents in and receive notifications from ServiceNow.
☐ ☒
13.1.2.9 Categorize incident
• There seems to be a tendency to downgrade severities. Further categorizations for incidents are needed.
➢ Green and red zones are needed for each specific product. The ability to determine how critical a specific incident is, depending on product type and timing.
• Understanding of incident is not clear. Next steps once incident is categorized are not clear.
☒ ☐
Implement E2E Incident Management with ServiceNow
STANDARD OPERATING PROCEDURE | VERSION 1.0 | PAGE 32 www.almahaconsulting.ca
PROCESS REFERENCE RECOMMENDATIONS FOR TO-BE STATE KEY BPI LT
13.1.2.10 Prioritize incident
• Need to determine priority levels for internally reported incidents—each team seems to have a different classification.
• Priority 3 and 4 are currently not communicated to clients, P1 and 2 have a different process, and the differences are not clearly defined.
➢ Definitions need to be revisited for clarity purposes. Next steps by priority/severity should be defined.
• Need to determine when an incident is severe enough to be escalated. This is especially true of internally reported incidents.
☒ ☐
13.1.2.10 Prioritize incident
• Currently, the incident management process does not have SLAs associated with it.
➢ IT Admin will roll out an internal support SLA, which will be integrated with a future release of ServiceNow.
• For the current release of ServiceNow, manually promoting a standard incident to a Major Incident does not change the priority level assigned to the incident. The priority must be manually updated to reflect the established OLAs.
➢ Future release to allow ServiceNow to automatically change the priority level when an incident is promoted to a major incident.
☐ ☒
13.1.2.16 Reassign to 2nd or 3rd line support
• Need to determine where agile fits in with respect to escalations, including the expectations for each team—define what is expected as far as how often people need to be online/checking phones.
☒ ☐
13.1.2.32 Set incident state to “Closed”
• Currently, there is no visibility as to when an incident is closed.
• Ticket should be updated in ServiceNow. Caller should close the incident via a link provided in the email communication received from Service Desk confirming incident resolution. Otherwise, ServiceNow automatically closes the ticket after FIVE (5) calendar days.
☒ ☐