Capture change request affected CIs & impacted services related lists into a template

[rlehmann]

We are currently working towards our implementation of Change Management,

Our change request form has the related lists of affected CIs and impacted services, as they relate to the primary CI field and BSM.

One of our requirements is for our ITIL users to be able to create templates for changes they perform against the same set of affected CIs/services.

The challenge we are having is that there doesn't appear to be a way to capture the affected CIs/impacted services information within a template.

Even as administrators, we have been unable to find a way to capture these fields within a template.

Our ITIL users will not be receptive to the new change management process if they cannot utilize templates with multiple affected CIs/impacted services.

We are wondering if there is something we missed or if anyone else has come up with a viable solution to address this requirement?

As always, any information shared is greatly appreciated.

Cheers

Ron

[Michael Fry1]

You should be able to create related templates on the CI's affected (task_ci) table for Affected CI's and task_cmdb_ci_service table for Impacted Services.

[ronaldstagg]

Hi Ron,

I am exploring a solution for a similar situation. What I am doing as a POC in our organization is to leverage configuration groups (cmdb_ci_group) to define our patch groups.

Here's what I did:

1. Asked Our SrvrOps team to give a list of major patch groups for various "chunks" of our environment. Fir each group, I asked for all member servers.
2. I created a business service "Patch Management" as a child service under "Datacenter Management". Under "Patch Management", I used the names of each patch group pre-pended with "PatchMgmt"" such that a patch group my SrvrOps team calls "Domain Controllers", in my CMDB, I will call it "PatchMgmt: Domain Controllers".
3. I created a relationship type: "Patches::Patched By".
4. Based on their inputs, I created importable spreadsheets for the patch groups, the CI for servers I didn't already have in our CMDB, and the relationships between the server CI's and their parent patch groups AND between each patch group to the parent business service of "Patch Management".
5. Then, I created a business rule to update the Affected CI's list whenever there is an update to the change record. There is an OOB BR called "Add CI in affected Cis List" I deactivated and created a custom rule from:

Name:   Custom - Add CI in affected Cis List

Table: change_request

Active: true

Advanced: true

When to run: "After" Insert, Update

Advanced:

Condition: gs.getProperty('change.conflict.mode')=='advanced' && current.cmdb_ci!=''

Script: (see below code block)

//clear any items currently in the affected CIs list

removeAffectedCIs(current.sys_id);



//add children of "cmdb_ci"

addCiChildrenAsAffectedCIs(current.cmdb_ci,current.sys_id);



function addCiChildrenAsAffectedCIs(argCi, argTask) {

     var rel = new GlideRecord('cmdb_rel_ci');

     //find all related cis where configuration item is parent in a relationship

     rel.addQuery('parent',argCi);

     //include this line to only find CIs of a given class, not all CIs

     //rel.addQuery('child.sys_class_name','cmdb_ci_server'); 

     rel.query();

     while (rel.next()){

           if(!ChangeCollisionHelper.isCiInAffectedCis(rel.child,argTask)){

                 ChangeCollisionHelper.addCiToChangeAffectedCis(rel.child,argTask);

           }

     }

}



function removeAffectedCIs(argTask) {

     var m2m = new GlideRecord('task_ci');

     m2m.addQuery('task',argTask);

     m2m.query();

     m2m.deleteMultiple();

}

If you have all your relationships set properly, whenever you choose a patch group CI, the children should populate.

I am still currently working on the Affected Services, piece. If I don't follow-up to this post, ping me back in a week or so.

Caveat: I have not had this in production yet, so, your mileage may vary and it may not work at all for you, but, hopefully it will get you started.

Hope this helps!

[rlehmann]

Hi Ronald

That is definitely an interesting approach, which should be workable.

Please do let us know if this ends up working out the way you anticipate, once you move it to production.

Thanks

Ron

[ronaldstagg]

Ron L.,

Will do, we are about 2 weeks from implementation, have made some tweaks from the original POC. Will update with details post-deployment.

Since the original POC, we've added "Impacted Services", such that, if a system that is patched support multiple business services, we can enumerate those on a separate tab for use during our CAB meetings.

This will be a huge win for us, because, now, we wont rely solely on "tribal knowledge" for potential risk or impact. We'll have the relationships properly defined in the CMDB and we'll let the tool do the heavy lifting