Percent of Incidents referencing a CI - Product Knowledge

Percent of Incidents referencing a CI  Get Well Playbook

Incidents without a CI in the last 60 days

A step-by-step guide to analyze and remediate missing CI Information

Table of Contents

Summary

Goal of this Playbook

Audience

Problem Overview

Executive Summary

How this playbook can help you achieve business goals

How this playbook is structured

Problem Analysis

Upstream Causes

Downstream Consequences

Impact on Your Business

Engagement Questions

Remediation Plays

Summary

Play 1: Analysis - Validate

Play 2: Analysis – custom CI field usage

Play 3: Mark CI field as mandatory

Play 4: Identify top offenders (optional)

Play 5: Identify Incidents that are not Incidents

Play 6: Identify Incidents that have Services as CIs

Data Governance

Summary

Goal of this Playbook

Identify and remediate Incident records with missing or 'empty' CI reference values in the last 60 days.

Details about this playbook

Author Emir Eminovic Date 09/23/2020 Addresses HSD # HSD0003965 Applicable ServiceNow Releases New York, Orlando, Paris, Quebec Time required Approximately 1 to 8 hours Audience

ServiceNow Admin or Discovery Admin

Configuration Manager or Configuration Management team

Incident Process Owner or Incident Management team Problem Overview

An Incident should record what was broken (CI), how long it was out of service (MTTR) and how it got fixed (Knowledge). Organizations not utilizing these components tend to have a very reactive Incident process which delays people getting work done.

One cannot implement a proactive (predictive) outage prevention practice without having the foundational component in the process, knowing what has/will fail and recording that incident for future trending and prediction.

It is important to identify the actual CI that has failed and use its attributes for proper incident routing and resolution to achieve better business outcomes.

Executive Summary

How this playbook can help you achieve business goals

This playbook will guide on how to ensure that you are improving the selection process of the right CI by focusing on key identification attributes, as well as properly recording the CI, which was out of service (broken).

How this playbook is structured

This Playbook will guide you through seven plays.

Play 1 (an analysis play) helps you identify how you record CIs in your process today

Play 2 (an analysis play) helps you identify if you have created a custom solution to select/track CIs

Play 3 (a fix play – optional / recommended) tells you how to set the CI field as mandatory at Incident resolution stage

Play 4 (an analysis play) helps you identify top contributors / integrations not recording CIs in the incident process

Play 5 (an analysis play) helps you identify if your Incident Process also covers Knowledge and Service Requests

Play 6 (an analysis play) helps you identify if you are choosing Services as CIs on the Incident Form

Play 7 (a Data Governance play) lists the guidelines and processes for continuing to ensure your Incident workers are correctly service restoring tickets. Problem Analysis

Upstream Causes

Product - Incident Workflow does not require the CI field to be populated, as users do not know what the CI should be, and the field is not marked mandatory to make Incident submission easier

Process - CI field is not mandatory at the right stage in the incident lifecycle

People - ServiceDesk agents are expected to triage the issue and fill in the CI field, but fail to do so

Data Migration - Previous ITSM tool did not have the CI field or it was not mandatory. Same was applied to the NOW implementation

Process - Placeholder CIs or ticket categorization are used instead

Data Quality - CIs are difficult to locate and hence are not mandatory

Coverage - CIs are not in the CMDB and hence are not mandatory

Standards - Alerts are not binding to a CI due to a misconfiguration. Enterprise naming and identification standards are missing or not enforced.

Downstream Consequences

Data Consequence

Data loss - unable to report on Incident trends such as: CI with frequent outages, total cost of CI ownership, total outage time

Compliance failures (internal and external auditors) to identify what was fixed Operational Consequence

Inefficient Incident routing from Service Desk causing delays in MTTR

Manual Process circumvention is prone to errors

Unable to predict future outages without previous data App Consequence

Missing Data - unable to use automation and/or workflows that automatically assign Incidents based on CI support/assignment group

Missing Data - unable to use default features such as mapping outages to Services Impact on Your Business

Not having the correct CI identified upfront can impact the following:

Lower MTTR Data Completeness

Incident Reduction Service Awareness

Increase Operational Visibility Process Alignment

Audit/Compliance Data Governance

Process Automation Data Accuracy Engagement Questions:

Consider the answers to these questions:

How do you find a CI in your CMDB, so it can be added to the incident?

How do you know what was broken?

How do you route Incidents?

How do you evaluate Impact and Urgency of an Incident?

How do you how much time you spend supporting a Technical Service?

How do you prevent outages form occurring?

How do you analyze IT components that break frequently?

Remediation Plays

Summary

The table below lists and summarizes each of the remediation plays in the playbook. Details are included later.

