As organisations race to automate processes and unlock efficiency, many discover an uncomfortable truth: what works in a pilot does not always hold up at scale. According to Greg Holmes, Field CTO for EMEA at Apptio, an IBM company, the difference between short-term success and sustainable automation lies in financial rigour.
Holmes argues that intelligent automation initiatives often fall into a familiar trap. Early projects are built quickly, show promising results, and win internal praise. But when companies attempt to roll them out across the enterprise, costs rise faster than expected and budgets begin to strain. The issue, he says, is not the technology itself but how financial planning is handled from the start.
Moving from reactive cost control to value engineering
Traditional technology adoption often follows a “build it and they will come” mindset. In automation, that approach can leave leaders exposed. Holmes explains that many pilots look cost-effective because they rely on over-provisioned infrastructure or simplified assumptions that do not reflect real-world usage.
By integrating FinOps principles with automation, organisations can shift from reacting to cost overruns to proactively engineering value. This means tracking resource consumption early, including metrics such as cost per transaction or API call, rather than waiting months or years to assess whether a programme is delivering returns.
“That visibility changes how engineering teams make decisions,” Holmes notes. “You can understand the economics of what you’re building from day one.”
Understanding the unit economics of automation
Innovation projects already face steep odds. Holmes points out that roughly 80 percent of new initiatives fail, often because financial risks remain hidden during the pilot phase.
A small automation that saves 100 hours a month may appear successful. But once it moves into production, the picture can change. Compute and storage demands grow, API calls multiply, edge cases emerge, and support costs increase. Without careful tracking, those factors can erode the original value proposition.
The key is unit economics. Organisations need to monitor metrics such as cost per customer or cost per transaction as automation scales. If those costs rise alongside growth, the underlying model is flawed. When scaling is done well, unit costs should fall.
Holmes highlights a Liberty Mutual case study where the insurer identified around $2.5 million in savings by measuring consumption metrics, rather than focusing solely on labour hours saved.
Bringing financial accountability closer to developers
Holmes is clear that financial governance cannot sit only with the finance team. Instead, cost awareness should be embedded directly into development workflows.
By integrating governance into infrastructure-as-code tools such as HashiCorp Terraform and platforms like GitHub, teams can see cost estimates at deployment time. This allows engineers to make informed decisions before resources are spun up, avoiding the cycle of deploying first and fixing later.
The goal is to ensure teams are building the right systems, at the right scale, at the right time.
Aligning finance and technology through a common language
Tension often arises between CFOs focused on return on investment and automation leaders who track operational metrics like hours saved. Holmes believes this disconnect slows progress.
Technology Business Management (TBM), which underpins Apptio’s approach, is designed to bridge that gap. The TBM taxonomy translates technical resources such as compute, storage, and labour into IT services and business capabilities. This allows both finance and business leaders to see exactly which services they are consuming and what is driving cost increases.
For business users, the benefit is clarity. They may not need to understand every technical layer, but they can see a detailed breakdown of service consumption and cost drivers as usage grows.
Addressing legacy systems and long-term costs
Legacy technology adds another layer of complexity. Some organisations use automation to mask inefficiencies in outdated systems, rather than redesigning processes. Holmes warns this approach often increases technical debt instead of reducing it.
A total cost of ownership (TCO) analysis can help clarify the right path. He points to the Commonwealth Bank of Australia, which assessed the full lifecycle costs of 2,000 applications, including infrastructure, labour, and ongoing engineering effort.
In some cases, legacy systems remain valuable and worth maintaining. In others, the cost of the automation layers needed to keep them running reveals that replacement is the more economical option.
Planning for stability as automation scales
Finally, Holmes stresses the importance of long-term budgeting. While variable, usage-based costs offer flexibility, they can also introduce volatility. Longer-term commitments to platforms and technologies can provide predictability, enable economies of scale, and support standardised architectures.
By balancing tight control of variable costs with strategic long-term planning, organisations can scale intelligent automation without the financial shocks that often derail transformation efforts.
