At a glance
- Challenge
- Contracts, usage, ownership and optimisation actions live in separate systems, so no view connects software cost to the value it produces.
- Approach
- Build a cost and consumption model on owner-validated data, maintain an opportunity register, and track realised value through to finance validation.
- Primary KPI
- % of addressable software spend covered by trusted, owner-validated cost and consumption data.
- Impact
- Optimisation value traceable from identification to finance-validated realisation, with forecasting that leadership can plan against.
01
Executive Summary
Software cost analytics usually stalls for a structural reason rather than an analytical one. The spend data lives in the ERP, the entitlement data in the SAM platform, the usage data in a dozen publisher consoles, and the ownership data — if it exists — in the CMDB. Each dataset is maintained by a different team to a different standard, and joining them requires decisions nobody is authorised to make.
This playbook describes building that join deliberately: establishing which spend is addressable, mapping it to entitlement and usage, attaching a validated business owner, and then maintaining an opportunity register that tracks each optimisation from identification through validation to realisation. The distinguishing feature is that realisation is confirmed by finance, not claimed by the function that identified it.
That single governance choice is what makes the analytics credible over time. Optimisation programmes that self-certify their savings lose executive confidence within about two cycles, usually when someone notices that the claimed savings do not appear in any budget.
02
Business Challenge
Executives ask three questions that current reporting cannot answer: what does software actually cost this business unit, is that cost proportionate to what the unit gets, and what did last year's optimisation programme actually deliver. The first fails on ownership mapping, the second on usage data, the third on the absence of any validated benefit tracking.
The credibility problem compounds. Because savings are claimed rather than validated, finance discounts them. Because finance discounts them, optimisation is not funded on the basis of expected return. Because it is not funded on that basis, the analytics capability that would produce validated numbers is never built — and the cycle repeats.
03
Typical Symptoms
Organisations that need this playbook usually recognise several of the following.
- Software spend can be reported by publisher but not by business unit or application.
- A material share of spend has no confirmed business owner.
- Usage data exists in publisher consoles but is never joined to cost data.
- Optimisation savings are claimed by the technology function and never appear in a budget line.
- The renewal pipeline is visible only to procurement, and only for contracts it was asked to handle.
- Dashboards are rebuilt manually each quarter and are stale by the time they are presented.
- Cost avoidance and cost reduction are reported as the same number.
- Nobody can state the value of the current optimisation opportunity pipeline.
04
Business Risks
Business risks by domain, with the risk and its impact
| Domain | Risk | Impact if unaddressed |
|---|
| Operational |
Manual, quarterly assembly of cost and usage data from disconnected systems |
Analyst effort is consumed by data preparation, the view is stale on arrival, and the same reconciliation is repeated every cycle with no cumulative improvement. |
| Commercial |
Optimisation opportunities identified but never tracked to closure |
The pipeline value is unknown, actions age without owners, and opportunities expire against contract dates that nobody was tracking. |
| Compliance |
Savings self-certified by the function that identified them |
Finance discounts the reported benefit, executive confidence in the programme erodes, and future optimisation is not funded on the strength of its return. |
| Technology |
No ownership mapping between spend, application and business unit |
Cost cannot be attributed, so accountability cannot be assigned and the analytics answer only the publisher-level question that was never the one being asked. |
05
Operating Workflow and Reference Architecture
Operating workflow
10 stages, each producing a defined output. This workflow is specific to this
playbook; the category lifecycle on the
Software Value index is an overview of how the playbooks relate,
not how any one of them runs.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative analytics workflow. Realised value is validated by finance rather than self-certified by the optimisation function — the single governance choice that determines whether the reporting retains executive credibility. Outcomes are not guaranteed.
Reference architecture
The systems, data and controls the workflow above runs on.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative reference architecture. The ownership mapping in layer two is the component most often missing, and it is the one that determines whether the analytics can answer a business-unit question or only a publisher question.
06
Implementation Approach
A representative implementation sequences in 5 phases. Duration and overlap
vary with estate size, data quality and the number of source systems in scope.
Phase 1
Scope and data foundation
Define what addressable spend means and assemble the sources. Scope ambiguity here produces coverage figures that cannot be compared between cycles.
- Addressable spend definition. Agree with finance what is in scope — licences, subscriptions, maintenance, cloud software — and what is deliberately excluded, and hold that definition stable.
- Source assembly. Establish feeds from the ERP, the contract repository, the SAM platform, SaaS subscription sources and the CMDB, each with a named owner and refresh cadence.
- Publisher normalisation. Normalise publisher and product names across sources so spend, entitlement and usage can be joined at all.
- Coverage baseline. Measure and publish the share of addressable spend that can currently be joined to entitlement, usage and an owner.
Business value
Coverage becomes a stable, comparable measure, and the gaps become a work list rather than a caveat repeated in every report.
Phase 2
Ownership and cost modelling
Attach accountability to cost. Without ownership the analytics can only describe publishers, which is not the question leadership is asking.
- Application-to-owner mapping. Map each application to a named business owner, business unit and cost centre, treating unmapped spend as an exception with a closure date.
- Owner validation. Have owners confirm the mapping, since a mapping the owner has not seen will be disputed the first time a number is reported against it.
- Unit cost modelling. Model cost per user, per instance or per core as appropriate to the licence metric, so comparisons across business units are meaningful.
- Trend baselining. Establish a baseline for publisher and business unit cost trend so subsequent movement can be interpreted.
Business value
Cost becomes attributable to a named owner and comparable across units, which turns the dashboard from a description into a management tool.
Phase 3
Opportunity register
Make optimisation a tracked pipeline rather than a periodic exercise.
- Opportunity logging. Log each opportunity with its value expressed as a range, the assumptions behind it, a named owner and an expiry date tied to the relevant contract event.
- Stage gating. Track opportunities through identified, validated, approved, in-progress and realised, so pipeline value is never confused with delivered value.
- Owner validation. Require the business owner to confirm feasibility before an opportunity moves beyond identified, which removes the theoretical items early.
- Ageing management. Report opportunity ageing and drive items that are approaching their contract-event expiry.
Business value
Leadership can see the pipeline value and its maturity, and opportunities stop expiring silently against contract dates nobody was watching.
Phase 4
Realised value and finance validation
Close the loop with the only signature that makes the number credible.
- Baseline statement. State the baseline against which each benefit is measured before the action is taken, not after.
- Finance validation gate. Have finance confirm realised benefit before it is reported, using the same standard applied to any other benefit claim.
- Avoidance versus reduction. Classify and report cost avoidance separately from cost reduction, since conflating them is the fastest route to losing finance's confidence.
- Variance analysis. Compare realised to modelled benefit and feed the variance back into how future opportunities are estimated.
Business value
Reported benefit carries finance's signature, so the programme is funded on the strength of a validated return rather than a discounted claim.
Phase 5
Forecasting and executive reporting
Turn the model into forward-looking input rather than a backward-looking report.
- Forward spend model. Model forward software spend from contract commitments, renewal pipeline, demand trend and known growth, presented as a range with assumptions.
- Renewal pipeline view. Publish the forward renewal calendar with value, owner and optimisation status per renewal.
- Dashboard freshness. Automate refresh and report data age on the dashboard itself, so consumers know how current the view is.
- Board pack. Produce a consistent board view — cost, trend, coverage, pipeline, realised value — rather than a bespoke narrative each cycle.
Business value
Software becomes a forecastable budget line with a visible optimisation pipeline, reported on a consistent basis the board can track over time.
07
Technology Components
Capability categories with representative examples. The analytics layer is usually built on tooling the organisation already owns; the constraint is almost always ownership mapping and data governance rather than the BI platform. Products are named as examples, not recommendations.
Source systems
- Finance ERP (e.g. SAP, Oracle ERP)
- Contract repository
- SAM platform
- SaaS management data
- ServiceNow CMDB
Data and modelling
- Data warehouse or lakehouse
- Publisher and product normalisation
- Unit cost model
- Ownership mapping
Value tracking
- Optimisation opportunity register
- Benefit baseline records
- Finance validation workflow
- Avoidance versus reduction classification
Reporting
- Power BI or equivalent
- Executive dashboard
- Renewal and forecast view
- Board pack
08
Governance Considerations
Governance should be proportionate. The six areas below are the minimum set that has to be
explicit for this capability to hold up under internal review.
Ownership
A named analytics owner accountable for coverage and dashboard freshness; business owners accountable for their mapped spend; finance accountable for the benefit validation standard.
Decision rights
Finance approves the addressable spend definition and validates realised benefit; business owners approve optimisation actions affecting their applications; the governance forum prioritises the pipeline.
Policies
Benefit measurement policy defining baseline, avoidance and reduction; ownership policy requiring a named owner per application; data quality policy per source feed.
Approvals
Changes to the addressable spend definition approved by finance; opportunities above a value threshold approved by the governance forum before execution.
Evidence
Baseline statements retained per benefit claim, owner validation of mapping and actions, and finance confirmation of realised value with the date and method recorded.
Controls
Coverage threshold reporting, dashboard data-age display, opportunity ageing alerts against contract-event dates, and periodic reconciliation of modelled to realised benefit.
09
Success Metrics
Primary KPI
Trusted spend coverage
Addressable software spend joined to entitlement, usage and an owner-validated business mapping — the denominator for every other figure in the view.
≥ 90% of addressable spend
Operational KPIs
Contract coverage
≥ 95% of spend
Spend linked to a contract record with terms and dates.
Ownership completeness
≥ 98% of spend
Spend mapped to a named, validated business owner.
Dashboard freshness
≤ 7 days
Age of the underlying data at the point of consumption.
Renewal visibility
100% of contracts, 120 days ahead
Renewals visible before the action window.
Governance KPIs
Action ageing
< 10% over 90 days
Opportunities open past their target without progress.
Finance-validated benefit
100% of reported savings
Benefit confirmed outside the technology function.
Baseline statements
100% of opportunities
Benefit baselines stated before action.
Avoidance and reduction separation
Reported separately
Classification applied consistently.
Value KPIs
Optimisation opportunity value
Tracked as a range
Pipeline value with stated assumptions.
Validated savings
Against modelled
Opportunities confirmed feasible by the business owner.
Realised savings
Against validated
Benefit confirmed by finance as delivered.
Forecast accuracy
Within ±10%
Forward spend forecast against realised spend.
Publisher cost trend
Tracked per cycle
Cost movement by publisher against baseline.
Business unit cost trend
Tracked per cycle
Cost movement by consuming unit against baseline.
Indicative targets
Every target above is an indicative KPI for a typical enterprise, intended to support
planning discussions. Baselines should be measured in the first operating cycle and targets
set from them. These are not benchmarks, commitments or achieved client results.
10
Positive Business Impact
Executive answers to executive questions
Cost by business unit and by application, not only by publisher — which is the form in which leadership actually asks the question.
Optimisation value that finance accepts
Realised benefit carries a finance signature and separates avoidance from reduction, so the number is not discounted before it reaches the board.
A pipeline instead of an annual exercise
Opportunities are logged, aged, owned and gated, so value is worked continuously rather than rediscovered each planning cycle.
Renewals visible with time to act
The forward renewal pipeline surfaces contract events with enough lead time for optimisation to affect the outcome.
Software as a forecastable budget line
Forward spend is modelled from commitments, pipeline and demand rather than extrapolated, giving finance something it can plan against.
Accountability that follows the cost
Owner-validated mapping means every reported number has a person attached to it, which changes how the report is received.
Outcomes depend on estate, contracts, data quality and organisational context, and are not guaranteed.
11
Related Playbooks
Playbooks commonly delivered alongside, before or after this one.
Important — please read
This playbook describes a typical implementation approach and a representative operating
model. It is illustrative guidance, not a statement of results. Any figures, targets or
ranges shown are illustrative and are intended to support planning discussions rather than
to predict or promise an outcome. Outcomes are not guaranteed and depend on the estate,
contracts, data quality and organisational context of each engagement.
No client names, client data, engagement detail or confidential delivery material is
disclosed anywhere in this library. Technology named in these pages appears only as an
illustrative example of a capability category and does not imply a partnership,
certification or recommendation.
