Software Asset Management Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the discovery dashboard get built instead of the entitlement register?

Because deployment data is available and entitlement data is not. Somebody can point a discovery tool at the estate this week and produce an impressive dashboard of installed titles by version, and that feels like progress. Entitlements sit in purchase orders in the finance system, agreements in a legal repository, amendments attached to emails and support renewals in the procurement tool, so nobody starts there.

The result is a system that answers half the question. Knowing what is installed tells you nothing about exposure, because exposure is the gap between deployment and entitlement, and the entitlement side is where the specificity lives. Your position is decided by your contracts: a legacy agreement with a grandfathered metric, an unlimited licence agreement with a certification date, affiliate definitions that determine whether an acquired subsidiary is covered at all, migration and downgrade rights negotiated at a renewal, development and test exclusions, territory restrictions.

The model that works makes the entitlement a structured, versioned record: publisher, product, metric, quantity, effective and expiry dates, the specific clause it derives from, and the restrictions that apply. Document extraction gives you a first pass from contracts and order forms into candidate entitlements, and a human confirms each one, because interpretation is the value rather than the transcription. Versioning is what makes the whole thing defensible, since you must be able to reconstruct what you were entitled to during any past period rather than only today.

What goes wrong when you turn a decade of contracts into entitlements?

This is the largest single effort in most of these projects and it is not an engineering task.

The first problem is completeness. Organisations under audit routinely discover entitlements they had forgotten they bought, which sounds like good news and is actually a warning: if you can find forgotten purchases, your register was never a register. Assemble from purchase orders, agreements, amendments, support renewals and reseller records, and reconcile the count rather than accepting the first source that looks authoritative.

The second is ambiguity. A material proportion of clauses do not have one obvious reading. When that happens the tool records somebody's opinion as if it were data, and eighteen months later nobody remembers it was an opinion. Capture the interpretation explicitly with the person who made it, the date, and the alternative reading, so that a future negotiation can model both positions side by side rather than discovering the assumption during a call with an auditor.

The third is acquisitions. An acquired entity's entitlement history is frequently incomplete, and the affiliate definition in your own agreements decides whether their deployments are covered by your contracts at all. That question is often unanswered inside organisations that have grown by acquisition, and it is worth answering before a publisher asks. Give someone with authority the job of making interpretation calls, and hand a developer your ten most awkward agreements before anyone prices the work.

Why do the discovery, virtualisation and cloud integrations break after launch?

Three data sources feed the position and each fails in a way that produces confident wrong answers.

Discovery tools disagree by design. One sees managed endpoints, another sees domain joined servers, a third sees more but names things differently, and each counts a different population. Normalise into one asset model with an explicit source of truth per attribute and a reconciliation queue for conflicts, rather than letting whichever feed ran last overwrite the others. Alert when a feed stops, because silence looks identical to no change.

Virtualisation is the one that decides money. For several publishers the licensable quantity depends not only on where a workload runs but on where it could run, so cluster boundaries, host counts and workload mobility settings are part of the calculation. Discovery tells you today. The argument needs history, which means capturing hosts, clusters, enforced boundaries and which workloads ran where, continuously, from the day you start. History you did not collect cannot be reconstructed, and that gap is precisely what an audit converts into a demand.

Cloud is the third and it needs a second topology model rather than an extension of the first. Bring your own licence rules, dedicated host requirements and instance sizing all change the calculation, tags are applied inconsistently, and instances appear and disappear within a billing period. Sample continuously rather than monthly, or your position rests on whichever snapshots happened to be convenient.

What happens when drift and audit evidence are not covered?

Someone adds two hosts to a cluster. A team spins up database instances for a load test and forgets them. A subsidiary joins the domain. Each of those can move an effective position overnight, and in most organisations it is discovered at the next annual review, by which point it is a year of exposure rather than a five minute conversation with an engineer.

