When Tooling Fails

The pattern is consistent. A business invests in a tool, often as an extension of an existing system. For example, adopting ServiceNow SAM Pro simply because ServiceNow already underpins the CMDB. Expectations are set around savings, optimisation, or control. Twelve months later, the tool is live, dashboards exist, and yet very little has changed. Costs have not materially reduced. Licensing risk remains. Decision-making is no better than before.

What looks like a tooling problem is usually a capability problem that shows up in three predictable ways.

Failure 1: Buying tools without understanding the data problem

Every tool – be it ITAM, SAM, SaaS, or FinOps tool is only as good as the data feeding it. This is obvious in theory but routinely forgotten in practice.

Organisations are sold outcomes before anyone has confirmed whether the required inputs exist, are accessible, or are usable. Savings forecasts are produced without validating whether entitlement data can be sourced, whether cloud consumption APIs are available, or whether inventory data is accurate enough to support licence or cost decisions.

This is particularly visible with large enterprise platforms such as ServiceNow. ServiceNow can support ITAM, SAM, and increasingly FinOps use cases, but it does not magically create data maturity. It expects clean discovery data, reliable contract records, consistent user identity, and integration with cloud and SaaS sources. Without that, the platform simply industrialises confusion.

In SAM, this often surfaces when organisations discover they cannot reliably locate contracts, metrics, or historic entitlements. In ITAM, asset records exist but are incomplete, duplicated, or misaligned with reality. In FinOps, it appears when cloud billing data is available but cannot be mapped to teams, products, or environments in a meaningful way.

There is a second layer that is missed even more often. Contextual data. Tool outputs rarely stand alone. Licence optimisation decisions require organisational data such as departments, cost centres, or joiner and leaver status. FinOps recommendations need ownership models and workload context. Without this, teams generate insights they cannot act on.

If you cannot clearly answer what data your tool needs, where it comes from, who owns it, and how reliable it is, you are not ready to buy a tool. You are ready to do the groundwork.

Failure 2: Defaulting to convenience instead of outcomes

Tooling decisions are frequently driven by what is easiest to buy rather than what is most likely to work.

An existing platform is already deployed. Procurement frameworks are in place. Commercial leverage exists. The argument is made that adding another module or capability is more efficient than introducing something new. ServiceNow is again a common example, but the same logic applies across ERP, cloud management, and SaaS platforms.

Convenience is not inherently wrong. It becomes a problem when it replaces outcome-driven selection.

A tool that is excellent for ITSM does not automatically become the right choice for SAM or FinOps. A cloud cost platform optimised for engineering teams may be a poor fit for financial accountability. A SAM tool designed around Microsoft may struggle with SaaS sprawl.

There is also a strategic risk that is rarely discussed. Consolidating multiple critical capabilities under a single vendor can weaken future negotiating positions and limit flexibility. What feels commercially sensible in year one can become constraining by year three.

The tooling market across ITAM, SAM, and FinOps is broad and uneven. Some tools are deep and narrow. Others are broad and shallow. Some are built for practitioners. Others are built for reporting. Without clear selection criteria grounded in your objectives, any choice is a gamble.

Tooling should be selected based on the decisions it needs to support, not the procurement path of least resistance or lowest cost.

Failure 3: Ignoring implementation and operational reality

Buying a tool is a procurement exercise. Making it deliver value is an operational one.

Many organisations underinvest in implementation, integration, and ongoing operation. The assumption is that once the platform is live, value will follow. In reality, most tools require sustained effort to configure, maintain, and embed into day-to-day processes.

In ITAM and SAM, this includes maintaining discovery integrations, updating licence models, and governing data changes. In FinOps, it means managing tagging policies, maintaining allocation logic, and regularly reviewing recommendations. Tools described as simple to deploy still require ownership and care to remain accurate.

When these costs are ignored, the tool quickly becomes shelfware. Dashboards exist, but trust in the data erodes. Practitioners revert to spreadsheets, and leadership begins to question the return on investment.

The true cost of a tool is not the license fee. It is the license fee plus implementation effort, integration complexity, and the ongoing skills required to keep it relevant. If the combined cost exceeds the value delivered through savings, risk reduction, or efficiency, the tool has already failed.

The common thread: tooling without intent

Across ITAM, SAM, and FinOps, the same root cause appears. Tools are bought before organisations are clear on what they are trying to achieve and what it will take to achieve it. We regularly see organisations reach this point with technically capable platforms that were never given the conditions to succeed.

Effective tooling decisions start with intent. What decisions need to be improved? What behaviours need to change? What data must be trusted? What trade-offs are acceptable?

Before investing, practitioners should be able to answer these questions with confidence:

• Do we know what data is required to generate meaningful outputs?
• Have we identified the additional context needed to act on those outputs?
• Are our selection criteria driven by outcomes rather than convenience?
• Have we accounted for implementation, integration, and ongoing operation?
• Do we have the capability to run this tool well, not just own it?

If the answer to any of these is unclear, the risk is not that the tool will underperform. It is that it will never properly launch.

This is where many organisations benefit from stepping back and stress-testing their tooling strategy before committing. Not to slow progress, but to avoid investing in platforms that cannot succeed in their current environment.

Tooling should amplify good practice, not compensate for its absence.

For a deeper dive on ITAM tooling, download our eGuide - Why Most Platforms Fail to Deliver Value and How to Choose One That Doesn’t. It does not compare feature lists. It focuses on whether the platforms in the marketplace can produce defensible outcomes in a real operating environment.

It will help you answer the question “Which platform, combined with the right operating model, will allow us to explain our position, defend our decisions, and act on them every month?”