Best practices in implementing Unauthorized Change capability

[Ed Laar1]

Hi,

ServiceNow Discovery is able to discover changes in the infrastructure like new CI's installed or Changes in/on already existing CI's and update the CMDB accordingly.

As every CMDB update should formally be based on an approved change request ServiceNow Discovery has the Unauthorized Change capability. In this capability a CMDB update executed by Discovery is checked against the existence of an approved change request. When this is NOT the case an Unauthorized Change is created and send to a group for post implementation approval.

Does anybody have any experience in implementing this and willing to share these experiences?

Looking forward to them,

Ed

[carl_hensley1]

Check out https://docs.servicenow.com/bundle/quebec-it-service-management/page/product/change-management/concept/unauthorized-change-request.html 

also note, you can set up ServiceNow to run discovery when a change is implemented.

https://docs.servicenow.com/bundle/madrid-it-service-management/page/product/change-management/concept/change-mgmt-integ-wth-Discovery.html

[Ed Laar1]

Hey Carl,

Thanks for your reply. Already found that docs out but I am looking for operational implementation experiences and best practices. Do you have any of such? What to do, which steps, how to set and so on.

Thanks in advance,

Ed

[carl_hensley1]

Hi Ed,

This will change by customer. My suggestion is to keep it simple and slowly refine it.

Start with the unauthorised change event, and ensure the change manager understands the process to be followed when an unauthorised change is detected.  See how many incidents are raised post changes via reports.

Having a simple process in place and using OCM to articulate that this is being monitored is a good start.  To me, the simplest is best with a known strong process to followup if detected, with meaningful reporting/dashboard to measure how well it is working (knowing whether you need to improve it or not) 

As for initiating discovery on a change, you just need to be careful, when the discovery is triggered, as it is triggered when the state changes (set in property either implemented or review).  Some customers have their discovery schedules set to discover devices at low peak times (of the device), so worth checking with the discovery administrator before considering this.

carl

[Ed Laar1]

Hi Carl,

Thanks for your info. Also my idea to start simple with:

A CI class containing very important CI's (that should formaly never been touched without an approved change)

A Change type with possibly the most impact on the involved CI out of this CI class

Regarding initiating discovery on a change: For me this is phase 2. My idea of the first phase is to run discovery by schedule and let the system check based on the above mentioned criteria.

Next step is to expand these criteria

Next +1 step is to initiate discovery on a change: What does this exactly mean? As soon as a CHG is set into a certain state discovery of the involved item/items is started? In that case there is an approved CHG so no worries or do I understand something wrong?

Thanks in advance for sharing and help!!

Ed