Play Name

Play 1: Analysis - Validate

What this play is about

Identify % of Incidents without CI Required tasks

Review Dashboard output Play 2: Analysis – custom CI field usage

What this play is about

Identify any custom solution to associating CIs to the Incident record Required tasks

Run script and review output Play 3: Mark CI field as mandatory

What this play is about

Set the CI field as Mandatory Required tasks

Create UI Policy for CI field Play 4: Identify top offenders (optional)

What this play is about

Identify users and resolvers who do not provide CIs Required tasks

Analyze Dashboard output Play 5: Identify Incidents that are not Incidents

What this play is about

Identify items where CIs are missing that might not be Incidents Required tasks

Filter Incidents and Analyze Play 6: Identify Incidents that have Services as CIs

What this play is about

Identify Incidents Where Services have been populated as CIs Required tasks

Review list of Incidents Play 7: Data Governance

What this play is about

Helps you establish standard operating procedures, as well as periodic data certification Required tasks

Provides detailed advice, best practices and data audit instructions

Play 1 - Analysis - Validate

What this Play is about

Identify if there are Incidents without CIs in your instance

Required tasks

Download, import and commit the Incidents Without CIs Dashboard.xml update set. For more information, see Retrieve an update set .

Once you have successfully installed the Dashboard, navigate to it ( Self - Service > Dashboards > Incidents without CI in the last 60 days )

The first card will provide the count of Closed or Service Restored Incidents created in the last 60 days that do not have a CI identified.

The second card will provide the count of all Closed or Service Restored Incidents created in the last 60 days.

Sample

If there are no Incidents without a CI, and the first card shows a zero, then this playbook does not apply to you.

Otherwise, proceed to the next play.

Additionally, a report has been included to help you identify if the CI captured on the Incident form is a type of a Service. Generally, selecting a service does not indicate an outage of said service, but rather a user not being able to consume it. Play 2 - Analysis - custom field usage

What this Play is about

Many customers have customized the way they track CIs during the Incident lifecycle. Some have created their own CI field; some require the CI on closure. This play will attempt to identify fields other than the default cmdb_ci field, that reference the CMDB_CI table.

Required tasks

Navigate to System Definition > Dictionary (sys_dictionary_list)

Apply the following Filters:

Table (name) IS incident AND

Column Name (element) STARTSWITH u_ AND

Type (internal_type) IS Reference AND NOTE: It is a good idea to study all Custom references on your incident table

Reference IS Configuration Item

Your Filter should look like this:

Or alternatively run this Script

If there are no custom fields, proceed to the next play

If you are using a custom field, return to Play 1 and modify the reports/queries/scripts to check against your CI field to get a more accurate picture. Once done proceed to Play 3. You will need to modify any scripts to reflect your customization.

NOTE: Consider migrating back to the default configuration to track CIs on your Incidents. Several default components rely on that information being there. Play 3: Fix Play – Mark CI field as mandatory

What this Play is about

This play helps you make the CI field mandatory when the Incident reaches resolution lifecycle stage. This is our recommendation at which stage to force the CI entry, if one is not known yet. If you can get the CI info sooner, perform the same action on that stage.

The individual that has been working the incident and has restored service should now be able to provide the CI that has been the root cause of the outage.

If in previous steps you have discovered a customization, you will need to locate your policy that applies to your process. Commonly, there is a resolution CI that can be made mandatory at this stage.

The CI and Resolution CI do not have to be the same, as during Service restoration one could find another service component caused the outage. Collecting this data and trending on it helps you identify Knowledge gaps.

Required tasks

If you have modified default Policies and/or have customized your process, you might have to apply these changes to a custom component.

Navigate to System Policy > Rules > Data Policies . To learn more about Data Policy , review our Product documentation

Locate Make close info mandatory when resolved or closed policy

In the Data Policy form, navigate to Related Lists > Data Policy Rules , then click New

Enter the following:

Field Name : Configuration Item

Mandatory : True

Read Only : Leave Alone

Click Submit

To validate that the Configuration Item field is now required do the following:

Open an Incident that has not been resolved yet

When the record loads do one of the following

Click the Resolve Button -or- Change the status dropdown to Resolved

Notice the CI field is now mandatory:

Validate that this did not have any adverse impact on any custom rule/workflow you might have implemented

NOTE: Once a CI has been identified, now you can easily add Impacted Services and CIs by simply right-clicking the Incident Form Header and selecting Refresh Impacted Services UI Action on the form context menu Play 4: Analysis Play – Identify top offenders (optional)

What this Play is about

In this play you will run review the top offenders that allow Incidents without CIs.

Required tasks

Return to the Dashboard you have imported in Play 1

