Search
Login
Become a member

KPIs & Metrics

From Model to Insight: The Metrics That Make TBM Matter

Article contents

Quick Links

Using Metrics to Drive Transparency, Efficiency, and Value

TBM enables organizations to make better decisions about their technology investments by applying a standard taxonomy, model, and set of disciplines that link cost, consumption, and business value. A critical outcome of TBM implementation is the ability to track and report on key performance indicators (KPIs) and metrics that reveal how technology resources are used, how efficiently they’re consumed, and how well they support the strategic goals of the organization.

These metrics don’t just report results—they shape decisions. Whether you’re modeling labor costs across product teams, aligning cloud spending to business units, or measuring the cost efficiency of technology towers, the KPIs produced through TBM provide actionable insights for practitioners and executives alike.

For organizations that adopt TBM, metrics and KPIs become core to:

  • Validating cost allocations and unit rates
  • Demonstrating accountability and cost transparency
  • Optimizing infrastructure and cloud resources
  • Benchmarking services and operations
  • Tracking business alignment and value realization

To support these outcomes, TBM modeling requires clear metric definitions, consistent data inputs, and a robust data foundation. This page details the most frequently reported TBM-aligned KPIs—organized by maturity phase—and defines the required data fields, their likely source systems, and connections to TBM use cases.

Key Terms and Concepts

Understanding TBM KPIs depends on a common vocabulary. The following concepts appear frequently throughout this page:

The Role of Maturity Phases in KPI Development

As TBM capabilities evolve, so does an organization’s ability to produce meaningful and actionable metrics. The High-Impact TBM Use Cases guide groups common practices and KPI adoption into three maturity phases:

  • Ramping – Focused on foundational visibility. This phase establishes cost transparency, basic allocations, and initial stakeholder trust in the TBM Model.
  • Accelerating – Emphasizes refinement, accountability, and expanded insight. Organizations build on the TBM Model to support service-based costing, product-based views, and cross-functional financial management.
  • Innovating – Enables strategic decision-making, business outcome mapping, and investment planning. Organizations in this phase fully leverage TBM insights to drive transformation, improve portfolio decisions, and maximize value realization.

This page follows those phases to help TBM teams understand:

  • Which KPIs become relevant at each stage
  • What data is required to produce them
  • Where that data likely resides
  • Which TBM use cases these KPIs support

Each metric listed includes a brief explanation, common data sources, and embedded references to help modelers, analysts, and leaders take the next step.

Quick Tip: Looking for additional implementation support? Explore our Labor, FinOps, and Agile pages for role-specific KPI insights.

Ramping: Building Cost Transparency and Foundational KPIs

The Ramping phase is the starting point of TBM maturity. At this stage, organizations are focused on building the core capabilities needed to understand and report on technology spending. The goal is to move away from opaque cost centers and toward a structured cost model that can inform basic decisions. KPIs and metrics in this phase are foundational: they help technology and finance leaders establish accountability, improve visibility, and prepare for more advanced optimization and value realization activities.

Ramping KPIs emphasize cost transparency, allocation coverage, and the development of trust in data. These metrics lay the groundwork for stakeholder engagement and support the creation of core views in the TBM model, including the Finance View, IT View, and early Business View components.

These KPIs align with several core TBM Use Cases, including Cost Transparency, Budget & Forecast, and Labor Financials, which aim to illuminate current-state financials and prepare organizations for value-based decision-making. For guidance on how to build your TBM model to support these metrics, see our TBM Modeling and Cost Allocation Methods pages. For taxonomy alignment, refer to the TBM Taxonomy v5.0 and related Framework guidance.

Budget Variance by Cost Pool

Budget Variance (%) = [(Actual Spend – Budgeted Spend) ÷ Budgeted Spend] × 100

What It Measures:
 This KPI tracks the difference between actual and budgeted spend across each TBM Cost Pool, highlighting where technology spending deviates from financial expectations. It can be measured in absolute terms (dollar variance) or as a percentage of the budgeted amount.

Why It Matters:
 Understanding where spending diverges from the budget is a foundational financial discipline. By aligning variance reporting to TBM Cost Pools (such as Hardware, Software, Internal Labor, External Services, and more), organizations gain a more granular and actionable view of spending behaviors.

This KPI supports the Budget & Forecast use case by enabling monthly or quarterly performance tracking at the right level of granularity. It improves transparency across stakeholders and provides early indicators of over- or under-spending trends that can inform corrective actions, reforecasting, or spend optimization.

Because TBM defines and standardizes cost categories across IT spend, it makes it easier to report variances consistently across departments, time periods, and financial systems—especially when integrating forecast and actuals data into the TBM model.

For detailed modeling approaches and reporting techniques, refer to the TBM Modeling page and the publication High-Impact TBM Use Cases, which outlines how this KPI supports financial planning maturity.

Required Data Fields:

  • Total labor costs (internal and external)
  • Allocation logic or drivers (e.g., headcount, time, consumption units)
  • Mapping to applications, services, towers, or consumers
  • Optional: fallback allocation rules or default cost centers

Likely Source Systems:

  • HR or Payroll Systems – for cost and headcount data
  • TBM System – for cost modeling and allocation logic
  • Time Tracking or Agile Tools – for resource allocation inputs
  • Service or Application Registries – for destination mappings

Direct Cost Ratio = (Direct Spend ÷ Total Spend) × 100

Indirect Cost Ratio = (Indirect Spend ÷ Total Spend) × 100

What It Measures:
 This KPI compares the amount of IT spend directly tied to a product, service, business unit, or other consumer (direct costs) to the amount of IT spend that supports shared or generalized infrastructure and services (indirect costs). It is usually expressed as a percentage or ratio.

Why It Matters:
 A high ratio of direct to indirect cost indicates that the organization is successfully tracing technology spend to accountable consumers. Indirect costs—such as shared infrastructure, central services, or pooled labor—are often necessary, but excessive reliance on indirects can obscure cost drivers and reduce accountability.

TBM enables better visibility and granularity in classifying and allocating both direct and indirect costs. By mapping costs through the TBM Taxonomy’s layered model—from Cost Pools to IT Towers and eventually to Consumers—organizations gain more precision in identifying what is truly direct versus indirect. TBM also supports the allocation of indirects in a fair and transparent way, improving stakeholder trust and engagement.

This KPI contributes directly to the Cost Transparency use case, providing a signal to executives and TBM practitioners that the modeling and allocation process is maturing.

You can find additional examples and advice for classifying and managing indirect costs in the TBM Taxonomy v5.0, along with practical implementation tips on the TBM Modeling page.

Required Data Fields:

  • Total IT spend
  • Direct IT spend (attributed to a consumer without allocation)
  • Indirect IT spend (requiring allocation to reach a consumer)

Likely Source Systems:

  • TBM System / ITFM Tool – for direct/indirect classification and spend modeling
  • ERP / General Ledger – for raw cost inputs
  • Cost Center Hierarchies – for identifying shared services or centralized resources

Forecast Accuracy (%) = [1 – (|Forecast – Actual| ÷ Forecast)] × 100

What It Measures:
 This KPI compares forecasted IT spend to actual spend over a given period—typically monthly or quarterly. It quantifies how close financial forecasts are to reality, either in absolute variance or as a percentage accuracy score.

Why It Matters:
 Accurate forecasting is essential to informed decision-making and financial accountability. This metric allows organizations to evaluate the reliability of their budgeting and planning processes and identify areas for refinement. Over time, improved forecast accuracy helps stabilize operations, reduce surprises, and build trust with business stakeholders and finance partners.

TBM enhances forecast accuracy by aligning forecast inputs to the TBM Taxonomy, ensuring consistent definitions and allocations across all spend categories. It also allows forecasts to be directly compared to modeled actuals in the same system, streamlining variance tracking and reconciliation efforts.

This KPI supports the Budget & Forecast use case by enabling feedback loops that improve both predictive capabilities and fiscal discipline. When measured consistently, it helps stakeholders hold forecast owners accountable and encourages process improvements across teams.

For guidance on how this KPI supports financial governance and TBM reporting, visit the TBM Modeling page and review the High-Impact TBM Use Cases publication.

Required Data Fields:

  • Forecasted spend by TBM Cost Pool or sub-category
  • Actual spend for the same time period and category
  • Timeframe (month or quarter)
  • Optional: Forecast timestamps and forecast owner for governance tracking

Likely Source Systems:

  • Financial Planning Tools / EPM Systems – for forecast data
  • General Ledger or ERP Systems – for actuals
  • TBM System – to map and normalize both datasets by TBM Cost Pools

Labor Cost by Tower = ∑ Labor Costs mapped to each IT Tower

Labor Cost by Cost Pool = ∑ Labor Costs categorized into Internal or External Labor Cost Pools

What It Measures:
 This metric identifies and totals labor-related expenses—such as salaries, contractor costs, and associated benefits—by either IT Tower (e.g., End User, Compute, Applications) or by TBM Cost Pool (e.g., Internal Labor, External Labor). It provides a structured view of how human resources contribute to various functions or investment categories in the technology organization.

Why It Matters:
 Labor is the largest expense in most technology organizations, yet it is often poorly categorized in general ledger systems. By mapping labor costs to TBM Cost Pools or IT Towers, organizations gain a clearer understanding of where human resources are focused and how those costs contribute to the delivery of services and capabilities.

TBM modeling enables labor costs to be allocated and reported with a level of precision unavailable in traditional finance tools. By enriching raw cost data with titles, time tracking (if available), project codes, and organizational mappings, TBM makes labor cost insights actionable. Whether modeling workforce efficiency, justifying staffing levels, or supporting funding discussions, this KPI lays the groundwork for meaningful labor analytics.

This KPI directly supports the Labor Financials use case by enabling deeper visibility into how labor is distributed across the organization. It also supports the Cost Transparency use case by revealing the human cost drivers within each tower or cost pool.

You can explore this KPI in greater depth through the TBM & Labor page, which outlines labor modeling techniques and workforce analytics in TBM. Additionally, the publication Transitioning from Time Cards to Agile Labor Management offers strategies for labor cost modeling in Agile and hybrid environments.

Required Data Fields:

  • Labor costs (salary, contractor costs, benefits)
  • Employee or contractor title
  • Organizational unit or team
  • Labor classification (internal vs. external)
  • Cost Pool or IT Tower mapping
  • Optional: project or capability attribution

Likely Source Systems:

  • Payroll or HRIS Systems – for raw labor cost and title data
  • TBM or ITFM Tools – for mapping to Cost Pools or Towers
  • Project Tracking Tools – to identify time spent on initiatives
  • Planning Systems – for forecasts and labor plans

% Allocated = (Allocated IT Spend ÷ Total IT Spend) × 100

% Unallocated = 100 – % Allocated

What It Measures:
This KPI tracks the percentage of total IT spend that has been allocated to a consumer—such as a business unit, product, service, or capability—versus the portion that remains unallocated or pooled. It’s a direct measure of how effectively costs are being traced to the consumers of technology.

Why It Matters

Early in a TBM journey, one of the most valuable improvements is transforming pooled, opaque costs into allocated, understandable ones. A higher percentage of allocated spend improves transparency, ownership, and accountability, while unallocated spend undermines trust and limits decision-making.

