So you have an ITAM Policy, the business understands SAM/ITAM, your framework is established with all the necessary processes needed, and key stakeholders have been identified and have pledged buy in with their time and the data they own. The technology is installed, and your staff know what to do with it on a day-to-day basis. So what's next?
To move into the top echelon of SAM maturity, you should be able to demonstrate the following characteristics:
A Reporting Interface: You will already have identified key stakeholders who require ELPs, and how frequently they are needed (after all, being at the top end of maturity, you will be able to produce these documents in a repeatable and timely fashion). However, the rest of the business might be approaching your ITAM function for other non-ELP reports. Being able to transact such requests in a timely and efficient manner helps embed the ITAM function and the value your SAM suite offers to the company.
Key Performance Indicators (KPIs): Maintaining a health-check of your SAM Framework will involve the placement of KPIs against:
KPIs are subjective in nature, and in isolation may not mean very much to the business at large. Where they gain greater traction/interest with the business is where the KPIs report in money saved or a risk percentage.
Ultimately, the SAM Manager should be using a dashboard of KPIs to manage the SAM function, rather than seeking to drive changes in company culture through the deficits highlighted in ELPs.
Exceptions Analysis: The percentage of errors pertaining to licensing and installations should be spiralling downwards; however, exceptions will invariably crop up as staff find ever more creative means of circumventing protocol. The ITAM function should be looking to investigate and close any loop holes that arise, so as to prevent repeat offender-type activity.
Proactive Contract Support: If you have a dedicated Contracts Team, then they will need a lesson in how IT works. Sweating the small stuff about price per installation is not the way forward when negotiating with software vendors; costs are multiplied through differences in versions and editions; platform types, core counts, numbers of users and any other 3rd level metric a software vendor might wish to include in the licence consumption calculation. If this information is not ever-present in the minds of contract staff, then too much time could be wasted on unit-price discounts.
Furthermore, the contracts team will also need the results of a recent ELP, so that they know what software is in reserve. This, aligned to intended future usage, and also the remaining supported life of the software title(s) under contract will help out the contracts team on the best possible footing to future-proof the business in respect of software contract risk.
Mergers & Acquisitions: Finger in the air assessments of understanding the size of an IT estate being bought or sold off can create unwelcome and sizeable bow-waves of post M&A activity. If a portion of the legal entity is being sold off, then the parent company should be looking to review its volume contracts. Don't forget that such contracts were negotiated on the former size of the company (which has now shrunk). Such spin-offs often attract the attention of software vendors, as the sold-off or bought entity wishes to trumpet this complicated business procedure. Therefore, being able to justify the figures arrived at to support the sale/purchase is a true sign of demonstrating proactive SAM.
As-a-Service: Due to the subscription-like nature of paying for as-a-service software, such accounting can move financial expenditure from CAPEX (Capital Expenditure) to OPEX (Operational Expenditure). To most of us, this means little or nothing, providing the evidence of purchase is relayed to the SAM suite. However, to our financial cousins, this could cause elevated temperatures and racing pulses. OPEX values show up on the Profit and Loss sheets, and so could colour the profits of the company in a less favourable light. If as a SAM Manager, you are able to reduce this impact by ensuring as-a-service software is ONLY being offered to those employees who need it (and most definitely not to former employees) then you are demonstrating commercial acumen to the business - good proactive SAM.
Top tip: The finance director wants to you shave 20% off your as-a-service expenditure - how can you do this? Start by taking the support and maintenance element of your as-a-service expenditure and re-accounting for it in CAPEX: You're welcome
Automation: A recent buzzword in SAM and IT, automation in this instance refers to the connected transfer of data between disparate systems. At its core, SAM Suites view this as second nature, insofar as entitlement and inventory data is invariably imported into a SAM suite by this very means. Give a thought though, for all the other data that you might be reasonably expected to make use of - this too, benefits from being ported seamlessly into your SAM suite. The fresher the data, the greater the shelf-life your SAM reports can enjoy. Remember the System Process/Data Map in Blog 2? Get that right, and acres of time and effort can be saved in your automation initiatives.
PDCA: "Plan-Do-Check-Act“ the Deming Cycle should be applied to your SAM Framework. Those KPIs we mentioned before? Today's accuracy target is tomorrow's norm. Best practice too, should also highlight the KPI accuracy reported in generating SAM reports (i.e. this report has been generated covering 85% of the IT estate, and the date of inventory capture was on: dd/mm/yyyy. The last date of entitlement capture was dd/mm/yyyy. The relative rate of software change in the IT estate is: xx%)
Technology Weave/Value-Chain Analysis: Viewing the IT estate through the eyes of software vendors could provide you with a slanted view that is not shared by the rest of the business. Typically, non-SAM staff will adopt a service-based approach of looking at IT: Messaging, E-portal, Pay-roll etc; they will perceive IT as the solution to the business problem, not the component parts that form that technology stack. Being able to report in a SAM fashion on that technology stack is high-end SAM, and being able to do so in a repeated and systematic fashion is well worthy of a pat on the back.
Proactive Risk Reporting: At SAM Charter, we look to reinforce data integration within the SAM suite by using what we call an Orphan Data Process. A more leisurely view of this process can be taken by clicking on the link above, but the summary goal of this exercise is to ensure that the data within the SAM suite is as drum-tight as possible. Namely:
- All installations can demonstrate the correct Proof of Entitlement
- That the licence pool is being properly managed
- That the recognition files used in reconciliation between installation and entitlement are as up to date as possible.
At the point where you know this data is as closely aligned as possible, then you know you have addressed a sizeable chunk of quality assurance requirements within the SAM suite itself.
Conclusion: SAM is not a Faberge egg, it is a wind chime - and the quality of the sounds made depend on your ability to remain flexible and adaptive to IT change. The true trick to maintaining an acceptable level of SAM is in realizing the business value it can offer, and what the business expects from SAM; your job as a SAM Manager then turns into facilitator and expectation manager.