This is the penultimate post in this series on Model Management. Previous posts are available here:
- Role Model, or Why Model Management is Important
- Models vs. Model Categories: Model Management, Part 2
- What's in a Name?: Model Management Part 3
- Which Model Is Which?: Model Management Part 4
- What Is Normal?: Model Management Part 5
- Model the Service Catalog: Model Management Part 6
- Field Day: Model Management Part 7
On occasion, you may find it useful to track some additional information associated with your Models. This is information is related to the Model that it does not make sense to store in a Configuration Item or Asset record because it is information that is common to the Model. Why maintain that same information in multiple different records? Instead, you can extend Models to include fields such as Form Factor, End of Life, Refresh Cycle, Default Warranty Length, and Manufacturer URL. Each is covered in detail with a recommendation for the type of field in parentheses.
Form Factor (Choice)
Do you know the breakdown of laptops to desktops in your environment? Can you identify how many tablets in your environment? This is a great example of information you should not need to select or enter on every different CI or Asset. Not only that, but it is information you might be interested in from both CI and Asset perspectives. For example:
- CI: How many incidents do you get per month on laptops? How does this compare to desktops?
- Asset: How much do you spend on laptops?
With this in mind, you can create a Form Factor field on the Model record. This should be a Choice list to keep the options consistent. Some tips as you set this up:
- Pick a term and use it consistently. You do not want to have to try to choose whether something is a Laptop or a Notebook.
- How specific you want to get is up to you to determine. You may call something a Desktop or you might distinguish between a Tower, Mini-tower, All-in-one, Small Form Factor (SFF), or UltraSlim Desktop (USDT). The options provided by the Manufacturer can help you decide what to use.
- Have the end user device team and the data center team identify how they want their form factors defined.
- The data center team may want to identify the size of the rack mounted devices in the form factor field, but if there are too many options, you may want to provide a second field that becomes available based on the selection of a rack mount option.
The Form Factor field and some possible options.
Rack Size is only presented if a Rack Mount Form Factor is selected via UI Policy.
One of many potential reports that leverage Form Factor.
End of Life Date (Date)
Manufacturers do not make and support a particular model of device forever. They eventually announce an End of Life (EOL) date when they will no longer provide support or update drivers. This is valuable information to have readily available, and is good information to add to a Model record.
This EOL report shows Assets based on Models that are nearing their End of Life.
You may want to include this field on the Product Model [cmdb_model] table rather than the Hardware Model table, as Software also has and EOL date. Then you can add that field to both the Hardware Model and Software Model forms.
Refresh Cycle (Integer representing years or months)
You may have a different term to identify this, such as expected life, but many organizations identify the length of time they expect a particular type of device to be used in the environment before it needs to be replaced. Rather than having users asking if they are due for a refresh, you can set the Scheduled retirement field on the Asset record. To better automate this, though, you can identify the refresh cycle for a Model and have this automatically set the Scheduled retirement. This field could use an integer of years or months as an input. Just be sure to pick one and stick with it.
Many organizations set this based on the form factor. For example, laptops have a three year refresh cycle while desktops have a four year refresh cycle. If you want to get even fancier, you can set this value based on the value in the Form Factor field.
The trick here is to determine from when you want to calculate the Scheduled retirement and then make the calculation. This will likely be the Install date, but your organization may choose to do it based on receipt of the item into stock.
Refresh cycle, listed here in months, helps identify when Assets based on this Model will be refreshed.
To automatically set the Scheduled retirement date, you can create a Business Rule to calculate it based on the Install date with this JavaScript. You can adjust this to meet your needs:
// Determine the difference between now and Installed
var nowOffset = gs.dateDiff(gs.nowDateTime(),current.install_date.getDisplayValue(),true);
nowOffset = nowOffset * 1000;
nowOffset = parseInt(nowOffset,10);
// Calculate the scheduled retirement from now and convert to numeric
var tempRetDate = new GlideDateTime(gs.monthsAgo(-current.model.u_refresh_cycle));
var newDate = tempRetDate.getNumericValue();
// Calculate and set the Scheduled retirement
newDate = newDate + nowOffset;
var newRetDate = new GlideDateTime();
newRetDate.setNumericValue(newDate);
current.retirement_date = newRetDate;
current.update();
Set the Conditions on the Business rule to run only when Scheduled retirement is empty and there is an Installed date to use for the calculation. You can decide if you want to run this only when new Assets are created or to update existing records, too.
Default Warranty Length (Integer representing years or months)
While you should capture the exact Warranty expiration date from the Vendor, if you have a standard warranty with your Vendor for a particular Model, you could use this field to identify this and automatically calculate the Warranty expiration field on the Asset. This should be considered as an estimate to use when you do not have this information coming directly from the Vendor.
Manufacturer/Vendor Website (URL)
In the previous post, I described how you can attach the manuals for a Model directly to the Model record. You can also create a URL field to point directly to the Manufacturer's web page for the particular model. While this is subject to change over time as the Manufacturer creates new devices, it could be useful to get the latest information on a Model before it reaches EOL. Optionally, you could point to the web page for the Model provided by your Vendor.
I am sure this list is not exhaustive. What other fields would you add to your Model records?
Most of this series has focused on Hardware Models. The final post in the series takes a closer look at Software Models and how management of those models differs from the Hardware.
6 Comments
