Incident Management Best Practice Process Guide Helsinki

ServiceNow Best Practice Process

Incident Management
Published: March 2016

Table of Contents

Introduction .................................................................................................................................................................. 3
Incident Management using ServiceNow ..................................................................................................................... 3
Roles and Responsibilities ............................................................................................................................................ 3
Incident Manager ...................................................................................................................................................... 3
Caller ......................................................................................................................................................................... 3
Service Desk Analyst (1 line) ................................................................................................................................... 4
st
Operational Support (2 /3 /4 line) ....................................................................................................................... 4

nd rd th
Service Desk Manager ............................................................................................................................................... 5

Using the State Model .................................................................................................................................................. 5
New ........................................................................................................................................................................... 5
In Progress ................................................................................................................................................................ 6
On Hold ..................................................................................................................................................................... 6
Resolved .................................................................................................................................................................... 6
Closed ....................................................................................................................................................................... 7
Canceled ................................................................................................................................................................... 7
Establishing Priority ...................................................................................................................................................... 7
Incident Categorization ................................................................................................................................................ 8
Managing Major Incidents ............................................................................................................................................ 8
Parent/Child Incidents .................................................................................................................................................. 9
Incident Templates ....................................................................................................................................................... 9
Reports, Homepages and Metrics ................................................................................................................................ 9
Interoperability with other processes ........................................................................................................................ 10
Problem Management ............................................................................................................................................ 10
Change Management .............................................................................................................................................. 10
Knowledge Management ........................................................................................................................................ 11
Configuration Management .................................................................................................................................... 11
Service Level Management ..................................................................................................................................... 11
Event Management ................................................................................................................................................. 11

© 2016 ServiceNow, Inc. All rights reserved.

ServiceNow and the ServiceNow logo are trademarks of ServiceNow, Inc. All other brand and product names are trademarks or registered trademarks of their respective holders. 2

Introduction
This guide is created to explain how the incident management process is designed to work specifically using
ServiceNow. It should be used by engagement managers, technical consultants and anyone involved in
implementing the incident management application. It should be used in conjunction with technical
implementation guides to ensure the application is applied consistently to all customers. This should also ease
customer upgrade paths and the ability to expand their use of the platform.
Incident Management using ServiceNow

An incident is defined as an unplanned interruption or a reduction in the quality of a technical service or a failure
of a configuration item (CI) that has not yet impacted a technical service. Incidents can include failures or
degradation of services reported by users, technical staff, third-‐party suppliers and partners, or automatically from
monitoring tools.
The primary goal of the incident management process is to restore normal service operation as quickly as possible
and minimize the adverse impact of incidents on business operations, ensuring that the best possible levels of
service quality and availability are maintained. Normal service operation is defined as an operational state where
services and CIs are performing within agreed service and operational levels. Incident management is responsible
for managing the lifecycle of all incidents. A temporary workaround to restore service is all that is required in
many cases to complete the process.
ServiceNow focuses on the use of automation and information to speed the path to resolution.
Roles and Responsibilities
Incident Manager
Unlike the change management process where each ticket needs to be reviewed in some manner by the managers
of the process incident management does not require that. The Incident Manager is concerned primarily with
those incidents that are causing a higher impact. Typically they focus on managing critical incidents and the health
of the incident management process.
Responsible for:
• Developing and maintaining the incident management process and procedures
• Leadership and facilitation of the incident management process within the Technology organization
• Continual improvement of the process
• Gathering and reporting on metrics to ensure the process is being followed and is effective
• Managing critical incidents
Caller
The Caller is the individual who is being impacted by degradation to a service or someone who has discovered an
impact/potential impact to a service. This could be a member of an operational support team. Alternatively if the
issue has been discovered automatically through an event monitoring system then the Caller may be captured
against that system.



Responsible for:
• Bringing incidents to the attention of the Service Desk
• Participating in the implementation of a solution or workaround
• Confirming successful resolution
Service Desk Analyst (1st line)

