Evaluating custom Location table on the asset record

Product Success Playbook

A step-by-step guide to analyze and remediate custom location

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 Asset records

Play 3: Fix Play

Data Governance

Summary

Goal of this Playbook

This playbook helps you analyze and provides general guidance on identifying custom location tables or custom location attributes referenced from the asset table.

Details about this playbook

Author Mario Cassani Reviewer Daniel Slocum Date 11/02/2021 Addresses HSD # HSD0010620 Applicable ServiceNow Releases Paris, Quebec, Rome, San Diego Time Required Varies, depending on the instance customization level. Audience

Configuration Manager or Configuration Management team Asset Manager or Hardware Asset Manager ServiceNow Administrator or Discovery Administrator

Problem Overview

ServiceNow provides great flexibility to meet business outcomes when it comes to asset management. The ability to make copies of the current baseline processes and customize them to the business need makes the goals and objectives of each individual use case achievable in a short period of time. But having customization or trying to operate a process in a way that is not congruent with the ServiceNow design can become problematic.

Assets should have a defined and well documented location that allows managers and administrators to quickly identify where the physical asset can be found. Accurately tracking the location of assets supports the enterprise in the areas of technical support, regulatory compliance, disaster recovery, inventory, procurement, fixed asset and cost accounting, lease return, asset disposal, HR planning, and strategic planning.

Executive Summary

How this playbook can help you achieve business goals

Identifying if one or more custom location tables are present in your ServiceNow instance will enable you to review them for retention, deletion, or migration of data to out of box tables.

Similarly, the identification of custom attributes on out of box tables should lead to an evaluation and a decision to leave in place or to undertake a corrective action.

How this playbook is structured

This Playbook is structured to guide you through an analysis of the current state of custom locations. This playbook does not offer specific remediation steps as a result of the analysis, but rather 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 an optimal asset management experience and performance.

Once analysis and validations are complete, you can determine which custom attributes are to be migrated and/or deleted. These decisions should be based on the baseline alternatives, business value, and effort required. Doing so will support a cleaner and more maintainable asset inventory with location information.

Problem Analysis

Upstream Causes

Your organization may have multiple sources of location data integrated into ServiceNow. Possible sources include facilities databases, distributed asset management systems, and distributed network scanning systems. At the time the customization was adopted there may have been a lack of consensus for location data ownership coupled with an urgent business need, which led to the decision to add a custom attribute or table. An implementation, development or administration team member did not realize an appropriate attribute already existed within the models data schema. A legacy system had a particular attribute defined, and the implementation team decided to create a new field or table to hold legacy data rather than advocate for use of baseline fields. Downstream Consequences

Data Consequence

Unnecessary complexities in data model. Duplication of data across tables. Custom Mapping rules between the Asset and CI records may be in place, which need to be maintained. Operation Consequence

Ambiguity on the data when trying to use the location information ( looking at 2 different places ). Unnecessary investigation time searching for the correct location table. Increased complexity in reporting App Consequence

New functionality released by ServiceNow may duplicate the fields and data Data on custom tables will not be considered on baseline reports, dashboards and features Overhead maintaining process to keep custom tables data up to date

Impact on Your Business

Financial Optimization Incorrect location information will introduce increased costs based out of missed support contracts, incorrect warranties, incorrect maintenance vendors, inability to find assets for lease return, lack of inventory visibility, etc. Risk Compliance Ambiguity on the location data could potentially introduce associated risks with the assets. Ultimately introducing compliance issues with business policies regarding any kind of assets. Lower MTTR Having an incorrect location associated with the CI used in downstream processes like Incident and Change can adversely affect the MTTR KPI. An inability to physically find a CI to perform diagnostics, repairs, completion of a Change request, or resolution of an Incident will in many cases cause delays. Increase Operational Visibility When data is stored in multiple locations, selection of the correct data element is made more difficult, which impacts user efficiency and reporting. Better User Experience Fewer customizations within the table schema will result in simplified implementations and workflow development When data resides within expected fields there is a 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/tables in your Asset data implementation?

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

For each custom field/table, 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 table 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 table 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 tables been reviewed to ensure there are no newer base fields that can be used? How do you decide when to add a new attribute or table to your ServiceNow instance? Is there an Architect or governance team helping to make informed decisions? Have your custom tables and attributes been extended from baseline table?

Remediation Plays

Summary

The table below lists and summarizes each of the remediation plays in the playbook.

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 Asset Model tables Analyze Play

What this play is about

Analyze and document list of custom attributes/tables Required tasks

Analyze and document list of custom attributes/tables 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

In this play you will review the number of custom attributes on your Asset Model 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

Download and import the Non OOB Location Tables Fix script

Run the Fix script

Upon successful completion, review the output from the query

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

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

Play 2 - Analyze your asset records

Identify the owner of the attribute/table and the users of 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).

Is the information used for a business critical process? While the information captured in the custom attribute/table may have an identified owner, often field additions are to support a legacy business process. Identifying the business value a particular custom field or table 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.

Has ServiceNow released an equivalent base attributes or table? 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. Undertake an effort to compare your custom attributes and tables to the current out of box schema.

Are there similar attributes in other tables that could be used via a relationship? When implementing the models sometimes we need to add custom fields to capture specific information, at this point we need to think about where to add the new attributes. We need to think about if the new information will be useful at a parent class making it available to all tables extended from the parent class or if it is only needed on a specific table. It is also important to recognize if the data is available in a related table.

Can we use an extended table? If new information fields are needed that are not available on the location baseline table, we can create an extended table from the location table that will maintain the integrity of the out of box table while making the data available to the asset and CI record pair.

Play 3 - Fix Play

What this Play is about

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

This section does not give explicit step-by-step instructions on everything that can be impacted. However, as a rule, you will need to confirm the processes that utilize 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/table 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 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 location attributes without proper review and approval.

Required tasks

Document an internal policy that prevents the creation of new attributes/tables without approval from a qualified person or team

Institute a code review process that watches for custom attributes/tables in Update Sets

Create a report that shows any custom fields and tables created after the last attribute clean-up was performed. Review periodically with Stakeholders.

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

Congratulations

You have completed this Product Success Playbook.