SAM & Your Policy Template
Many of the issues that can dog the discipline of Software Asset Management results from the failure of a company to align its IT operations to its IT and Business strategies. To that end, SAM Charter has put together a series of headings that you might wish to include in your ITAM/ SAM policy document, which should help qualify the “why” behind the “what” of this IT discipline. Please note: your ITAM/ SAM policy document should be direct, punchy and to the point. Think of your audience: This is a document that is to be read by people who can just about spell “IT”! They will not wish to be dazzled by esoteric terms such as “Cores”, “Virtualization” or “Containers” – but what they will be looking for is the direction and purpose with which IT/ software assets will be governed, and what factors shape that direction. Ideally, the document will include no more than 3-4 pages of content (excluding cover page, annexes etc.) but should point to an ITAM/ SAM Operations Document for those who might wish to read about aspects of the Policy in greater detail.
To that end, we have put together some headings that could prove useful in the creation of your own policy document, why the heading could be important and what sort of content could be included against that heading and will conclude with where that fits into your documentary matrix to support ITAM/ SAM.
ITAM/ SAM Mission Statement:
This can be quite tricky to encapsulate, as you are looking to come up with a single sentence or phrase that conveys the spirit of your policy template – and IT is not a topic that induces emotion in many people! Companies in the late 90’s and early noughties jumped on the band-wagon of “To be the world’s best [insert sector here] company.” This sentiment has to be filtered through IT, and then applied to ITAM/ SAM and make would-be readers enthusiastic about what they are going to read.
ITAM/ SAM Vision:
The Twitter throttle character-count is off at this point, and the single sentence sentiment can be expanded upon here; this is where we can add company colour to the Mission Statement, and try to give the Mission Statement-hook above more corporate colour. Our vision can include topics such as:
A formal risk management exercise should be conducted via a Corporate Governance Process to identify which risks ITAM/ SAM can reasonably be expected to tackle.
Licence and Cost Optimisation:
ITAM/ SAM should (as a minimum) be looking to produce timely and accurate ELPs (Effective Licence Positions) but aside from this reporting function, it should also be am agent for change; driving licence optimization across the IT estate.
Technology can be enabler, but we should always be looking to qualify how technology can propel business objectives.
As part of that desire to promote competitive advantage, ITAM/ SAM should look to be “fleet of foot” – agility, combined with the right technology in the right place at the right time (and at the right price) will only serve to reinforce that ITAM/ SAM is at the heart of positive change in your company.
ITAM/ SAM should act as guardians in supporting which new technology trends are a risk and which can benefit your company. End users can be advocates of new tech, but as we know, we have to temper enthusiasm with order so that we can demonstrate appropriate management of the risk that new tech can bring.
Software Vendor Audits:
This should be owned by the ITAM/ SAM Team, spearheading a company’s efforts in managing audit engagements. This ITAM/ SAM Policy document should spawn a separate ITAM/ SAM Audit Strategy document that offers details on what strategy and operations should look like when a vendor comes knocking.
ELP Refresh Rates:
Attempting to maintain a level of oversight on a vendor with just 20 installs, compared to a major vendor like Microsoft or Oracle, would entail a team larger than any SAM team I have ever seen. A risk-based approach should be applied to the frequency and effort applied to ELP management and maintenance. One of the worst mistakes many companies make is that they only generate ELPs when called upon by a vendor, or at the contract negotiation phase. If a quarterly update is maintained for major vendors, then the ELPs can be used to drive change in an IT estate.
Not to be overlooked; this is where company objectives should be detailed; some objectives might be charitable in nature (donating retired hardware to charity), best practice (to adhere to ISO 19770-1: 2017), legislative (e.g. SOX) or regulatory/ sector-based (PCI/ DSS). Based on the nature of the data that ITAM/ SAM can retrieve, reporting should expand beyond ELPs, and assist in these areas.
The ITAM/ SAM policy should detail the reach of the ITAM/ SAM processes to be created. This is important, particularly in larger/ enterprise organisations, as certain territories or business units could be managing their own IT assets, and so accountability for ITAM/ SAM should fall to those in charge of their own IT.
Although not contained in the ITAM/ SAM Policy document, reference should be made to its location. The RACI Chart should detail all stakeholders involved in all the ITAM/ SAM processes so that no assumption is made about who is doing what when it comes to IT/ software management. A RACI Chart supporting out SAM Process Kit can be found in our SAM Starter File (.zip) available for free on our whitepapers page).
A list of processes and their primary goals could be something that forms an Annex to the ITAM/ SAM Policy, as the list could get quite large for the 3-4 page document we’re aiming for and distract from the communications/ education goal of the ITAM/ SAM Policy Document.
ITAM/ SAM Operations Plan:
This is where you can go crazy! Again, the ITAM/ SAM Policy document should point towards the ITAM/ SAM operations plan and expand in much greater detail on all of the points/ headings contained in the ITAM/ SAM Policy document.
Once more, depending on the quantity of technologies engaged with, detailing which technologies are to be sued and why could find its way to an Annex of the ITAM/ SAM Policy Document.
ITAM/ SAM Maturity:
ITAM/ SAM are not static disciplines, so we should be making mention of the idea that we are looking to improve/ progress this discipline over time. This curve/ roadmap could be based on risk, but should appraise readers that ITAM/ SAM is not a “silver bullet” by which all woes will be resolved instantly.
Definition of which IT/ SAM assets are in scope:
As well as defining a geographical/ business-based boundary, it’s also worth qualifying which IT/ SAM assets are to be covered by this policy. This could be further qualified by creating a Support Software Catalogue, (download your free whitepaper on creating an SSC here) which would support ITSM and ITAM/ SAM operations.
A Reporting Process should be established to act like a USB port for the rest of the business to interface with the ITAM/ SAM system (and by system we mean the right blend of People, Process and Technology) that way, a two-way structured exchange of information can take place.
The engine by which the ITAM/ SAM system will progress along the maturity curve; Plan, Do Check and Act are the principle components of the Deming Cycle and should be applied to the ITAM/ SAM System, and highlighted in the ITAM/ SAM Policy document.
A suggested document hierarchy is offered below, often missed under the assumption that the technology will answer all ITAM/ SAM problems – at best though, a SAM Suite is nothing more than a barometer for licence compliance; the business has to act on compliance reports to improve its given situation. If it only waits to do this when it is called upon to generate an ELP, (an audit or contract renewal) then the business will always lose. For a deeper dive on the nature of the documents below, please see our webpage on our SAM Process Kit.
Having an ITAM/ SAM Policy should help mitigate the risk of a passive asset management.