The Service Desk Analyst is considered the front line or face of the Technology organization. They will be the
people the rest of the organization interacts with most commonly and this will typically be when users are
experiencing some sort of technology related issue. The goal of the SDA is to deal with as many incidents as
possible themselves at the point of receiving the incident. This is first call or initial contact resolution. Ideally they
want to solve the Callers issue immediately without having to involve other support teams and without the Caller
having to contact them a second time.
Even if the issue cannot be dealt with by the SDA many organizations will still keep ownership and communication
of the incident with the SDA even though others may be providing the actual resolution.
Since the SDA is expected to resolve incidents themselves they need a very broad range of knowledge across all
technical services, they may be considered a ‘jack of all trades, master of none’. This means they need access to
information to help with their diagnosis, as they are likely to have limited knowledge on each subject. They must
at least try to determine a good line of investigation so that they can pass the incident to the correct Operational
Support team for further diagnosis.
Responsible for:
• Recording, ownership, monitoring, tracking, and communication about incidents
• Investigating and diagnosing incidents
• Providing resolutions and workarounds from standard operating procedures and existing known errors
• Escalating incidents to operational support
• Communicating with the caller
Operational Support (2nd/3rd/4th line)

If a Service Desk Analyst is unable to resolve an incident on their own they must pass responsibility to someone
else who will have more knowledge and experience. Organizations will differ in how they structure their support
nd
teams however a common approach would be to have 2 line support teams within the Service Desk reporting
structure who specialize in particular services and would be considered the SMEs for these services. Escalating to
nd
2 line would still keep the incident within the Service Desk.
rd
3 line support is typically the operational team responsible for the service. For example Database Support,
Network Support, Application Development etc. These are the teams whose main focus is the delivery and
maintenance of that service.
th
4 line support may not need to exist in many organizations but this could be where the service is supplied by an
external vendor and all internal support teams have failed to resolve the issue. The incident now needs to be
escalated outside of the organization.
Essentially the higher the line of support the more knowledge and experience they should have on the specific
service in question, the less general knowledge they will have across all services.
Responsible for:
• Investigating and diagnosing incidents escalated from the Service Desk
• Developing workarounds


• Resolving and recovery of assigned incidents

• Creating incidents after detecting a service failure or quality degradation or a situation that may result in
one
Service Desk Manager

The Service Desk Manager is a key stakeholder in the incident management process. It is their team who will
resolve the majority of incidents.
Responsible for:
• Managing resources assigned to the Service Desk
• Managing Service Desk activities
• Monitoring and reporting on Service Desk performance
• Taking overall responsibility for incident and service request handling by the Service Desk
• Making improvements to the Service Desk
Using the State Model

States in any ServiceNow application serve a specific purpose. They are designed to make it clear where in a
process a particular record currently resides and to display progress. States should represent a unique phase in a
process where a specific set of related activities are grouped together designed to achieve a particular outcome in
order to move to the next phase of the process. For example in Change Management the Review state should
contain all activities required to review the success or failure of the change after implementation. It would not be
expected that review activities would occur during other states. Out of the box Incident Management has the
following state model:
• New
• In Progress
• On Hold
• Resolved
• Closed
• Canceled
New
This is where the incident ticket is opened and all known information about the symptoms experienced is
captured. Any services that have experienced an impact are logged as a Business Service CI. The incident remains
in New state until it is being worked on. It can be updated with additional information from the Caller many times
not just when it is first raised. Incidents can be created from multiple sources.
• The Service Desk Analyst can create the incident directly as a result of a phone call or email from a user.
• End users are able to make use of the Self Service portal where they can directly create a ticket. This
would use a record producer to generate an incident record rather than exposing the full incident form to
users that would not understand most of it.
• Incidents can be automatically generated via external systems such as event monitoring.
• Inbound emails can generate incident records.


