Cloud bills rarely “explode” overnight. They creep up through test environments that never shut down, storage that never tiers, commitments bought too early, and—more recently—AI and SaaS costs that arrive without a clear owner. For operations leaders the problem is seldom a missing dashboard. It is that technology spend lacks owners and a decision cadence.
According to Gartner’s July 2026 forecast, worldwide IT spending is expected to reach $6.37 trillion in 2026 (up 14.2% from 2025), with IaaS growing 29.3%. On the practice side, the FinOps Foundation’s State of FinOps 2026—the sixth annual survey, with 1,192 respondents representing more than $83 billion in annual cloud spend—shows FinOps moving from explaining last month’s bill to shaping technology decisions before commitments are made.
Mature FinOps is not a one-off bill cut. It ties spend to business value—with owners, unit costs, and decisions before deploy.
This article summarises findings we opened from primary sources, then turns them into realistic steps for organisations in Indonesia. It does not claim MarkasDev sells a FinOps product, and it avoids “save X% in a week” hype.
What changed in 2026
FinOps scope has moved beyond public cloud
State of FinOps 2026 reports a decisive expansion: 98% of respondents now manage AI spend (up from 31% two years earlier; from 63% in 2025), 90% manage or plan to manage SaaS (up 25 points), 64% manage licensing, 57% private cloud, and 48% data center. The FinOps Foundation updated its mission from the value of cloud to the value of technology.
The practical implication: if your team only watches the AWS or Azure invoice, you are looking at a partial picture. Tokens, GPUs, data-cloud platforms, observability, and SaaS licences often grow faster—and with less clarity—than ordinary virtual machines.
Optimisation still matters, but it is no longer the only goal
Workload optimisation and waste reduction remain a daily priority for many teams. Collectively, though, scope expansion, governance and policy, organisational alignment, and forecasting now rival optimisation alone. Mature practitioners report that the “big rocks” of waste are gone; what remains are smaller opportunities that take more effort. The centre of gravity is shifting to unit economics, AI value quantification, and influence over technology selection.
FinOps has shifted up into technology leadership
Seventy-eight percent of FinOps practices now report to the CTO or CIO. The dominant operating model stays lean: centralised enablement (60%) or hub-and-spoke (21%)—81% in total—with execution through federated champions rather than a large central empire. Teams that engage VP/C-suite leaders show 2–4× more influence over cloud service selection, provider choice, and cloud-versus-data-center decisions than those that stop at director level.
Five practices that keep spend from floating free
The sequence below follows the familiar path of visibility first, then optimisation, then a durable operating model—also outlined in 2026 FinOps practice summaries. Figures below are from State of FinOps unless noted otherwise.
Technical tags (region, instance type) help engineers, but FinOps needs answers: who owns it, which budget, and what decision follows? At minimum: owner, cost_center, env, and a product/service identity. Enforce them with policy-as-code at deploy time—not with a scolding after the invoice arrives. For shared costs (networking, Kubernetes clusters), define an explicit allocation model so “unallocated spend” does not become a permanent grey zone.
2. Normalise data across vendors
When scope includes multi-cloud, SaaS, and AI, mismatched billing schemas become the bottleneck. The FOCUS (FinOps Open Cost and Usage Specification) is designed to normalise cost and usage datasets. You do not need expensive tooling on day one; you do need one allocation model that finance and engineering share.
3. Rightsize first, then buy commitments
Buying Reserved Instances or Savings Plans on top of inflated capacity locks waste in for the term. Start with non-production: shut it down outside business hours, clear orphaned volumes and stale snapshots, then review native provider recommendations monthly. Only after the baseline is cleaner should engineering and finance discuss commitment coverage and utilisation together.
4. Bring AI and SaaS into the same scope
With 98% of practices already managing AI spend, “how much do we spend on AI?” must be answerable per product or process—not as one mysterious invoice line. Tie tokens, GPU-hours, or model calls to agreed outcomes (tickets closed, cycle time, transaction volume). Without that link, AI still sounds strategic but cannot be defended.
5. A decision cadence, not reactive reviews
Cloud changes week to week. Run at least three cycles: weekly anomaly review, monthly team review (waste plus forecast versus actuals), and quarterly commitment and architecture review. Embed them in calendars you already keep (product stand-ups, budget meetings); do not invent a separate FinOps calendar that is easy to ignore.
What this means for organisations in Indonesia
Many Indonesian organisations—mid-size firms, regional SOEs, healthcare facilities, local finance institutions, logistics—already use public cloud, SaaS, and early AI, often without a named FinOps function. You do not need a ten-person FinOps team. You need clear cost owners and decisions before architecture locks in.
- Start with a spend map, not a tool. List cloud accounts, projects, must-have SaaS, and AI experiments. Who approves? Who sees the invoice? If the answer is “IT alone”, showback will stay weak.
- Give finance and engineering a shared language. Pick three to five unit economics that matter: cost per transaction, per branch, per patient-day, or per shipment—not only total rupiah per month.
- Protect non-production first. In many local organisations the fastest savings come from staging left on 24/7 and uncontrolled production data copies—not from redesigning the core application.
- Do not let AI become “special spend without an owner”. Every AI proof of concept needs a sponsor, a spend cap, and stop criteria—just like an integration project.
- Connect this to Operate, not only to a project. After go-live, the bill follows uptime. Without monitoring and controlled change, “one-month savings” vanish by month three.
Mapped to MarkasDev’s three phases:
| Phase |
Main question |
Written outcome |
| Diagnose |
Which accounts, workloads, SaaS, and AI drive cost—and who owns them? |
Spend map, tagging gaps, priority options |
| Deliver |
What acceptance criteria cover required tags, non-prod schedules, and architecture cost estimates? |
Milestones with cost gates before deploy |
| Operate |
Who watches anomalies, rotates commitments, and reviews forecasts? |
Review cadence, alerts, and operational cost SLA |
Diagnose fits when the spend map and owners are still unclear—cheaper than buying a FinOps platform before the business questions are answered. In Deliver, put architecture cost estimates and mandatory tagging into acceptance criteria, especially for servers and environments and integrations that add data paths. After go-live, Operate keeps the anomaly rhythm so savings do not evaporate; we contrast that with reactive maintenance in maintenance vs Operate.
If cloud architecture decisions still swing every quarter, IT consulting with written outputs—or the Diagnose–Deliver–Operate approach—keeps the discussion on facts rather than vendor preference. For the data foundation before AI, see data integration before AI.
Realistic first steps this week
- Export the last 90 days of billing by account/project; mark lines with no owner.
- Set mandatory tags for new resources (owner, cost_center, env) and block violating deploys in one environment first.
- Shut down or schedule non-production outside business hours; record savings as a baseline.
- Pick one unit-cost metric for a primary product or service; report it alongside uptime.
- For AI proofs of concept: set a monthly spend cap and a sponsor before API keys are shared.
If you want to map cost owners and architecture risk before a larger cloud or AI budget is locked, start with a Diagnose conversation — or read what Diagnose includes first. You leave with a written map and decisions you can use with or without us.
Sources