Updated: 5 days ago
Say you’ve been asked to launch or refresh your organization’s Software Asset Management (SAM) program to optimize your environment and curb audit costs. We suggest you begin with a program charter, which is like a mission statement that communicates to the rest of the organization that this program will be a real, documented, repeatable methodology to maintain software compliance across the business.
A good SAM charter accomplishes three things: it shows your internal and external constituents that you take software governance seriously, it articulates the program’s goals and priorities and success metrics, and it identifies your executive sponsorship and stakeholders. As a former software auditor, it’s the first thing I would ask for to get the lay of the land. This leads me to one of the main areas where SAM programs fall short: the stakeholder alignment.
Too often, there’s a big disconnect between the SAM team, procurement, IT and legal. They have different priorities, they don’t communicate effectively, and they don’t naturally collaborate. Many of these organizations have a SAM program -- it’s just not working.
For these reasons, I believe getting stakeholder input is a great place to start a SAM program. To be effective, you must have consensus with everyone and take a committee-based approach. You have to find out what they want out of a SAM program, what would success look like to them, and what are the biggest challenges. Of course, you’ll have to streamline the input and re-set the unrealistic expectations that tend to sink a SAM program and build alignment around what the program can do. Expectations must be controlled for the program to succeed and stated clearly in the charter.
The following slide illustrates the other critical components of a SAM program.
Let’s jump ahead to the tools you’ll need, and what to beware of regarding these tools.
A good SAM tool will help automate the SAM process. The market leading tools are Flexera and Snow, but there are many others. They’re all good, but it’s important to remember that they only get you to the 50-yard line, because there’s no “easy button” for the SAM process.
Here are some of the limitations of SAM tools which can lead to problems when it comes to an audit.
Tools cannot do environment designation very well. For example, when a tool looks at your laptop, it doesn't know the purpose or the environment of that laptop. It might just be your laptop, or a production laptop with everything needed by an employee. But what if you're running tests on the laptop? Test laptops are often licensed differently from production laptops, and that’s just one of the many things that the tool does not distinguish.
Contract language is another problem area for SAM tools, which can scan servers and laptops, but not read and interpret the subtleties in contracts. This task requires the human element. Examples of contract language that would elude a tool: you have unlimited use rights, like with an Oracle ULA which lets you use as much as you want, but only until the end of the month, and then it changes. Or you have embedded user rights where you have software like a database that the tool finds, but that database was actually free, embedded in your bundled purchase of another product. The slide above lists the many other areas in the contract where SAM tools fall short.
Entitlement data is another tool limitation, because there’s so much information involved, and it’s not in any standard format. Again, this step requires a person to review entitlement purchases, make sure they are standardized and aligned, that they include the quantity, version or edition information, and a metric. Only then can you feed the information into the SAM tool.
And finally, there are the unmeasurable metrics - the things that SAM tools don't track. They simply cannot track everything, and I think there's often a misunderstanding at the executive level that thinks, “OK, we have a SAM tool, it's going to track Microsoft now”. Wait! Not everything in Microsoft, or IBM, or whatever you’re running, can be tracked.
For example, you might have a product that's licensed by terabytes of storage. And maybe the tool doesn't measure terabytes or grab those. Or you have indirect users accessing the environment – these won’t be counted by a SAM tool. Or you have different licensing levels, say a less expensive “read” license, and a more expensive “write” license, and the tool doesn't pick this up. All of these items have to be addressed by a person and a process.
Suffice it to say that there are many, many software products that will exceed the capabilities of your SAM tool, and I’ve identified some of the most common in the chart below.
A proper SAM program calls for an experienced team of professionals with expertise in publisher licensing models, conducting organizational audits for license compliance, and knowledge of the functionality and limitations of SAM tools. Resources with this level of proficiency are hard for organizations to find, as they typically require multiple years of software auditing experience and can be costly additions to an organization’s SAM team. That’s why many organizations bring in consultants to augment their SAM efforts, such as members of our Compliance Services team, who previously worked as professional software auditors.
For more information on this subject, download our recent webinar that discusses SAM best practices, visit our website to view our portfolio of software audit-related blogs, educational content, and training options, or contact your ClearEdge representative.
- Tres Larsen is the Managing Director of Audit Software Services at ClearEdge Partners.