Skip navigation
All Places > Snow Product Hub > General Licensing Forums > Blog > 2017 > August
2017

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:

 

Your Systems

Your Processes

Your Staff

 

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.

So let's work on the assumption that you have got the foundation of a SAM program in place; you have identified your stakeholders; your operational scope is confirmed and your IT and business goals can be linked to the day-to-day activities of your SAM program.

 

Next, we need to consider some of the documentation that will support you in ensuring that SAM reaches a BAU state, and supports not just SAM, but other key areas of the business.

 

ITAM Policy:  A 2 or 3-page document using very simple language explain what SAM is, why it is important to the business and what the proposed roadmap for SAM might be.  This document should be written in 80% business-speak, as it should be pitched at someone who occupies a senior position in the company, but has only a cursory understanding of IT.

 

ITAM Operations Plan:  Next we need a larger document that seeks to explain how on a day-to-day basis we are looking to tackle the issue of SAM.  This should include details such as the processes applied to the SAM lifecycle, the interfaces with other areas of the business, expected reports the SAM function is prepared to produce, and what steps will be taken to drive SAM maturity over time.

 

Supported Software Catalogue:  This will tie in with the afore-mentioned work you will have done on scope.  Where a lot of SAM programs fail is that they believe they have to throw their arms around the world and account for every piece of installed software for all vendors across all of their estate; with 100% licensing and contractual precision.  Unless you have a cast of 1000s representing the ITAM function, then this is not a realistic proposition.  Take a risk-based approach in determining which vendors or titles take priority over another.  The factors that could influence the assessment of which titles to tackle in what order will be unique to your company.  Equally, you could embark upon a value-chain-analysis exercise; so that the most commercially valuable titles are the ones that make it to the head of the compliance queue.  What methodology is chosen, make sure it is referenced in the ITAM Policy Document, and qualified in the ITAM Operations Plan Document, so that no one is in any doubt as to why you have chosen the sequence of software that you have.

 

Process Maps: These should offer 30,000ft view of what a given process seeks to achieve and the manner in which it operates. It might also allude to the technology that is used in completing this task, and also which key stakeholders are engaged with the various function steps that comprise the overall process.  Critical to understanding the bigger picture and how processes interact, is the modelling of data that is influenced by the function steps.

 

Process Definition Document:  This document offers a 10,000ft view of a process, ideally aimed at a Line Manager/Head of Department.  This looks to link the process to the business and IT goals, and any regulation/ best practice the process should be addressing.

 

Standard Operating Procedure: (SOP) Imagine someone came into a SAM role and from day one was expected to know what to do with a given process.  This is the remit by which you should draft an SOP so that a stakeholder can effectively contribute to a process. If the job role calls for knowledge of a system or work discipline, then this should be reflected in the level of detail to which the SOP is written.

 

RACI Chart:  Responsible, Accountable, Consulted and Informed.  This matrix defines to what level a SAM Stakeholder engages in a given process AND the framework as a whole, and is an exceptionally powerful document to move forward with.  NB:  If you refresh your processes, don't forget to refresh your RACI chart.

 

Communications Plan: Armed with your RACI chart, you can set about plotting what messages go to whom, when, how often and through what medium.  This will vary depending on the project/ BAU status of your SAM program, and also the level of involvement the SAM stakeholder is expected to maintain.

 

The physical medium of the articles mentioned above will be guided by corporate preference.  However, if you have a company standard for such documentation, then it would be appropriate to stick with a style that the business knows and understands so as to avoid culture shock.

 

Use cases:  Going back to the risks that were highlighted in any decent Corporate Governance Process and/or SAM gap analysis, you can start to identify the critical reports that need producing, and also get an idea of the VIPs/Major stakeholders in your company that need those reports.  Approach the Software Asset Management System from their point of view.  An approach I picked up from agile looked to identify those use cases like so:

 

 

As a <insert job role here> I want to be able to perform <insert task here> so that I can achieve <insert business/IT/SAM goal here>.

 

This will also allow you to prioritise those reports/use cases which will help keep your SAM System business-relevant.  If such an exercise becomes a formal part of your SAM agenda, then documenting and revisiting these use cases could prove very useful. It could mean the winding down of previously tricky reports to be produced, or equally, it could highlight a new direction the business is going in that no one had thought to inform the ITAM function of.  At its core, this exercise seeks to reinforce the synapses that sit between the processes that comprise your Software Asset Management Framework.  Is data effectively transmitting from one process to the next?  If it's not modelled to do so then you could be creating information cul-de-sacs.

 

A System Process/Data Map:  One of the biggest over-sights I often see on SAM program creations is the ability of implementers/consultants to map the overall solution.  If our process maps offer a 30,000ft view of processes, then a unifying Framework Map should model the Software Asset Management System used by the company - A 60,000ft view if you will.

 

Conclusion:  Your way-points to demonstrate progress could be the completion of processes, the on-boarding of vendors, the installing and testing of technology, or even the placement of FTEs to cover skills-shortfalls in the ITAM team.  Whatever these are, don't forget to promote such wins via the communications policy mentioned above; and don't forget to link such wins to the overall goals and ambitions of the business.  Stating that Tommy has joined the ITAM team might be news for Tommy's cousin who works in marketing, but stating that Tommy is an Oracle Licensing Expert and will help with cost-optimisation strategies to keep IT spending to a minimum is much more likely to boost Tommy's profile, and please the higher-ups that SAM maturity means something to their business.