Fotolia_102028626_Subscription_Monthly_M_1_-102720-edited

Axios blog

Axios Blog

The Bermuda Triangle of SAM

Written by Rory Canavan, SAM Charter

M08-blog1

While I was acclimatizing to life after the RN, I spent four years at the University of Plymouth studying Computing & Informatics. The primary goal of the course was that it would offer you a taster of varying computing disciplines, which you then honed towards your favorite areas of study in your final year.

Programming challenged my will to live, but the saving grace of the course was the systems and business analysis modules that sought to teach me how to employ investigative techniques and modeling methods to show how a system currently works, and accordingly, how technology could improve the current situation.

Fast forward several years, and I find myself in Software Asset Management (SAM); an area of IT that could benefit from more than a pinch of wisdom from those systems analysis modules from way-back-when. I might be accused of summarizing here, however, I think the plug and play nature of technology is not serving the thought processes needed to support this important IT discipline. Systems are not merely comprised of software – owning a SAM suite is like owning a cooker, and owning a cooker does not make you Gordon Ramsey!

How mature are your Software Asset Management operations? Find out for yourself with our complimentary assessment survey.

M08-cta

You need to invest a fair portion of your time (and budget) into the processes that sit round your SAM suite. Let me present this use-case to qualify this point:

A project manager has been tasked with standing up a new service that requires a technology-stack to support it. Being from that wing of the business, our hero circumvents standard IT protocol when it comes to purchasing software, and so gets his request rubber-stamped by his immediate superior without any sense of IT due-diligence:

  • No IT department approval (to see if IT have approved the software)
  • No license checks (to see whether the software is already owned)

And so, following ITIL® best-practice, he/she then takes that request and splits it between procurement and deployment so as to save time (after all, who wants to wait for authentication that software is owned before deploying it?!) This 90’s thinking is at the root of many of the problems SAM faces. I can understand why a company would not want to wait 30 days (or so) for paperwork to arrive to say that the company has the right to install software – SLAs would be exploding left, right and center. However, in this day and age, we use SKUs (Stock Keeping Unit) numbers to order software, so we can instantiate the license off the raising of the purchase order rather than wait for a receipt. Anyhow, back to our project manager…

Being a project manager, procurement (in a worst-case scenario) will do little more than ensure that the purchase does not exceed the project budget, and so our project manager can revert his attention back to whichever department looks after software deployment.

Procurement need to look in the mirror and ask themselves:

  • Did the request arrive through authorized channels?
  • Has the software being requested received IT’s blessing?
  • Is the software provider on an approved vendor/reseller list?
  • Does the cost of the purchase trigger an ITT (Invitation to Tender) activity, so as to use competition to drive best value for money?
  • Does a contract exist to support the purchase of this software, so as to ensure that contract prices, rather than retail prices, are applied?

Our project manager is now on a roll - all he needs to do is to get the software deployed, and this matrix of mis-fortune will be complete. Being one of the guys, the project manager has no trouble fast-tracking the deployment – not least because the deployment team “already have that title packaged for roll-out…” The project manager then gives his final thumbs up and the software is deployed.

As a minimum, the deployment team should check that:

  • The licenses are in place to cover the deployment
  • The packaged software EXACTLY matches the purchased software (and indeed, that the purchased software matches the requested software)
  • The software license supports the IT architecture that the software will be installed upon (just because a deployment is technically achievable, doesn’t mean to say that the contract/ license permits such an installation)

Six months roll by and the project manager has moved on to another assignment, procurement can’t remember what they bought last week, never mind six months ago, and the deployment team are equally short of such information… And then a software vendor knocks asking your company to demonstrate your installation data compared to your purchase and contract data – and so the Bermuda Triangle of SAM is complete.

Returning to the beginning of this blog, recognizing the boundary between entities (i.e. a request, a purchase and a deployment of software) helps dissect the points at which SAM due-diligence can greatly help an organization – it may well be that Service Management already has the aforementioned processes in place, but might not have the SAM mix in place to ensure that license and compliance risks are avoided before errant installations become problems to resolve.

And returning to the other key point raised at the beginning of this blog, you could still have a SAM suite installed, and these poor practices could still mean that you do not have effective control of SAM in your IT estate. Having a SAM suite might help alert you to a mis-match of purchase data to installation data, but if you do not have the rod of Governance running through your SAM function, then all it will be capable of is to merely report that IT is being mis-managed; it won’t have the authority to drive the required change.

The final point I would like to finish on is this: You may derive great comfort from using an ELP (Effective License Position) to demonstrate how over or under compliance you might be with a given software vendor, but that final red or black figure at the bottom of the report has been crafted for the benefit of the software vendor – not you or your company. Having the Key Performance Indicators (KPIs) attached to your processes to assess SAM health is like the difference between an x-ray and an MRI scan – KPIs can be altered through process improvement, which in turn can improve your ELP. 

How mature are your Software Asset Management operations? Find out for yourself with our complimentary assessment survey.

Take the assessment

 

Latest 5 articles