What are you dealing with?
As we have seen in The truth about audit tools there are three main categories of problem with tools:
  1. Poor quality of information (e.g. Rubbish in rubbish out and Mind the Gap)
  2. Tool vendor's being overly ambitious in terms of the time things will take (e.g. Deployment and required resources to get things done)
  3. What you can achieve with your tool/s (e.g. Licence optimisation)
All three of these areas are directly affected by the quality of information being fed into the tools.

The bottom line

Ultimately, the rule with tools is simple.

If your software estate is well controlled and has been for some time, then all the problems normally experienced with tools reduce if not disappear and your objectives such as licence reconciliation and then licence optimisation become realistic.

The myth or at least the misunderstanding that has been pushed by the SAM market and the tool vendors in particular is that tools are the answer, in two ways:
  1. Tools will do the job for you.
  2. Tools will identify where there are problems.
We can state categorically that tools are not the answer in both instances.

If the controls you have in place are not up to scratch, then tools will be rendered useless or extremely expensive to configure.

SAM tools will NOT tell you where the problems with your controls are, they will only ever reflect the state of your controls.

That means they can only show you what has happened as a result of a lack of controls.

The solution is to deal with the problems way before the information gets to the tool, i.e. implement proper SAM controls.

This is what SAM is all about in this context.  If you have a high level of control over what is happening to your software in terms of purchasing, deploying, maintaining and retiring, then it is relatively easy to reconcile a licence position whenever you need to.

Without the proper controls, all you are doing is fighting chaos with inadequate tools which is the most inefficient approach.

What controls?

We have detailed which controls you need to have in place in:
The best way to maximise the use of a tool for desktop software is to:
  • Rationalise the number of software titles on your estate.
  • Lock your machines.
  • Standardise your software builds.
  • Control the deployment of your software.
  • Use the right media to install the software.
  • Don't upgrade applications, blitz the existing version and install from new.
  • Make sure machines are removed when retired.
  • Remove user accounts as they leave your organisation
The more these are in place then the:
  • Less work you have to do further down the road
  • Easier it is reconcile a licence position
  • More efficient are your processes
  • Lower the costs of SAM
  • Easier it is to maintain and support the software on your estate
  • Easier it is to identify 'rogue' software, breaches in policy and ultimately security of your network.
All of these feed on each other and a vicious circle of chaos becomes a virtuous circle that mitigates risk and controls costs.

For server software
All of the above goes for both the desktop and server environments, but servers deserve a further special mention.

Everything that is wrong with inventory tools with desktop management is doubly so with server management.

There are specialist tools designed specifically for the task, but they also require a great deal of configuration within the licensing context.

They may be great at controlling the server remotely or patching or any other kind of management, but when it comes to licensing all the tools that we have worked with leave a lot to be desired.

Our advice with inventory tools and servers - expect to do the majority of licence management manually.

Inventory tools are ok at identifying what is and what isn't a server (Windows) and the edition of Windows Server that is installed.  But as soon as you start looking at server applications then it all goes the way of the pear.

Paying for a short cut?

There are many SAM solution providers who offer services around 'data cleansing' or 'tool configuration' or 'tool teaching'.

Whatever it is called it amounts to the same thing, where the service will 'clean' the data so that you are left with a tool that in theory only reports on software that requires a licence.

The second part of this is that they should also be renaming any identified licensable software where the name is confusing or won't easily match a licence description.

Whenever someone is doing this work for you, focus completely on what they are going to provide in the licensing context.  Anything else might be useful, but the whole point is to make your reconciliation process as simple as possible.

Is it worth it?

This is one solution, but you are effectively paying to cheat the inadequacies of the original promises from the tool vendor.

It also means that should any new software be deployed onto your network, the tool has to be taught for each and every new executable file that is found.

This will always be a time consuming and expensive activity, which often has to be outsourced due to the level of knowledge required to do it properly.

We are not saying that this is a bad thing, it suits many organisations, but if the deployment process was cleaned up so that the information the tool was collecting was clean there wouldn't be a need for data cleansing at the end of the chain...

The outcome?
All this means is that customers hire external resource teach these tools what the tool creator should have provided from the beginning.

So why isn't such information available to the tool vendors?

Part of the problem is the enormity of the task.  There is so much software around that is constantly being updated that it is a full time job to keep any recognition library completely up to date.

The tendency in the market is that the more money you pay, the better the tool will be at properly recognising what is what from a licence requirement perspective, but not one of them has got it completely sorted.

As a tool vendor once said to us, this is the holy grail for which they are all searching.

If the ISO Standard Parts Two and Three could get every software publishers to follow the same rules then they would be a step closer, but it is not at the top of the publishers' to do list as they produce more products, constantly develop them and try to remain competitive.

In the mean time the responsibility of making this work sits with you, the end user, and even though it might take a huge amount of work to make a tool function properly, that is what the industry tacitly requires you to do.

Hence why we advise that you resolve the issues at source, so that all the tool is doing is reporting as clean a situation as possible.

Finally in this section we ask Do you need SAM tools?...