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

Best practice

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

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 Management” Colin 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

Can’t find what you’re looking for?