Is it a good idea to sync CMDB operational status from the asset state/substate?

[joshuamayes]

Hi guys,

[Background information]

I am very much a rookie when it comes to ServiceNow and only have a few months experience with it.

My organization is currently trying to implement Asset Management in ServiceNow.   Before ServiceNow our Asset Managment solution was a custom software which was not much more robust than a list of serial numbers and User IDs in an excel sheet.

While we were looking at the status synchronization from Assets to CI's we were unhappy with the out-of-the box use of CMDB Hardware state and substate, and decided that the best fields to use in the CMDB were Operational Status and Install Status.   We were actually happy with the out-of-the-box choices for the Asset State/substate fields and so we kept those (and added a couple).

[Decision Cliff-notes]

• We are using the ootb configuration for asset state and asset substate
• We are ignoring and disabling the use of hardware status and substatus on cmdb tables extending from cmdb_ci_hardware
• We will be using install_status and operational_status to track state information in the cmdb

[Decision justifications]

• An article was found where an SN employee stated that hardware status and substatus are remnants of a failed attempt to do asset management in the cmdb
• The intended use of hardware status seemed to infringe on the financial aspect of asset management, and we didn't feel as though this kind of data was useful or even made sense to track for a CI.

[The problem]

So by default ServiceNow includes a process that can sync install status and hardware status from the asset state/substate.   However, such a method appears not to exist for the operational status.   We are afraid that by not having the changes to the asset table update the operational status we will experience "data shearing" (a term that describes the same data existing in two places where the data does not match or conflicts the other data repository.   This condition damages a companies ability to trust either source of data.).

Additionally we are concerned that there may be a reason that ServiceNow decided not to include this process in the default configuration.

[The question]

• Is it fallacious of us to assume that the asset state and substate can determine a CI's operational status?
• Can anyone think of a reason for why we might not want this mapping and synchronization to occur?

Message was edited by: Joshua Mayes

[sachin_namjoshi]

Hi Joshua,

Please note that every asset won't have corresponding install status of CI.

e.g Windows server is a CI and it's not asset.Hence, it's not necessary to always sync asset state, substrate with CI operational status.

If you want this to happen on your instance, then you can create business rule to drive CI operational status with asset state for your selected classes.

Regards,

Sachin

[joshuamayes]

Hi Sachin,

Thank you very much for your response.   I have a pretty solid plan for actually implementing the synchronization and we understand that CIs without assets won't be affected by the asset/CI synchronization.

This question was more about best-practices and design philosophy rather than technical how-to's and limitations.

Basically we wanted to ask the community "Does this make sense to do?   If not, why not?"

[joshuamayes]

I edited the main question and wanted to try and bump this thread.

[akash_mehta · Accepted solution]

Joshua:   Great question and very well written and asked.   So thank you.

1)   You are correct Hardware status and sub-status are older concepts and not consistent from an overall cmdb standpoint.

2)   Your use of Asset State/Substate and CMDB Install Status and the sync between is correct.

        *   If you add items in your Asset State/Substate - you may want to map that to CIs via the Asset CI Install Status Mapping capability in ServiceNow (Asset/Administration)

3)   Operational status really shouldn't need to be "synced" with Asset status.   I have had customers use this field mostly with non-end user equipment devices...CIs that need Change Management.

        *   So when a CI is first created - if it needs change management to implement - the process should start with Operational status as "Non-operational", then the Change ticket will move it to "Operational".

Let me know if that helps.

-Akash