Digital Transformation and Software Asset Management

At the SAMS Europe event in Berlin I facilitated a series of round table discussions on how Software Asset Management should be adding value to digital transformation projects, why it often is not, and how to fix the most important disconnects.

Over five 30-minute work groups it became clear that, while there was plenty of discussion and many different points to consider, a couple of topics kept bubbling to the top. The 25 or so participants — all senior SAM stakeholders in large European enterprises — felt that for the SAM function to contribute meaningfully to transformation, there needed to be greater focus on two things:

1. Building relationships with non-SAM stakeholders
2. Choosing tool sets fit for tomorrow’s needs, not yesterday’s

Both are worth taking seriously, and they fail in different ways.

Building relationships with key stakeholders

This was a top-three takeaway for four of the five discussion groups.

There was general acceptance that the SAM team too often acts in isolation, while sitting on data, insight and expertise that would be genuinely useful to stakeholders across the organisation. The team has the answer to questions other people are asking badly, and nobody in either direction knows it.

Most participants agreed that the SAM team cannot wait to be invited to the party. It has to engage proactively and demonstrate how the function adds value to transformation and governance projects.

That can be done in several ways: preparing dashboards of useful insight aimed at specific stakeholders, securing executive sponsorship for a larger role in transformation work — most SAM teams represented reported into either the CIO or the CFO — or, as one group put it, using coffee and cake to bribe reluctant stakeholders into a meeting.

What was clear was that these SAM teams were not content to sit back and work their existing queue. They wanted to help their organisations achieve transformational goals and they knew they could add value.

An interesting aside. When the room was asked how many attendees had received personal career development training — as opposed to hard-skills training such as licensing or product courses — fewer than one in ten hands went up. That was an unscientific show of hands rather than a survey, but it points at something real: it is unrealistic to expect SAM teams to suddenly become good at networking when nobody has equipped them with the interpersonal skills to do it.

Tool sets for tomorrow’s needs

The second common theme was that teams lacked the tools — and therefore the visibility — to play an early role in transformation.

There was consensus that most SAM teams did not have enough visibility of spend outside IT, or of technology consumed in the cloud and on mobile devices. Most were still focused heavily on on-premises software and hardware, partly because their tools offered nothing else. Participants acknowledged that SaaS spend was probably costing their organisations too much, and that where processes existed at all, the tools did not help enforce them.

Several teams were constrained by reporting and analytics. Some lacked the pre-canned reports needed to satisfy a growing group of stakeholders; others lacked the ability to deep-dive and analyse data in a way that reflected changing needs. A few could not create dynamic dashboards at all, and were reduced to emailing PowerPoint files to senior stakeholders once a month.

That dissatisfaction fed directly into the other things the groups identified as prerequisites for SAM having a seat at the transformation table: a better understanding of the current baseline, improved visibility of toxic cloud consumption across both SaaS and IaaS, and greater control over spend.

What has changed since

Everything in the section above was a fair description of incumbent SAM tooling at the time. It is no longer a description of what is available, and it would be misleading to leave it standing as if it were. Each gap the groups named now has a specific answer.

Spend and consumption outside IT. CerteroX SaaS Management discovers applications through three converging signals — identity provider sync from Entra ID and Okta, connector sync pulling authoritative user and licence lists from the vendor, and a browser extension that attributes usage per user. Forty-seven connectors ship today, resolving against a catalogue of more than 35,000 applications. That is how you see the software finance is paying for that IT never bought.

Cloud consumption. CerteroX Cloud Management covers twelve cloud and data platforms with twenty-six named, individually tunable recommendation checks — abandoned instances, obsolete snapshot chains, instances stopped but not deallocated, reserved instance and savings plan opportunities — and ingests the FinOps Open Cost and Usage Specification (FOCUS) natively, so the cost model stays portable rather than locked in a vendor schema. Certero reports an average cloud cost saving of 38% across environments under management.

Mobile. CerteroX ITAM includes mobile device management for iOS and Android, including Apple DEP, in the same console and the same schema as the Windows, macOS, Linux, AIX, HP-UX and Solaris inventory. Mobile is not a separate product with a separate reconciliation exercise.

Dashboards and analysis. Personal and role-shared dashboards, trend charts, KPIs and threshold alerts are standard, and there is a read-only API with a documented Power BI data source for the teams whose stakeholders want the numbers inside their own reporting. Reporting agents run on a schedule and deliver to Slack and Microsoft Teams. Nobody needs to be emailing a monthly deck.

Tools that enforce process. This was the sharpest complaint in the room and it is the one that has moved furthest. Governance Policies express compliance as code with a reusable filter builder — BitLocker enabled, Defender running, Azure VM tag hygiene — and export and import as JSON. In SaaS Management, a workflow engine with eight triggers, eleven conditions and thirteen actions handles the sequence between detection and resolution, so an unused licence at thirty days of zero usage results in something happening rather than a line on a report nobody actions.

Toxic consumption. The phrase the groups used in 2019 has a direct descendant. Unused licence detection, app rationalisation ranked by recoverable saving, per-application budgets with warning and critical thresholds, offboarding checklists showing per-licence revocation status, and OAuth grant risk scoring all exist to answer the same question: what are we paying for, and who actually has access to it?

The one gap the groups did not anticipate is now the most urgent. AI tools are bought on expenses, adopted without approval and given access to company data. CerteroX classifies them from application feature tags in the catalogue rather than a hardcoded list, so the detection set grows on its own, and ranks adoption risk by the share of the organisation using each tool. Ten people on an AI assistant is a different problem from a thousand.

Increasing the value of Software Asset Management

Those are two very different challenges with two very different remedies.

Soft skills are genuinely important in Software Asset Management. Relationships with stakeholders across the organisation are what separate a programme that succeeds from one that does not, and they determine the respect and the opportunity the function is given. Career development training would benefit almost any senior SAM professional, and the show of hands in Berlin suggests hardly anyone is getting it.

Less obvious, but with a similar effect, is your choice of SAM services partner. A good one understands the politics of a large organisation as well as they understand data centre licensing. In practice that is close to having a coach standing next to you.

On the tooling side there are two situations.

For organisations that have not yet invested in a SAM tool — admittedly rare in those groups, which represented large, mature enterprises — the discipline is to build selection criteria from a forward-looking view of what will be required in twelve to thirty-six months, not a historic view of what SAM used to be. Establishing those requirements is also, conveniently, an excellent excuse to meet the stakeholders you needed to build relationships with.

For organisations with an incumbent tool, the choice is to stick with what you have and work around its limits, to supplement it with something that fills the gaps, or to replace it.

Replacement is the most daunting option, and not without reason. SAM tools have a reputation for being slow to deploy, difficult to configure and heavy to run, so swapping is not a decision to take lightly. But the reputation was earned by a generation of architecture, and architecture is the thing that has changed. A platform built on one data model, with one agent and one schema across every asset class, does not carry the integration burden that made the old ones painful — because there is nothing to integrate.

Ask a vendor to show you the thing working, not a slide about it, before you believe any claim about how fast it goes in. That applies to us as much as anyone. Book a demo and make us prove it.