Software Asset Management: Watch Out For These Common Pitfalls

Having a SAM tool automatically means you are compliant, doesn’t it? Unfortunately, it doesn’t. There are many misunderstandings about what Software Asset Management (SAM) can mean for an organization. So how do you make sure that SAM is actually a success in your organization? Here are some of the most frequent pitfalls you should pay attention to.

It is useful to know which licenses you need and which are unnecessary but this is just the first step in the whole process. This just means that you know what your current position is. In fact, SAM can then help you to reorganize business processes and procedures. These could include central purchasing, reducing the number of vendors, and so on.

It’s best to cut up a SAM project into little pieces (but not too many) because it has to remain manageable for all the stakeholders. For example, start with the software for the ten most used vendors. Before you begin, ask yourself what the ultimate goal of the SAM project is. Is it to discover useful information about a number of manufacturers or to be completely and dynamically compliant?

It goes without saying that the IT department focusses on achieving its own objectives and in doing so sometimes forgets the impact that this can have on licensing. For example, if employees are being offered a virtual desktop as standard then this will have implications for the licenses. Another example: if parts of the work are outsourced then this affects the existing contracts too.

In many cases, SAM is assigned to a single person. Apart from the fact that the person chosen is seldom the right person, SAM isn’t a job for a single person but for the entire organization.

Manufacturers’ ever-changing licensing rules can make it difficult to determine your ELP. In many cases, you have to go back years for this and review everything carefully at a line-by-line level. For example, are the licensing rules known that applied when a license was purchased? What licensing rights have been built up during the active maintenance of licenses? Which benefits will lapse if the maintenance ends?

When answering these questions, you may find yourself faced by a difficult dilemma: if you can’t work things out, should you ask a manufacturer for help or would it be better to let sleeping dogs lie?

In this case, you first need to establish which license metrics are being used in-house and how they are being applied. Is your organization licensing its software on a ‘per user’ (concurrent or named) basis, or per processor or per core? Or is it doing so on a ‘per domain’ basis or even by using cloud-based credits?

If corporate sponsorship is lacking then SAM is doomed to failure. This is because SAM is not a project for a single team – instead, it must be embedded in the consciousness of the entire chain and/or organization. For instance, no employee at all will like it if his or her Professional license is reduced to a standard license, with the IT department having to be very sure of its ground if it is to ‘deprive’ a colleague of something.

This issue becomes even more complex for international companies. For example: if a European or North American branch takes a decision about SAM then it is by no means certain that colleagues in Asia will go along with this decision.

The size of the company or the amount of the annual payment do not justify a different interpretation of the licensing rules. Standardization contracts with a high annual invoice amount do not release you from all your licensing duties; as the client, this remains your ultimate responsibility.

Sometimes, organizations start using a tool enthusiastically but stop doing so when a new management team sets different priorities. In this case, SAM is often seen as a cost item whose benefits are not immediately apparent.

Last but not least: it is true for many organizations that processes fail to run smoothly, which can then make it difficult for SAM to get off the ground. Examples:

• Those responsible for SAM do not communicate with IT-ers who for example are handing out new laptops or rolling out new servers;
• Departments buy new software themselves without involving the IT department;
• HR fails to inform the right people when someone leaves, so that accounts and the associated licenses remain in place unnecessarily.