An automation pilot can save 100 staff hours each month and still become a poor investment at scale. The demonstration may run on over-provisioned infrastructure, exclude difficult exceptions, and ignore support work that appears only when thousands of transactions arrive.
Apptio field CTO Greg Holmes argues that FinOps and Technology Business Management should enter the project before production. Instead of assessing value months later, teams track resource consumption and business output from the first deployment.
The goal is to replace a persuasive time-saving estimate with unit economics that survive growth.
Cost Per Outcome Reveals Whether Scale Works
Production multiplies compute, storage, data transfer, API calls, exceptions, and support. If cost per customer or transaction rises with volume, the automation model is moving in the wrong direction.
FinOps connects consumption with outcomes so teams can see whether each additional unit becomes cheaper. Holmes cites Liberty Mutual identifying roughly $2.5 million in savings by using consumption metrics rather than relying only on labour hours.
Hours saved remain useful, but they do not show infrastructure waste, correction work, or the cost of edge cases. A complete measure includes quality, failure, support, and the resources required to deliver the result.
The baseline must include the real cost and quality of the current process, not an idealised manual alternative.
Financial feedback should reach developers through their normal tools. Integrations with infrastructure-as-code systems such as Terraform and GitHub can estimate cost and enforce policy before a resource is deployed, avoiding repeated cleanup after the bill arrives.
Technology and Finance Need a Shared Language
The CFO may ask for return on investment while an automation leader reports tasks completed or hours released. Technology Business Management maps compute, storage, labour, and other resources through IT services to business capabilities.
That taxonomy lets a business owner see what service was consumed and which technical costs made it more expensive. It also gives engineering teams a reason to optimise something more meaningful than a generic cloud bill.
Ownership cannot sit only with finance. Developers influence architecture and consumption every day; business leaders determine whether the outcome is valuable; finance tests sustainability. Shared metrics prevent each group from declaring success in a different language.
The method should also retain uncertainty. Early projects will not predict every exception. Forecast ranges, sensitivity tests, and explicit assumptions are more credible than one precise return calculated from a controlled pilot.
Total Cost Clarifies the Fate of Legacy Systems
Automation can extend an old ERP system or become a bridge to replacement. If it merely masks an inefficient process, each wrapper adds technical debt and operating cost.
A total-cost-of-ownership model includes infrastructure, labour, support, engineering, and the automation layers surrounding the legacy application. Commonwealth Bank of Australia applied such analysis across 2,000 applications of different ages.
Age alone does not justify retirement. Some legacy systems continue delivering strong value. Others appear inexpensive only because the cost of keeping them functional sits in adjacent scripts, teams, and exceptions.
Budgeting must balance variable operating cost with longer commitments. Flexible consumption supports experimentation, while multi-year platform choices can improve pricing and architectural consistency. Leaders need enough visibility to choose deliberately rather than oscillating between surprise bills and premature lock-in.
Holmes notes that innovation projects have a high failure rate, often because financial opacity conceals production liabilities. Financial rigour should not suppress experimentation; it should identify which experiments deserve expansion.
An automation is ready to scale when its cost per useful outcome declines, controls operate inside delivery, and the organisation understands the complete system it must maintain. A pilot proves that a task can be automated. Unit economics determine whether it should become part of the business.