TBM is purpose-built to improve this KPI. Through modeling and allocation logic tied to the TBM Taxonomy, organizations can trace costs through the Cost Pool and IT Tower layers to the Consumer Layer, enabling fine-grained attribution. Without TBM, organizations often rely on high-level approximations or static spreadsheets that fail to track costs with the granularity needed for trust and action.

This KPI directly supports the Cost Transparency use case by helping TBM teams demonstrate progress toward greater clarity, even before granular metrics like unit cost or TCO are in place.

For guidance on how to drive better allocations and lower unallocated percentages, refer to the TBM Allocation Methods page, and explore best practices in the High-Impact TBM Use Cases and TBM Taxonomy documentation.

Required Data Fields:

  • Total IT spend (modeled through the TBM Cost Pool layer)
  • Allocated IT spend (mapped through to Consumer Layer or equivalent)
  • Optional: Allocation mappings by business unit, product, or capability

Likely Source Systems:

  • TBM System / ITFM Tool – for modeled and allocated data
  • ERP / General Ledger – for initial cost sources
  • Cost Allocation Engine – for allocation logic (sometimes part of TBM tool)

Percent of Labor Costs Allocated = (Allocated Labor Costs ÷ Total Labor Costs) × 100

What It Measures:
 This metric calculates the percentage of total labor costs that have been successfully allocated to specific services, towers, applications, or consumers within the TBM model. It distinguishes between labor expenses that are modeled and traceable versus those that remain unallocated or held in shared pools.

Why It Matters:
 Unallocated labor costs create blind spots in technology cost models and prevent organizations from understanding the true cost of delivering services or running specific operations. As labor is often the single largest component of IT spend, improving labor cost allocation is essential for building credibility and precision in TBM reporting.

TBM enables this KPI through its structured modeling of internal and external labor cost pools, integration of labor data from HR and financial systems, and alignment with service, application, and tower hierarchies. By creating and refining allocation logic—whether based on project time, resource assignments, or rule-based drivers—TBM teams can continuously reduce unallocated labor.

This KPI supports the Labor Financials use case by helping organizations move from generalized labor expense tracking to actionable, traceable labor allocations. It also informs progress within the Cost Transparency use case, especially in early model development and stakeholder reviews.

For more guidance, visit the TBM & Labor page or review the publication Transitioning from Time Cards to Agile Labor Management, which explains how labor allocations can be managed in both time-tracked and Agile environments.

Required Data Fields:

  • Total labor costs (internal and external)
  • Allocation logic or drivers (e.g., headcount, time, consumption units)
  • Mapping to applications, services, towers, or consumers
  • Optional: fallback allocation rules or default cost centers

Likely Source Systems:

  • HR or Payroll Systems – for cost and headcount data
  • TBM System – for cost modeling and allocation logic
  • Time Tracking or Agile Tools – for resource allocation inputs
  • Service or Application Registries – for destination mappings

(Output sourced from TBM Maturity Assessment)

What It Measures:
 A composite score that reflects the organization’s overall maturity in executing Technology Business Management (TBM) practices. The score is derived from the official TBM Maturity Assessment tool, which evaluates six key categories: Data, Taxonomy, Engagement, Value, Reporting, and Automation.

Why It Matters:
 The TBM Maturity Score provides a structured, repeatable, and benchmarkable way to understand how advanced an organization is in its TBM journey. It enables leadership to identify current capabilities, set future-state targets, and prioritize areas for investment and improvement. The assessment is based on a robust framework originally developed for U.S. federal agencies and modernized for broad applicability by the TBM Council and REI Systems.

Unlike subjective maturity judgments, this score emerges from a formalized tool that can be reviewed regularly—during new TBM implementations, periodic check-ins, or after major organizational shifts. It creates a shared view across IT, Finance, and business stakeholders about where the organization stands and what’s next in advancing TBM capabilities.

Because TBM maturity is directly tied to value realization, this KPI is essential for organizations seeking to transition from cost management to strategic decision enablement. It supports executive discussions about resourcing, reporting, automation, and long-term ROI from TBM efforts.

You can access the official assessment tool and supporting materials in the publication The TBM Maturity Assessment: A New Tool for Determining the Maturity of Your TBM Practice.

Required Data Fields:

  • Forecasted spend by TBM Cost Pool or sub-category
  • Actual spend for the same time period and category
  • Timeframe (month or quarter)
  • Optional: Forecast timestamps and forecast owner for governance tracking

Likely Source Systems:

  • Financial Planning Tools / EPM Systems – for forecast data
  • General Ledger or ERP Systems – for actuals
  • TBM System – to map and normalize both datasets by TBM Cost Pools

IT Cost per Employee = Total IT Spend ÷ Total Employee Headcount

What It Measures:
A foundational KPI that divides total IT spend by the number of employees in the organization, providing a normalized view of technology investment on a per-person basis.

Why It Matters:
Tech Cost per Employee offers a straightforward way to understand how much the organization is spending to support its workforce through technology. It helps leaders benchmark costs over time and across departments, and enables high-level comparisons with industry peers.

Because TBM structures total Technology spend through its Taxonomy and modeling practices, incorporating direct and indirect costs, allocations, and shared services, it provides a more complete and reliable basis for this metric than traditional finance systems alone.
This KPI directly supports the Cost Transparency use case by creating a consistent and traceable view of spending that can be used in early benchmarking and internal discussions about efficiency and cost drivers.

You can explore more practical applications of this KPI in the TBM & Labor page and the publication Transitioning from Time Cards to Agile Labor Management. Both provide helpful perspectives on how headcount and labor-driven metrics intersect with broader TBM goals.

Required Data Fields:

  • Total IT spend (from the TBM Cost Pool layer)
  • Total employee headcount
  • Optional: Headcount by business unit or region

Likely Source Systems:

  • IT Financial Systems / TBM System – for modeled and allocated IT spend
  • HR Systems – for accurate headcount data

IT Spend as a % of Revenue = (Total IT Spend ÷ Total Revenue) × 100

What It Measures:
This metric compares the total technology spend to the organization’s total revenue, providing a high-level view of technology investment relative to business size and income. It serves as a basic benchmark for evaluating how much the organization spends on IT as a proportion of its earnings.

Why It Matters:
IT Spend as a Percent of Revenue is a frequently cited industry benchmark used by boards, CFOs, and CIOs to evaluate how an organization’s technology investment stacks up against peers. It helps set context for budgeting decisions and can signal whether technology is being under- or over-funded in light of organizational performance.

TBM enhances the accuracy of this KPI by ensuring that the IT spend figure includes all relevant and modeled costs, from shared services to infrastructure to vendor spend. Unlike traditional accounting views that may exclude indirect allocations or shared service costs, TBM provides a more holistic and standardized cost foundation, aligned with the TBM Taxonomy and Cost Pool layer.

This KPI supports the Cost Transparency use case by normalizing IT spend in a way that enables credible internal and external comparisons—one of the first steps in building trust with business leaders around cost and value.

To see this KPI in context, visit the Cost Transparency use case and refer to the 2024 State of TBM Report for benchmark ranges across industries.

Required Data Fields:

  • Total IT spend (fully modeled via the TBM Cost Pool layer)
  • Total organizational revenue (enterprise-wide)

Likely Source Systems:

  • TBM System / ITFM Tool – for fully modeled and allocated IT spend
  • ERP / Financial System – for actual revenue (e.g., SAP, Oracle, Workday Financials)

Labor Spend by Type = Sum of Labor Costs (FTEs); Sum of Labor Costs (Contractors)

What It Measures:
 This KPI compares total labor spending on full-time employees (FTEs) versus contractors. It quantifies the total amount spent on each labor type over a given period, enabling analysis of workforce composition and associated cost structures.

Why It Matters:
 Technology organizations rely on a mix of FTEs and contingent workers to meet delivery goals, manage cost flexibility, and access specialized skills. Understanding how much of total labor spend goes to contractors versus employees reveals insights into workforce strategy, potential risk exposure, and budget planning.

TBM enables this metric by modeling labor costs through the Cost Pool layer (specifically, the Internal Labor and External Labor pools), normalizing data across disparate HR, finance, and vendor systems. It provides a single view of labor spend composition that aligns with organizational structure and TBM reporting.

This KPI supports the Labor Financials use case by providing clarity into labor costs—often the largest portion of the IT budget—and identifying opportunities for optimization, conversion, or policy changes. It’s especially important when seeking better visibility into how different workforce strategies affect cost transparency and value delivery.

You can explore additional context in the TBM & Labor page and the publication Managing the Financials of Agile Teams, which both address how labor costs can be accurately modeled and reported using TBM.

Required Data Fields:

  • Total labor cost, by individual or role
  • Employment type indicator (FTE or contractor)
  • Optional: Labor cost by Tower or Cost Pool for further segmentation

Likely Source Systems:

  • HR Systems / HCM Tools – for employee classifications and salary data
  • Vendor Invoicing or Procurement Systems – for contractor costs
  • TBM System – to integrate, normalize, and model labor spend by cost pool

Accelerating: Enabling Optimization, Accountability, and Service-Based Metrics

The Accelerating phase represents a turning point in TBM maturity. Organizations in this stage have established core cost transparency and are now focused on refining their models, enhancing allocation accuracy, and linking spend to services and resources. The emphasis shifts from simply reporting costs to managing them—enabling accountability at the service owner level and driving optimization efforts across towers, applications, and cloud platforms.

Accelerating KPIs focus on unit cost comparisons, service ownership, application health, and cloud efficiency. These metrics allow leaders to understand the cost and performance of specific technology towers, optimize consumption, rationalize portfolios, and begin benchmarking against internal and external standards. Importantly, they also help business and technology leaders identify where action should be taken to reduce waste, improve delivery, or increase value.

These KPIs support the core TBM Use Cases associated with the Accelerating phase, including Total Cost of Ownership, Application Rationalization, and Cloud Financial Management. These use cases are central to operationalizing TBM data and fostering a culture of cost accountability across teams. For guidance on enabling these capabilities in your TBM model, see our TBM Modeling and IT Resource Towers pages. For taxonomy alignment, refer to the TBM Taxonomy v5.0 and the TBM Framework’s Model and Outcomes layers.

Application Rationalization Rate

Application Rationalization Rate = (Number of Rationalized Applications ÷ Total Number of Applications) × 100

What It Measures:
 This KPI tracks the percentage of applications that have been reviewed, consolidated, retired, or replaced as part of a rationalization effort—relative to the total application portfolio. It measures progress in reducing redundancy, technical debt, and unnecessary spend across the application landscape.

Why It Matters:
 Application Rationalization Rate offers visibility into how efficiently an organization is managing its application portfolio. High rationalization rates can signal improved operational efficiency, reduced licensing and support costs, and stronger alignment with business capabilities.
 TBM enables rationalization efforts by linking application costs to business functions, towers, and consumers, providing the structured insights needed to identify redundancy, justify consolidation, and monitor impact over time.
 This KPI supports the Cost Transparency use case by enabling early-stage identification of inefficiencies and opportunities for simplification. It also provides a foundation for more strategic metrics around business value realization and modernization efforts.

You can explore modeling techniques that support this KPI in the TBM Modeling and Cost Allocation Methods pages.

Required Data Fields:

  • Total number of applications in the current portfolio
  • Number of applications targeted or completed for rationalization (retired, merged, migrated)
  • Optional: Application metadata (e.g., cost, owner, business capability alignment, usage data)

