Du er her

Why we need continual improvement in SAM – PT I

The path towards Software Asset Management (SAM) often starts with the panicked reaction to a software vendor audit.  Having gone through the painful process of scrabbling to gather information and put in place policies governing the procurement, allocation, use and reclamation of software, however, it pays dividends to commit to some form of continual improvement of the SAM program.

Why?  Well, for a number of reasons.  First we know from all walks of life that any kind of endeavor is more likely to succeed when we do it because we want to, not because we have to. Even if we stay with the audit scenario, this still rings true. 

Active license optimization through better software management is much more effective than simply being prepared to provide audit data when the inevitable request arrives.  Just consider how many software publishers are currently using audits (or ‘license reviews’ if you prefer the politically-correct term) to drive the adoption of new licensing models or cloud-based delivery models – which are not always in the customers’ best interests.

Over the next couple of weeks, we’re going to discuss a number of good reasons why your SAM program should live and breathe with frequent reviews rather than be left static.  Each post will give you an easily-digestible snippet that over the coming weeks will combine into a strong business case to support the continual improvement of SAM practices. If you’re reading this not yet having implemented a SAM strategy, don’t worry.  Taking heed of the points that follow could put you ahead of the game and help you form the business case you need to invest in better management of software procurement and consumption.

To remain in sync with the business

It goes without saying that every SAM framework is first written at a set point and is therefore reflective of the operational priorities of the organization at that time.  Equally obvious is that operational priorities, business practices and employee behaviors change over time. 

Therefore our first justification for continual improvement in SAM is to remain closely-aligned with the rest of the business, its goals and priorities. Consider a SAM framework that was written prior to the explosion in the use of cloud-based software or employees using personal devices to access business applications. Unsurprisingly, if you were to examine such a program today, it would at best have some holes that need addressing. At worst, it could be completely antiquated and actually doing more harm than good.

We know that an increasing amount of ‘IT spend’ is happening outside of the IT department, as stakeholders across the organization make their own decisions on what IT hardware, software and services best meet their needs.  To try to fight this is a waste of time.  

But by identifying the changes in software use, and comparing this against what the IT organization thinks is best for the organization (both in terms of achieving the business goals and managing costs, which are not always the same thing), the SAM team can revise the SAM framework so that it is a) more realistic and b) better able to drive desired software procurement and consumption behavior. Regular reviews are a two-way street. Not only can the SAM function influence, it can better understand how to add value back to the business in the form of meaningful reports and intelligence. Here are some simple suggestions for questions to address as part of a scheduled SAM program review:

  1. Are our key software vendors changing the way they license and/or deliver apps?
  2. And if yes, do the new offerings suit us or not?
  3. Are we seeing a change in how business applications are being used?
  4. Are we being increasingly asked for different kinds of reports that should perhaps become standardized?
  5. Have we seen unexpected software appear on inventory reports?
  6. If so why? What is driving it?

 

A periodic review of the SAM framework can help the SAM function achieve the fine balance between promoting best practice across the organization and policing the actual procurement and usage of software. 

It is arguably easier for the SAM team to identify and correct examples of behavior that is contrary to the framework when the framework itself is up to date and relevant to the business as usual operations of the organization.

Next time we’ll start to look at some examples of how evolving your SAM program can help you better sweat assets and what ‘best practice’ actually means in the real world. In the meantime, if you’d like to learn more about how to critique your current SAM framework and software management practices, why not speak to one of our SAM gurus?