Evaluating custom hardware model fields - Product Knowledge

Evaluating custom hardware model fields  Product Success Playbook

Evaluating custom hardware model fields

A step-by-step guide to analyze of Custom hardware model 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 Asset Model records

Play 3: Fix Play

Data Governance

Summary

Goal of this Playbook

This playbook walks you through the analysis and general guidance on identifying custom hardware model fields. Excessive custom attributes on model records should be reviewed to ensure they are both relevant and appropriate. With each new ServiceNow release a review of custom attributes is needed to preclude conflict with new out of box features and to identify if new features fulfil the business need that resulted in the creation of custom attributes.

Details about this playbook

Author Mario Cassani Reviewer Daniel Slocum Date 11/02/2021 Addresses HSD # HSD0010592 Applicable ServiceNow Releases All Releases 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 significant flexibility to meet business outcomes when it comes to asset management. The ability to add attributes to hardware model records seems as if it would be innocuous, not having much, if any, detrimental impact to out of box processes and platform applications. To that end, you’d mostly be correct. Where customers who add attributes to the hardware product model table encounter trouble is maintaining tech debt and upgradability.

Trustworthy hardware assets is at risk when model information is missing or inaccurate. The creation of custom attributes precludes automatic upgrade of the model form when SerivceNow releases changes, which increases customers additional effort during upgrade and the potential to miss critical new features do to skipped updates.

The Hardware model form contains prerequisite data to create asset records with a related configuration item in the proper CMDB class. Model detail also provides information to the creation of Service Catalog items such as potential substitutes and compatible assets as well as cost detail from vendors.

It is common for customers to consider the model record for the addition of attributes to record security releases, patches and vital information to secure the type of hardware. While this data can be useful to Risk Management, Security Operations and Configuration Management, having custom fields on the model can duplicate and / or make information ambiguous to the point that the information is not usable.

Executive Summary

How this playbook can help you achieve business goals

Identifying custom attributes will allow you to conduct a review to determine if a custom attribute can be migrated to make use of baseline attributes. This will align with the business goal of cost optimization when upgrading the platform. Similarly, identifying any custom attributes can lead to an evaluation and corrective action, increasing the optimization of resources by making the platform closer the baseline. If no custom attributes are present, you are assured that when ServiceNow releases new values, those are not missed. If you do identify custom attributes are present, you should review your instance upgrade history to identify if any updates have been skipped. Most notably those would be related to hardware model forms, workflows, script includes, business rules, and client scripts.

How this playbook is structured

This Playbook is structured to guide you through an analysis of the current state of hardware model 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 your analysis and validation are complete, you can determine which custom attributes are to be migrated and deleted or retained. These decisions should be based on available out-of-the-box alternatives, business value, and effort required. Doing so will support a cleaner and more maintainable asset inventory, while avoiding potential data issues that can severely impact assets inventory 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. An Implementation, development or administration team member did not realize an appropriate attribute already existed within the model data schema. Development mistakes such as correcting a field name typo within the same Update Set, without pruning the incorrect attribute from the Update Set before promotion. 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 baseline fields.

Downstream Consequences

Data Consequence

Unnecessary complexities in data model. Duplication of data. Custom Mapping rules are in place and need to be maintained. Data on custom fields will not be considered on the baseline reports, dashboards and features Operation Consequence

The model form may not be current causing out of box features to not function as designed. The model record may be heavily customized to support Risk Management, SecOps, and Configuration Management business needs that may be better supported through the use of process specific applications available the ServiceNow platform. App Consequence

Upcoming functionality or newer applications may duplicate the fields and data Overhead creating/maintaining processes to keep custom fields data up to date Discovery and other applications might populate base attributes as intended, leading to data mismatches and confusion List views could contain more than one of the same labels for different fields, leading to confusion

Impact on Your Business

Risk Compliance Ambiguity on the model data could introduce associated Service Asset and Configuration and compliance risks for asset and CI records related to the model. Lower MTTR Having an incorrect model associated with the CI used on downstream processes like incident and change will affect the MTTR metric because of the incorrect extended data of the model.( eg: warranty, support contract, etc. ) Increase Operational Visibility Data can be wrongly selected based on the duplication or inadequate data severely impacting visibility. 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 model 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 orphaned?

Can you verify where the custom attribute is being used across the platform? 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 customization 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 model tables? Is there an architect or governance team helping to make informed decisions?

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 hardware model table Analyze Play

What this play is about

Analyze and document list of custom attributes Required tasks

Analyze 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 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 customizations.

Required tasks

Download and import the Custom Fields Hardware Model Fix script

Run the Fix script

Upon successful completion, review the script output

Note 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 after reviewing the results. In the next section we will analyze each field individually. Play 2 - Analyze your Asset Model records

Who is the owner of the attribute and who is using that data? A team or individual should ultimately have been responsible for adding the attribute in the Asset table in the first place. This team or individual can often 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 may have an identified owner, often the fields additions were to support a legacy business process. Identifying the business value 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 a candidate for removal.

Have equivalent base attributes become available in the platform? 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.

Does the hardware model have the information asset managers need? When we add a custom field to the hardware model we need to keep the data up current. If the custom field has no data, it has no value rendering it a good candidate for removal.

Play 3 - Fix Play

What this Play is about

Once you have identified candidate attributes for retirement or migration to a base/upgraded 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, generally, you will need to confirm the people, processes, and platform features/elements that use the custom attributes you have today, and then determine if that usage drives business value greater than the maintenance costs of maintaining each custom field. This effort can require time and careful consideration. When implementing changes, 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 frequently cloning production down to dev and test instances. Use scripts to migrate existing data from custom fields to any base or equivalent fields. Make 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:

Workflows Forms Reports Business Rules UI Actions Client Scripts Email Actions Transform Maps Catalog Items and variables/variable sets 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 Model Manger, Asset Manager, CMDB Owner, should approve any additions to the baseline of hardware model 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 Model attributes without proper review and approval.

Required tasks

Document an internal policy that prevents the creation of hardware model attributes without approval from a qualified person or team

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

Create a report that identifies custom fields on hardware model tables created after the last attribute clean-up was performed. Periodically review the report with Stakeholders.

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

Congratulations You have completed this Product Success Playbook.