Use of custom attributes in ITAM


Get Well Playbook

Use of custom attributes in ITAM

A step-by-step guide to analyze and remediate ITAM Custom fields

 

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: Review your data

Play 2: Analyze your custom records

Play 3: Fix Play

Data Governance

 

 

Summary

Goal of this Playbook

This playbook does not provide specific remediation steps, but general guidance in identifying custom attributes in your IT Asset Management implementation. Excessive custom attributes should be reviewed to ensure they are both relevant and appropriate.

Details about this playbook

Author Emir Eminovic
Date 11/02/2021
Addresses HSD # HSD0010434
Applicable ServiceNow Releases All Releases
Time Required Approximately 1 to 8 hours

Audience

  • Asset Manager or Asset Management team

  • ServiceNow Admin

 

Problem Overview

ServiceNow provides an enormous amount of flexibility to meet specific business outcomes. While customizations can often help achieve business value, using customizations inappropriately - either when an out-of-the-box solution exists, or at an incorrect implementation level, should be avoided.

Custom attributes provide flexibility to address business needs. In older versions of the ServiceNow Asset Module, some attributes did not exist that are now available out-of-the-box. Whatever the reason to create these as custom attributes (indicated by the u_ prefix of the field name) is, if now platform provided fields are available, data should be migrated to make use of the native fields as soon as possible. 

Using out-of-the-box attributes provides benefit both from ease-of-upgrades, and from ensuring that data is in well-understood locations that can be used by multiple applications throughout the platform. If business data resides in custom attributes, these may be shown on specific reports that have been created to consume the data, but the value may be lost in other applications that would also consume this information in out of the box reports or processes.

Executive Summary

How this playbook can help you achieve business goals

  • Identifying custom attributes will enable you to review them, determining which can be migrated to make use of out-of-the-box attributes.

  • Documenting existing customizations reduces risk during upgrades and implementation of new modules in the platform

How this playbook is structured

This Playbook is structured to guide you through an analysis of the current state of Asset custom attributes. This playbook does not offer specific remediation steps as a result of the analysis, but rather we provide some general guidelines. None of the plays are required actions. Good judgement and careful thought should be used in choosing one or more of these plays to guide you towards optimal Asset Management experience and performance.

Once analysis and validation are complete, you can determine which custom attributes are to be migrated and/or deleted. These decisions should be based on the out-of-the-box alternatives, business value, and effort required. Doing so will support a cleaner and more maintainable Asset implementation, while avoiding potential data issues that can severely impact Asset and CMDB trust and efficacy.

 

Problem Analysis

Upstream Causes

  • At the time of customization there were no appropriate attributes provided for a legitimate and urgent business need, which led to the decision to add a custom field

  • A legacy system had a particular attribute defined, and the migration implementation team decided to create a new field rather than advocate for use of out-of-the-box fields

 

Downstream Consequences

Data Consequence

  • Unnecessary complexities in data model

  • Custom Data is not replicated in the CMDB

  • Custom Mapping rules are in place and have to be maintained

 

Operation Consequence

  • CMDB and Asset are not in sync

  • Extra overhead to maintain these additional fields in database, including the time required for new team members to learn custom attribute names

App Consequence

  • Overhead of maintaining custom solutions to populate data in non standard fields

  • Newer applications and features provided by the platform will expect that data resides in provided fields

  • Data in custom attributes not used in newer platform provided reports, features, dashboards, notifications etc..

 

Impact on Your Business

  • Increase Operational Visibility

    • When using baseline fields, there is greater chance of process alignment to well understood practice guidelines which are built into the platform

    • Data integrity and reliable operation of your platform will contribute directly to providing the maximum amount of information for any business process using it

  • Process Automation

    • There are many provided digital workflows throughout the platform its applications. These can be used immediately when data resides within the provided fields

    • As these workflows evolve, less time will be spent updating customized versions of them to continue the use of custom attributes

  • Better User Experience

    • Fewer customizations within the table schema will result in much simpler implementations and workflow development

    • When data resides within expected fields there is a more reliable and consistent experience for developers, admins and users

 

Engagement Questions:

Consider the answers to these questions:

  • Do you have a list of all custom attributes in your Asset Implementation?

  • Does every custom attribute have an identified business reason behind its existence?

  • For each field, is there an owner who needs that attribute? Has that field been populated, maintained, governed and secured or has it been forgotten?

  • Can you verify where the custom attribute is being used? Is it being populated simply because “we’ve always had to populate it”, or because there is actual value being realized?

  • Was a custom field added with the intent to drive a particular user behavior, and is that goal obtainable through any means other than customization?

  • Has the effort of maintaining the customizations outgrown the value of having them?

  • Have custom attributes been reviewed to ensure there are no newer base fields that can be used?

  • How do you decide when to add a new attribute to the Asset Tables? Is there an Architect or governance team helping to make informed decisions?

  • How is this custom field mapped to the CMDB?

 