Likely Source Systems:

  • TBM System – for application cost modeling and consumer mapping
  • Application Portfolio Management (APM) Tools – for inventory and status tracking
  • CMDB – for application relationships, lifecycle stage, and technical metadata
  • Enterprise Architecture Tools – for functional alignment and rationalization planning

Cloud Cost per Solution = Total Cloud Costs Allocated to Solution ÷ Number of Solutions

What It Measures:
 This KPI measures the total cost associated with delivering a specific cloud-based solution—typically a product, business-facing capability, or internal service—over a given period. It includes all relevant cloud charges such as compute, storage, network, and platform services mapped to the solution through TBM modeling.

Why It Matters:
 Cloud Cost per Solution reveals how much cloud spend is tied to a specific solution or outcome, enabling better decision-making around consumption, efficiency, and pricing strategies. It helps teams assess whether cloud investments are producing value, monitor unit economics, and identify optimization opportunities.

TBM provides the modeling framework to allocate cloud costs across solutions accurately—using invoice-level data, tagging, cost pools, and towers. Without TBM, cloud costs often remain siloed at the billing or account level, making solution-level insights impossible.

This KPI supports the Budget & Forecast use case by enabling more accurate forecasts and cost planning for cloud-hosted solutions. It also lays the groundwork for cloud-specific optimization KPIs and benchmarking efforts.

Explore related cloud-focused techniques in TBM & FinOps: A Guide for Connecting FinOps Teams, Data, and Insights to TBM for Comprehensive Technology Financials and the Intelligent Cloud Adoption guide, both of which provide practical examples of cost modeling and decision-making in hybrid and public cloud environments. For taxonomy support, see the cloud allocation guidance on the TBM Taxonomy page.

Required Data Fields:

  • Cloud invoice line items (with resource type, usage, and costs)
  • Solution or application mapping (tagging, account grouping, or allocation rules)
  • Optional: Tags or labels for environment, business unit, or capability
  • Optional: Contractual pricing data (for committed use or discount tracking)

Likely Source Systems:

  • Cloud Cost Management Platforms (e.g., AWS Cost Explorer, Azure Cost Management)
  • TBM System – for applying allocations, tags, and mappings to solutions
  • FinOps Platforms – for detailed billing and tagging analytics
  • CMDB or Application Inventory – to associate infrastructure with business solutions

Cost per Story Point = (Total Cost of Agile Team / Total Story Points Completed)

Cost per Epic = (Total Cost of Agile Team / Number of Epics Completed)

What It Measures:
 This KPI calculates the cost of delivering Agile work items—typically story points (for sprint-level estimation) or epics (for broader deliverables). It divides relevant labor and shared costs by the total number of story points completed or epics delivered within a given period.

Why It Matters:
 Cost per Story Point or Epic is a key metric for organizations practicing Agile delivery. It allows leaders to understand the financial efficiency of Agile teams and provides a normalized basis for evaluating velocity, team performance, and forecasting future delivery costs.

TBM enables this KPI by integrating labor financials with Agile tooling. Rather than relying solely on time tracking or team-reported burndown rates, TBM allows organizations to associate modeled labor costs, contractor rates, and shared infrastructure expenses directly with Agile units of work.
 This metric supports the Labor Financials use case by helping organizations track Agile delivery in financial terms, and contributes to Budget & Forecast activities by improving estimation accuracy for future work based on historical cost-performance.

Required Data Fields:

  • Direct labor cost by Agile team
  • Shared service and infrastructure costs (allocated to teams or workstreams)
  • Agile work metrics:
    • Total completed story points
    • Total completed epics
  • Optional: Sprint duration and team size for deeper velocity and cost-per-sprint analysis

Likely Source Systems:

  • TBM System – for total cost modeling by team
  • Agile Planning Tools (e.g., Jira, Rally) – for story point or epic tracking
  • HR Systems – for labor cost details and team alignment
  • Financial Systems – for shared and vendor cost modeling

Percent of Budget Tied to Strategic Initiatives = (Budget Allocated to Strategic Initiatives ÷ Total IT Budget) × 100

What It Measures:
 This KPI tracks the proportion of the total IT budget that is allocated to formally defined strategic initiatives—such as digital transformation, cloud migration, AI enablement, or sustainability—rather than ongoing operational activities.

Why It Matters:
 Measuring the percentage of spend tied to strategic initiatives helps technology leaders demonstrate alignment with enterprise goals. It allows executive stakeholders to assess whether investments are focused on growth, innovation, and transformation, rather than simply maintaining the status quo.
 TBM enables this KPI by providing a structured model for tagging and categorizing spend according to initiative, product line, or business capability. Using the Solution layer in the TBM Taxonomy, budget elements can be directly mapped to the initiatives they support.
 This KPI supports the Budget & Forecast use case by providing insight into where future spend is committed and whether it aligns with strategy. It also lays the groundwork for Innovating-phase KPIs that evaluate initiative success and value realization.

Required Data Fields:

  • Total IT budget
  • Initiative tags or codes
  • Budgeted amounts by initiative
  • Optional: Business capability mapping
  • Optional: Department or unit allocations

Likely Source Systems:

  • Financial Planning & Analysis Tools (e.g., Anaplan, Adaptive Insights) – for budgeting data
  • TBM System – for modeling budget to solutions and initiatives
  • Project Portfolio Management Tools (e.g., ServiceNow, Planview) – for initiative definition
  • Enterprise Architecture or Capability Mapping Tools – for strategic alignment

Percent of IT Spend Tied to Business Capabilities = (Sum of Spend Assigned to Mapped Capabilities ÷ Total IT Spend) × 100

What It Measures:
 This KPI reflects how much of the total IT spend is traceably allocated to defined business capabilities, such as Customer Engagement, Logistics, or Risk Management. It highlights the maturity of business alignment by measuring the extent to which technology costs can be mapped to what the business actually does.

Why It Matters:
 Understanding how technology investments support specific business capabilities is a foundational step toward strategic IT planning. It enables business leaders to evaluate whether technology spend aligns with enterprise priorities and drives meaningful outcomes.
 TBM uniquely supports this KPI by linking IT costs (from the Cost Pool and Tower layers) to business-oriented Solutions, which can be tagged with business capabilities from an enterprise capability model. These mappings are often embedded in the TBM model or imported from enterprise architecture tools.
 This KPI is particularly useful in advancing the Cost Transparency and Budget & Forecast use cases, by enabling conversations about how budgeted or actual spend aligns to core business activities.

Required Data Fields:

  • Total IT spend (from the TBM model)
  • Mapping of Solutions or Services to Business Capabilities
  • Optional: Capability model with definitions and hierarchy
  • Optional: Spend by Cost Center or Tower for additional granularity

Likely Source Systems:

  • TBM System – for modeled and allocated spend by Solution
  • Enterprise Architecture Tools (e.g., LeanIX, Mega) – for business capability definitions
  • PPM or ITSM Tools – for service/project metadata
  • Financial Systems – for cross-referencing budget or actuals

Percent of Solutions Measured with FinOps KPIs = (Number of Solutions with Active FinOps KPIs ÷ Total Number of Solutions) × 100

What It Measures:
 This KPI tracks the percentage of technology solutions—applications, platforms, or digital products—for which FinOps-aligned performance and cost metrics are actively measured and monitored. FinOps KPIs typically include cloud spend variance, committed use discount coverage, utilization rates, and cost per unit of cloud service.

Why It Matters:
 This metric reflects the maturity of cloud financial operations across the organization. As cloud adoption grows, visibility into usage, efficiency, and cost performance becomes critical to ensure financial control and value realization. Measuring solutions with FinOps KPIs enables practitioners to drive accountability, optimize resource consumption, and align spending with business value.

TBM is uniquely positioned to support this KPI by providing the data modeling, allocation methods, and tagging frameworks needed to surface relevant FinOps insights. When integrated with cloud platforms and FinOps tools, TBM allows organizations to tie cloud performance data directly to solutions, budgets, and strategic goals—advancing from cost containment to value optimization.

Required Data Fields:

  • List of active technology solutions (from TBM model)
  • Count of solutions with defined FinOps KPIs
  • FinOps performance metrics per solution (e.g., cloud spend variance, RI coverage, usage rates)

Likely Source Systems:

  • TBM System – for solution definitions and mappings
  • FinOps Platform / Cloud Cost Management Tools – for cloud spend metrics (e.g., CloudHealth, Apptio Cloudability, AWS Cost Explorer)
  • Cloud Platforms (AWS, Azure, GCP) – for raw usage and cost data
  • EAP Systems – for tagging and product ownership data

Budget Variance (%) = [(Actual Spend – Budgeted Spend) ÷ Budgeted Spend] × 100

What It Measures:
 This KPI categorizes IT spend according to its purpose: maintaining current operations (“Run”), expanding existing capabilities or markets (“Grow”), or enabling transformational change and innovation (“Transform”). It shows how much of the IT budget is used to support stability, incremental value, or strategic reinvention.

Why It Matters:
 Run-Grow-Transform (RGT) analysis is a critical lens for aligning technology investments with business strategy. It allows CIOs and CFOs to assess portfolio balance and answer questions like: Are we investing enough in innovation? Are operational costs crowding out transformation?
 TBM is uniquely suited to produce this metric because it enables consistent modeling of IT spend by Solution, Project, or Initiative. By assigning RGT classifications to modeled solutions or projects—typically through tagging in the TBM tool or via integration with project/initiative planning systems—organizations can view total spend through a strategic lens.
 This KPI strengthens the Budget & Forecast use case by allowing budget owners and strategy leaders to evaluate whether forward-looking investments align with desired outcomes.

Required Data Fields:

  • Total IT budget
  • Spend or budget amounts by solution, project, or initiative
  • RGT classification (Run, Grow, or Transform)
  • Optional: Business unit or capability mapping

Likely Source Systems:

  • TBM System – for modeling spend by solution or project
  • Project Portfolio Management Tools (e.g., Planview, ServiceNow) – for initiative classification
  • Financial Planning Tools – for budget data
  • Enterprise Strategy Tools – for business capability definitions and investment priorities

Team TCO by Product Line = Sum of (Labor + Vendor + Shared Service + Infra Costs) for all Teams aligned to Product Line

What It Measures:
 This KPI calculates the Total Cost of Ownership (TCO) for Agile or cross-functional teams, aggregated by product line. It includes direct labor costs, shared services, infrastructure, and any other technology resources consumed by the team to support a product, solution, or value stream.

Why It Matters:
 As organizations shift toward Agile and product-centric delivery models, it becomes essential to understand the full cost of supporting a product or digital capability. Team TCO by Product Line enables technology and finance leaders to compare investment levels across products, evaluate return on investment, and make better prioritization decisions.

TBM is uniquely suited to produce this KPI by enabling spend allocation not just by technology function, but also by product line, feature team, or value stream. Through its Solution layer and labor modeling capabilities, TBM helps organizations link labor, infrastructure, and vendor costs to product ownership in a traceable, transparent way.
 This KPI plays a key role in the Labor Financials and Budget & Forecast use cases, particularly for organizations undergoing Agile transformation or adopting product-based funding models.

For more on how TBM supports labor modeling and Agile transformations, see the TBM & Labor page and the publication Managing the Financials of Agile Teams.

Required Data Fields:

  • Direct labor costs by team member or team
  • Team membership metadata (e.g., product line, department, role)
  • Allocated infrastructure and shared services costs
  • Vendor costs associated with team tools or products
  • Optional: Product ownership mapping or value stream ID

