Shaking off SAM’s ‘solitary’ stereotype
Generally, when we refer to SAM within an organisation, it tends to imply the singular and a function that’s the responsibility of a solitary SAM professional. This perception seems to exist regardless of the size of organisation.
Whilst that may have been the case in the early days, when SAM was a static tool for periodic software inventory management, it’s very now out dated and actually somewhat stereotypical. It’s a bit like the 70s film image of a lone IT guy eating junk food all day whilst watching screens in an old control room.
Multi-stakeholder approach is needed
Far from being a one man or, if we are looking to dispel those negative stereotypes, one woman, job, SAM is now a business requirement in its own right. And the numbers of people involved in SAM related activity on an ongoing basis reflects this.
As the emphasis has moved beyond licensing compliance to optimisation and cost prevention, SAM has broad reaching relevance. This spans IT, governance, procurement and project management functions. Combine this with the fact that most mid and large-sized organisations have dispersed teams working across several sites, this creates the need for both a multi-stakeholder approach and cross-functional support.
From a product perspective working collaboratively places greater importance on including multi user capability within the SAM tools themselves – not only from a reporting point of view, but also data entry and management.
Although IT might own the user and audit data, purchasing needs access to actual usage levels to negotiate favourable license entitlements and reports to justify their arguments.
Added to this, making data from the SAM solution available to IT help desk staff, for example, can dramatically accelerate problem resolution times and create the potential to achieve first-time fixes.
So what’s preventing this from being commonplace?
The problem here lies not with the organisations using SAM, as they can appreciate the requirement. It lies with the technology, because most SAM solutions are designed to suit the lone SAM stereotype and effectively create silos of data.
What is essential for this to become a reality is multi-user capabilities that allow different levels of secure access to the many stakeholders involved.
It means introducing a web based interface so that users can input relevant information concurrently, generate standard management reports that don’t require specialist skills to generate and receive alerts and reminders when further action is needed.
The table below identifies the key stakeholders that need to be involved in the SAM process and why they need unfettered access to a common SAM solution:
|
Stakeholder |
SAM involvement |
| SAM professional | View software installs, check available licenses and potential shortfall risks, identify opportunities to optimize license availability (e.g. reharvesting unused licenses) |
| Procurement | Check current status of licenses (e.g. are any spare) before initiating purchase orders, adding new licenses to the repository, managing volume licensing agreements |
| IT (including sub-teams for end user computing, servers etc.) | View the configuration, location and status of IT assets deployed across the network (normalized data from multiple inventory solutions) |
| Corporate governance | Verify license position across the organisation, monitor compliance risks and check policies on asset procurement are being adhered to |
| Finance | Monitor the allocation and use of IT resources by individuals and groups for the purposes of budgeting, cross-charging etc. |
It may be a cliché but there are still too many silos in IT. SAM now has the potential to do away with all that and have a beneficial effect on breaking them down. It may even enable a new positive stereotype to take hold.
Related articles:
- Tags: Governance · licensing · procurement · project management · SAM · stakeholders
About Peter Bjorkman
Peter is a software and Web entrepreneur with 20 years in the business and more than 15 years of experience in designing and developing software products. As the CTO at Snow Software, he is responsible for the overall roadmap, architecture and design of the Snow Software product line.
On a related point…
SAM is not a singular process – i.e., ‘the SAM process’. SAM is a program,
comprised of many cross-lifecycle processes, within and external to IT and even
the organization itself. (SAM is also comprised
of policies, data, technologies, and people (roles and accountabilities).)
Every SAM professional should be asking themselves “who else in the organization can use this data?”
Once other teams are getting value from the knowledge you share it is remarkable how helpful other departments will become, there’s something in it for them!
PS: I’d include Senior Management (CxO) in the list of stakeholder also.
“The problem here lies not with the organisations using SAM, as they can appreciate the requirement.”
I’m not so sure about this. Yes, the organisation at an intellectual and strategic level may recognise that they (a) need to maintain a level of compliance and (b) can probably contain costs by doing so sensibly. This is a very different mindset to one where the necessity and benefits that can be derived from a structured and ingrained approach to SAM ( and indeed ITAM) is filtered right the way through the organisation and dealt with at a tactical level.
SAM can no longer be a one man band unless that man also happened to be the owner or CEO. No one working in the ITAM function is going to have enough authority to “Make” something happen. This function is all about influencing thoughts and ideals, about being able to evangelise the benefits that can be had if everyone plays a part.
Sad fact, the success of ITAM/SAM is almost entirely dependant on all the various groups involved being on board because it will mean them doing things in what they may consider to to be a less than efficient manner and having the budget because make no mistake there will be an impact on their resources that isn’t being funded by the ITAM team.
A tool is useful, no doubt about it. Without one a large organisation has no hope. However a tool is but a small piece of the puzzle. The tool needs to be surrounded by solid adherence to well defined process and be driven by people that know how licensing works for the the vendors that they are scoping. Never be fooled into thinking any tool can actually and accurately reflect a position without having knowledgeable SME’s uploading the entitlement, ensuring it is applied in the way the company wishes to operate and that relevant data is correctly captured.
I tool is nice to have, process and across the board buy into the program is essential. Given the choice I would pick across the board buy in first, process second and only then worry about which tool vendor’s pockets I am lining.
Just my two cents
Jim Webber
Great points, great approach, thanks Jim.
Piaras – good call on the CxO Reporting – have to agree that high-level senior reports are highly valuable, and even better if the CxO can generate them themselves without having to request them from SQL gurus.
Jim – agree with you around Board-level buy-in. It’s very difficult for any SAM /
ITAM program to succeed without it. But perhaps (as Piaras suggests) giving
them their own view of the data generated by a competent SAM solution – and
helping them understand how that data can help them make better business
decisions – is one way of gaining that buy-in?
Matt – completely agree that there must be levels of information view. However in order to be able to get that accurate, top level view in the first place. . . . . . See where I’m going?
You can use the promise of the ubiquitous “CxO Dashboard” as a carrot in exchange for them employing the executive stick to the rest of the organisation to ensure you get there in a sensible and bloodless manner. What you can’t do is deliver them this dashboard first before they have mandated its conception and delivery.
Interesting article. I agree with a lot of the comments below. I have been in the SAM business for over 15 years and I think all too often the business case for SAM is the missing link. Most SAM programmes have too much emphasis on the need for data rather than the desire to turn data into value.