Not long ago, I wrote a blog about the importance of the Master Software List (aka License Repository or Library). I referenced a number of ideal data sets which should be included, but let’s focus on these two: “what does the software do”, and “who uses it”. Think about that. How nice would it be to have that information handy?

Consider the following scenario.

Joe from Engineering wants some expensive software that will save his team a good amount of administrative overhead. He talks to his manager, who advises him to check with the SAM team to see if the software is already in use in the organization. (Kudos to Joe’s manager for directing Joe to the SAM team!)

Joe sends an email to Lucy, one of the ITAM team members.

Hi Lucy. We’re looking at buying XYZ software. Can you advise if it’s already been purchased?

Thanks,

Joe from Engineering

Lucy replies:

Hi Joe. We don’t show that software has been installed or purchased, but there are similar software types already in the environment.  

Here is list of alternate, already approved software, along with Application and Business Owner name, in case you’d like to reach out for more information.

Thanks,

Lucy from ITAM team

Joe responds: Hi Lucy. What do you mean by “already approved software”?

Lucy:  Hi Joe. All software goes through an approval process to ensure the software is secure for the environment, that the vendor is an approved partner, that it’s compatible with other current programs, and that it’s cost efficient. The software titles I provided have been through the process.

Joe: Ok, thanks.

(NOTE: I threw this in here to show that if you have a set approval process for software requests and it’s continuously communicated, it helps to quell new software requests and eliminate duplication of software types. (This should be standard operating procedure).

One week later, Joe sends an email to Lucy.

Hi Lucy. Thanks for the recommendations. We are going to use ABC software, and the HR team has some extra licenses. I think this software will meet our needs.

This saves us a bunch of money!

Thanks again,

Joe

Lucy: You’re quite welcome! And don’t forget to put in a software transfer request so we can track the licenses.

Joe: What do you mean by “software transfer request”?

(Ha ha, I better stop there, as that will take us down a whole other email trail and a whole other process).

But, since I mention “process”, I should point out that the above email exchange could and should be handled through a well-documented ticketing process. (Including the software transfer request).

The main point is, your SAM team needs to have this data at their fingertips. Lucy knew right where to look to find software with similar functions, and she was able to provide names of the people who knew most about the software - the application owner and the business owner. In turn, Joe was able to talk to the people who use the software and validate that it would meet his needs.

This is a result of maintaining the software license repository (or whatever you want to call it). Though there are several SAM tools which offer out of the box categorization, there still needs to be tweaking to get to the primary functions of the software. And the identification of Business Owners and Application Owners obviously requires a manual touch.

The above scenario shows just one way in which the collected software information can be of value. (Lucy saved Joe (and the company) a bunch of money on their software purchase)! The data that your SAM team compiles is needed for purchasing, risk and vendor assessment, accounting, IT security, and IT operations decisions, to name a few. And I bet a bunch more money could be saved!

Considering the alternative, it makes far more sense to provide the resources and tools necessary for your SAM team to compile and track this information. How is this handled at your organization? Do you have set processes and a good software repository to ensure limited spend and risk?