Likely Source Systems:

  • TBM System – for aggregated cost modeling across cost pools and solutions
  • HR Systems – for labor cost data and team alignment
  • Agile Planning Tools (e.g., Jira, Rally) – for team metadata and assignments
  • CMDB or EA Tools – for mapping infrastructure to products or services
  • Financial Systems – for vendor costs and shared services

TCO = Labor + Infrastructure + Licensing + Shared Services + Other Direct & Indirect Costs

What It Measures:
 This KPI captures the full, end-to-end cost of delivering a specific application or service. It includes direct and indirect costs such as labor, infrastructure, software licenses, support, hosting, and any allocations associated with shared resources. When applied consistently, it reveals the true financial footprint of each technology service or asset.

Why It Matters:
 TCO by Application or Service is a cornerstone KPI in the TBM model. It empowers organizations to compare the cost of delivering different applications or services, assess business value versus cost, and support rationalization, investment, and optimization decisions.
 Unlike traditional finance systems that often record costs at an aggregated department or GL level, TBM’s layered model links technology components, labor, and shared services to the services and applications that consume them. This enables more precise and actionable TCO calculations.
 This KPI directly supports the Total Cost of Ownership use case by helping technology leaders, application owners, and finance partners assess where costs are concentrated, justify investments, and manage applications as products with measurable financial impact.

To explore how this KPI fits into broader application and service management efforts, visit our TBM Modeling page.

Required Data Fields:

  • Application or Service ID
  • Labor cost by application or service
  • Infrastructure cost by application or service
  • License/software cost (if applicable)
  • Allocated shared service costs (e.g., network, storage, support)
  • Other relevant operating and capital expenditures tied to the service

Likely Source Systems:

  • TBM System – for modeled and allocated costs
  • ITFM or GL Systems – for source financials
  • CMDB / Service Management – for application-to-resource mappings
  • HR Systems – for labor distribution
  • Cloud and Hosting Invoices – for consumption-based costs

Unit Cost = Total Cost of Service ÷ Number of Units Consumed

What It Measures:
 This KPI captures the cost of delivering individual technology services or resources—such as compute (VMs), storage (GB), or network access (ports)—by dividing the total cost associated with the resource by a usage unit. It enables service-based costing and supports cost recovery, benchmarking, and operational decision-making.

Why It Matters:
 Unit Costs are essential for understanding the efficiency of technology delivery and for driving informed decisions about optimization, vendor selection, and internal chargeback/showback models. They reveal whether services are cost-effective, overprovisioned, or subsidized.
 TBM’s structured taxonomy and allocation methods enable accurate modeling of these unit costs, ensuring that shared services, indirect costs, and consumption patterns are fairly and transparently represented in each unit’s final cost.
 This KPI supports the Cost Transparency and Budget & Forecast use cases by offering quantifiable, defensible cost breakdowns that can be used to align consumption with budgets, surface inefficiencies, and enable comparisons across business units or platforms.

You can explore real-world applications of this KPI in the case study EDF Energy Delivers Defensible IT Recharging Across the Cloud and Traditional IT Services With TBM and in the publication TBM & FinOps: A Guide for Connecting FinOps Teams, Data, and Insights to TBM for Comprehensive Technology Financials, both of which demonstrate how organizations have implemented unit pricing and visibility strategies across hybrid cloud and traditional IT environments.

Required Data Fields:

  • Total cost of service (e.g., total compute, storage, or network costs)
  • Volume of units consumed (e.g., number of VMs, total GB used, number of ports)
  • Optional: Allocation rules or mappings by consumer (business unit, application, etc.)

Likely Source Systems:

  • TBM System – for aggregated and allocated cost by resource type
  • Cloud Billing or Virtualization Platforms (e.g., AWS, Azure, VMware) – for unit consumption data
  • CMDB or ITSM – for infrastructure configuration and ownership
  • Cost Management Tools or Spreadsheets – for internal service definitions and unit pricing logic

Utilization Rate = (Actual Usage ÷ Provisioned Capacity) × 100

What It Measures:
 Utilization Rates measure the percentage of available infrastructure capacity—such as compute (CPU/memory), storage, and network bandwidth—that is actively in use over a given period. These KPIs are typically reported separately for each resource category.

Why It Matters:
 Understanding infrastructure utilization is critical for identifying inefficiencies, right-sizing assets, and controlling costs. Low utilization signals excess capacity and wasted spend, while high utilization may indicate performance risk or a need for expansion.
 TBM enhances these metrics by aligning them with allocated costs and service delivery. Through the TBM Model’s Resource Tower layer, utilization data can be directly linked to cost pools and consumer solutions, creating actionable insights.
 These metrics support the Budget & Forecast use case by helping teams predict future resource needs and justify investment decisions based on real consumption trends. They also serve as essential building blocks for optimization strategies in both on-prem and cloud environments.

For guidance on how to incorporate infrastructure insights into your TBM practice, see the TBM Modeling page. 

Required Data Fields:

  • Provisioned capacity by resource type (e.g., total CPU cores, total GB storage)
  • Actual usage metrics by resource type (e.g., average CPU usage, GB consumed)
  • Optional: Asset metadata (e.g., business unit, location, environment)
  • Optional: Allocated cost data by resource or service

Likely Source Systems:

  • Monitoring Platforms (e.g., Datadog, Prometheus, Splunk) – for real-time usage
  • Infrastructure Management Tools (e.g., vCenter, AWS CloudWatch) – for capacity and consumption
  • TBM System – to align usage with financial models
  • CMDB or Asset Management System – for asset metadata and categorization

Innovating: Connecting Technology to Strategic Value and Emerging Priorities

The Innovating phase represents the most advanced stage of TBM maturity. Organizations in this phase have already achieved consistent cost transparency and optimization practices—and are now focused on maximizing strategic value, driving innovation, and supporting evolving priorities like sustainability, AI enablement, and business model transformation.

KPIs and metrics in this phase enable senior leaders to make informed decisions that extend beyond cost management. They support conversations about how technology contributes to environmental goals, accelerates innovation, and aligns with corporate strategy. These metrics often require more complex modeling, richer tagging and attribution methods, and integrated data across business and technology domains.

Innovating KPIs emphasize business value realization, multi-dimensional reporting, and the use of TBM as a lever for competitive differentiation. They rely on a fully mature TBM model and often include integrations with external benchmarks, environmental reporting frameworks, and advanced planning and forecasting systems.

This KPI set supports TBM Use Cases like Sustainability & ESG Tracking, AI Investment Modeling, and Business Capability Enablement. For organizations advancing toward these capabilities, we recommend exploring our Connected Standards guidance, the TBM Taxonomy v5.0, and the latest TBM Framework materials. Advanced modeling and reporting methods are also discussed on our TBM Modeling and TBM for Agile pages.

AI Carbon Footprint

AI Carbon Footprint = Total kWh Used × CO₂ per kWh

What It Measures:
 This KPI calculates the total greenhouse gas (GHG) emissions associated with running artificial intelligence (AI) workloads, including compute-intensive model training and inference processes. It is typically expressed in kilograms or metric tons of CO₂ equivalent (CO₂e), and can be measured at the model, workload, or solution level.

Why It Matters:
 AI workloads can consume significant amounts of compute, storage, and power—especially during training phases for large language models or deep learning systems. As organizations increase their use of AI, they must monitor the environmental impact of these workloads to remain compliant with ESG goals, stakeholder expectations, and regulatory frameworks.

By incorporating emissions data into the TBM model, organizations can attribute carbon impact to specific AI solutions, enabling transparency, accountability, and more sustainable decision-making. TBM is especially effective for generating this KPI, as it enables allocation of sustainability data (e.g., energy consumption, carbon emissions) across solutions using the same modeling structures and tagging strategies used for financial data.

This KPI supports sustainability-driven IT governance and aligns with Innovating-phase use cases like Sustainability Optimization and AI Financial Management, which seek to optimize the business value, performance, and environmental impact of modern workloads.

Required Data Fields:

  • Total power consumption per AI workload (kWh)
  • Carbon intensity of power source (CO₂e per kWh)
  • Workload metadata (tags, timestamps, business capability association)
  • Solution mapping for AI services or models

Likely Source Systems:

  • AI Platforms (e.g., OpenAI, AWS SageMaker, Azure ML) – for workload telemetry
  • Cloud Provider Billing / Emissions Data (e.g., AWS, Azure, Google Cloud)
  • TBM System – for allocation and solution tagging
  • Sustainability Reporting Tools – for emissions intensity data

AI Training vs. Inference Spend = Total AI Training Spend ÷ Total AI Inference Spend

What It Measures:
 This KPI compares the organization’s technology spending on training AI models versus operating them in production (inference). It helps leaders understand the cost distribution between AI development and delivery.

Why It Matters:
 As AI adoption matures, organizations often shift from heavy training efforts toward scaled inference. Tracking this balance supports cost governance, platform planning, and strategic decision-making about where to invest AI resources. A training-heavy spend profile may indicate ongoing experimentation or refinement, while inference-dominant spend suggests operationalization and value delivery.

Technology Business Management enables this metric by providing a structured way to tag and allocate AI-related costs across projects, cloud services, and solutions. Through solution-level modeling and integrated tagging, TBM captures nuanced views of spend across the AI lifecycle. This KPI is particularly valuable in environments where AI training requires high-performance infrastructure or cloud instances, and where accountability for AI value delivery is needed across business capabilities.

This metric supports the publication TBM for AI Value Realization: A Guide to Optimizing AI Investments by Aligning Business Fundamentals for Maximum Value and ROI and aligns with the Innovating-phase emphasis on advanced visibility and business alignment of emerging technologies.

Required Data Fields:

  • Spend by cloud resource or infrastructure tagged as “AI Training”
  • Spend by cloud resource or infrastructure tagged as “AI Inference”
  • Solution ID or Business Capability (for deeper insight)

Likely Source Systems:

  • TBM System – for modeling, allocations, and tagging of AI-related spend
  • Cloud Billing Platforms (e.g., AWS, Azure, GCP) – for identifying training/inference resources
  • AI Operations Tools – to validate usage types
  • Enterprise Architecture or Capability Mapping Systems – for tagging by capability

Benchmark Variance (%) = (Your Unit Cost – Peer Group Unit Cost) ÷ Peer Group Unit Cost × 100

What It Measures:
 The degree to which an organization’s unit costs for key technology services (e.g., cost per VM, GB of storage, network port) differ from industry or peer group benchmarks. This metric is typically expressed as a percentage above or below the median or average of a selected benchmark set.

Why It Matters:
 Benchmark Variance to Peer Group is a critical KPI for organizations seeking to understand the relative efficiency and competitiveness of their technology operations. While internal cost trends and allocations provide insight into historical performance, benchmarking offers external validation of value and efficiency. By comparing normalized unit costs to relevant industry peers, organizations can uncover whether their spending is aligned with expectations—or whether optimization opportunities exist.

TBM is uniquely suited to generate this KPI because it normalizes and categorizes costs using the TBM Taxonomy and models them through the IT Tower and Sub-Tower layers. This alignment ensures apples-to-apples comparisons with industry benchmarks, many of which are structured using similar taxonomies.

