The issue with SAM is not data. It is the approach.

SAM Promises Savings That the Organisation Rarely Realises.

I have delivered the same SAM report to the same client several quarters in a row. Unused licences, over-provisioned agreements, and consolidation opportunities. The figures were solid, the potential was real, and nothing happened. Then we ran it again the following quarter.

If you work with Software Asset Management, you have experienced a version of this. And I want to be precise about where the fault lies, because it does not lie with you, nor does it lie in your data. Most of the SAM functions I have seen are run by highly skilled professionals who produce accurate results.

It is the approach that fails. We have built a discipline that is excellent at identifying value but structurally incapable of realising it.

I have spent over a decade in various commercial software roles. First on the advisory side for Nordic and global enterprises, then internally within a large Danish energy company where I built the SAM strategy from scratch, managed Microsoft, SAP, and Oracle relationships, and led renegotiations. I have seen it from both sides of the table. The pattern does not change.

SAM is necessary. It is simply not sufficient.

Why Are Optimisations Not Utilised?

The reason is not incompetence, nor is it poor data. It is the conflicting interests of stakeholders.

SAM sits in procurement or IT finance. Optimisation requires action from application owners, platform teams, or business units. These individuals have different priorities, different KPIs, and different leadership. A SAM report landing on their desk is an unfunded request competing with their actual delivery targets, and it typically asks them to relinquish resources they have already paid for. From their perspective, there is no benefit in executing it.

Consequently, it remains on the "nice to have" list. Indefinitely.

Here is what changes that. When an optimisation is tied to the architecture, three things happen that a SAM report alone cannot achieve:

It shifts to a different governance forum. A licensing finding belongs in the procurement backlog. A capability finding belongs in the investment portfolio, where application owners must already defend their budget on an annual cycle. The conversation ceases to be optional.

It gains a business owner. When you can identify which capability an application supports, there is someone outside of IT whose metrics improve when it is rationalised. That individual has the mandate to prioritise it. The SAM manager rarely does.

The request changes form. "Give up 47 licences you pay for" is a loss. "This capability is served by four tools. Here is the consolidation case, and here is where the funds will be reallocated instead" is a reallocation with executive backing.

The same finding. Entirely different odds of being executed.

The SAM Limitation

That is the execution issue, but there is also a scope issue, which is the reason the realisation problem exists in the first place.

Ask your SAM team:

• Which of our 400 applications actually support our core business capabilities?

• We run three CRM systems. What is required to consolidate them into one?

• If we exit Vendor X, which business processes will fail?

• What does this application actually cost when you include integrations, operations, and business dependency – not just the licence?

These are not unreasonable questions. They are what your CIO and CFO need answers to in order to make investment decisions. SAM cannot answer them because SAM does not know what the applications do in a business context, how they interconnect, or who depends on them.

SAM sees licences. It does not see the business.

What Do Those Questions Actually Require?

Take the exit question, because it is the one I have been asked most frequently and been least capable of answering properly.

"What breaks if we exit Vendor X" is not a simple lookup. It is a traversal. You start at the vendor, move to the applications they provide, from there to the integrations feeding those applications, then to the capabilities those integrations serve, and finally to the business processes and owners above them. Four or five hops before you reach something a CFO can act upon.

Every time I was asked this during a negotiation, the honest answer was that it would take longer to figure out than the negotiation window allowed. So we entered the renegotiation without it, and the vendor knew we lacked it. This is not a data quality problem. It is a structural problem: a table stores one relationship per column, so the moment a question crosses multiple relationship types, you are back to manual joins and someone's memory of how the ERP integration was actually built.

A graph database stores relationships as first-class objects. The traversal is the query itself. This single difference shifts the exit analysis from a six-month project to a question you ask on a Tuesday. This means it can be raised in a live negotiation instead of arriving long after it has concluded.

This is why Clariox is an Ardoq partner, and why most of what we deliver is built on that platform. I did not approach it as an architect looking for a modelling tool. I approached it from the commercial side, after repeatedly needing answers I could not get in time, and the graph is the structure that produces them quickly enough to matter.

Here is what I now believe is achievable – and I say 'believe' advisedly, because the ambition is higher than what most SAM functions are set up to deliver today:

• Entering a renegotiation knowing your actual dependency profile, rather than merely asserting it

• Viewing capability overlap across business units as a standing view, rather than a one-off analysis

• Pricing an application based on everything linked to it, not just licences

• Understanding the criticality and business value of dependencies so we can make informed trade-offs between cost and value

• Testing a divestment or an M&A integration against the model before committing to a date

• Ranking the portfolio against the strategy in an afternoon

None of this is exotic. It is the job SAM was established to perform, using a data structure capable of supporting the questions.

Same Data, Different Question

(Illustrative, not client figures.)

The difference is not data quality. It is context.

Why It Is Urgent

Vendor pricing is becoming more complex, not less. Cloud consumption, AI add-ons, platform bundles, and consumption-based models. The days of simply counting licences are drawing to a close. You must understand what is consuming what, and why.

Boards demand commercial accountability, not compliance reports. No one gets promoted for being licence-compliant. "We reduced IT spend by 15% while accelerating our strategic programmes" is a board-level conversation, and it requires connecting cost with value.

Transformation creates architectural debt faster than SAM can keep pace. Every cloud migration, M&A integration, and digital programme adds applications, dependencies, and costs. This impacts Danish companies particularly hard: many of the large estates here have been assembled through acquisitions and shared-service consolidation, meaning duplicated capability is the default state, not the exception.

The Three Levels

Level 1: SAM (compliance). What licences do we have? Are we compliant?

Level 2: SAM and vendor management (cost management). What are we spending? How do we optimise renegotiations?

Level 3: Architecture and commercial advisory (strategic decisions). What should we invest in? What should we exit? What is the business case? What breaks if we change?

Level 3 is not a replacement for SAM, nor is it a different team. Typically, it involves the same people with a broader mandate and a connected data model supporting them. The SAM function most companies built was always intended to deliver commercial IT intelligence. It simply never received the layer that enables it.

And if your environment is genuinely small—three or four strategic vendors and a short application list—you do not need this. Level 2 executed well will serve you. The threshold is roughly where no one in the organisation can hold the full picture in their head anymore.

The Uncomfortable Question

If your CEO asked tomorrow: "Show me our top 10 IT investments ranked by how well they support our strategy, and tell me which we should double down on and which we should phase out."

Could your SAM team answer? Your procurement team? Your vendor managers?

Or would it require six months of spreadsheets, opinions, and departmental tribal knowledge to produce something defensible?

If it is the latter, you do not have a SAM problem. You have a governance and visibility problem.