Implement E2E Incident Management with ServiceNow · Implement E2E Incident Management with...

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)

https://almahaconsulting.ca/wp-content/uploads/2019/11/E2EIM-w-ServiceNow_BPMN.pdf

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

http://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




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




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.




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)




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


• 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





Regulatory, Risk and Legal References [Enter the applicable regulatory, risk and legal references here].




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.




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.




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.




• 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.




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.




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.




• 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




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.




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.



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



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





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.


https://almahaconsulting.ca/wp-content/uploads/2019/11/E2EIM-w-ServiceNow_BPMN.pdf



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.




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.




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.




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.




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”.




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


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.




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



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.



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


TBD N/A




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


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


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




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.




List of Supporting Documents • ServiceNow Incident Form

• Incident Email Notifications and Supporting Documentation

• Incident Management Established SLAs / OLAs

• IT Teams Resolution Procedures and Playbooks




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.

☐ ☒





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.

☒ ☐





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.

☒ ☐


Implement E2E Incident Management with ServiceNow · Implement E2E Incident Management with...

Documents

Transcript of Implement E2E Incident Management with ServiceNow · Implement E2E Incident Management with...