In Progress
The incident is now actively being worked on. This is quite often recognized when the Assigned to field has been
populated with an individual and many customers will want to automatically update the state field when this has
happened. However just because an Assignee has been named does not mean they have actually begun to work
on it. It may simply be assigned to their list of work. It will be for the customer to determine what constitutes
moving to In Progress and this could be manual.
While the incident is in progress the goal is to conduct diagnostic steps to determine the cause and then to fix the
issue. The fix could either be a temporary workaround or a permanent solution whichever will end the impact
soonest.
As the incident is being diagnosed it may be reassigned to a number of different groups as certain things are ruled
out or in and the cause is narrowed down. It is common for customers to want to track the number of times an
incident ticket is reassigned as one of the key metrics of the process.
On Hold
The On Hold state is used to highlight when work has begun on resolving the incident, it is not yet resolved but it is
temporarily not being worked on due to waiting for a further action to occur. There could be a number of reasons
for this but commonly they are things such as the Caller needs to provide further information or the solution is
identified but a change needs to be implemented to achieve this. There is a separate on hold reason field to
determine why the incident is on hold. This is a choice list so that customers can only include those reasons which
they determine legitimate for pausing an incident therefore guiding the users of the process to follow it correctly.

The Service Level Management product will make heavy use of this state since putting something on hold will
typically act as the pause condition for all SLAs.
Resolved
Once the fix has been applied and tested by the Assignee and they deem that it has been successful they will move
the incident to Resolved. The Caller is notified of this and it is during this state that they are expected to validate
the Assignees belief that is it fixed. If they agree then the incident can be closed with no further action. If they
disagree and are still experiencing an impact then they can send the incident back to In Progress state with their
explanation around why.
In most cases customers will set a time limit on when the Caller can disagree with a Resolved state and this will be
around 5-‐7 days. Once the time limit is reached the incident will automatically move to Closed and the Caller
would need to raise a brand new incident if symptoms persisted.
There may be situations where it was not possible to resolve the incident. Maybe the symptoms were too difficult
to reproduce or the cost of fixing the issue was deemed prohibitive. In these cases the incident would still be
considered resolved but with a close code of Not Solved.
If the incident has followed the Major Incident Management process it may be that a customer would also want to
conduct some form of post mortem review process. This should take place during the Resolved state.


Closed
Once the incident has been confirmed as resolved and any necessary close out work has been completed the
incident is moved to Closed. At this point all work on the ticket is finished. Should any follow up work be required
this will be via a problem, change or other associated process.
Canceled
An incident should only be set to Canceled if it was opened by mistake and an incident did not actually exist.
Establishing Priority
Incident prioritization typically drives the timescales associated with the handling of the incident and the targeted
time to resolution. There are a couple of methods that can be used to determine priority.
In most cases priority is established using a combination of impact vs. urgency, where:
Impact is the effect that an incident has on business. For example if the incident only impacts a single employee
the impact is low in comparison to 500,000 paying customers with Twitter accounts.
Urgency is the extent to which the incident's resolution can bear delay.
Priority is generated from urgency and impact according to the following table.
Urgency High Urgency Medium Urgency Low
Impact High Priority 1 Priority 2 Priority 3
Impact Medium Priority 2 Priority 3 Priority 4
Impact Low Priority 3 Priority 4 Priority 5


It is possible to automatically establish the priority of the incident based on the CI that is identified in the incident
record. With this technique, the business criticality value of the CI is used to determine the priority of the incident.
This ensures a more accurate and consistent prioritization of incidents, as the determination of impact and
urgency can be a subjective call.
Incident Categorization
Incident categorization is commonly used to drive assignment in the incident management process as well as
establish trends (incident types/frequencies) for use in problem management, supplier management and other
ITSM activities.
See Categorize incidents in ServiceNow Docs for a list of the category and subcategory values available in the base
system although these are just considered examples rather than best practice categories.
See Define an assignment rule for incidents in ServiceNow Docs for a description of how to automate assignment
based on categorization.
This method of categorization requires the creator of the incident to manually select the category and subcategory
from predefined lists.
It is possible to automatically categorize and assign the incident based on the CI that is identified in the incident
record. With this technique, the incident management process inherits the same categorization schema as CIs
maintained through the configuration management process and the category of an incident is automatically
determined once the affected CI is identified in the incident record. This technique ensures more accurate and
consistent categorization of incidents and supports a CI-‐centric approach to IT service management.
Managing Major Incidents

