Change process and missing CI information

[Chaz_]

Hi,

I would like to get a steer on what a best practice solution would look like for the following use case. I am looking to minimise technical debt where possible and provide a solution which meets good architectural design principles.

When raising a change against CIs, a quality gate is needed which prevents the user from raising changes where any of the affected CIs is missing data defined in the CMDB Health recommended fields for that class. If CI information is missing on any of the selected CIs, then the user should be prompted to update the CI(s) by means of a link which appears in a pop-up box. If they own the CI, they should be able to populate the missing data without too much delay. If they don't own the CI, a notification should be sent to the CI owner asking them to populate the data as someone is trying to raise a change against it.

Above is a high level summary. I'm looking for ideas or suggestions as to how this can be best implemented. A few reasons I've posted in here are as follows : I'm not too sure whether a flag would be appropriate on the change or individual CIs, and how that would be maintained ie. through a daily job. We would need the CI to be usable on a change immediately after the data has been corrected, so a flag on the change may be better and then lookup each CI. I'm wondering how much load time it would add to a change if this check was added to lookup each CI and check against its list of recommended fields in CMDB health. Hope the logic makes sense. Would welcome any suggestions.

Thanks.

[Daniel Borkowi1 · Accepted solution]

Hi @Chaz_ ,

I wouldn't built this in the Change Management Process - in my Opinion it's too reactive waiting for a change. It's part of the Configuration Management Process. You can measure CI Health like completeness there. And if something isn't in a healthy state you can create CMDB Health Metric Tasks and assign it to Data Owners - with a SLA and escalation behind. This is quite more proactive - imho. 

Greets
Daniel

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Chaz_]

Thanks Daniel. I like this solution and approach.

Just a final question - would it be possible to link the CMDB health metric tasks to a change, so that when raising a change, it checks against the health metric tasks and stops the user from progressing the change if they have open health metric tasks against the CI(s) being affected on the change?

[Daniel Borkowi1]

Hi @Chaz_ it's not out-of-the-box available, but that's easy because Change Request and Health Result (cmdb_health_result) is linked to the unhealthy CI. These records contains also all needed information - CI is related and description contains reason what is wrong.  So it's an easy logic. You can also build a related list which shows all Health tasks attached to an CI which is attached to the Change, use sys_relationship_list.

Btw. if you want additional use Health Tasks to proactively assign remediation task to responsible teams,  you need to decide for which Health Metric a task should be created (https://<instance>.service-now.com/$cmdb_health_properties.do). Here you need to select under Health Metrics(tab on right side) the metric you want to have such a task and then enable Create Task.

Greets
Daniel

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Chaz_]

Thanks for your advice on this. That's great.