Required Data Fields:

  • Unit cost data (e.g., cost per VM, cost per GB storage, cost per network port)
  • Benchmark peer group data for same unit cost categories
  • Optional: Service volume assumptions for weighting comparisons

Likely Source Systems:

  • TBM System – for modeled unit costs aligned with IT Tower layer
  • Benchmark providers (e.g., Gartner, ISG, Apptio Benchmarking)
  • ITSM or CMDB – for service volumes and configuration details

Carbon Emissions per User = Total CO₂e per Solution ÷ Number of Users per Solution

What It Measures:
 This KPI calculates the average amount of carbon emissions attributable to each user of a technology solution. By distributing total emissions data across the number of users, it provides a normalized metric for evaluating the environmental impact of technology usage.

Why It Matters:
 As organizations face growing pressure to meet Environmental, Social, and Governance (ESG) goals, tracking carbon emissions at the user level enables more actionable sustainability reporting and planning. This KPI helps highlight areas where emissions can be reduced by optimizing infrastructure, consolidating workloads, or shifting to lower-emission platforms. It’s particularly valuable when comparing the sustainability performance of different applications or business units.

TBM plays a critical role in enabling this KPI by integrating emissions data with the broader cost and consumption model. Through taxonomy alignment and solution-level allocations, TBM allows emissions to be tied directly to the consumers and solutions that generate them. This approach provides far more transparency and decision-making value than stand-alone sustainability reporting tools.

Required Data Fields:

  • Total carbon emissions (CO₂e) per solution
  • Number of users per solution
  • Optional: Business unit or regional breakdowns

Likely Source Systems:

  • Sustainability Platforms or Carbon Accounting Tools – for emissions data
  • TBM System – for cost and user allocations by solution
  • Identity Management or Application Access Logs – for user counts

Carbon Offset Spend as % of Total IT Spend = (Carbon Offset Spend ÷ Total IT Spend) × 100

What It Measures:
 This KPI quantifies the portion of overall IT spending that is dedicated to purchasing carbon offsets, providing insight into how much the technology organization is investing to mitigate its environmental impact.

Why It Matters:
 As sustainability becomes a strategic imperative, technology leaders are under growing pressure to demonstrate accountability for emissions and environmental impact. Tracking carbon offset spend helps organizations assess the financial commitment they are making to reduce their carbon footprint and align with ESG (Environmental, Social, and Governance) goals.

TBM is especially well-suited to support this metric. Through structured modeling of spend across the TBM Taxonomy, organizations can isolate sustainability-related costs—including carbon offsets—and connect them to specific Solutions, applications, or infrastructure categories. This enables traceable, reportable, and auditable climate-related metrics.

This KPI supports the Sustainability Cost Attribution use case by offering visibility into sustainability-linked spend and allowing leaders to evaluate whether current offset investments are sufficient, equitable, and aligned with policy goals.

Required Data Fields:

  • Total IT Spend (from the TBM Cost Pool layer)
  • Carbon offset spending (modeled as a distinct GL category, vendor code, or tagged project)
  • Optional: Offset spend broken down by solution, tower, or application

Likely Source Systems:

  • TBM System / ITFM Tool – for total modeled IT spend and sustainability allocations
  • General Ledger – for expense entries tied to sustainability or carbon offset purchases
  • ESG Reporting Platform or Sustainability Teams – for tracking climate-related budget items

Cost per AI Transaction = Total AI Spend ÷ Total Number of Inferences

What It Measures:
 This KPI captures the average cost of executing a single AI transaction or inference—such as processing a machine learning prediction, generating a response in a large language model, or completing an AI-powered decision workflow. It allows organizations to understand the unit economics of AI workloads and determine if those operations are cost-effective.

Why It Matters:
 As AI workloads become more embedded in business processes, understanding their cost impact is critical to managing overall technology spend. This metric enables leaders to assess the value of AI by comparing cost per inference across use cases, deployment models (cloud vs. on-premises), and providers.
 TBM supports this KPI by modeling AI-related infrastructure, cloud spend, and application costs across Cost Pools and IT Towers. Combined with tagging practices and TBM Taxonomy v5.0 classifications, TBM helps isolate and allocate AI workload costs accurately—something traditional finance systems are not built to do.

Required Data Fields:

  • Total AI-related spend (infrastructure, platform, software)
  • Volume of AI inferences or transactions performed
  • Optional: AI spend by solution or workload type

Likely Source Systems:

  • TBM System / Financial Modeling Platform – for allocated AI spend
  • Cloud Billing or AI Platform Logs – for inference count and cost breakdown
  • AIOps or Observability Tools – for operational volume metrics

Cost per Security Incident = (Total Incident Response & Remediation Costs) ÷ (Number of Incidents)

What It Measures:
 This KPI estimates the average financial cost of responding to and recovering from individual security incidents. It typically includes labor, tooling, remediation, legal, compliance, downtime, and reputational costs associated with each incident.

Why It Matters:
 Understanding the average cost of a security incident helps organizations evaluate the true financial impact of their security posture and risk exposure. It also enables more informed investment decisions about cybersecurity tools, processes, and staff—helping CISOs and technology leaders advocate for appropriate levels of funding and response capability.

While most cybersecurity platforms track incident volume, few can reliably tie those incidents to financial consequences. TBM fills this gap by linking incident data from operational systems to financial modeling in the TBM system. By tagging response labor, tooling, and remediation activities to security incidents—or estimating their cost per incident using historical response cost modeling—organizations can begin to benchmark performance and justify future investment in risk mitigation.

This KPI is particularly valuable when paired with KPIs like IT Risk Mitigation Spend as % of Total IT Spend to track not just the input but the impact of risk-related investments.

Required Data Fields:

  • Number of security incidents (monthly/quarterly)
  • Labor cost related to incident response
  • Tooling and software cost related to response and remediation
  • Legal, audit, and compliance-related costs (if material)
  • Downtime or business disruption cost (if applicable)

Likely Source Systems:

  • Security Incident & Event Management (SIEM) tools – for incident counts
  • TBM System – for labor, tooling, and other spend allocated to Risk & Compliance
  • HR and Financial Systems – for labor rates and overhead
  • GRC or ERP Systems – for compliance and legal costs

Cybersecurity Coverage per Solution = (Number of Implemented Required Controls per Solution ÷ Total Required Controls per Solution) × 100

What It Measures:
 This KPI tracks the breadth and consistency of cybersecurity controls applied across each business solution (including applications and supporting infrastructure). It typically reflects the percentage of critical cybersecurity controls (e.g., identity management, encryption, monitoring) implemented for each solution, based on a defined control framework or policy baseline.

Why It Matters:
 Cybersecurity threats continue to evolve, and incomplete protection of business-critical solutions can expose organizations to significant risk. By measuring cybersecurity coverage at the solution level, this KPI provides a holistic view of security hygiene across the technology portfolio. It enables technology and risk leaders to identify gaps, prioritize remediation based on business criticality, and demonstrate due diligence to internal stakeholders and regulators.

TBM is uniquely suited to support this KPI because it provides a structured model for mapping IT components—including infrastructure, applications, and services—to solutions and associated costs. This mapping allows security teams to assess control coverage in the context of business value, total cost of ownership, and strategic importance. Additionally, TBM-integrated data from platforms like ServiceNow CSDM or CMDBs enables automated association of controls to each solution component.

Required Data Fields:

  • List of critical security controls required per solution (baseline or framework)
  • Actual controls implemented per solution
  • Solution name and components (applications, infrastructure, services)
  • Control compliance status per component

Likely Source Systems:

  • Governance, Risk, and Compliance (GRC) Tools – for control definitions and status
  • Configuration Management Databases (CMDBs) or ServiceNow CSDM – for asset-to-solution mapping
  • TBM System – for modeling solutions and associating cost, ownership, and impact

Energy Cost per Workload = Total Energy (kWh) × Cost per kWh

Energy Cost per Solution = Sum of Energy Costs for All Workloads Supporting the Solution

What It Measures:
 This KPI calculates the direct energy cost attributed to operating a specific workload or solution. It enables organizations to monitor and manage the financial impact of energy consumption across compute, storage, and other technology infrastructure in support of environmental and cost efficiency goals.

Why It Matters:
 Energy usage is one of the most significant contributors to both operating costs and environmental impact in modern technology environments—especially in energy-intensive workloads such as high-performance computing or AI inference. By tying energy costs directly to individual workloads or solutions, organizations can make informed decisions about workload placement, infrastructure design, and sustainability initiatives.

This KPI represents a fusion of financial and environmental awareness, made possible through TBM modeling that links consumption and cost data across infrastructure, cloud, and on-prem systems. It supports use cases related to Sustainability and Cloud Cost Optimization, providing granular insights that promote accountability for both carbon and capital.

Required Data Fields:

  • Total energy usage (kWh) by workload or solution
  • Cost per unit of energy (e.g., $/kWh)
  • Mapped workloads/solutions from TBM Solution layer
  • Optional: Infrastructure usage by workload (CPU hours, storage GBs)

Likely Source Systems:

  • Cloud Provider Invoices – for usage and energy attribution
  • Facilities or Energy Management Systems
  • TBM System or CMDB – for workload-to-solution mapping
  • FinOps Platforms – for cloud resource usage and cost detail

Percent of Shadow IT Addressed = (Shadow IT Addressed ÷ Shadow IT Identified) × 100

What It Measures:
 The percentage of shadow IT—technology resources procured or managed outside the formal IT organization—that has been discovered and either integrated into the TBM model, governed under standard policies, or decommissioned.

Why It Matters:
 Shadow IT poses financial, security, and governance risks by bypassing formal oversight and introducing untracked costs into the organization’s technology ecosystem. Measuring the percentage of shadow IT identified and addressed reflects an organization’s maturity in creating comprehensive visibility into technology usage and spend—regardless of where it originates.

TBM enables this KPI by standardizing how technology resources are modeled, categorized, and allocated. The TBM Taxonomy allows costs associated with shadow IT to be mapped to appropriate Towers, Cost Pools, or Solutions, enabling comparison, oversight, and accountability. Through consistent modeling and alignment with finance and procurement systems, TBM practitioners can surface shadow IT previously hidden in general ledger or procurement data.

Required Data Fields:

  • Total number or spend amount of shadow IT resources identified
  • Total number or spend amount of shadow IT resources addressed (governed, integrated, or eliminated)
  • Optional: Spend associated with each shadow IT asset

Likely Source Systems:

  • Procurement Systems – for purchases made outside of IT
  • TBM System – for modeled technology cost visibility
  • Cloud Billing Platforms – for usage not tied to central governance
  • IT Asset Management (ITAM) and SaaS Management Tools – for inventory discovery

GRC Audit Readiness Score = (Controls with Valid Evidence / Total Required Controls) × 100

What It Measures:
 This KPI evaluates how well-prepared the organization is for governance, risk, and compliance (GRC) audits. It typically combines measures of documentation completeness, policy enforcement, control coverage, and system evidence availability into a single composite readiness score.

Why It Matters:
 Audit readiness is essential for maintaining trust, avoiding costly penalties, and proving that risk and compliance processes are functioning effectively. A high GRC Audit Readiness Score demonstrates operational discipline and the ability to meet regulatory and internal standards. It also enables proactive identification of gaps that may hinder compliance or security outcomes.
 By leveraging TBM to map risk and compliance activities to costs, technology components, and solutions, organizations can take a more structured and measurable approach to readiness. When GRC systems are integrated into the TBM model, this score becomes not only trackable, but actionable.
 This KPI supports emerging TBM use cases around risk visibility and technology governance and aligns closely with the Service Health and Risk Management themes in the TBM Framework.

