Having gone through the hard work of completing a RACI chart, and deciding which activities are project-based and those which are BAU, now comes the task of identifying the data sources required to support the activities and objectives of your Software Asset Management Programme.
Whatever you may be calling your processes or what they might be seeking to achieve for your business, some core data sources for your Software Asset Management programme will be essential if you are hoping to demonstrate success.
Inventory Data: Core to any Software Asset Management Programme is the ability to demonstrate installs vs. rights to use, so having previously set the scope of your Software Asset Management Programme, your inventory tool should be able to recognise the software you are trying to account for. More on inventory tool selection will follow, but for now, you should be able to manipulate the data in such a way that it accurately reflects what is installed, and is obtainable in a systematic and repeatable process.
Purchase Data: Purchase data acts as the counter-weight to your install data; and this is where the prior preparation can be so advantageous. You will be leveraging your business relationship with whichever department in your company looks after purchasing to obtain this information. Will this information be easy to retrieve? Will the data provided be fit for purpose? Is there a means of capturing this data electronically? All of these questions and more will have to be answered; not just from a project perspective, but also as BAU.
HR Data: Any audit and reconciliation worth its salt will have to pay due regard to licensing metrics – the over-simplification of one install to one licence will see companies potentially paying over the odds by ignoring second use rights/multiple use rights. Other licensing models require user data to be brought into the calculation of what’s been used, and what might have to be paid for. Accordingly, some degree of metering may be called upon to compare against install data; or if you decide to get quite specific around the allocation of licences to individuals you may need a process to scope licences to users – rather than have them swept up in a generic pot for comparison. Any HR data used should be periodically checked for accuracy to ensure that staff allocated specific licences are still in the employ of the company.
Licensing Models: As touched on above, a straightforward comparison of one install to one licence, could underplay the fine print in licences that could allow for multiple installs of a software title under one licence. Pivotal to conducting and audit and reconciliation is to fully understand how licensing models work – and these models differ not just from vendor to vendor, but also within a vendor’s product range. The greater your knowledge of licence metrics and models, the more prepared you will be to go toe-to-toe with a software vendor if/when they come knocking.
Contract Data: If you believe that one contract with a software vendor is much like any other, then think again. Prices and terms and conditions could have been negotiated that could supersede the standard terms and conditions that are contained within a licence. A periodic review/mental refresh of such agreements is recommended; not least prior to the time of renewal/renegotiation.
Hardware Data: Variations in hardware specs have been influencing licensing models for some time (e.g. processor licensing for Oracle server titles) however, software vendors increasingly look to monetize their position by factoring in processor types, processing power and even processing manufacturer into the licensing calculations. More recently, one vendor of virtual software has turned to the amount of RAM dedicated to an install of their software to determine the bill due. So whilst the upgrade of a processor (or a series of processors) in a server may seem like a cunning plan, consult the licensing T&Cs of the software they are hosting to avoid any nasty shocks in the future.
3rd Level Metric Data: This will be data that is spun into a licence consumption that won’t typically be recovered by a standard installation/ inventory scan. Examples include: Millions of Barrels of Oil Produced in a Day; Number of credit card transactions; length of runway(!); the list goes on. Understanding what that value is, how to retrieve it, and then use it as part of your compliance calculation will be pivotal to setting budgets for financial forecasting.
Your data requirements to generate accurate audit and reconciliations are stipulated by the licensing models you have agreed to (or at least inherited) once the rhythm of this heartbeat is understood, you can set about prioritising which data should be collected and in what order.
Once more, being able to break-down what data is used by which processes highlights the value of viewing entities within the SAM System (e.g. a contract, a licence, a software request, a supported software catalogue) and then considering their respective life-cycles and how they interact. The touch points for these entities will be the processes; accordingly, the processes will need to communicate with each other. To get a flavour of how processes could work and play well together, either head over to our whitepapers page to download our SAM Template Eco-System, or for a more instant experience, go to our SAM-System webpage and glide your cursor over the image for a magnified view representing how SAM processes could inter-connect.