With lots of new Snow customers joining the Snow Globe and lots of good questions being asked not just about Snow but about the world of SAM in general I thought it would be a good time to re -share a great Blog written earlier this year by 'ITAM Professional of the Year 2017' @Rory Canavan
FROM SAM NEWBIE TO EXPERT
Written by Rory Canavan - the Mar 6, 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.