Required Data Fields:

  • Number of required audit controls for each GRC framework (e.g., SOX, HIPAA, NIST)
  • Number of controls with documented implementation evidence
  • Number of audit artifacts available (e.g., logs, screenshots, attestations)
  • System health or SLA compliance records
  • TBM-aligned mapping of controls to solutions or cost objects (optional)

Likely Source Systems:

  • GRC platforms (e.g., ServiceNow GRC, RSA Archer)
  • Document management systems
  • Audit and compliance logs
  • TBM system (for associating solutions, costs, or accountability)

Greenhouse Gas Emissions per Workload = Σ(Resource Usage × Carbon Intensity Factor) ÷ Workload Output (e.g., requests, compute hours)

What It Measures:
 This KPI quantifies the carbon footprint associated with a specific technology workload, typically measured in kilograms or metric tons of CO₂ equivalent (CO₂e) per compute hour, transaction, or service unit. It helps organizations understand the environmental impact of individual workloads—whether running on-premises or in the cloud—and how that impact varies based on platform, configuration, and usage patterns.

Why It Matters:
 As environmental sustainability becomes a strategic priority for organizations, understanding the emissions tied to specific workloads is critical for responsible technology management. This KPI enables targeted emissions reduction strategies, such as workload placement optimization, renewable energy prioritization, and architecture modernization. It also supports corporate ESG reporting and compliance with regulatory frameworks (e.g., CSRD, SEC climate disclosures).

TBM is uniquely suited to generate this KPI by associating cost and consumption data with workload-level operational attributes. By leveraging the TBM Taxonomy’s Tower and Sub-Tower structures, as well as tagging and solution-level modeling, TBM allows teams to allocate emissions to the business capabilities and solutions they support. The integration of cloud provider emissions data and sustainability dashboards further enhances accuracy.

This KPI supports innovation-focused efforts to embed sustainability into strategic planning, product development, and cloud transformation. For guidance on modeling ESG metrics with TBM, visit the Connected Standards and TBM Taxonomy v5.0 pages. Also see our OpenGreenOps microsite for community insights on sustainability in technology.

Required Data Fields:

  • Workload or solution identifier (tagged or mapped in the TBM model)
  • Resource usage (e.g., CPU hours, memory usage, storage, data transfer)
  • Carbon intensity factor (by platform, region, or cloud provider)
  • Optional: Business capability or product mapping

Likely Source Systems:

  • Cloud Platforms (AWS, Azure, GCP) – for emissions data, workload tagging, usage metrics
  • Sustainability Dashboards or Emissions APIs – for regional carbon intensity and reporting factors
  • TBM System – for workload classification, cost modeling, and business mapping
  • Infrastructure Monitoring Tools – for on-prem usage and telemetry

IT Risk Mitigation % = Risk & Compliance Spend ÷ Total IT Spend

What It Measures:
 This KPI tracks the portion of total technology spending that is dedicated to reducing or mitigating business, operational, and cybersecurity risks. It includes expenditures on risk-related tools, services, processes, and controls—such as cybersecurity platforms, data protection, GRC systems, and compliance initiatives.

Why It Matters:
 As organizations mature in their TBM practices, they increasingly face pressure to justify not just the efficiency of their spending, but also the resilience of their technology environment. This KPI helps leaders understand how much is being invested in risk reduction and whether that level of investment aligns with the organization’s risk tolerance, regulatory requirements, and security posture.

TBM is uniquely equipped to support this KPI by clearly categorizing Risk & Compliance-related costs through the Risk & Compliance Tower in the TBM Taxonomy v5.0. A well-structured TBM model also ensures these costs are properly allocated—allowing organizations to differentiate between risk mitigation spending for infrastructure, applications, cloud, and individual solutions. This capability is often lacking in general ledger or cybersecurity tools alone.

For organizations aligning TBM with Enterprise Risk Management (ERM) or cybersecurity governance, this KPI provides a traceable, financial lens on protection-oriented investments. It can also serve as a leading indicator for discussions with the CISO, audit teams, or regulators.

You can explore risk-based cost modeling practices in the TBM Taxonomy v5.0, which formally introduces the Risk & Compliance Tower.

Required Data Fields:

  • Total IT spend (modeled in the TBM system)
  • IT spend categorized under Risk & Compliance (from the Tower or sub-tower layer)
  • Optional: Spend by solution, asset class, or business function

Likely Source Systems:

  • TBM System or IT Financial System – for modeled and allocated spend by Tower
  • Security or GRC Tools – for tagged or mapped investments (optional)
  • Enterprise Budgeting Tool – for alignment with capital and OPEX plans

MTTR = Average (Remediation Date – Discovery Date) for all critical vulnerabilities in the measured period

What It Measures:
 This KPI tracks the average time it takes from the discovery of a critical vulnerability to its full remediation across the organization. It is typically measured in days and can be scoped to applications, infrastructure, or entire solutions.

Why It Matters:
 MTTR is a key performance metric for risk management and cybersecurity responsiveness. Shorter remediation times reduce exposure windows, minimize the chance of exploit, and signal effective operational security processes. Tracking MTTR for critical vulnerabilities enables IT and security leaders to identify bottlenecks in patching, approval, or deployment processes and assess the overall maturity of their vulnerability management program.

While security systems often report MTTR operationally, TBM enhances this KPI by connecting vulnerability management data to the broader solution landscape and IT investment structure. Through integration with asset inventories, application portfolios, and IT towers, TBM enables organizations to track MTTR by business-critical solution, cost center, or provider. This contextualized view helps prioritize remediation efforts based on risk to business outcomes and justify resource allocation.

For example, by aligning vulnerability remediation with the Risk & Compliance Tower in the TBM Taxonomy v5.0, teams can create visibility into effort, ownership, and investment effectiveness—ensuring accountability across security and infrastructure teams.

Required Data Fields:

  • Discovery date of each critical vulnerability
  • Remediation completion date for each vulnerability
  • Associated asset, application, or solution name
  • Severity rating of the vulnerability

Likely Source Systems:

  • Vulnerability Management Tools (e.g., Tenable, Qualys) – for timestamps and severity ratings
  • IT Asset Management Systems – for mapping vulnerabilities to applications/solutions
  • TBM System – for aligning affected assets to business units or IT towers
  • Change Management Systems – for validating patch deployment dates

Percent of AI Workloads Tagged = (Number of AI Workloads Tagged to a Business Capability ÷ Total AI Workloads) × 100

What It Measures:
 This metric calculates the percentage of AI workloads—such as models, pipelines, inference endpoints, or AI-powered features—that have been mapped to a defined business capability. It reflects how well AI investments are understood, governed, and aligned with strategic business value.

Why It Matters:
 As artificial intelligence becomes more pervasive in enterprise operations, organizations must go beyond experimentation and quantify the business relevance of AI workloads. Tagging workloads to business capabilities ensures that AI usage is tracked, governed, and optimized for real business outcomes—not just technical outputs.

TBM provides the foundation for this KPI by offering a structured taxonomy of business capabilities and a modeling approach that enables data, applications, and AI workloads to be associated with those capabilities. This metric supports strategic alignment, risk mitigation, and portfolio optimization for AI initiatives.

You can explore foundational practices for capability mapping in the TBM Modeling and TBM Taxonomy pages. For broader insight into connecting technology efforts like AI to measurable outcomes, refer to the publication TBM for AI Value Realization: A Guide to Optimizing AI Investments by Aligning Business Fundamentals for Maximum Value and ROI.

Required Data Fields:

  • Inventory of AI workloads (models, pipelines, AI-enabled apps or solutions)
  • Business capability taxonomy
  • Mapping of each AI workload to a business capability
  • Total count of AI workloads

Likely Source Systems:

  • AI platforms (e.g., Azure ML, AWS SageMaker, Google Vertex AI) – for workload inventories
  • Architecture tools or CMDBs – for tagging structures
  • Enterprise portfolio management (EPM) or TBM system – for business capability taxonomy

Percent of Applications with Security Controls = (Number of Applications Meeting Minimum Security Controls ÷ Total Number of Applications) × 100

What It Measures:
 This KPI tracks the proportion of applications in the organization’s portfolio that have implemented baseline security controls, such as encryption, authentication, vulnerability scanning, and logging. It serves as a measure of coverage and consistency in the application security program.

Why It Matters:
 A strong cybersecurity posture depends on the consistent implementation of security controls across all solutions—especially those that are externally facing, handle sensitive data, or support critical operations. Measuring this percentage helps organizations identify gaps in their control coverage, prioritize remediation, and mature their security practices.

By integrating this KPI with TBM modeling, organizations gain a more strategic view of their security investments. TBM enables application portfolios to be tied to cost and value layers—such as IT Towers and business-aligned solutions—so that control gaps can be assessed not just by number but by impact. For example, applications supporting customer-facing solutions may warrant higher scrutiny and faster remediation.

In the context of the Risk & Compliance Tower and Application Tower in the TBM Taxonomy v5.0, this KPI also supports governance and compliance tracking. It reinforces accountability by aligning application owners with the presence—or absence—of required controls.

Required Data Fields:

  • Application inventory (complete list of applications)
  • Security controls present per application (e.g., encryption, authentication, logging)
  • Minimum control baseline required
  • Business criticality or tier (optional)

Likely Source Systems:

  • Application Portfolio Management Tools (e.g., ServiceNow APM, LeanIX)
  • Security Configuration Management Tools
  • CMDB (Configuration Management Database)
  • TBM System – for application-to-solution alignment

Percentage of Spend Supporting AI Solutions = (AI-Tagged Spend ÷ Total IT Spend) × 100

What It Measures:
 This KPI tracks the proportion of total technology spend that directly supports artificial intelligence (AI) solutions, including infrastructure, platforms, applications, and labor. It expresses AI-related spending as a percentage of total IT spend and can be segmented by AI type (e.g., machine learning, generative AI) or by supporting resource layers (e.g., cloud compute, GPUs, data services, engineering labor).

Why It Matters:
 As organizations invest in AI to drive competitive advantage, understanding the cost of enabling those solutions is essential. This KPI provides visibility into how much of the technology budget is dedicated to AI enablement and how spending is distributed across platforms and resource types. It supports executive decisions on AI strategy, cost justification, and value realization.

TBM makes this KPI possible by classifying spend according to Solutions, Applications, and Towers, while enabling the use of tags and metadata to flag AI-related components. This structured modeling ensures that both direct and indirect costs—such as infrastructure, licenses, data pipelines, and engineering labor—can be accurately traced to AI initiatives.

To learn how to adapt your TBM model to capture AI solution data, see TBM Taxonomy v5.0 and the Connected Standards page. Both offer guidance on flexible tagging and solution modeling for evolving technologies.

Required Data Fields:

  • Total IT spend (from the TBM Cost Pool layer)
  • Spend allocated to AI-tagged solutions or applications
  • Optional: AI-specific infrastructure, licenses, labor, or cloud platform charges

Likely Source Systems:

  • TBM System – for total spend, tagging, allocation by solution
  • Cloud Platforms – for AI service usage and cost (e.g., AWS SageMaker, Azure OpenAI, GCP Vertex AI)
  • Product or Engineering Systems – for labor mapping to AI initiatives
  • Enterprise Architecture Tools – for solution classification and tagging

