As enterprises race to automate operations at scale, many discover that success in pilots does not guarantee sustainable results. According to Greg Holmes, Field CTO for EMEA at Apptio, an IBM company, the missing ingredient is often financial rigour — not technology.
Intelligent automation has become one of the most powerful levers for enterprise efficiency. From robotic process automation (RPA) to AI-driven decision systems, organisations are investing heavily in technologies designed to eliminate manual work, accelerate workflows, and reduce costs.
Yet despite widespread adoption, a familiar pattern continues to emerge: automation initiatives that shine during pilot phases struggle — or fail entirely — when rolled out across the enterprise.
Greg Holmes, Field CTO for the EMEA region at Apptio, believes the root cause is not technical complexity, but financial blind spots.
“Too often, automation follows a ‘build it and they will come’ mindset,” Holmes says. “It works well in a controlled pilot, but once you move into production, the financial reality looks very different.”
The Automation Scaling Gap
Enterprise leaders frequently approve automation pilots based on promising early results: reduced cycle times, improved accuracy, or hundreds of labour hours saved each month. These metrics are compelling — but incomplete.
“What’s missing is a clear understanding of what happens when that automation scales,” Holmes explains.
Pilots are typically run in ideal conditions: limited workloads, small data volumes, and infrastructure that is often over-provisioned to ensure performance. When the same automation is deployed at scale, costs related to compute, storage, data transfer, APIs, and ongoing support grow rapidly.
“The financial modelling often assumes that what worked in the pilot will work the same way in production,” says Holmes. “That’s rarely true.”
This disconnect is one of the primary reasons why intelligent automation initiatives stall after early success.
From Cost Reaction to Value Engineering
Holmes argues that enterprises must fundamentally rethink how they manage automation costs. Instead of reacting to budget overruns after deployment, organisations need proactive financial governance embedded directly into automation workflows.
“When we integrate FinOps capabilities with automation, we move from being reactive on cost management to being proactive around value engineering,” he says.
This approach allows technology leaders to measure cost and value simultaneously — from the earliest stages of development.
Rather than waiting months or years to assess whether automation is delivering ROI, teams can track metrics such as cost per transaction, cost per API call, or cost per customer served from day one.
“That level of visibility changes behaviour,” Holmes explains. “It forces better design decisions early, before problems compound at scale.”
The Harsh Reality of Innovation Failure Rates
Innovation carries inherent risk. Holmes notes that industry data suggests around 80% of innovation projects fail, often not because the idea was flawed, but because financial risks were hidden during early stages.
“A pilot might show that automating a process saves 100 hours a month, and leadership sees that as a clear win,” he says. “But what it doesn’t reveal is how much infrastructure was quietly over-allocated to make that pilot succeed.”
In production environments, over-provisioning is rarely viable. As automation scales, resource usage becomes more complex:
- API calls multiply as volumes increase
- Edge cases and exceptions emerge that were never tested in pilots
- Support and maintenance overheads grow
- Infrastructure costs fluctuate based on demand
“All of that changes the economics,” Holmes adds.
Without visibility into these factors, organisations risk approving automation initiatives that look efficient on paper but become financially unsustainable in practice.
Understanding Unit Economics in Intelligent Automation
To scale automation successfully, Holmes emphasises the importance of unit economics — understanding how costs behave as usage increases.
“Organisations need to track the marginal cost of automation at scale,” he says. “That means knowing what it costs to serve one more customer, process one more transaction, or execute one more workflow.”
If costs increase as volume grows, the automation model is fundamentally flawed. Effective scaling should result in declining unit costs, not rising ones.
Holmes points to a case study from Liberty Mutual, where the organisation identified approximately $2.5 million in savings by introducing consumption-based metrics.
“They didn’t just look at labour hours saved,” he explains. “They looked at what it actually cost to run and scale the automation — and that changed the outcome.”
Financial Accountability Beyond the Finance Team
One of the most significant shifts Holmes advocates is moving financial accountability closer to engineering teams.
“Cost governance can’t sit only with finance,” he says. “It has to be embedded into development tools and workflows.”
By integrating financial controls into infrastructure-as-code platforms such as HashiCorp Terraform and version control systems like GitHub, organisations can enforce policies at deployment time.
This means developers can see cost estimates immediately when provisioning resources — rather than discovering overruns weeks later.
“Instead of deploying first and fixing later, which turns into a whack-a-mole problem, teams can verify they’re deploying the right things at the right time,” Holmes explains.
This shift transforms cost management from a policing function into a design principle.
Bridging the CFO–Automation Leader Divide
Scaling intelligent automation often exposes tension between executive stakeholders.
- CFOs focus on ROI, total cost, and financial predictability
- Heads of Automation track operational metrics like hours saved and throughput
Both perspectives are valid — but without a shared language, alignment becomes difficult.
“This translation challenge is exactly what Technology Business Management (TBM) and Apptio are designed to solve,” says Holmes.
TBM provides a structured taxonomy that connects technical resources — such as compute, storage, software, and labour — to business capabilities and outcomes.
“It creates a common language between technology, finance, and the business,” Holmes explains.
Making Costs Understandable to the Business
From a business user’s perspective, the underlying complexity of IT systems is often invisible — and unnecessary.
“I don’t need to understand every IT layer underneath,” Holmes says. “What I need is clarity on what I’m consuming and why it costs what it costs.”
TBM enables this by mapping technical inputs into service-level cost models. Business leaders receive transparent views of:
- Which services they consume
- What drives cost increases
- How usage impacts overall spend
“That transparency builds trust,” Holmes notes. “It also enables better decisions about where to invest, optimise, or stop.”
Automation, Legacy Systems, and Technical Debt
For organisations burdened with legacy ERP and core systems, intelligent automation can feel like a shortcut to modernisation — but Holmes warns this approach carries risk.
“If automation is just masking inefficient processes instead of redesigning them, you’re building more technical debt,” he says.
The key is understanding total cost of ownership (TCO).
The Commonwealth Bank of Australia provides a compelling example. The bank applied a TCO model across 2,000 applications, spanning multiple generations of technology.
This analysis accounted not only for infrastructure and licensing, but also hidden costs such as:
- Engineering effort to maintain automation
- Integration complexity
- Ongoing support and operational overhead
“Legacy doesn’t automatically mean bad,” Holmes explains. “Some legacy systems deliver incredible value and are absolutely worth maintaining.”
However, in other cases, the cost of automation layers required to keep outdated systems functional outweighs their benefits.
“When you add everything up, you sometimes realise you’re not just paying for the old system — you’re paying for all the scaffolding around it,” Holmes says.
Budgeting for Stability in an OPEX World
One of the biggest challenges in scaling automation is managing variable costs.
Cloud-based automation platforms typically operate on an OPEX model, offering flexibility but introducing volatility. Costs can spike due to demand changes, inefficient design, or unexpected growth.
Holmes argues that organisations need longer-term visibility to counter this volatility.
“When you make multi-year commitments and standardise platforms, you gain predictability,” he says.
Long-term planning allows enterprises to:
- Negotiate better pricing
- Standardise architectures
- Reduce duplication
- Build automation designed for longevity
“That stability makes it much easier to scale intelligently,” Holmes adds.
The Future of Intelligent Automation
As automation matures, Holmes believes the winners will be organisations that combine innovation with discipline.
“Automation isn’t just a technical challenge anymore,” he says. “It’s a financial and organisational one.”
Successful enterprises will be those that:
- Track unit economics from day one
- Embed cost governance into engineering workflows
- Use shared financial frameworks like TBM
- Take a lifecycle view of automation investments
“Scaling automation without financial rigour is like driving fast without a dashboard,” Holmes concludes. “You might feel in control — until you’re not.”
Industry Spotlight: Intelligent Automation Conference Global
IBM is a key sponsor of the Intelligent Automation Conference Global, taking place in London on 4–5 February 2026.
Greg Holmes will join industry experts on day one for the panel discussion “Scaling Intelligent Automation Successfully: Frameworks, Risks, and Real-World Lessons.”
Attendees can also connect with IBM and Apptio teams at stand #362 to explore practical approaches to automation governance, FinOps, and value-driven scaling.