The ITAM Review

News, reviews and resources for worldwide ITAM, SAM and Licensing professionals.

Software Asset Management – Tips From The Trenches (Part 1)


Tips from the Trenches

Software Asset Management (SAM) is a key process for any organisation to meet its legal, financial and reputational responsibilities. The ITIL definition for SAM is ““Software Asset Management (SAM) is all of the infrastructure and processes necessary for the effective management, control, and protection of the software assets within an organisation throughout all stages of their lifecycle”

In practical terms, having a good SAM process allows you to answer the following questions about your infrastructure:

  • What is installed in your environment?
  • What is supposed to be installed?
  • Who is using the Software?
  • How much are they using it?
  • Are they supposed to be using it?
  • How are they using it?
  • Can you prove you’re allowed to use it?

Unfortunately, in practice SAM is seen as being SEP (Someone Else’s Problem) but with penalties resulting in reputational damage, fines or even prison sentences, ignorance is most definitely not bliss.

A long time ago in a galaxy far, far away

How to manage software has been an issue since the 1980s. The BBC Micro, Apple and Microsoft all made using computers accessible.  The advent of the PC caused a huge uptake in application software and with this came the issue of how to manage it. The world tactic was to ignore or to make it SEP.

A common perception is that the costs to implement Software Asset Management or SAM are higher than the potential savings to be made. Translation; more trouble than it’s worth.

In reality Gartner and Forrester both have a ROI on SAM in terms of months.

The risks of being under licensed could hurt your organisation in terms of financial implications, reputational damage and failure to comply with regulations and standards.

The present and the hole we have dug for ourselves

Today, SAM issues are constantly in the news. Organisations across the globe have to pay fines of thousands, if not millions, of pounds to software houses for either under licensing or for not having proof that the appropriate licences are in place. In the advent of regulations such as SOX or BASEL III, having a strong SAM process is more important than ever.

So that’s the bad news, the challenges we face and the pressures we are all under. How do we fix it?  I don’t have a magic wand but I do have years of experience in IT (I am the Queen of Geeks!)., but I do have a list of tips for running an effective SAM process, from implementation, BAU, responding to audits and Continual Service Improvement or CSI.

Tip 1:  Surviving your SAM implementation

In the book, “Best Practice for Software Asset ManagementColin Rudd wrote “the most difficult aspect of any process is its initial implementation. This has to be achieved whilst maintaining normal BAU processes and workloads.”

Don’t try to boil the ocean – because of the complexity of software licensing it is easy to get bogged down in detail. Focus initially on licensing that is organisation wide and provided by big hitters such as Microsoft and Oracle.  Prioritise by risk to the overall organisation.

Start with the end in mind – bear in mind that your process must be user friendly because I guarantee, if your customers think that using the SAM process will result in lots of red tape, they will circumvent it, causing you problems down the line. When designing your processes, imagine you are about to be audited tomorrow. How will you respond? What do you have in place already? Where is your proof?

Know your supporting players. – look at what is in place at the moment and look at what can be used for SAM. We’re not trying to reinvent the wheel here so work smart not hard. Do all software requests go through a SPOC such as the Service Desk? Is there a Request Fulfilment process you can link in to? Is the procurement process centralised? Does IT Security have an Acceptable Usage policy that you can reference?

Remember that SAM isn’t just about toolsets – to be able to manage control and protect your environment, you will need support. That support will be in the format of people, processes, products and partners. A business case is your way of asking for support. When writing it, ensure you have someone of appropriate seniority (preferable director level) to sponsor it and write it in business ‘lingo’. Remember, the approval board will use your business case as a decision making tool, so make it easy for them to approve it. Speak their language; talk business benefits not techie requirements.

Tip 2:  Know what constitutes proof of licence in your environment

Sounds daft doesn’t it? Of course I know what counts as proof of licence. It’s that piece of paper with the nice sparkly sticker on it. Where did I put it again? Oh dear …

In truth, proof of licence could be one or any of the following:

  • Software
  • The master copy of the software itself on the master media
  • Distribution copies of software on the free standing media or servers
  • Installed operational instances of the software
  • Codes
  • Software pass codes or License keys
  • Software maintenance authorisation codes
  • Documentation
  • Software License certificates or other ‘proof of Licenses’
  • Terms and conditions of Licenses
  • Support Contracts
  • The software release documentation
  • Upgrade Components

The message? Get the software vendor to confirm in writing what acceptable proof of licence is during negotiations. Have it as a mandatory question / requirement for any RFIs / RFTs issued by your organisation.

