There are no silver bullets in SAM

There-are-no-silver-bullets-in-SAM

The one constant in life (and SAM) is change…

In this, the final blog I will be writing during my tenure consulting for 1E – I wanted to leave the reader with a notion of what a software asset management (SAM) framework should be capable of adapting to.

Possibly the reason we don’t talk about a SAM system or a SAM framework, is because we have been willingly led by the nose by tools providers that their product is the silver bullet to SAM, and so with a weary reluctance we nod our heads and watch systems implementers and product consultants scurry about our premises like the mice on Bagpuss (US readers, please reach out to your British colleagues for this reference) in the vain hope that the tool is the solution.

But as I heard on a recent podcast on ITAM Review: “A fool with a tool, is still a fool!”

There are no silver bullets in SAM, and so whilst the implementation of a software product might answer an element of your SAM woes, the wider picture will still need addressing.

So rather than swallow the orange whole, let’s take a stab at the information that might reasonably be expected within the SAM solution, and then assess the frequency and speed of change for that data.  If, after having gone through a software vendor audit, you will wish to keep a tempo or operating routine to keep your reports fresh/relevant then perhaps you might be able to direct finite resources to where they are needed to ensure that whatever ad-hoc reporting mechanism provided you with your audit and reconciliation reports is consolidated, and then refined, over time:

Scope: Typically, once known, not subject to vast amounts of change although the business does have a knack of conducting deals that can exponentially grow a SAM Framework scope without informing IT.  Equally, additional software vendors could be added with little or no regard to the capability of the existing inventory tool to monitor new titles/platforms.

Inventory Data:  Typically experiences minor changes across a large volume, and are daily in nature.  In an ideal world, this would remain static as this would add value to software usage reports; however, IT experiences the ripples of change dictated by company/personnel changes. New software titles can also present their own unique challenges; an ability to manage the transition between “new to your network” and “new to your SAM suite recognition database” is something worth considering.

HR Data:  Hopefully, this won’t be too dynamic – however, the flexibility around transferring user licenses from ex-employees to new employees varies from one software vendor to the next.  Investigate this thoroughly.

Hardware Data:  Investigate multiplexing; and investigate what constitutes hardware.  Some software vendors (IBM and Oracle by way of example) will count physical devices as requiring a license to use a database.  Also, component (CPU) manufacturer and core data will also be used to calculate the cost around license consumption in the server/database arena.

Procurement Data:  Depending on the size of your company, this could be considerable and frequent.  Purchases act as authentication of licenses, and so need creating within the SAM suite off the back of the paperwork being processed.  Make sure quality information is used in the creation of licenses – wherever possible, use software vendor SKUs for license generation purposes.

This list is not exhaustive, but in assessing data flux/change, hopefully you will begin to see where you need to direct your SAM efforts once a BAU status is close to being declared.

Share this post

Share this post on your favourite social media platform.

Find this article useful?

If so please click here