Review each tile and review the top offenders identified for each category By Contact Type – are incidents of one type more likely to not have CIs? What can be done to supplement the information?

By Category – are Incidents in one category more likely to have missing CIs? Discuss your CMDB coverage with your Discovery Administrator for CIs for those categories

By Resolution Code - are specific codes more likely to be without a CI?

By Resolved by - who are the users not binding a CI at the time the root cause has been identified? By Creator – who are the users that create Incidents without CIs? By Closer – who is closing the ticket without the CI?

Sample Follow up with the top offenders as to why they create/close Incidents without a CI

If another employee is responsible, use the engagement questions to help you find out what gaps are in the process, so it can be easier for them to add the CI

If automation is causing these records, then contact the owner the integration and review with them.

Did the integration ever work properly?

When did it stop working?

Who can fix it?

Consider using a certified Connector for your 3rd party integration over any self-implemented and/or outdated solution

Note: Incidents created via automation should always have a CI associated with them. Evaluate if the Integration has a certified ServiceGraph Connector and migrate to it to eliminate this defect.

Top Offenders are representatives of broken process in your organization. The voice of these customers should not be ignored. Work with them to improve your Incident process and close any gaps. Play 5: Fix Play - Identify Incidents That Are Not Incidents

What this Play is about

Often users contact the ServiceDesk to learn about something or to request something new. To better service them, users can be presented with Knowledge Articles on a self-servicing portal as well as request things in a Service Catalog without having to contact the ServiceDesk. However, when they do, the Incidents should be properly categorized and recorded so you can continually improve the service.

Required tasks

Review your Incidents over last 60 days and look for Incidents that are not Incidents

Navigate to Incident > All

Set the following filters

Created after 60 days ago

Configuration Item is Empty

Incidents that appear to not be ‘true’ Incidents (where a Service was interrupted or downgraded) can be remediated through two main methods.

To begin, look for the following keywords in Incident Short Description (or other that you think may be used in your organization) to Identify Incidents which are not true Incidents:

How do I

Where can I

I need something

access to

Help me

Method 1: Establish channels that no longer require Incident usage:

Identify Technical Services that can be used as CIs for these Incidents

For example: any Office 365 knowledge requests should be correlated to the Office 365 Technical Service

Create catalog requests or Knowledge Articles (Self Service) that can be used instead of the Incident process

For example: any Access request should be assigned to your Identity and Access Management system in which the agent fulfills the request; How do I map a printer should be a KB available on your portal for the user to view

Method 2: Use ITSM Agent Workspace.

This is an out of the box interface designed for Service Desk agents and those in similar roles, that provides an easy-to-navigate, multi-tab interface to efficiently oversee and resolve multiple incidents, problems, and change requests.

By using ITSM Agent Workspace, service desk agents can create Interaction records . Using an interaction record, agents can create or reference customer information from a customer contact. Agents can then decide if the conversation is an incident, case, or request.

By creating an Interaction Record before creating an Incident, user interactions are categorized properly. Metrics such as the one this playbook is centering on then provide a clearer line-of-sight into true Incidents, allowing appropriate action to be taken if CIs are still missing.

Learn more about Agent Workspace . Play 6: Identify Incidents That have Services as CIs

What this Play is about

This play is educational / analysis centric. This helps identify records where a service has been entered in the CI field. This is a common issue for many service desks. Having a service in the CI field will not adversely affect the score associated with this playbook (HSD) – however services should be stored in the Service field instead of the CI field.

Required tasks

Locate and run Incidents where CI is a Service report. This report was included in the update set from play one

Review the list of matching records

Consider reviewing the Common Service Data Model to help you better understand Applications, Services, Offerings and Capabilities that you provide.

Consider educating Incident Creators on using the Service field (business_service) to capture Services instead.

Services have non-discoverable meta data that can be used for Incident Routing and can be helpful when the same data is not present with underlying Configuration Items.

Sample Data Governance

What is this Play about ?

This play lists the healthy habits around periodic validation of CI to Incident data.

In one of the previous plays, you have made the field mandatory and as such should have a high degree of compliance. However, over time people introduce changes to the system or perhaps new automations are enabled. It is important to keep up with the ever-growing demand and that new functionality is not introducing non-compliance data.

Required tasks

Review Upstream Causes form this Playbook regularly

Periodically review output from the first play in this playbook. Alternatively, set up a report or add the count of Incidents without CIs to a dashboard. Rerun any play steps in the playbook as needed

Review compliance in non-production environment to earlier validate new functionality is not introducing non-compliance data

Finally, if your users are having a difficult time finding a CI then a CI Reference Qualifier might be a solution for you Congratulations You have completed this Get Well Playbook.