Changes Without CIs - Product Knowledge

Changes Without CIs  . Get Well Playbook

Percent of Changes referencing a CI

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 Play - Validate there are changes without CIs

Play 2: Analysis Play - Custom CI field usage

Play 3: Fix Play - Mark CI field as mandatory

Play 4: Analysis Play - Identify top offenders (optional)

Play 5: Data Governance

Summary

Goal of this Playbook

To help you identify and remediate Change records with missing or empty CI.

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

Change Management Process Owner or Change Management team

Configuration Manager or Configuration Management team

ServiceNow Administrators

Problem Overview

A Change should always record what was changed (CI), what was impacted by the change, who approved the work and if it got implemented successfully. Organizations not utilizing these components tend to have more unauthorized, failed and emergency changes.

Changes that have not been properly vetted prior to execution could potentially result in unintended outages caused by the change.

Executive Summary

How this playbook can help you achieve business goals

This playbook will guide on how to ensure that you are recording what component has been changed.

How this playbook is structured

This Playbook will guide you through five (5) plays.

Play 1 - Analysis Play - helps you identify Change records with omitted CI values

Play 2 - Analysis Play - helps you identify Change records that reference CI by means of custom attributes

Play 3 - Fix Play - tells you how to set the CI field as mandatory at Change resolution stage

Play 4 - Analysis Play - helps you identify top offenders who do not record CIs in the system

Play 5 - Data Governance Play - lists guidelines and processes for continuing to ensure your Change workers are correctly closing tickets

Problem Analysis

Upstream Causes

Change Workflow does not require the CI field to be populated, as tasks are used to identify each CI in the change.

CI field is not mandatory at the right stage in the change lifecycle.

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

CIs are difficult to locate and hence are not mandatory.

CIs are not in the CMDB and hence are not mandatory.

Downstream Consequences

Data Consequence

Unable to report on change trends such as: CI with frequent changes, total outage time caused by a change

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

Proper authorizations to perform the change might not be obtained

Unable to evaluate the risk of the change

Unable to communicate outages to customers

Increased inefficiencies when a change is not successful App Consequence

Unable to use automation or workflows that automatically assign approvals based on CI ownership

Unable to use base features such as Priority, Risk and Impact assessment

Unable to use conflict checker

Unable to check if the change is within designated windows

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 know what was changed?

How do you know who needs to approve a change?

How do you evaluate Impact, Risk and Priority of a change?

Who do you notify if a change is not successful?

How do you communicate changes to the consumers?

How do you prevent outages caused by changes?

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

How do you check for conflicts and schedule of a change?

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 there are changes without CIs

What this play is about

Identify percentage of changes without a CI Required tasks

Install Dashboard and review output Play 3: Analysis - Custom CI field usage

What this play is about

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

Run script and review output Play 3: Fix Play - 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: Analysis Play - Identify top offenders (optional)

What this play is about

Identify requestors and implementers who do not provide CIs Required tasks

Run script and review output Play 5: Data Governance

What this play is about

Helps you establish periodic review of changes without CIs Required tasks

Provides steps to periodically review changes without CIs

Play 1 - Analysis Play - Validate there are changes without CIs

What this Play is about

Identify Change records with missing or 'empty' values in the Configuration Item field or attribute

Required tasks

Download and import the CMDB Fix Script .

Run the script as a Fix Script and review the results.

Download and import the Changes Without CIs Dashboard.xml Dashboard Update Set. For more information, see Retrieve an update set .

Once you have successfully installed the Dashboard, navigate to it.

The first card will provide the count of changes created in the last 60 days that do not have a CI identified.

The second card will provide the count of all changes created in the last 60 days.

Sample:

If there are no changes without a CI, then this playbook does not apply to you. Otherwise, proceed to the next play.

NOTE: You might have to modify the script and provide a filter, if you wish to exclude changes with specific status codes (e.g. Draft or Cancelled). This is important to modify to get a more accurate picture.

Play 2 - Analysis Play - Custom CI field usage

What this Play is about

Many customers have customized the way they track CIs during the change lifecycle. Some have created their own CI field; some require the CI on a change task. This play will attempt to identify other fields that reference the cmdb_ci table.

Required tasks

Navigate to System Definition > Dictionary (sys_dictionary.list)

Apply the following filter:

Table (name) IS change_request 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 change_request table

Reference IS Configuration Item

Or alternatively run this script .

Sample:

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 query/script to check against your CI field to get a more accurate picture. Once this is done proceed to Play 3. You will need to modify any scripts to reflect your customization.

If you are using change tasks to track the CIs, then return to Play 1 and modify the script to evaluate the change_task table instead.

Play 3: Fix Play - Mark CI field as mandatory

What is this Play about?

This play helps you make the CI field mandatory upon submission of the Change Request. If the CI is not clearly marked on the Change Request, then your Change Advisory Board (CAB) should reject the request.

If you discovered a customization in the preceding Plays, you should update any applicable policies or procedures.

Required tasks

Before you begin please note the following:

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

In addition, a process change of this magnitude requires alignment from your Change Management Process Owner and might require a communication plan, so your users understand what is required of them.

Create a new Data Policy. To learn more about Data Policy, review our product documentation .

Enter the following: Table: Change Request

Short Description: Make CI mandatory for NEW Change Requests

Description: Make CI field mandatory for NEW Change Requests (or enter a description that is meaningful to you)

Conditions

State IS New

Consider adding State IS NOT Draft if you allow Draft/Placeholder change records to be created

Sample:

Click Save

On the form, in Related List > Data Policy Rules, click New

Enter the following:

Field Name: CMDB_CI

Mandatory: True

Read Only: Leave Alone

Sample:

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

Create a NEW Change Request

On form load notice that the Configuration Item field is now mandatory

Sample:

Validate this did not have an adverse impact on any custom rule or workflow you might have implemented

Sample:

Play 4: Analysis Play - Identify top offenders (optional)

What is this Play about?

In this Play you will rview the top offenders that submit or perform changes without CIs

Required tasks

Return to the Dashboard you have imported in Play one

Review the output and identify the top offenders for each category

By Type - what change types are not requiring the CI?

By Assignment Group - what groups perform changes without CIs?

By Created By - who are the users that create changes without CIs?

By Category - what change categories are not requiring the CIs?

By Close Code - are changes without Cis more likely to fail?

By Closed By - who is closing the change without the CI?

Sample:

Follow up with the top offenders as to why they create or close changes 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 made easier for them to add the CI

If change requests are created form templates, review Standard Change Properties (or any custom properties you might have created) and ensure that Configuration Item is mandatory or pre-populated when possible

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

Did the integration ever work properly?

When did it stop working?

Who can fix it?

Top offenders represent one or more broken processes in your organization. The voices of these customers and their feedback should not be ignored. Work with them to improve your Change Management process and close any identified gaps.

Play 5: Data Governance

What is this Play about?

This Play lists the healthy habits around periodic validation of change request data to CI.

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

Required tasks

Periodically run and review output generated using Play 1 of this Playbook. Alternatively, set up a report or add the count of Changes without CIs to a dashboard. Rerun any Play steps as needed.

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

Work with your Change Advisor Board (CAB) to ensure they do not approve any changes where the CIs are not properly identified.

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.