Below is a set of primary Software Asset Management (SAM) principles that need to be consistently applied to all SAM work. From time to time and in special situations one or more of these get skipped or forgotten. Use this list to ensure all SAM principles get addressed for every transaction, or that there is a conscious and appropriate decision not to address them based on the situation.
What we own
What we’re using
Terms and conditions
Ensure we’re in compliance
Review the data; look for patterns, what doesn’t ‘add up’?
Ask questions, review again and repeat till complete
Document what you’ve learned
What is your recommendation?
Validate with at least 1 other person
Clearly communicate to requestor; back up with data
Other Important Topics
When vendors change license metrics, assert our license rights for licenses already purchased; change only if it benefits your company
Share with vendors only what they have a right to know
Always be confident in vendor communications
Educate internal users/user groups
The section below provides more detail on some of these items.
1. The Data
- Understand the license terms – how do we count it?
- Do your homework
- Know what our terms actually are before engaging in conversations or making decisions
- How do we count usage of our licenses?
- Reach out to team members to clarify
- Analyze future needs
- What is the desired future implementation/future needs?
- Compare current and future needs to how many we own.
- What options support the desired future in the most effective way?
- Do we already have enough licenses to support future needs?
- Collaborate with the users/owners
- Review Architecture roadmap.
2. The Analysis
- Understand the implementation and utilization
- The SAM team is responsible for understanding software license metrics and for validating them.
- We can add the objective perspective as well as the understanding of the terms and conditions that the users don’t have.
- Ask the questions (obvious and not so obvious, ones that users like and ones they don’t) and make sure we get the data we need to assess the actual utilization.
- Draw a picture for yourself. Validate it with the user.
- Ensure we are in compliance
- If not and we are not being audited by the vendor, ensure our implementation gets in compliance
- Do so by changing implementation and then having users purchase additional licenses if needed
- Find out who can make changes and coordinate
- Take care with communications/emails and discoverable documentation when addressing issues
3. The Recommendation
- Make recommendations from the data gathered
- To be credible, we must gather the data and make recommendations from it, rather than passing along someone else’s recommendation.
- Making recommendations is one significant way we add value and ensure the organization is making good business decisions – one of Jake’s main ‘keys to success’ for his organization.
4. Other Important Topics
- Vendor changes to licensed software metrics
- Assert our contractual rights (if we have them); vendors cannot change these for licenses we already own; license metric changes will probably apply to future purchases
- License rights that survive the termination of the contract
- Ensure users know our rights (see above); if needed remind vendors of our rights
- It is important that we maintain these rights in our internal and external communications (in case of any future claim)
- Research the impact of changes the vendor wants to make
- Decide on how to address (if needed); if beneficial to your company then accept, if not then develop plan to address with the vendor
- Limit information shared with vendors
- Only share with the vendor what they have the right to know (about our implementations)
- Base this on our contractual terms
- Educate users
- Be confident in vendor communications
- Do our homework first
- Affirm our position
- Build the relationship
- Ask for what we need
- Ask vendors for information we should know only as a last resort
- Educate users
- Take opportunities to educate users on what SAM does and why, and who we are
- Help them understand why we don’t want to share implementation information with vendors
- Help them understand how we can help them
- Build relationships