ARTICLE: Ilan Justh; "Playing The Detective in Software Asset Management Projects"

Best practice

ARTICLE: Ilan Justh; "Playing The Detective in Software Asset Management Projects"

Back in December last year Cynthia Farren shared her views on the key skills to look for in an IT asset manager.

Two of the key atttributes Cynthia mentioned were strong analytical skills and the ability to solve puzzles. These are certainly evident in Ilan Justh’s article below, where he details his experiences in some of the forensics involved in Software Asset Management projects.

“It’s elementary, my dear Watson.”
This article starts with this famous quote because software licensing often requires the skills of a Sherlock Holmes to do the job with which we are tasked. Why do I say this, you may ask? Simple. We have to research vendors, contracts, purchases, and inventories, and then determine how people utilize these assets (both hardware and software). That’s the easy stuff. The hidden detective comes out when we have to look up OLD information. Yes, that is where the real difficulties lay. If you are in a situation where all of your older purchases, especially software, are straight-forward, clearly stated and easy to gather, then consider yourself lucky. In my last role, I wasn’t so fortunate.

Starting From Scratch
In my most recent position, a major defense contractor, they had ZERO useful records of what had been purchased over the previous five years before I arrived (And you wonder why military spending is seen as a black hole!) To be able to determine risk, exposure, needed software, and licensing compliance, we first needed to establish an ownership baseline. We had records from SMS and Altiris but they were incomplete and really only showed usage and not ownership. We had just switched over from Ariba to SAP, so I need to get archival data. We needed the numbers from pre-historic times in order to verify data prior to my arrival as best possible. My first step was to figure out where the data was located and how to get it. Then I needed to create a repository for everything that I gathered. We had older data in our Ariba system. We also had data from individual vendors, and from other co-workers. I knew I had to create a consistent alphabetically sorted naming convention so that I could eventually summarize my numbers. With three purchasers previously buying products, each used a different naming convention so I had to establish a list where the names matched industry standards. It was now time to put on my CSI badge and start the forensics.

It was now time to grab the low hanging fruit and work up to the tough stuff. I went to the accounting bean counters and asked for reports on what had been purchased. I then went into the old Ariba system and pulled a report on EVERYTHING that was ordered from our DIVISION in any category that even remotely could have been computer stuff. I had to include engineering equipment, office equipment, data center purchases (remember storage items need storage software and servers often came bundled with an O/S). To be safe I even included miscellaneous. I found thousands of line item purchases.

Building A Consistent Database
I knew that the data needed to first be sorted by a description, so I clarified and massaged each line purchase, creating a consistent naming convention. I also realized that I was tasked ONLY with software licensing, but I was dealing with hardware purchases at the same time. I had to first filter out purchases that were obviously hardware buys. In many cases the costs, descriptions, vendors, and other indicators would tell me information that helped to decide what bucket the purchase went into. In other cases it required opening the order information and looking at purchase data. Sure enough, the items often included buried software that needed to be placed in the correct area on the spreadsheet that I was building. I wanted to know the obvious things. I needed to get counts of software, but I also needed to know when it was bought, the PO number, the requester, the vendors (and contact data), the cost, and any associated keys or codes. Just as importantly, I had to create a standardized naming convention.

I started with over 10,000 line items and after almost three months, was able to narrow them down to slightly over 2,000 purchases. The hardware purchases were placed in a similar document and handed off to my hardware counterpart. Now came the fun part. Yes, I am crazy, but this is the type of research that I LOVE to do. I first contacted our primary software vendor and cross-referenced everything they knew about, and then transferred that data into my master matrix document. I repeated this with every other vendor I was able to determine as major suppliers and worked my way down. I then asked others if they had insights into orders based on whatever data I could provide. Next, I Googled some of the data I found in Ariba. Often times, all I had was a vendor code or other cryptic descriptions. Real CSI forensics stuff! Finally it was time to make the phone calls that I was dreading. I had to talk to software vendors or providers and ask them variations of: “on August 23, 2003 we paid you $413.84 … can you tell me what it was for …?.” This was very embarrassing, I admit but it was the only way to gather the numbers I needed. Eventually using intuition, research, and luck I was able to create a fairly complete document. It even came down to sometimes looking at the price of the item. Tracking costs sometimes made matching easy and also made it obvious when an upgrade (or a viewer) was ordered rather then the full package.

Lessons Learnt
So what did I learn from this journey? Document, document, document …. Ohhh did I mention get everything written down. I imagine many of us started this Battaan Death March focused on the destination but it is what you learn during the hike that is of equal value. Look to see how you can improve communications with your vendors. See if there are deals on upgrades. Get the names of your new representatives (many of mine were people no longer there). Use this as an opportunity to browse their websites. You might discover new products or press releases for actions that impact your decision making.

20/20 hindsight is a beautiful thing. You always see how you would do things differently. Luckily I didn’t find that I left stones unturned or that I went up the wrong fork in the road. Thinking through what I wanted to accomplish, writing down a plan (and following it) and focusing on the details were critical however. The only things I would have changed is to tell my manager how messed up things were so she would have better understood the quagmire I was slogging through – we all end up finding that communications is a landmine we need to avoid. I also came to the conclusion that if finances were different I would have preferred to place the data directly into an ITAM program rather then into a spreadsheet.

Ilan is an experienced IT Asset Management professional based in California, at the time of publication Ilan is currently seeking an new position in the IT Asset Management market. His LinkedIn Profile is here.

Photo Credit

Can’t find what you’re looking for?