Apptio: Why scaling intelligent automation requires financial rigour
Most automation pilots look great on slides. Then production arrives, costs spike, and the model falls apart. The fix isn't more tooling-it's financial discipline built into the lifecycle from day one.
The thesis: intelligent automation only scales when finance and engineering share the same unit-level truth. That means real-time cost signals, policy guardrails in the pipeline, and decisions made on marginal economics-not anecdotes.
From reactive cost control to proactive value engineering
Integrating FinOps moves teams from post-mortem cost reviews to live value tracking. Instead of waiting months to see if an automation adds value, you track consumption metrics-cost per transaction, API call, workflow-straight away.
Start simple: define a small set of unit metrics that engineering can instrument and finance can trust. FinOps practices are built for this.
Get the unit economics right
Many pilots succeed because they run on over-provisioned infrastructure with ideal data and few edge cases. Production brings volume: API calls multiply, exception paths emerge, and support overheads grow.
Track marginal cost at scale. If cost per customer or per transaction rises as volume grows, the model is flawed. Effective scaling drives unit costs down, not up.
A real-world example: Liberty Mutual uncovered about $2.5 million in savings by instrumenting consumption metrics-beyond counting "hours saved." That shift revealed where value was real and where it was noise.
Put governance in the hands of developers
Financial accountability can't live only in spreadsheets. Bring it into the deployment workflow with policy-as-code. Integrations with Infrastructure-as-Code tools (e.g., Terraform) and repositories (e.g., GitHub) let teams see cost estimates and policy checks before anything goes live.
Guardrails beat cleanup. Enforce standards on instance types, data egress, API thresholds, and tagging at deploy time. This prevents the "deploy now, fix later" spiral that inflates spend.
Create a common language with TBM
The CFO speaks ROI. The Head of Automation speaks hours saved and throughput. You need a translation layer. That's what TBM (Technology Business Management) provides: a taxonomy that maps compute, storage, labor, and platforms to IT towers and business capabilities.
With TBM, business leaders can see a clear bill of consumption and understand precisely which drivers push costs up with usage. Explore the framework at the TBM Council.
TCO beats quick fixes for legacy
For legacy ERP and core systems, you have a choice: use automation as a patch, or as a bridge to modernization. If you wrap broken processes without redesigning them, you're stacking technical and operational debt.
A TCO lens changes the answer. One bank ran TCO across 2,000 applications-factoring infrastructure, labor, and the engineering needed to keep automations alive. Some legacy systems stayed because their value was strong. Others were retired once the true cost of all the automation layers was counted.
Budget without the sticker shock
Variable costs (OPEX) give flexibility-but they swing with demand and engineering discipline. Long-term commitments create pricing leverage, simplify architecture choices, and stabilize forecasts.
Blend both. Manage variable spend tightly, while making multi-year commitments where you have conviction. Standardization lowers build costs and reduces variance in unit economics.
Metrics that matter (finance-first scorecard)
- Cost per transaction, API call, workflow, and exception
- Marginal cost at N, 10N, and 100N volume
- Unit cost curve slope (is cost per unit falling with scale?)
- Support overhead per bot/process and exception rate per 1,000 transactions
- Data egress and inter-service network cost per workload
- Tagging coverage and policy violations at deploy time
- Reserved/committed coverage vs. on-demand spend
- Payback period, NPV, and IRR per automation initiative
Action plan for CFOs and Heads of Automation
- Mandate FinOps instrumentation from day zero: every service reports cost per unit.
- Require policy-as-code guardrails in CI/CD: cost estimates and compliance checks block non-conforming deploys.
- Separate pilot vs. production cost models; explicitly model scale effects (API volume, support, data transfer).
- Adopt TBM taxonomy so finance, tech, and the business share one view of cost and value.
- Use TCO to decide: keep, refactor, or retire legacy-count the automation wrappers too.
- Set quarterly "spend-to-value" reviews that tie unit economics to business outcomes.
- Balance OPEX flexibility with multi-year commitments where usage is predictable.
- Align incentives: teams own both performance and cost per unit targets.
Where to learn more
IBM is sponsoring the Intelligent Automation Conference Global in London on 4-5 February 2026. Join the day-one panel "Scaling Intelligent Automation Successfully: Frameworks, Risks, and Real-World Lessons," and visit IBM at stand #362 to go deeper on the practices above.
Bottom line: automation scales when finance sets the rules of the game and engineering enforces them in code. Make unit economics visible, govern at deploy time, and commit where it pays to standardize.
Your membership also unlocks:
