Crossfuze is pleased to invite you to attend a free partner webinar presented by BDNA, and presented by Crossfuze’s co-founder and CTO, Jacob Andersen.
This webinar will cover licensing complexity, software proliferation and poor quality data that have made Software Asset Management (SAM) complicated and laborious. We’ll show you how to:
Date: Thursday, December 11, 2014
Time: 10:00am PT / 1:00pm ET / 18:00 UTC
Visit the BDNA Registration page: http://tinyurl.com/sam-chasm
Several years ago, I worked on a large ServiceNow implementation of change management. One of the key requirements on that project was to allow for the logical grouping of CIs. The primary reason for this grouping was to facilitate referencing and adding/removing these common CIs when they were all affected. This is fairly common when you’ve got a group of CIs that need the same routine maintenance or patching for example. You can imagine if you had to do this constantly for 100 different CIs how much of a pain that could become :). This capability doesn’t exist in ServiceNow and it’s actually more complex to implement than you would think but I’ve had a solution for it for quite some time.
In response to a few questions on the ServiceNow community I’ve decided to formalize this solution in an update set and publish it here on ServiceNow Guru. It allows for much simpler management and usage of these grouped CIs and can be found here in the ‘Configuration Item Groups’ update set. This has also been incorporated along with several hundred additional improvements in the Crossfuze Change Management turnkey solution. If you like this solution and are looking into change management, I highly recommend taking a look and requesting a demo!
he ability to associate Affected Configuration Items against a task is one of the most basic pieces of the various task forms in ServiceNow. ServiceNow gives you the ‘Configuration Item’ field to associate a single CI and the ‘Affected CIs’ related list in the event that your task needs to be associated to multiple CIs. I’ve written before about the benefits of tracking all of this information in one place to simplify reporting and usage requirements. During an onsite visit with a customer this week I noticed another opportunity to improve the functionality of the ‘Affected CIs’ related list. It would be very useful to be able to right-click items in the ‘Affected CIs’ related list and show a BSM Map or associated tasks just like you can do for the ‘Configuration Item’ field UI Macro icons. This post will show you how you can set these list context UI Actions up in your instances.
t should come as no surprise to you that, if used properly, your CMDB can be an extremely valuable input to your incident/problem/change processes. This is true not only of the actual CIs, but also the ‘Affected CI’ records that you create. ServiceNow gives you a couple of different places to track this information. The first is the ‘Configuration Item’ field available to all Task types in the system. You can add this field by personalizing the form for any task. The second is the ‘Affected CIs’ (task_ci) many-to-many table. This can be added to any task form in your system by personalizing the related lists for that form.
This setup allows you to track a primary CI or Business Service against a given task in the field on the form, and it also allows you to track multiple Affected CIs against a task if necessary in the related list. What I don’t like about this setup is that these are managed independently so there’s not a single place to see ALL of the Affected CIs in your environment. My solution to this problem has always been to centralize all of this information into the ‘Affected CIs’ related list by copying the ‘Configuration Item’ field value into it. This simple idea gives you a much better look into your Affected CIs for reporting, and allows for more proactive troubleshooting through CI Business Service Maps as an input into your task processes.
ne of the most basic needs that a customer has when building out their CMDB is extending it to match the types of CIs that they’re currently using in their company.Â This is especially true when bringing data in from a 3rd-party CMDB (such as IBM’s CCMDB, HP’s uCMDB, etc) with Service-now.Â Some of these CMDBs have hundreds of class types with scores of fields for each class.Â How can you get the 3rd-party data into Service-now when the schema is so different?
There are essentially four main steps to accomplish this: decide what classes and fields need to be brought across, create a mapping document, extend the Service-now CMDB to accept the new classes, and send the data from the 3rd party CMDB to Service-now.