A sub-‐process within incident management is the Major Incident Management process. The specific criteria for a
major incident will need to be determined by the customer however for the most part this will include all P1
incidents and potentially some P2.
Some typical major incident criteria are:
• The ability of significant numbers of customers and/or key customers to use services or systems is or will
be affected
• The cost to customers and/or the service provider is or will be substantial, both in terms of direct and
indirect costs including financial penalties for any SLAs breached
• The reputation of the Service Provider is likely to be damaged
In addition to these factors the amount of effort and/or time required to manage and resolve the incident is likely
to be large and it is very likely that agreed service levels (target resolution times) will be breached.
This process is directly coordinated by the Incident Manager. They will ensure that all necessary technical
resources have been engaged and are dedicated to the incident. They will also be coordinating the
communications around the incident. This will be to key internal stakeholders and to the customers who are
impacted. It is important for customers to be regularly updated even just to be told that there has been no further
progress than to be left in the dark and assume no one is trying to resolve their issue. The ServiceNow Incident
Alert Management plugin enables organizations to create and manage communications related to major incidents
or business issues. This allows incident alert administrators to bring together all involved or impacted users during
these events and establish quick and easy communication within this group.


Once the major incident has been resolved there will be follow up steps to review what happened and where
improvements can be made in the future. Typically lessons learned and next steps are produced. It is common for
a problem record to be generated to track any further work required even if the incident itself has been resolved.
Parent/Child Incidents
Where an incident is causing a wide impact this will be evident with a number of records being raised by different
Callers for the same issue. Although these incidents are reporting the same thing and might be considered
duplicates of each other it is good to capture each instance where the impact has been experienced so that the
size of impact can be more easily determined. The down side of having many incidents logged with the same issue
is that they will all need to be updated as the incident is diagnosed and resolved. This can be easily handled by
designating one incident as the parent and relating all other incidents to this parent via the Child Incidents related
list. When work notes or comments are added to the parent these will automatically copy to all related child
incidents. In addition when the parent is resolved the child incidents will also be resolved and the closure
information copied over.
Incident Templates
Incident templates may be also be established to handle issues that are seen repeatedly and require the same
steps to resolve each time. The Service Desk agent can raise a new incident from a template when they are
responding to a call or email from a user. See Templates in ServiceNow Docs for a description of how to use the
template feature of ServiceNow to support this concept.
Reports, Homepages and Metrics

There are numerous reports available in ServiceNow that can be used to generate charts, publish to a URL, or
schedule to be run and distributed at regular intervals. Users can also create custom reports. See Create and
manage reports in ServiceNow Docs for more details on this capability.


In addition to reports, each user can create a personal homepage and add gauges containing up-‐to-‐the-‐minute
information about the current status of records that exist in ServiceNow tables. See Customize homepages in
ServiceNow Docs for details.
Metrics and Performance Analytics can be used to understand the health of the incident management process and
where improvements can be made.
Some useful indicators:
• Open Incidents – Are there many open incidents for a long time -‐ more than 90 days? Are more assigned
to a particular group?
• New incidents -‐ Do you have a peak on Mondays – so you need more staff on that day? Any other
seasonal variations?
• Backlog growth -‐ Are you keeping pace? What factors (category, etc) affect it?
• Resolved incidents – What’s the resolution time? Which group is resolving the most?
These type of metrics can be used in conjunction with Performance Analytics to get an easy to understand view of
where to focus improvement efforts.
Interoperability with other processes
Problem Management
Problem Management is the ‘next step’ process for incidents that require further investigation for the root cause.
Problem records can be generated directly from the incident record and will copy over key data. Incidents can be
put into On Hold state with a reason of Awaiting problem. There could be many incidents associated with a single
problem and the higher the number of incidents the clearer the scale of impact becomes. It may be that when the
problem was first encountered the number of associated incidents was low and so it was decided not to pursue a
permanent fix however as the number increases and the impact widens that decision may be reviewed.
If a workaround exists for the problem this can be logged into the problem record and automatically pushed into
all associated incident records.
Once the problem has been fixed all associated incidents can be automatically closed.
Change Management
For many incidents the solution will require work on a service, hardware or software. Conducting this work will
require a change record to be raised.


