A six-step plan for building a SAM programme that covers on-premises, SaaS and cloud as one problem rather than two — scope, maturity, people and technology, accountability, and what to do first.
Software concerns now span traditional on-premises infrastructure, Software-as-a-Service and cloud Infrastructure-as-a-Service — and increasingly the AI tools sitting on top of all three.
That raises a question worth settling before you plan anything. Do you treat these as “old world” and “new world”, run by different teams with different tools and different reporting lines? Or do you manage your commercial relationship with each software publisher holistically, regardless of where the software happens to run?
The second answer is the right one, and it is harder. Microsoft does not care that your on-premises licensing sits with SAM and your Microsoft 365 subscription sits with the service desk. Neither does Oracle, and neither will an auditor. But a plan that starts by declaring “we will cover everything” and nothing else is not a plan. What follows is a six-step structure for building one that survives contact with the organisation.
Most SAM programmes are funded on a compliance argument and then judged on a savings argument. Decide which you are actually being asked to deliver, because they lead to different first-year work.
There are broadly three purposes a SAM function can serve, and you can pursue all three eventually — but not simultaneously, and not in year one:
Write your purpose down in a sentence that a finance director would recognise as a commitment, then say it consistently. The single most common reason SAM programmes lose sponsorship is that nobody outside the team can articulate what they are for.
You cannot plan around a number you do not have. Before you assess anything, build a picture of where the money goes.
Scope means four categories, and most organisations have decent visibility of one of them:
Two figures are worth carrying into the scoping conversation. 46% of SaaS licences go unused, with the average organisation using 54% of what it buys. Wasted cloud spend runs at 29%, up for the first time in five years. Those are industry averages rather than predictions about you, which is exactly why the scoping exercise matters — you are trying to find out whether you are the average.
Practical output of this step: a list of publishers and vendors ranked by annual spend, with an owner’s name against each and a note of which ones you currently have no measurement for at all.
Maturity assessment is where plans usually go wrong, because it is treated as a scoring exercise rather than a diagnostic. The score does not matter. What matters is identifying the specific capability you are missing that blocks everything else.
Assess honestly across four dimensions:
ISO/IEC 19770-1 gives you a formal framework if you need one for a board paper. For planning purposes, a blunt four-way self-assessment against the questions above usually tells you the same thing in an afternoon.
The output is a shortlist of blocking gaps. If your entitlement records are in three shared drives, no amount of discovery improves your licence position. Fix the blocker, not the score.
All three, in that order of difficulty. Technology is the part you can buy.
People. SAM needs someone accountable, not a rota. It also needs publisher depth — Oracle, IBM and SAP licensing are specialisms, and a generalist will not get there by reading the terms. If you cannot recruit that depth, contract it: a managed service extends the internal team without turning a niche skill into a permanent headcount.
Process. The processes that matter are the ones at the boundaries: joiners and leavers, request and approval, decommissioning, renewal, and the point where procurement issues a purchase order. SAM that only runs a quarterly reconciliation is archaeology. SAM wired into those five moments is control.
Technology. What the platform has to do is more specific than most requirement documents make it. It has to recognise software reliably — CerteroX SAM resolves against a Software Recognition Database of over 3.5 million titles, with release date, end-of-support and extended-support dates attached, because “SQL Server” is not an answer. It has to meter usage, not just installation: a rolling 90-day utilisation figure is what turns an inventory into a reclamation list. It has to cover the platforms you actually run, which for most organisations means Windows, macOS and Linux plus AIX, HP-UX or Solaris somewhere in the datacentre. And it has to cover SaaS with the same rigour, which means connectors that pull authoritative licence lists from vendors rather than guesses — 47 of them ship today, against a catalogue of over 35,000 applications.
The point of insisting on specifics is that these are the capabilities that decide whether step 6 is possible. A tool that produces a list of installed software has not helped you prioritise anything.
Two questions decide whether a SAM programme survives its second year: who pays for it, and who is accountable for the waste it finds.
On cost, be straightforward. A SAM programme costs tooling, people and time, and it should be funded against a specific, named recovery — a renewal you intend to negotiate down, an audit exposure you intend to close, a licence pool you intend to harvest. Funding SAM against a general promise of efficiency invites a general question about value at the next budget round.
On accountability, the harder problem: SAM finds waste that belongs to someone else. A hundred unused design licences are a departmental budget line, and the department has no incentive to give them back unless it sees the money. This is where showback and chargeback earn their keep. Attribute cost to the team that consumes it, publish it, and set a threshold that triggers a conversation before the renewal rather than after it. In practice that means cost pools with real owners, budgets with warning and critical thresholds, and named owners against every application — application, business, technical and data owner are four distinct roles, and conflating them is why nobody answers the email.
Accountability without attribution is a memo. Attribution without authority is a report. You need both.
You will not do everything in the first year. Sequence the work by exposure and effort, not by what is easiest to inventory.
A reasonable default order:
Publish the sequence and the reasoning. A prioritised plan that omits something deliberately is a stronger position than a comprehensive plan that quietly fails to deliver any of it.
With scope. Everything in steps 3 to 6 depends on knowing what you have and what it costs, and most organisations discover during step 2 that the answer is materially different from what they assumed — usually because SaaS and cloud software have been procured outside the process that SAM was built around.
Treating the old world and the new world as one problem is not a philosophical position. It is the only way the numbers add up.
Other posts covering the same ground.
Cloud sprawl, decentralised buying and relentless audit pressure are pushing older ITAM setups past the point they were designed for. Here is where they crack first, and the four moves that keep you ahead of it.
The licensing changes that mattered in June and July 2025 — Microsoft Product Terms, the return of the SAMOSA Act, the end of the Microsoft 365 nonprofit grant, Adobe's AI credit cuts, a Dutch ruling against Broadcom, and rising Oracle Java audit activity.
The software asset manager owns the compliance position, but the value of the role is wider than that: risk prioritisation, procurement intelligence, tooling and the answers nobody else in the business can give.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.