By Ed Cartier, xAssets
ITAK V5 I6
So, management finally relented and approved the budget for the acquisition of an ITAM solution. You published your RFP, did your due diligence and selected a vendor. The software is installed, your custom reports and customer specific fields are completed and you’re all set to go. What’s the first thing you’re gong to do? Most people would answer that running a full discovery and inventory is the logical first step. Let me take a radical position here and disagree.
Although performing a full discovery and inventory is a critical component of any ITAM program, I would offer that these processes are not the right first step. My logic goes like this: knowing and cataloging what you have is important, but without the right records to compare the discovery data to, it has little meaning. It will indicate what you have, but not if you have all the equipment you paid for, or if you are properly licensed for all the deployed software. I would suggest that the first step in an ITAM program is loading the CMDB or repository with your purchase order, software license records and maintenance and disposal records before performing a discovery scan. Let me explain.
Taking the time to populate the CMDB provides you with a baseline of what you paid for and what you are supposed to have installed and deployed. Yes, it takes time, but it is time well spent. You will end up with a single database of all of your assets, and if they have been upgraded, moved, transferred or disposed of. In addition, following your initial discovery analysis, a report comparing the discovered equipment and software with the corresponding records in the CMDB will provide you with information, not just data.
To start with, such a report enables you to perform an initial hardware reconciliation. The concept is similar to software reconciliation, but can yield significant financial rewards. Being able to immediately match purchased equipment with discovered equipment will highlight inventory problems, security problems and expense anomalies. For example, one regional telecommunications carrier performed this analysis immediately following its initial discovery scan. The scan indicated that over 1000 routers that had been purchased were not discovered on the network. A subsequent scan replicated these results. An investigation found them in a warehouse, in the original packaging. They all had maintenance agreements and were being depreciated, even though they were not in use. The company took measures to alleviate the situation and saved thousands in the process.
But, it could have been worse. What if the routers were actually disposed of, but were still on the books, being depreciated? Accountants tend to take a dim view of such practices. A quick look at the disposal records would indicate if that was actually the case, and the company’s books could have been adjusted before an audit and year end close.
Or, take the case of devices not in any purchase records. Just after completing a discovery actions can be taken to identify the location and owner of such devices. Management can take steps to determine why they were not in the asset database, what function they were performing and if there was any threats to the corporate databases or intellectual property. Knowing the device was installed reports its existence; knowing it wasn’t a corporate asset allows immediate action to be taken.
The reverse can also be the case. Comparing discovered assets with disposal records will identify anything that was written off and is still in use. A big accounting no-no.
Then there is software. Unless you are in crisis mode and a snapshot inventory is required as part of an audit or license true-up, loading the software license records before the inventory and discovery gives you not only a real compliance baseline, but a platform from which you can proactively manage your software assets. Let’s suppose an organization is adding staff (don’t laugh, it could happen). Knowing how many copies of key software titles are deployed is important as it will give management how many extra copies will be needed. However, immediately knowing how many were paid for will give an accurate picture of the budget impact. It is possible that more licenses that were needed were originally purchased (Gartner® once published that most organizations were 20% over licensed) and that a surplus will exist even after adding staff.
In addition, potential licensing liabilities can be avoided by loading the CMDB before performing the discovery scan. The discovery scan will list all of the titles, but not if the company purchased licenses for all those titles. “Brought-from-home” software poses a real problem in the case of an audit. Remember that an audit compares license and purchase order records with the software that is discovered. A list of unlicensed software (no record of a purchase order) can enable management to locate the software immediately after discovery and delete it before it becomes a problem or liability.
All these scenarios, and the basic premise of loading the CMDB first, do rely on the CMDB and the discovery database to be one-in-the-same, or at least tightly integrated. That goes back to the opening paragraph of this piece. As part of your RFP and due diligence process (for tips on this process see my article “How To Write an RFP” in ITAK Vol 5 Issue 3) put a few of the following points on your “must have’ list.
- The solution must include a repository/CMDB that tightly integrates to the discovery database
- The discovery database must be part of the repository/CMDB
- The discovery database and the repository/CMDB must share a common reporting engine
- The repository/CMDB must be able to import common data file formats (e.g. .xls, .csv, .txt)
These features will enable you to get the greatest functionality from the entire solution. Of course, it only makes sense to insure that the discovery component identifies as many types of hardware and software possible, to insure that your inventory files mesh to your purchase records.
The whole point here is to insure that you derive information instead of just data from your ITAM tool. Data is fine, but is not sufficient to make real decisions. Information applies logic and a construct to data, and enables IT asset managers to make intelligent decisions and take appropriate actions. The sooner the information is available, the more value the organization can derive from the ITAM solution and the better you look to management. (Nothing like keeping those promises of how valuable the software will be). So, I stand by my recommendation of loading the CMDB before running a discovery; that’s my story and I’m sticking to it.