Make sure you have confirmed the information required as this will help you track your software licensing information in your SAM database.  Types of information to track could include:

  • Name of software
  • Vendor / Manufacturer
  • Licence details
  • Version number
  • Support details
  • Upgrade documentation

Come back soon for part 2 of this article, which will take you through the next 8 tips.

Image Credit

About Vawns Murphy

Irish mum of 3. ITIL V2 Manager (red badge) and ITIL V3 Expert (purple badge). SDI Managers certificate. Further qualifications in COBIT, ISO 20000, SAM, PRINCE2 and Microsoft. Author of itSMF UK collateral on Service Transition, Software Asset Management, Problem Management & the "How to do CCRM" book. Reviewer for the Service Transition ITIL 3 2011 publication. When not being pelted with brightly coloured balls in name of ITIL, I am a senior ITSM analyst for Enterprise Opinions.


  1. Matt Fisher says:

    Great first article, I agree with all the points suggested above. Hopefully I’m not jumping the gun and getting ahead of your next six tips, but on the subject of proof of license I think it’s worth expanding on the value that tools can bring here. While I wholeheartedly agree with your statement that it’s not all about the toolset, I do think it’s important to understand where the right tool can make a significant difference in terms of time and money. Having the ability to not only manage different kinds of proofs of entitlement, but also a solution that can automatically identify appropriate upgrade paths / rights can be a major labour-saver. After all, it’s difficult enough to understand basic licensing rights sometimes, let alone individual vendor’s different policies on up and downgrade rights! Looking forward to part two.

  2. John Tomeny says:

    Vawns makes a good start here with a description of the problem and an emphasis on developing sound and user friendly SAM processes. But sometimes there is confusion between: “what counts as proof of license” and proving ownership for software assets that have been found.

    Microsoft informs us in their SAM Brief that “Proof of License for Microsoft Software typically consists of a paid invoice or receipt in either an electronic or physical form…. [it] provides proof that your organization bought the licensed software from Microsoft or an authorized reseller and that the software license was paid for”.

    There are many SAM tools that are effective at finding software assets that need proof of ownership, but none can be completely effective at proving ownership. After all, until an organization can show that they have actually paid for the software discovered on their computers, they can’t expect software publishers to be satisfied. Step 1, discovering file copies, activation codes, etc. is important, but proof of ownership comes down to purchase records – “show me the money”!

    Some SAM tools can help facilitate purchase record keeping requirements, and help with organizing version upgrade rights, expiration dates, etc. so that reconciling purchased entitlements against discovered software is easy. But there is no escape from maintaining the trail of “electronic or physical” purchase records.

  3. Maya Turnbull says:

    This was a perfect introduction to a level-headed outlook on SAM. I am sure tools might have some mention in Part 2. Although before you can start scrutinizing existing toolsets/investing in new ones, sometimes focus around what it is that you want to achieve within your own SAM program is indeed the first step. If you haven’t set off with ‘the end in mind’, especially when investing in tools to help you do this, it is easy to get side tracked. So I think the right chord has been struck here. I sincerely look forward to reading any subsequent articles relating to this topic and would encourage rehashing some of the basic ideologies of SAM, like we have seen here.

  4. vawns says:

    Hi Matt,

    Thanks for the great feedback! I’ve talked
    a little about tools in the next part but have deliberately kept the detailed value they can bring for a later article but hear me out 🙂 All too often I see companies that have panic bought a SAM tool without first getting their people and process stuff sorted. Then when it all goes wrong they blame the toolset!

    I completely agree that SAM isn’t just a process or a toolset, it’s about having our people, processes, technology & partners working together effectively to ensure our environments are managed, controlled & protected to the appropriate (and hopefully legal!) standard.

    Best regards


  5. vawns says:

    Hi John,

    I completely agree that there is confusion all round – loving the “show me the money” approach! What makes it so difficult at the moment is that what one company might accept, another might not but I’m hoping that with the ISO standard refresh, other best practices such as ITIL & COBIT as well as groups & forums such as this one, the itSMF and the SIRB, things will improve.


  6. vawns says:

    Hi Maya,

    Thanks for taking the time to read and
    comment 🙂 You’re right – when starting out with SAM – we have to focus on the end game otherwise it is too easy to get side tracked – one way of doing this is by having a clear vision & mission statement underpinned with a policy,
    process, CSFs and KPIs. That way you can check quickly & easily that you’re still heading in the right direction.


Leave a Comment