Best Practice for Managing Asset State \ CI Status

[Robin Hearne]

I have a question for all you process experts out there.   Before I begin, this isn't about what you could do, this is about what is the best thing to do from a process and tool perspective.   I always try to be guided by what ServiceNow provides out-the-box and try to understand how the product was intended to be used before making any changes.

We are planning our Asset and Config Management deployment and are trying to make a decision on how to manage Asset state \ CI status.   The primary consideration is how the desktop support techs will update the record(s) to show when the asset\CI is in use, in maintenance, returned to a stock room etc.

The OTB experience is that the Status field isn't even exposed on the CI form, which leads me to think that the intended use is to manage it there and let the mapping feature take care of updating the CI status.   Also, previous ServiceNow documentation states "As a best practice, ServiceNow, Inc. recommends updating status on the asset form" (although this is from 2015 and this doesn't seem to be included in the latest documentation).

However....

This somewhat contradicts ISO\ITIL "best practice" which recommends that IMAC is part of the Configuration Management process, rather than the Asset Management process.   Also, the ITIL role only has read permission to the Asset record, so the desktop support techs would need the 'asset' role, which is arguably inappropriate given that they aren't really involved in the Asset Management process (just Configuration Management).   From a tool perspective, in order to manage IMAC in Configuration Management would require a number of changes on the CI form, such as adding the Status, plus exposing other fields such as Location, Stock rooms etc.   Which whilst simple to do, still suggest to me that this isn't how ServiceNow was intended to be used.

I'm leaning towards managing Asset State and either assign the Asset role or add an ACL to allow ITIL users to update the Asset State, Location etc, but I'd welcome other options before making a decision.

bsweetser - Hoping you might be able to give your opinion on this?

Thanks in advance.

Robin

[Damhoej]

I have the same observation, and lack an overview of the entire process in phases (a diagram of the life cycle of assets in ServiceNow).

It seems to me, that ServiceNow has been developed by technicians for technicians, and now the Business Process people are knocking at the door 😉

The documentation could benefit from some diagrams stating the intended flow and processes.

[Robin Hearne]

I just spotted a small typo in my original post which could make it confusing.   The third paragraph should have been:

The OTB experience is that the Status field isn't even exposed on the CI form, which leads me to think that the intended use is to manage it in the Asset record and let the mapping feature take care of updating the CI status.   Also, previous ServiceNow documentation states "As a best practice, ServiceNow, Inc. recommends updating status on the asset form" (although this is from 2015 and this doesn't seem to be included in the latest documentation).

[Daniel Slocum]

Hi Robin,

I've been asked this question many times.   I agree with you that IMAC, based on ITIL standards, is part of Configuration Management. Ultimately, this question is best answered by you as you know what is best for your organization and your deployment. As I've engaged with our customers, I've made the following recommendation. When the Asset is somewhere in the Asset Lifecycle manage Status Updates from the Asset Record.   When the Asset has been deployed manage updates from the CI.

[Community Alums]

Hi Robin,

What I often recommend is this comes down to process. From a technology standpoint, you could do this from either direction, but when it comes to asset related processes, it is best done from the Asset record, but as you state, that does not always make sense. Let me elaborate with a visual of the lifecycle:

The red portion of this diagram represents the Asset portion of the lifecycle. When you are making any changes in that portion of the lifecycle, it makes sense that those State changes are initiated against the Asset record. This includes moving from In stock to In use and even back into stock when a device is decommissioned.

The blue represents the operational aspects of the lifecycle. For state changes where something remains In use from the asset perspective, it certainly makes more sense to just be updating the Status of the CI and not even touch the Asset state if you do not need to. An exception might be if you transition something back to a "stockroom" for repair or maintenance.

All this being said, if you get your processes set up properly, you do not end up touching the State/Status of the Asset or CI unless it is from an exception standpoint. Then the updates become driven by the workflow. Then you end up tracking the process instead of managing states.

Take a break fix example. If your technician cannot access the Asset information, make a UI Action (button, link, context menu) from the CI record (or better yet, the Incident record) to pull the device back to a stockroom for repair. Identify what the process looks like here and that tasks that go into it. Put it in a workflow. Include steps in the workflow that update State on the Asset accordingly. Then you are focused on the the process you need to track to get the work done, and State/Status is updated as part of that process.

I hope this helps. Please let me know if you need more information.

Thanks,

Ben