Emergency changes typically require an incident record to be related to prove that they are urgent enough to
bypass the full process and lead times.
In some cases a change was implemented that resulted in an incident. An incident record can be created from the
originating change record to show the cause and link the chain of events together.
Knowledge Management
Knowledge is a vital part of the incident process. It is available using the Contextual Search feature embedded into
the incident record and record producers to display relevant knowledge articles as the incident is being created.
Contextual Search will use text entered into the Short description fields or other text fields to search for close
matches in the knowledge base and display these on the screen.

This is designed to assist either the Caller with information that may help them to resolve their own incident
without having to log it at all. Or it can help the Service Desk Analyst to find information that may resolve the
incident without having to escalate to an SME.
Configuration Management
The configuration management system underpins all incident management activities. It not only hosts the incident
and other service management records, but contains details of the infrastructure vital to efficient call handling.
Service Level Management

Service Level Management is used to define agreed timescales around the handling of incidents. These may be
internal agreements between support teams, contractual obligations from vendors or to customers and
expectations set with internal users.
These are used within the incident record in the Task SLA related list to alert resolution teams to how they are
doing within the promised timescales.
Metrics can be gathered for reporting on how well the agreements are being adhered to using the Reporting and
Performance Analytics functionality. These can then be used to establish where improvements need to be made
The most commonly tracked agreements include:
• Incident response times
• Target resolution times
Event Management
Automated event monitoring tools scan infrastructure to check for certain acceptable conditions that are
considered healthy. Once these conditions are no longer met an event or alert can be created to draw attention to
the change in health of the infrastructure. Where that change has been significant enough or is occurring


frequently enough that criteria would then be considered an incident where support resources would need to take
action. Incidents can be automatically created based on certain criteria allowing support teams to react quickly.
Typically these alerts can be set to catch issues before they create a much larger and more visible impact and a
major incident can be avoided.


Incident Management Best Practice Process Guide Helsinki

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Incident Management Best Practice Process Guide Helsinki

Caricato da

Copyright:

Formati disponibili

ServiceNow Best Practice Process

Table of Contents

Operational Support (2 /3 /4 line) ....................................................................................................................... 4

Service Desk Manager ............................................................................................................................................... 5

© 2016 ServiceNow, Inc. All rights reserved.

Incident Management using ServiceNow

Roles and Responsibilities

© 2016 ServiceNow, Inc. All rights reserved.

Service Desk Analyst (1st line)

Operational Support (2nd/3rd/4th line)

© 2016 ServiceNow, Inc. All rights reserved.

• Resolving and recovery of assigned incidents

Service Desk Manager

Using the State Model

© 2016 ServiceNow, Inc. All rights reserved.

© 2016 ServiceNow, Inc. All rights reserved.

Urgency High Urgency Medium Urgency Low

Impact High Priority 1 Priority 2 Priority 3

Impact Medium Priority 2 Priority 3 Priority 4

Impact Low Priority 3 Priority 4 Priority 5

© 2016 ServiceNow, Inc. All rights reserved.

Managing Major Incidents

© 2016 ServiceNow, Inc. All rights reserved.

Reports, Homepages and Metrics

© 2016 ServiceNow, Inc. All rights reserved.

Interoperability with other processes

© 2016 ServiceNow, Inc. All rights reserved.

Service Level Management

© 2016 ServiceNow, Inc. All rights reserved.

© 2016 ServiceNow, Inc. All rights reserved.

Potrebbero piacerti anche