SAM Policy Template

Introduction:

Your SAM Policy Template: Many of the issues that can plague SAM results from the failure of a company to align its IT operations and Business strategies.  We have put together a series of headings that you might wish to include in your ITAM/ SAM policy document.  This 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.”  Attempting to convey that in a SAM context is what we should be aiming for.

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:

Risk Management:

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.

Competitive Advantage:

Technology can be enabler, but we should always be looking to qualify how technology can propel business objectives.

Flexibility:

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.

Future-Proofing:

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 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.

Governance:

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.

SAM System-Scope:

The ITAM/ SAM policy should detail the reach of the ITAM/ SAM processes to be created.  This is important, as certain territories or business units could be managing their own IT assets. Accordingly, accountability for ITAM/ SAM should fall to those in charge of their own IT.

RACI Chart:

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.  This dispels any confusion about who is doing what when it comes to IT/ software management.  A Template RACI Chart can be found in our SAM Starter File (.zip) available on our whitepapers page).

Processes:

A list of processes and their primary goals could be something that forms an Annex to the ITAM/ SAM Policy.  The list could get quite large for the 3-4 content-pages, distracting from the goals of the 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.  Expanding in much greater detail on all of the points/ headings contained in the ITAM/ SAM Policy document.

Technologies:

Detailing which technologies are to be used (and why) could be an Annex of the ITAM/ SAM Policy Document.

ITAM/ SAM Maturity:

ITAM/ SAM are not static disciplines. We should be qualifying the idea that we are looking to improve SAM over time.  This roadmap could be based on risk, but should appraise readers that ITAM/ SAM is not a “silver bullet”.

Definition of which IT/ SAM assets are in scope:

Aside from defining a geographical/ business-based boundary, it’s also worth qualifying which IT/ SAM assets are to in scope.  You could further qualify this  by creating a Support Software Catalogue, which would support ITSM and ITAM/ SAM operations.

Communications:

An established Reporting Process acts like a USB port for the business to interface with the ITAM/ SAM system. That way, a two-way structured exchange of information can take place.

PDCA:

PDCA is the engine by which the ITAM/ SAM system will progress along the maturity curve. Plan, Do, Check and Act steps form the Deming Cycle and should be applied to the ITAM/ SAM System. Try and make sure this is explicitly called out in the SAM Policy.

Summary:

A suggested document hierarchy is offered below.  This is often missed under the assumption that the technology will answer all SAM Policy Template questions.  At best, 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 an ELP is needed, 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.

ITAM Document Hierarchy

Leave a comment

Your email address will not be published. Required fields are marked *