The SAM-Tool – DOs and DON’Ts

However, if you look at the SAM tool and its results again after 1-3 years, the simplest evaluations are no longer correct.

How many clients are in use? The customer states about 8,200, the tool knows about 5,000. How good might a compliance report be there?

What happened during the SAM tool lifecycle?

1. Surrounding systems have changed:
   • An Access database that used to maintain notebooks for the field service no longer provides the desired data because the field service now works with iPads.
   • Another connected system, with hardware of the subsidiary, has moved and one has forgotten the interface to the SAM tool.
   • The technical user to the Active Directory has been deleted, locked or his password has been changed.

2. New surrounding systems have been added
   • Software, which was previously always installed on the devices, is now obtained from the cloud
   • Another virtualization platform was introduced
   • Certain parts of the infrastructure have been outsourced

3. The company has changed:
   • Parts of the organization were sold
   • New branches were integrated into the organization

4. The organizational structure has changed:
   • The SAM tool manager has left the company
   • Software purchasing has been decentralized and stakeholders are not trained in the SAM process

5. The SAM tool shows errors:
   • Updates were not installed
   • SAM tool vendor has not implemented changed metrics

The list of points that need to be checked again and again could go on and on. In companies above a certain size, IT is always in a state of flux.

A solution to make a SAM tool 100 percent meaningful is not possible or only possible with a disproportionate amount of effort.

SAM tools are an important tool for obtaining certain basic information necessary for proper software asset management.

If a compliance audit is due (internal / external), the following procedure should be followed:

• Review of the contract situation. The contracts provide information about what may be used
• Which contracts are available? (Hopefully the contracts are stored in the SAM tool)
• Is there any maintenance?
• What are the restrictions of software use
• What information is needed to prove correct software use?
• Which of this information is available in the SAM tool?
• e.g. The amount of certain equipment, installations, etc.
• Use of at least one additional data source for cross-checking (Active Directory, DHCP, scan system)
• Can scripts of the manufacturer be executed?
• How would the manufacturer calculate?
• Random recalculation with standard means such as Excel

Compliance audits of any kind remain work. In the best case, you know the pitfalls of your SAM tool before the upcoming audit and know what information to extract from it and what needs to be added or subtracted.

A SAM tool whose quality can only be guessed at does not help, but only causes more confusion.

With the technical introduction, objectives, a set of rules and responsible persons should be defined, which ensure the establishment and maintenance of quality.

In our projects, the following approach has proven successful:

• Identify people who will benefit from the tool’s evaluations and enlist their cooperation
• Define the scope and priorities for the tool deployment
• Identify which manual activities remain necessary despite the tool and determine who is responsible for them.
• Perform regular quality audits for the data in the tool (correct recording of licenses and contracts, reliable data delivery via interfaces …)
• Install updates of the tool manufacturer in time

It’s better to know before the audit what the SAM tool can’t do than to start looking in the audit case.