Solution Health Score = Weighted Composite of Operational, Financial, and Compliance Metrics

What It Measures:
 A composite score that reflects the overall health of a technology solution—including its reliability, performance, cost-effectiveness, security posture, and compliance status. These scores are typically calculated by combining data from availability, incident, performance, cost, and policy adherence metrics, often integrated from systems like ServiceNow’s Common Service Data Model (CSDM).

Why It Matters:
 Solution Health Scores offer a holistic view into how well a technology solution is performing—operationally, financially, and in terms of governance. They are essential for assessing the quality and sustainability of solutions that support critical business functions. By aggregating performance and cost data into a single score, TBM practitioners and technology leaders can identify underperforming or overperforming solutions, prioritize remediation or investment, and communicate solution value to business stakeholders.

TBM enhances the usefulness of Solution Health Scores by mapping them to the Solutions layer of the TBM Taxonomy, enabling a common model that integrates financial, operational, and strategic data. When integrated with systems like ServiceNow CSDM, these scores provide actionable insights that help manage risk, optimize portfolios, and justify strategic investments in innovation and reliability.

Required Data Fields:

  • Solution name or unique ID (aligned to TBM Solutions layer)
  • Availability and performance metrics (e.g., uptime, mean time to resolution)
  • Incident and ticket volumes
  • Security and compliance indicators (e.g., policy adherence, vulnerability status)
  • Modeled cost data for the solution
  • Optional: Customer satisfaction or usage data

Likely Source Systems:

  • ServiceNow CSDM and CMDB – for solution mapping, incident and operational data
  • TBM System – for modeled and allocated cost data
  • ITSM and Monitoring Tools – for availability and performance metrics
  • GRC or Security Platforms – for compliance and risk data

Sustainability Cost Attribution (per Solution) = Sustainability Costs Attributed to Solution ÷ Number of Attributed Solutions

Cost per Carbon Offset Unit = Total Carbon Offset Cost ÷ Total Metric Tons CO₂ Offset

(e.g., Cost of Carbon Offset per Solution)

What It Measures:
 This KPI quantifies the cost of sustainability efforts—such as carbon offsets, renewable energy credits, or emissions penalties—and attributes them to specific technology solutions (applications, platforms, products). It provides a per-solution view of sustainability-related spending, enabling organizations to track and manage the financial impact of their environmental strategies.

Why It Matters:
 As sustainability commitments become central to business strategy, technology leaders must understand and manage the costs associated with decarbonizing IT. This KPI enables organizations to link environmental responsibility with financial accountability by attributing sustainability costs to the solutions that drive them. It promotes better investment decisions, supports ESG reporting, and helps identify high-impact areas for optimization.

TBM provides the modeling precision and metadata integration required to connect sustainability costs with the correct solutions. By extending the TBM Taxonomy with custom tags or integrating with carbon accounting platforms, organizations can incorporate environmental data into their financial models. This aligns directly with TBM’s goal of enabling informed, value-based technology decisions.

To learn how to structure your model to incorporate sustainability costs and carbon data, explore TBM Taxonomy v5.0, Connected Standards, and the GreenOps Microsite, which highlights community-led work in this space.

Required Data Fields:

  • Total cost of carbon offsets or sustainability investments
  • Mapping of sustainability costs to specific applications or solutions
  • Optional: carbon footprint per solution, region, or infrastructure type

Likely Source Systems:

  • TBM System – for cost attribution, solution mapping, and tagging
  • Carbon Accounting Platforms – for emissions data and offset cost details (e.g., Watershed, Normative)
  • Cloud Platforms – for emissions reporting and carbon offset charges
  • Enterprise Architecture or Configuration Systems – for application/solution ownership and metadata

Water Usage per Compute Unit = Total Water Used ÷ Total Compute Units

Water Usage per Data Center = Total Water Used by Location

What It Measures:
 This KPI quantifies the amount of water used to support compute operations, either on a per-unit basis (e.g., per VM, per server) or across an entire data center. It serves as a direct indicator of the environmental impact of technology infrastructure, particularly important in regions facing water scarcity or sustainability mandates.

Why It Matters:
 As organizations pursue ESG goals and respond to increasing scrutiny from stakeholders and regulators, water usage is emerging as a critical sustainability measure. Unlike energy consumption, water metrics are often underreported or inconsistently tracked—making this KPI a differentiator for advanced sustainability reporting and compliance.
 TBM helps drive water visibility by aligning infrastructure usage to solutions, services, and cost objects, enabling a more complete view of how physical resource consumption supports digital delivery.
 This metric supports sustainability use cases and integrates well with ESG reporting frameworks like GRI and CDP, especially when combined with greenhouse gas emissions and energy use metrics. It reflects a higher-order TBM capability, where environmental costs are linked to digital solutions and operational decisions.

Required Data Fields:

  • Water usage volume (liters or gallons) per data center or compute environment
  • Total compute units (e.g., number of VMs, CPU cores, server hours)
  • Optional: Data center region or sustainability classification

Likely Source Systems:

  • Facilities Management Systems – for water consumption data
  • Infrastructure Monitoring Tools – for compute utilization
  • Sustainability Reporting Systems – for ESG-aligned reporting fields

Join the TBM community: where innovators and leaders converge

The TBM Council is your gateway to a treasure trove of knowledge: think cutting-edge research papers, insightful case studies, and vibrant community forums where you can exchange ideas, tackle challenges, and celebrate successes with fellow practitioners.

We’re calling on organizations and forward-thinking individuals to dive into the TBM community. Participate in our events, engage in our discussions, and tap into a vast reservoir of knowledge. This isn’t just about networking; it’s about contributing to and benefiting from the collective wisdom in navigating the dynamic world of cloud computing.

Become a member
Linkedin Youtube

CONTACT

11100 NE 8th St. Suite 600
Bellevue, WA
98004

info@tbmcouncil.org

MEMBERSHIP

Join Community
What is TBM?
Community Newsletters

PRIVACY & TERMS

Terms of Use
Privacy Policy
Cookie Settings
Terms & Conditions

Copyright 2025. All rights reserved.

Red Hat built the world’s largest enterprise open-source software company, growing into a multi-billion-dollar firm before being acquired by IBM Corp. This open-source heritage often placed the value of technology in the product and engineering realm rather than with IT. Thus, not surprisingly, Red Hat’s TBM journey started with a new CFO wanting to know why IT costs were so high. Through the TBM framework and discipline, Red Hat IT successfully delivered cost transparency of all IT spend and then became a model for technology spend planning and forecasting. The IT team added the FinOps discipline to its capabilities and is now managing a broad hybrid cloud portfolio. However, TBM and FinOps have remained in the realm of IT only, until now. Red Hat’s current CIO, Jim Palermo, is driving TBM, FinOps, and Enterprise Agile Management across the company based on IT’s success and through the lens of value stream management. in this session, Jim will walk through Red Hat’s TBM journey and its current transformation to an operational business architecture framework built on value streams aligned to business outcomes.

Speaker:

  • Jim Palermo, VP, CIO, Red Hat

When the team at Tenet Healthcare made the decision to move towards a model that provided more accurate financial transparency, they looked to TBM practices and solutions. Join Paola Arbour, EVP and CIO at Tenet healthcare as she answers the question “why TBM?”, including what Tenet was trying to solve with the TBM Taxonomy, the effectiveness of their KPIs, and how building support and momentum across the entire company was critical to their successful TBM adoption. In this session, Paola will also share how Tenet continues to evolve their use of TBM, including for mergers, acquisitions, and divestiture activity, as well as segmenting cost structures.

Speaker:

  • Paola Arbour, EVP & CIO, Tenet Healthcare

Data driven decision making has been a key to longevity and delivering best in class service to State Farm’s customers over the past 100 years. Recently, State Farm decided to use a managed services company for the day-to-day support of their Infrastructure Services. Today’s technology leaders need to be able to make real-time, informed decisions to help ensure technology investments are meeting their customer’s needs, while continuing to support company long-term goals. Ashley Pettit, SVP & CIO at State Farm, will be joined by Randy McBeath, Enterprise Technology Executive, and Andy Moore, Technology Director, and together they will share how TBM aided in State Farm’s analysis and decision to move to a managed service provider.

Speakers:

  • Ashley Pettit, SVP & CIO, State Farm Insurance
  • Andy Moore, Technology Director, State Farm Insurance
  • Randy McBeath, Enterprise Technology Executive, State Farm Insurance

There is fast evolution occurring in the overall technology spend and value management market, with the advancements of cloud, Kubernetes, AI/ML, and other innovations. At the same time, we are seeing vast changes in the roles of the CIO, CFO, and business/digital leadership. In addition, TBM is intersecting with other disciplines and frameworks, such as Cloud FinOps, Agile engineering, and portfolio resource management. How is this affecting the TBM discipline, the TBM Council, and Apptio? For one, TBM is moving down market, becoming more accessible to all sizes and maturity of organizations, with easier ways to get started and a faster time to value. Cloud FinOps, meanwhile, is advancing and adding capabilities previously in TBM to the cloud cost management space. Join Apptio CEO Sunny Gupta as he explores the evolving TBM landscape and how he believes it will bring even greater opportunity and value to organizations worldwide.

Speaker:

  • Sunny Gupta, Co-Founder & CEO, Apptio

In today’s challenging economic times it is critical that CFOs, CIOs, and CTOs speak the same language when it comes to the value of technology spend. Having a single source of truth that everyone can feel confident in, track progress continuously throughout the year with shared insights, and analyzing options for resourcing and funding in order to reduce waste is where TBM deepens their partnership. In this discussion, join members of the TBM Council Board of Directors as they discuss the pivotal conversations and steps taken to collectively adopt TBM practices across the organization, including responding to naysayers and gaining allies.

Panelists:

  • George Maddaloni, EVP, CTO, Operations, Mastercard
  • Laura Walsh, CIO, Smithfield Foods
  • RJ Hazra, SVP & CFO, Technology & Security, Equifax
  • Moderated by Chad Doiran, Managing Director, Tech. Strategy & Advisory, Accenture

Fumbi Chima has led technology teams across multiple organizations throughout her esteemed career, including retail, manufacturing, media, and financial services. As a turnaround and high growth leader, Fumbi has leveraged TBM as a foundational practice to bring repeatable processes, purchasing guidelines, and cost/resource savings. Now at Boeing Employe Credit Union (BECU) serving more than 1.2 million members, Fumbi is driving their digital transformation with a clear vision and strategy to optimize their public-cloud with TBM and Cloud-FinOps, adopt a product model, and set the groundwork for future innovation and growth. Join Fumbi and Larry Blasko, President, Field Operations at Apptio, as they discuss the lessons Fumbi has learned along her TBM journey, and where this transformation leader sees the evolution of TBM taking the Technology industry.

Speakers:

  • Fumbi Chima, Chief Technology & Transformation Officer, BECU
  • Larry Blasko, President, Field Operations, Apptio

Technology leaders have a unique opportunity to transform their organizations into environmental champions with sustainable business practices. In this session, Neal Ramasamy, CIO at Cognizant and Phil Alfano, Field CTO at Apptio will share how TBM can be leveraged to achieve comprehensive visibility into real-time data-driven tracking to ensure company goals and actions are being met to achieve a sustainable future.