Remediation Plays

Summary

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

Play Name

 

 

Review your data

What this play is about

Query and Analyze existing schema of your instance to get an idea of the current state

Required tasks

Review list of custom attributes in your ITAM tables

Analyze Play

 

 

What this play is about

Review and document list of custom attributes

Required tasks

Review and document list of custom attributes

Fix Plays

What this play is about

Guideline on how to approach the cleanup process

Required tasks

Guideline on how to approach the cleanup process

Data Governance

What this play is about

Includes guidelines and processes for managing customizations

Required tasks

Follow these guidelines and processes to prevent unauthorized customizations

 

Play 1 - Review your data

What this Play is about

In this play you will review the number of custom attributes on your Asset tables and the specific tables they are on. You will also be provided guidance on what these values can mean and what to do if you have extraneous customizations.

Required tasks

  1. Download and import the Custom Attributes in CMDB Fix script

  2. Run the Fix script

  3. Upon successful completion, review the output from the query

    Note the actual table names and column names will be different, but a sample of the output is below:



  4. In general, we want to reduce the number of custom fields after reviewing the results. In the next section we will analyze each field at a time.

Play 2 - Analyze your custom fields

What this Play is about

Identify the reason behind why these attributes exist. Find out why were they created, who owns them and are they still used.

Required tasks

  1. Who is the owner of the attribute and who is using that data?

    A team or individual should ultimately be responsible for adding the attribute in the Asset table in the first place. This team or individual often can also be the person consuming the information that is captured here.

    If an owner cannot be identified, or more importantly, if individuals or teams cannot be identified who are actively using the data, the attribute is a strong candidate for removal (not migration).

  2. Is the information used for a business critical process?

    While the information captured in the custom attribute may have an identified owner, often the fields additions were to support a legacy business process. Identifying the business value that a particular custom field delivers is an important factor in determining if the attribute should be retained. If the attribute population is done simply because “we've always done it this way” or because it is to maintain historical trend data that otherwise has no current value, then that field is also a candidate for removal.

  3. Are there now equivalent base attributes available?

    Many custom attributes were created for good reason: they captured data critical to a business process in a field that was not available in the product at the time of release / implementation. However, with the rapid evolution of the ServiceNow platform, new and improved table structures are introduced with every family release. Forms, reports, dashboards, workflows, notifications, and much more are all built to make use of these provided fields.

  4. Are there similar attributes in other tables that could be used via a relationship?

    Sometimes during an initial implementation, relationships between tables are not leveraged as fully as they could be. If the data for a custom field is already tracked in another table, the existing table and column should always be used rather than creating a new field. More than likely there is a reason the data is in that other table, and there might even be other fields in that table which can be made accessible through this intended use of relationships and related lists. 

    Establish a relationship between the two records instead of copying and maintaining data in two places.

  5. Does the CI have the information Asset Managers need?

    There is a sync between Asset and the CMDB which can be bi-directional. An attribute that exists on a CI does not need to be replicated on the Asset record, but rather you can reference through dot walking and display to the asset manager.

 

Play 3 - Fix Play

What this Play is about

Once you have identified candidate attributes for retirement or migration to a base attribute, you should review the usage of it before carrying out any remediation.

This section does not give explicit step-by-step instructions on everything that can be impacted. However, as a general rule, you will need to confirm what uses the extraneous attributes you have today, and then determine if that usage outweighs the costs of having each custom field. This effort can require time and careful consideration. It may be best to align efforts to coincide with platform upgrades when users are already expecting small changes to their experience. You may save time in User Acceptance Testing by doing these in tandem.

Remember to not make changes directly in production. Always follow your established development practices such as a frequently cloning production down to dev and test instances. Use scripts to migrate existing data in custom fields to any base or equivalent fields, making sure to check that field types and maximum lengths are the same or appropriate.

Required tasks

1. Check for any usage of the custom attribute including:

    • Forms
    • Reports
    • Business Rules
    • Relationships
    • UI Actions
    • Client Scripts
    • Email Actions
    • Transform Maps
    • Any other components

2. Once you have identified where any data is used (if at all), you can understand the impact of deleting the custom attributes. Reference ServiceNow docs for more information around deleting table fields

 

Data Governance

What this Play is about


It is recommended that the Asset Management owner, in partnership with the CMDB Owner, should approve any additions to the baseline Asset attributes that are requested. Not all custom field additions should simply be approved.

This play tells you how to set up a process that keeps others from creating custom CMDB attributes without proper review and approval.

Required tasks

  1. Document an internal policy that prevents the creation of Asset attributes without approval from a qualified person or team

  2. Institute a code review process that watches for custom attributes in Update Sets

  3. Create a report that shows any custom fields on asset tables created after the last attribute cleanup was performed. Review periodically with Stakeholders.

  4. Regularly review IT Asset Management release notes for announcement of new attributes

 

Congratulations

You have completed this Get Well Playbook.