As can be seen from the literature and marketing brochures of many Service Management tool providers, the appeal to cross the border and reach into the Software Asset Management space is proving very difficult to resist, and there is some merit to the approach:
- Inventory agents for SAM report the same data as inventory agents for ITSM, so if an ITSM tool is already in place, why not use it and save a network manager a headache relating to network bandwidth?
- If an end user has a query relating to licensing or software in general, their guided instinct would be to reach out to the Service Desk to resolve that question – so it would make sense to have SAM related data at the disposal of the Service Desk.
- SAM could benefit from the practice of SLA adherence – as a discipline, it is too often rooted in getting reports “just so” rather than being able to offer reports “on time”. The repeated activity of generating compliance reports will see to it that a company is better placed to drive strategic and operational benefit through a company if it borrows such a concept from ITSM.
However, before anyone proclaims “I do”, it is also worth noting a few of the differences that will undoubtedly have to be overcome if a marriage is to proceed:
- Except for the most basic of calculations, “one licence does not equal one install”. Reconciliation engines within SM tools are going to have to step up to accommodate upgrade rights, downgrade rights, rights of secondary use, multiple use rights etc.
- If an SM systems provider proclaims “they do asset management” they should be able to demonstrate where and how to import proof of entitlement; IT already struggles obtaining such data from contracts departments as they (can typically) feel duty-bound not to share such data for fear of breaching confidentiality agreements between the company and the software vendor.
- IT Processes will need an overhaul – Systems integration between SM and SAM are but just one aspect the bullets above allude to; Service Management processes will need to account for licensing deviations highlighted in the software asset management lifecycle if a successful union is to take place.
This final point is worthy of further attention, because regardless of whether you decide to unite SAM and ITSM under one entity within your IT organisation or not, SAM still needs to be woven into your IMAC activities so as to help mitigate the risk of non-compliance.
“Here and there” installations on your desktop may not peak your interest, however, a liberal approach to random installs, moves and hardware changes in the datacenter could lead to liabilities matching or exceeding the salaries of your entire IT workforce; and with the pace and speed with which virtual servers can be instantiated and hosted, due diligence should not be considered a “nice to have” business ethos.
In an article published on this site just over a year ago (ITSM thoughts from the world of Software Asset Management) I posed the question does your service management division assist in the generation of analysis pertaining to a software support and maintenance contract review? (A strategic function of software asset management) Service Management is the discipline sitting on this valuable data, and whilst SAM suites have the capability to record that software has support and maintenance associated with it, SAM suites are invariably not used to monitor the consumption of support and maintenance.
I would welcome your thoughts on this, but also on the forthcoming article – borrowed from the sister-site (ITAM Review) we will be offering a Process of the Month analysis of how support & maintenance analysis could be achieved; and the fringe benefits it offers both Service Management and Software Asset Management.