Speakers:

  • Neal Ramasamy, CIO, Cognizant
  • Phil Alfano, Field CTO, Apptio

For McGraw Hill, having a transparent framework that drives smart investment strategies and a common language across this 135-year-old company is critical. Known as one of the “big three” education publishers, McGraw Hill must stay ahead of their competitors with innovation and value delivery. Join Yuliya Oberman, Finance Director for McGraw Hill Education and Eileen Wade, General Manager of the TBM Council as they discuss how TBM is essential to McGraw Hill’s enterprise resource strategies and digital transformation journey.

Speakers:

  • Yuliya Oberman, Finance Director, McGraw Hill Education
  • Eileen Wade, General Manager, TBM Council

In this fireside chat, Matt Yanchyshyn, GM, AWS Marketplace & Partner Engineer at AWS will join incoming General Manager of the TBM Council, Jack Bischof, for a discussion on best practices for building successful TBM practices focused on cloud financial management. Including a deep dive into the nuances, learnings, and milestones that the world’s 9th largest insurance company is achieving on their Cloud FinOps journey.

Speakers:

  • Matt Yanchyshyn, GM, AWS Marketplace & Partner Engineering, AWS
  • Jack Bischof, Incoming General Manager, TBM Council

Hear from Ajay Patel, COO at Apptio and Zubin Irani, CEO at Cprime as they discuss how the intersection of TBM and enterprise agile planning is a critical strategy for organizations to adopt if they want to drive business growth more efficiently, in real-time, and keep up with the speed of change that today’s organizations face.

Speakers:

  • Ajay Patel, COO, Apptio
  • Zubin Irani, CEO, Cprime

Join Origin Energy’s Adrian Thivy, GM, Enterprise Technology Services, as he shares how TBM is creating complete confidence in their spend-to-value ratios across IT and the broader company, allowing a rapid response to the market forces driving significant pressure on the “cost to serve” customers. A finalist for the 2022 TBM Council Award for TBM Pacesetter, hear how their TBM practice was built in record time, including lessons learned as they developed business capabilities and managed a significant cloud migration and transformation.  

Session topics will include:  

  • Establishing a clear purpose and common goals that drive cross-functional understanding
  • Utilizing an adaptative governance framework to ensure accountability across all stakeholders 
  • Leveraging TBM and ServiceNow CSDM to deliver a transparent, flexible, and sustainable model in a shorter time frame
  • How bespoke logic has dramatically improved transparency of cost more than 90%


Presented by:

  • Adrian Thivy, GM, Enterprise Technology Services, Origin Energy 

Many organizations aspire for a cloud-native posture, however few have the time, resources and budget to transform into 100% public cloud operations. Equifax has broken through those barriers to modernize its infrastructure globally — driving faster innovation for customers, more business agility, and stronger cybersecurity. Hear from Manav Doshi, GM, Technology Solutions on how the Equifax team is rebuilding a century-old company, with a real-time approach to optimizing cost and revenue growth in the cloud.

 

Presented by:

  • Manav Doshi, GM, Technology Solutions, Equifax 

Transport for NSW is the winner of the 2022 TBM Council Award for TBM Pacesetter, which recognizes significant progress and value with TBM in a relatively short period of time. In this session, hear how the merger of Roads and Maritime Services (RMS) and Transport for New South Wales resulted in the fastest consolidation of TBM data, models, and reports into a single TBM practice. Hear from Poonam Kataria, Sr. Manager of TBM, as she shares how TBM is driving Transport’s three key strategic outcomes: connecting a customer’s whole life; successful places for communities; and enabling economic activity.

Session topics will include: 

  • Utilizing the TBM Taxonomy to align M&A practices and drive behavioural change 
  • How the right level of support sets the right culture and TBM processes
  • Driving change in the organization based on data-driven facts

Presented by: 

  • Poonam Kataria, Sr. Manager, TBM, Transport for NSW 

Discuss how TBM supports visibility of investments across the enterprise to support setting best practices and standards for managing the impact of environmental, societal, and governance strategies by IT departments and organizations.

The TBM Council Standards Committee has built out TBM integration models with other IT disciplines, including Enterprise Agile and Product Thinking, as well as ServiceNow CSDM. Current findings will be shared to drive group discussion, experience, and feedback. 

Public cloud strategies are often embraced for the promise of rapid scalability, on-demand agility, and best-in-class security, resiliency, and features. However, public cloud adoption presents significant financial challenges that, when not addressed, inhibit any firm’s ability to exploit the promises of public cloud.  

To address these challenges, customers need to simultaneously resolve current inefficiencies and build capability to ensure avoidance of waste in the long term.  

In this session we discuss a detailed framework combining TBM-Cloud with FinOps, allowing customers to understand how to implement a program to overcome these challenges and financially succeed in the cloud. 

Session discussion topics include: 

  • A detailed view of the activities required to implement a TBM-Cloud with FinOps Journey 
  • Detail the flow of information required for each task 
  • Provide guidance on which activities should be performed when

 

Presented by:

  • Nathan Besh, TBM-Cloud Evangelist, TBM Council 

Project to Product Transition

Outcome-focused development via agile transformation

For organizations looking to transition from projects to products, TBM can help organize resources and outcomes into value streams – the specific sets of activities that align to business outcomes.

Accelerating Cloud Adoption

Drive measurable outcomes with your cloud strategy

For organizations trying to accelerate their cloud journey, TBM provides a way to map a plan and measure the outcomes from cloud migration to cloud cost management to cloud optimization.

Morning Sessions

A look back at 10 years of TBM leadership and community building.

Speaker:

  • Ashley Pettit, SVP & CIO, State Farm Insurance

Introduced more than 10 years ago, Technology Business Management (TBM) was born out of the need for CIOs to have a management system to drive their technology operating strategy. At its core, the TBM discipline gives visibility into technology spend to provide common ground and enable a collaborative partnership across teams for prioritizing resources and achieving business outcomes. In this session, the TBM Council Standards Committee Chair, Atticus Tyson will share how over the past few years TBM has evolved to ensure leaders are able to accelerate digital initiatives, embrace the cloud, and communicate today’s complex technology landscape. TBM enables organizations to frequently and quickly evaluate projects, platforms, and investments to address the needs of the modern enterprise.

Speaker:

  • Atticus Tysen, SVP Product Development, Chief Information Security & Fraud Prevention Officer, Intuit

Atticus Tyson and Phil Alfano will guide the group through an executive discussion to capture “What is digital success to you?”. Is it how your organization creates new business capabilities? The elimination of legacy processes and systems? Funding innovation? Or all of the above as long as it drives an improved customer experience? Discuss with your table mates, as an overall group, and capture learnings and takeaways to bring back to your own team.

Speakers:

  • Atticus Tyson, SVP Product Development, Chief Information Security & Fraud Prevention Officer, Intuit
  • Phil Alfano, Field CTO, Apptio

How does a 170-year-old financial institution deliver a new, fully modernized technology strategy while supporting 24×7 service to their customers across a multitude of platforms, including point-of-sale, mobile, and web services? Mike Brady, Nicole Holmes, and Chad Schmidt will share how at Wells Fargo, they are creating a Technology Infrastructure team founded in the TBM discipline and responsible for aligning with internal partners to adopt an automation first approach for accelerating the delivery of services and deploying enhancements at speed. All while remaining compliant, secure, and agile.

Speakers:

  • Mike Brady, EVP, Technology Infrastructure, Wells Fargo
  • Nicole Holmes, EVP, CFO for Technology, Wells Fargo
  • Chad Schmidt, SVP, Technology Finance Modernization, Wells Fargo

It’s been two years since the World Health Organization declared Covid-19 a global pandemic. To re-imagine employee and customer experiences, every company was forced to speed up their shift to digital from multi-year project plans to instead creating, executing, and delivering new business models in a matter of weeks. As we emerge from this crisis, we recognize this shift is not slowing down but exponentially increasing as businesses continue to respond to societal expectations of anytime, anywhere. In this session, Sunny Gupta will share how the companies best positioned to quickly respond to changing market conditions and hyper competition have a holistic view of their technology spend so they can be agile in their investment decisions, use the cloud as a competitive advantage, and align their resources to product delivery models and continuously measure value.

Speaker:

  • Sunny Gupta, Co-Founder & CEO, Apptio

Afternoon Sessions

Spinning up a cloud-native posture is a desired strategy for many organizations, however few have the time, resources, and budget to achieve 100% public cloud operations. In 2018, Equifax set a 5-year goal to achieve this, striving to provide their customers with faster innovation, more flexible business agility, and stronger cybersecurity. Hear from RJ Hazra, SVP & CFO, Technology on the lessons and successes the Equifax team has found along their journey, and what remains as they cross into their final year of their company-wide digital transformation.

Speaker:

  • RJ Hazra, SVP & CFO, Technology & Security, Equifax

The cloud is a significant shift in computing and companies need to get maximum value from it. FinOps is the evolving cloud financial management practice that empowers organizations to track and maximize cloud spend and enable tech, finance, and business teams to collaborate on data-driven spending decisions. In this talk, J.R. Storment, Executive Director of the FinOps Foundation will explore the intersection between TBM and the FinOps practice and the benefits achieved. Session discussion topics include: 

  • Creating a culture of ownership over cloud usage and spend
  • The most important challenges to tackle for delivering products faster while gaining financial control and predictability
  • FinOps organization structures in large and small organizations from the State of FinOps 2022 report

 

Speaker:

    • J.R. Storment, Executive Director, FinOps Foundation

In this engaging conversation, executive leaders will share both the challenges and best practices realized on their journey to embrace product-based innovation.

Session discussion topics include:

  • Achieving results as you shift from a projects-to-products innovation model
  • Maximizing CIO/CFO partnerships in this new paradigm
  • Building your innovation strategy around value streams, stable teams, and a high degree of customer centricity

Speakers:

  • John Wilson, VP, IT Costing & Performance Management, MetLife
  • Kaarina Bourquin, Director, Strategy & Portfolio Operations & Technology, The Standard
  • Moderated by Toyan Espeut, Chief Customer Officer, Apptio

Session abstract coming soon

Speakers:

    • Brendan Kinkade, VP, Build ISV, Technology & Hybrid Cloud, IBM
    • Moderated by Phil Alfano, Field CTO, Apptio Foundation

TBM empowers hundreds of decision makers with the facts they need to execute a digital strategy faster, without bias, and in alignment across business units. This includes technology consumers, service and application owners, LOB CIOs, enterprise PMOs, compliance leaders, budget coordinators, and many more. What are the fundamentals of developing and executing a successful TBM practice? In this session, experienced practitioners will share the lessons and foundations they’ve learned delivering business value for their organizations with TBM.

Session discussion topics include:

  • Fundamentals of proper support and sponsorship across key stakeholders
  • Demonstrating how and why TBM is core to strategy and a digital operating model
  • Developing, educating, and enabling your core team
  • Implementing or enhancing the necessary TBM processes

Speakers:

    • Jeri Koester, CIO, Marshfield Clinic Health System
    • Latrise Brissett, Managing Director, Global IT, Accenture
    • Leslie Scott, VP & CIO, IT Enterprise Services, Stanley Black & Decker
    • Moderated by Jason Byrd, Managing Director, Technology Strategy & Advisory, Accenture