Treat drift as an event rather than a report. Recalculate positions on a schedule and on change, and send alerts to a named owner with the specific cause: this cluster grew, this instance count rose, this user population changed. Set thresholds by publisher risk rather than uniformly, because two extra endpoints on a common product is noise and one new virtual machine in a database cluster may not be. This is the feature that turns the function from audit response into a continuous control, and it is where the money is actually saved rather than merely defended.

The evidence pack is the other half. When the letter arrives you should be able to produce, in days, the position per product with its full derivation, entitlement evidence with source documents attached, deployment data with the discovery method and date, the topology history, and a documented list of assumptions. Snapshot it immutably at the audit date, because a position that quietly recalculates while the audit runs destroys your credibility at exactly the wrong moment. Organisations that produce this quickly negotiate differently, and it shows in the settlement.

Should you build custom or configure what you already own?

If you are under about five hundred employees with a straightforward stack of cloud subscriptions and a couple of on premises products, configure. A contract folder, one discovery tool and a disciplined spreadsheet are proportionate, and a build would be theatre.

If you need broad coverage across thousands of titles quickly and your estate is conventional, buy. Flexera One and Snow bring deep publisher content libraries and strong normalisation of raw discovery data, which is hard work you should not repeat. ServiceNow Software Asset Management is the obvious choice if your configuration management database already lives there. USU is well established across European enterprises. Check too whether you already own a module you have never implemented, because unused entitlement to a platform you are about to replace is an awkward conversation to have afterwards.

Build when two or more apply. Your exposure is concentrated in a small number of publishers whose metrics are contract specific, which is the usual pattern. You have a virtualised or cloud estate where topology decides the position and a generic content pack gives you the worst case by default. You have grown by acquisition and hold multiple contract lineages. You have been audited and found the preparation cost unacceptable. Or you have priced a packaged platform and found the licence plus implementation plus the consultancy needed to interpret your contracts lands in the same range as owning something built around your actual agreements.

How do hidden costs get into the quote?

Contract volume first, and it dominates. Converting a decade of agreements, amendments and order forms into structured entitlements is the largest line in most of these projects, and it is analyst and legal time rather than engineering time. A quote that prices it by document count without having seen a sample is a guess.

Second, the number of publishers genuinely modelled. Each metric family is real work with its own calculator, its own test cases and its own edge conditions, so a scope of two publishers and a scope of twelve are different projects rather than the same project at different sizes.

Third, cloud, which adds a second topology model rather than a few extra fields. Fourth, multiple discovery tools with poor overlap, where reconciliation between them becomes a permanent operational queue rather than a one off mapping. Fifth, acquisitions, where entitlement history is incomplete and someone must make and record affiliate determinations.

Sixth, the ongoing analyst role. Confirming extracted entitlements, resolving reconciliation conflicts and reviewing drift alerts is a job, not a phase. A business case that assumes the system runs itself after year one will be revisited in front of your finance director.

What separates a build that works from one that fails here?

The programmes that work do one publisher end to end first, and they pick the one whose audit would hurt most rather than the one whose data is tidiest. That proves the entitlement model, the topology capture and the calculator pattern against a real position with real money attached, and the second publisher then costs a fraction of the first. The programmes that fail try to cover the whole estate at once, produce a partial position for everything, and cannot defend any of it.

Second, every position must be a derivation rather than a number. Which assets were included, which entitlements were consumed, which rule version applied and which assumptions were made. When you disagree with an auditor the conversation is then about a specific assumption, which is a discussion you can win, rather than about whether your tool is right, which is a discussion you cannot.

Third, start capturing topology history immediately, even before the rest of the system exists. It is cheap, it is the input you cannot recreate later, and it is the single most valuable thing you can begin this month. Everything else in the build can be reconstructed from documents. Where a workload ran last March cannot.

Finally, settle ownership before kickoff: the repository, the cloud accounts, the entitlement register and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. There is an obvious irony in reducing dependence on a publisher's version of the truth by creating a new dependence on a vendor's version of your data, and it is worth avoiding deliberately rather than discovering.