Preventing Vendor Audits: One Key Feature Missing From Most SAM Tools
Root Cause Analysis not Bandaids
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.
Conventional Wisdom
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?”
Help Me Manage and Learn from Exceptions
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%”.
- Tags: auditing · audits · feature · firefighting · key feature · one key · prevent · SAM · software · Software Asset Management · software auditing · software vendors · tools
About Martin Thompson
Martin is also the founder of ITAM Forum, a not-for-profit trade body for the ITAM industry created to raise the profile of the profession and bring an organisational certification to market. On a voluntary basis Martin is a contributor to ISO WG21 which develops the ITAM International Standard ISO/IEC 19770.
He is also the author of the book "Practical ITAM - The essential guide for IT Asset Managers", a book that describes how to get started and make a difference in the field of IT Asset Management. In addition, Martin developed the PITAM training course and certification.
Prior to founding the ITAM Review in 2008 Martin worked for Centennial Software (Ivanti), Silicon Graphics, CA Technologies and Computer 2000 (Tech Data).
When not working, Martin likes to Ski, Hike, Motorbike and spend time with his young family.
Connect with Martin on LinkedIn.
Martin
Thank you for emphasizing that common retrospective approach of most SAM
tools will not enable organizations to monitor compliance pro-actively. A software webshop – as you have already pointed out in one of
your previous articles – is an eligible approach to apply an approval process to software deployments.
Anyhow the crucial point
is that new software installations reported by computer inventory need to be verified whether there was an approval (appropriately
requested over the webshop) or not (being an unauthorized deployment). This approach requires corresponding integration between any
webshop and the SAM tool in place.
We at Matrix42 already provide that out-of-the-box meaning that any License Manager instantly
recognizes “wild” installations without having to investigate if there was an approval or not. I’d call it “tame your wild deployment
behavior”.
Good point. Love it.
Best regards,
Torsten Boch
Product Manager
Matrix42
i could go on and on about this one, with regard to process, tools, people, and how they all should and could
help each other with respect to unauthorized or un-entitled software license consumption.
the point I would like to throw out
there, in compliment to this one, is that bottom line, it all comes down to accountability, and I mean accountability from all ends of
the food chain, from the folks who manage the AM tool and the auto discovery tool, from procurement, all the way to the technician who
eventually drops that asset on the pallet to be sent to the disposal vendor, or returned to the original vendor.
Without true
accountability in the business of SAM, gaps or lack of responsibility, with regard to the business, however bad it may be, can hardly be
proven, and in turn, will rarely change.
Accountability, will, by nature, ensure the best chance of true control over desired the
desired result, just by putting someones name on it, or not on it.
Just my two cents on this topic..
Hi Martin,
I like the article! Companies will certainly benefit from pro-active management of Software
Licences.
One of the challenges I see is that companies struggle with more complicated licence models which are not managed via
installation counting with a SAM tool. In the SME market the software investment or at least, “customer worry” is in the desktop
orientated “per user” licences. I.E. You have a pool of device licences, and for every device the SAM tool finds the install, you
reconcile one licence.
In the enterprise software and hardware space, we find that a greater proportion of software spend tends to
be locked into CPU, Socket, PVU and client connection based licensing. I find that most SAM tools are not as well equipped (if at all)
to pro-actively count these types of licences.
In a number of enterprise cases, greater value is tied up in this kind of software
than the desktop based licences, yet the message tends to be: “be pro-active with your SAM tool”. Or in effect, worry about the smaller
risk.
Until these more complicated licence metrics are manageable by a SAM tool, this will always be a reactive process.
To your title, I’m not sure that any degree of preparation will actually prevent a vendor audit. At least in some cases I’m sure it
won’t, but It will make the audit process quicker, easier and ultimately less painful to respond to.
Many thanks,
Paul
Immergluck
Hi all,
very interesting discussion. I agree with Paul that the complexity is in the enterprise software.
Comparable to the financial and logistic world a kind of Rolling Forecast of Software Usage should be made for software in server
environments, resulting from and part of the decision process for server architecture. It should include a comparison with the realized
usage in the actual time frame and explain the differences. The differences should be used to improve the SAM procedures (this is also
comparable to the financial and logistic world).
Audits of vendors can focus on the process, with some samples, in stead of an audit
on all detailed data.
A prerequisite is a clear measurement method, agreed with the software vendor.
Nan Zevenhek
Agree completely with Chuck, Paul and Nan. Seems that there is a big concern about both
authorization and accountability in regard to software deployment out there in the market.
As I commented before authorization
and its control should be integrated with a web-shop to handle that in best practice manner. Accountability on the other hand should also
be integrated to the web-shop. Having both disciplines connected to and synchronized by a central web-shot enables consistency between
deployment and accounting. Definitely a core requirement to support user and management acceptance.
As for complex licensing
metrics – I agree to prior comments. Most tools do not support configurable license reconciliation based on Core Values, PVU or any other
weird formula. Anyhow there are tools that can do this job – providing “white box calculation” that can be adjusted and extended over the
time without having to wait for next tool release.
As for accounting purposes I suggest to decide software-by-software whether
vendor’s metric is used for accounting as well or some “smooth metric” is defined an applied. Be sure: if your license manager has
problems to understand the vendor’s license model, your end-users won’t at all. So it seems reasonable to choose some mixed pricing
that is similar but not identical with vendor’s metric.
I am convinced that key to success is, that you have done your homework.
Means that you maintain your SAM tool appropriately defining eligible license models and metrics as well as maintain your application
catalog. While most organizations obviously still not have any appropriate SAM tool in place (75% according to recent analysis from Ernst
& Young – introduced by Martin Thompson here) seems an excellent approach to consider “A & A” (authorization & accounting)
capabilities for their SAM tool selection.
Regard, Torsten Boch
I am reframing this discussion with my clients.
The issue is not avoiding audit –
once the software is installed you have already created a constructive liability.
The issue is avoiding that risk altogether by
creating preventative management control processes.
The first, basic step is, of course, understanding the contracts vs. the
installations. That’s fine, but that is reactive at best.
A single VM, with SQL Server, etc., can easily obligate the company to
a $10k liability. It takes seconds to copy.
With almost every company implementing VM tools to speed provisioning, and VDI to
reduce hardware costs we must create managment controls similar to those that we have for purchasing hardware.
I am asking my
clients to create asset management as the preventative management control point for standardization of product usage and authorization of
installation or use of software. This requires that Asset Management serve as the hub for this – because that is where the license
counts exist and most good AM tools already have this capability. Integrations with Client, Server and VM automation tools is needed.
And, integrations with Active Directory and VDI. And, for cloud, with purchasing.
This approach prevents unauthorized
installations and under-licensing. And, it exposes overlicensing – and when contracts are renegotiated, allows the savings from
elimination of unnecessary licenses.
Thanks Martin. This is a great example for the business value of being able to set a
series of Baselines of both software inventory and license ownership – and then to run reports that show where new installations or
removals have taken place.
Express Software Manager provides this functionality. Most of our customers set a Baseline each month,
and then run the “What’s Changed” report for software when they want to detect such activities. They can compare any Baseline they have
set with the current state of the environment, or they can compare any 2 Baselines. (The reporting is also available for hardware
changes.)
Drilling further into the report will also allow the administrator to see any changes on specific machines which have
occured during the time frame selected.
The ability to baseline is a great
one Bruce – but does it also show root causes – what causes the changes between baselines?
No, it does not. The baseline is simply helpful in determining the time frame in which the changes took place
and on which machines the changes took place, but not the root cause. I agree that most tools haven’t tackled this area, and it would
be extremely helpful from the standpoint of moving companies toward more airtight license management practices and improved governance.
Thanks for the insightful article!