For many line of business projects, Software Asset
Management is considered at best a necessary evil and, at worst, a hindrance.
Organisations – at least those with some semblance of organisation – recognise the
need to ensure that their use of software is legitimate and compliant, has been
procured and licensed correctly and does not expose the corporation to punitive
financial penalties from audits. Those companies which are more
forward-thinking also see benefit in their BAU bottom-line from SAM. Centralising
software acquisition and inventory makes it is easier to avoid duplicate purchases
when there is existing unused "shelfware" entitlement; also, a full software
lifecycle management process means that assets no longer required can be harvested
and either reused for new projects or removed from maintenance contracts if truly
redundant.
This type of SAM model has predominantly evolved in an
on-premise world. As more enterprise software moves to the cloud, and
particularly to SaaS solutions – 45% of all application software spend by 2021, according to a recent Gartner report – then many of the above tenets are often perceived to be obsolete. On-premise
software is primarily acquired via capital expenditure and is therefore recognised
as an asset that the owner has a responsibility to manage. SaaS software is
primarily acquired via operational expenditure; as such, it is not viewed as an
asset in the same way, but rather as a service that can be switched on and off
as required.
The absence of SaaS cost from the capex budget, meaning that
it is neither owned nor managed by the organisation in the same way as
on-premise software, has led many companies to conclude that SAM is not as essential
in this scenario. If the CFO’s primary remit of SAM is avoiding audit exposure –
especially since there is a 65% chance that the organisation will experience one or more vendor audits a year
– then the SaaS "pay as you consume" subscription model largely negates this
concern. The counter argument is that, while SaaS may reduce or remove
potential unbudgeted compliance expenditure, failure to introduce effective
management of such solutions is likely to simply shift cost elsewhere.
How? Let’s consider those line of business projects that I
mentioned earlier. From their perspective, the simplicity of accessing SaaS
solutions is heaven sent. With a cursory wave of the company credit card – or,
as I once witnessed, the project manager’s own credit card (no names, no pack
drill) – a software solution can be provisioned and accessible for productive
use in lightning quick time. Freed from the constraints of SAM processes and centralised
acquisition, the project will be more agile and therefore more likely to
deliver a business solution faster than via the traditional on-premise route.
Of course, this is one of the main benefits of SaaS. To a large extent, it’s
rather like:
However, the aforementioned "constraints of SAM processes
and centralised acquisition" do not exist only to manage software compliance. A
good SAM practice enables an organisation to manage software costs effectively across
the enterprise and throughout the entire solution lifecycle. It’s not just
about speed; after all, a car with brakes will go faster, and more safely,
through a corner than a car without brakes.
Line of business acquisition of any software solution – on-premise
or SaaS – outside defined company procedures (and often without any involvement
or management from IT) introduces Shadow IT. Shadow IT, by its nature, is obscured, in whole or part,
from IT and SAM visibility. In such an environment, without appropriate corporate
management and control, escalating ongoing costs are likely.
SaaS, in particular, is designed to make it relatively easy
to sign up without IT involvement; however:
Who has signed up? For how many users? For how long? For what grade of service (enterprise, standard, basic, starter, etc.)? Is it a multi-component SaaS offering and, if so, have only the component services required been purchased? What cost profile/terms have been signed up to and do they take account of additional usage by other LOBs and the potential price reduction that centralised "bulk purchase" by the organisation would attract? How will employees signed up to the service who leave the company be managed? Who will manage renewals, especially if they default to "evergreen" – i.e. where the term automatically renews, often at the same or an increased rate, unless specifically terminated (I’m sure many can relate to this if they’ve ever had a mobile phone contract)?
Who has signed up? For how many users? For how long? For what grade of service (enterprise, standard, basic, starter, etc.)? Is it a multi-component SaaS offering and, if so, have only the component services required been purchased? What cost profile/terms have been signed up to and do they take account of additional usage by other LOBs and the potential price reduction that centralised "bulk purchase" by the organisation would attract? How will employees signed up to the service who leave the company be managed? Who will manage renewals, especially if they default to "evergreen" – i.e. where the term automatically renews, often at the same or an increased rate, unless specifically terminated (I’m sure many can relate to this if they’ve ever had a mobile phone contract)?
In addition to potential cost exposure, the role of IT and SAM
in managing SaaS solutions deployed within the enterprise is important from a
data and security perspective. The LOB may well have determined that the
storage of data in a public cloud SaaS environment meets corporate and mandatory
legal requirements at initial implementation, but are they best placed to
ensure that this remains so when company and legislative requirements change? Have
they considered ownership of the data and, for example, how it can be retrieved
from the SaaS vendor (and confirmed as removed from their servers) if/when the
contract ends, or how often it is backed up and how easy it is to recover if
needed?
In my opinion, organisations are making a mistake when they
take the view that SAM is not required for SaaS software. I don’t underestimate
the effort that is required to augment existing traditional SAM processes for
cloud-based consumption, but as we move more and more into this type of software deployment, it should be a factor that is being considered and
designed for ASAP.
Comments and criticism more than welcome; thank you for
reading 😃.
