If organizations are to escape the painful cycle of firefighting against software audits and progress towards fully-fledged software asset management the focus needs to be on managing and acting on exceptions.
That is, identifying where leakages in management of software occur, taking action, and refining processes accordingly over time. No grand true up, but gradual business improvement.
However, existing SAM tools have some shortcomings when it comes to this approach.
Let’s take an example. We’re managing the vendor Shaftu software (a tribute to the brilliant Shaft University).
Typical SAM tools will provide the following:
Product
|
# Licenses Owned
|
# Installations |
# Used |
Delta |
Shaftu.exe | 500 | 550 | 450 | -50 |
So for Shaftu.exe we have bought 500 licenses, we have 550 copies installed on our network resulting in a deficit of minus 50 licenses. We are out of compliance and need to take action.
We can use the business intelligence gathered with shaftu.exe usage data to see that only 450 of the 550 installations are being used. So they may be the opportunity for removal of software (if terms permit) in order to maintain compliance.
This logic sells SAM tools. It allows for a true up, it gets the job done.
But the weakness here is that it is REACTIVE. Nothing provided here helps identify where the leaks occurred. The administrators might ask themselves – “How did we end up being 50 short? We were audited last year by ShaftU software and settled with them to get compliant! Where did things go wrong?”
What I believe would be more useful is to help administrators and Software Asset Managers to identify and manage exceptions. It would not be rocket science for SAM tool providers to build this sort of data into their analysis.
Product |
# Licenses Owned
|
# Installations February |
# Installations March |
Delta |
# Used |
Shaftu.exe | 500 | 500 | 550 | -50 | 450 |
Root Causes from Last Month
|
So between February and March the number of installs increased by 50. 25 of these were legitimate and tracked by our SAM program and 25 were not. Of the 25 that were not authorized we can see the nature of the install in order to take corrective action. The goal is to slowly iron out these exceptions by tightening up and refining processes and educating users.
I have picked some examples – I’m sure there is other data that SAM tools could gather to establish root causes.
The action required on these anomalies will vary according to the policies in place, the volume of exceptions and the nature of the exception.
Some companies might be able to act on each exception individually (One SAM analyst I knew would simply email a screenshot of the install from their SAM tool to the user and let them know big brother is watching).
For high volumes it might be a case of acting on types of behaviour (“Lets focus on educating the deployment team about our license management process”). Gathering this sort of data over time enables trends to be plotted in order to build a business case for company wide change.
Whatever happens, it allows Software Asset Managers to identify what is happening, establish root causes and take action that will result in lasting improvement. It also enables change to be documented e.g. “Our series of workshops with users over the last 3 months reduced rogue installs by 95%”.