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.