Skip to main content
are you new to SAM?

From SAM newbie to expert

By Guest Blogger … | March 06, 2017

If you are new to Software Asset Management, and want to avoid rookie errors, here is my brief guide on how to sidestep the more common (and not so common) SAM pitfalls. At every stage, the question you need to ask yourself is: Do I trust the results I am putting before senior management and the rest of the business?

Get visibility into business unit IT:  There is a school of thought that advocates empowered business units with their own technology budgets standing up IT assets.  While this lightens the load on IT, from a SAM perspective it is a bomb waiting to go off.  When engagement with the SAM team is curtailed, existing licenses go unused and project capital is exhausted through non-volume purchasing. Invariably, the first time the SAM team finds out about these IT assets is when there is a problem – a problem that might well have been avoided had consultation take place prior to installation.

Don’t give free rein to developers:  Hoping that off-the-shelf software will satisfy 100% of your software requirements is naïve, and so at one point or another, you will be dealing with developers who want something more. There is a deeply rooted culture in IT “not to upset the creatives”, but if you give your developers too much freedom, they could end up using incorrect versions and editions which are then deployed in a production environment with little or no SAM validation. Such ambiguity extends to elements of code pulled from the web and used as part of bigger application solutions.  The use of freeware in a commercial environment is not a binary call of yes or no, numerous shades of grey exist.

Be careful of system integration and indirect usage:  A recent court ruling ordered drinks giant Diageo to pay SAP £54m in additional fees for integrating its mySAP Business Suite with Salesforce. This brings into staggering focus that just because something is technically feasible doesn’t mean you are licensed to do it. Changes in software architecture should always be checked and double-checked prior to the change. I bet you anything that what happened at Diageo was project/program driven.

Don’t let procurement run away with it: Make sure the procurement function has an expert understanding how software licensing works when it comes to renewing software contracts. If you want to have more sway over the software renewal process, don’t be afraid to take a good, hard look at past arrangements. You should obtain the current contract well before renewal time and compare its terms and conditions against the existing deployment – essentially, an Effective License Position report. It is not enough to simply quote the numbers; you need to show there is a link between those numbers and the negotiated terms and conditions. At that point, you can make the case that you should be involved in future contract renewals.

Unpack the deployment process:  Take the time to study the relationship between your access request, procurement and deployment processes. Did we buy the software we requested? Is the software that we bought the software we deployed?  And finally, is the software we deployed the software we requested? Versions and editions of software can play a critical role in licensing, and in what can and cannot be done with those titles. If your deployment is reliant on packaged software, do you have the due diligence in place to guarantee that the installation is:

  • The edition and version requested
  • Has appropriate management approval
  • Has proof of entitlement to back up the installation
  • Is going to the right devices
  • Is approved by IT
  • Is architecturally approved for the deployment

Your SAM function most likely won’t have functional control over deployment, but without appropriate engagement in this area, you will forever be playing SAM catch-up when errors are made.

Beware false assumptions: Certain myths and misunderstandings have gained acceptance, but they don’t stand up to scrutiny or an audit.

  • Installed software doesn’t need a license if you aren’t using it
  • Stand-by/failover software doesn’t need a license
  • A software contract means we are automatically license-compliant
  • Vendors’ interpretation of terms such as development, clustering, partitioning and High Availability is uniform from one vendor to the next
  • Whatever comes out of an auditor’s mouth should be revered as gospel truth

You might have arrived in your existing SAM post by accident or by design – whatever the case, it is not one of those jobs where what you learned five years ago still holds good today. If you and your SAM team can stay on top of IT change, you give yourself and your company a much better chance of reaching SAM maturity and offering tangible support to your business.

Use this as the perfect opportunity to mature your SAM processes and ensure that you remain on top of your licenses moving forward. Learn how Snow License Manager 8 can help you avoid a negative audit experience.

Read our blog series and watch our videos to understand more, and then give us as a call to arrange a demo! Start taking the proactive steps to learn more about SAM today.

You May Also Like

Leveraging Factual Data When Considering RISE with SAP
Leveraging Factual Data When Considering RISE with SAP
Learn why having factual data to base your licensing decisions on is critical to avoiding overspending.
Read More
Microsoft 365 Price Increase and How to Prepare for Your Renewal Conversation
Microsoft 365 Price Increase and How to Prepare for Your Renewal Conversation
Learn what you can do to avoid increasing your Microsoft stack budget next year.
Read More
Why a Dirty CMDB is so Bad
Why a Dirty CMDB Is so Bad
Populating an asset repository or CMDB with dirty data creates more problems than it solves. Learn how an unreliable CMDB can impact the entire organization and see what steps you can take to improve data quality.
Read More