FinOps untuk organisasi: biaya cloud butuh pemilik, bukan hanya dashboard

Tagihan cloud jarang “meledak” dalam semalam. Ia naik perlahan lewat lingkungan uji yang tak pernah dimatikan, volume penyimpanan yang tak ditier, komitmen yang dibeli terlalu awal, dan—akhir-akhir ini—biaya AI serta SaaS yang masuk tanpa pemilik yang jelas. Bagi pimpinan operasional, masalahnya bukan kurang dashboard. Masalahnya: pengeluaran teknologi tidak punya pemilik dan ritme keputusan.

Menurut prakiraan Gartner Juli 2026, belanja TI global diperkirakan mencapai 6,37 triliun dolar AS pada 2026 (naik 14,2 persen dari 2025), dengan IaaS tumbuh 29,3 persen. Di sisi praktik, State of FinOps 2026 dari FinOps Foundation—survei tahunan keenam dengan 1.192 responden yang merepresentasikan lebih dari 83 miliar dolar belanja cloud per tahun—menunjukkan FinOps sudah bergeser dari “menjelaskan tagihan kemarin” menjadi disiplin yang membentuk keputusan teknologi sebelum komitmen dibuat.

FinOps yang matang bukan soal memotong tagihan sesaat. Ia soal menautkan biaya ke nilai bisnis—dengan pemilik, satuan biaya, dan keputusan sebelum deploy.

Artikel ini merangkum temuan yang kami buka dari sumber primer, lalu menerjemahkannya ke langkah yang realistis untuk organisasi di Indonesia—tanpa mengklaim bahwa MarkasDev menjual produk FinOps tertentu, dan tanpa hype “hemat X persen dalam seminggu”.

Apa yang berubah di 2026

Lingkup FinOps sudah melampaui cloud publik

Laporan State of FinOps 2026 mencatat perluasan yang tegas: 98 persen responden kini mengelola belanja AI (naik dari 31 persen dua tahun sebelumnya; dari 63 persen pada 2025), 90 persen mengelola atau berencana mengelola SaaS (naik 25 poin), 64 persen mengelola lisensi, 57 persen private cloud, dan 48 persen data center. FinOps Foundation bahkan memperbarui misinya dari nilai cloud menjadi nilai teknologi.

Implikasinya praktis: jika tim Anda hanya melihat invoice AWS atau Azure, Anda sedang melihat sebagian gambar. Biaya token, GPU, platform data cloud, observability, dan lisensi SaaS sering tumbuh lebih cepat—dan lebih buram—daripada mesin virtual biasa.

Optimasi tetap penting, tetapi bukan lagi satu-satunya tujuan

Workload optimization dan pengurangan waste tetap prioritas harian banyak tim. Namun secara kolektif, perluasan lingkup, tata kelola/kebijakan, penyelarasan organisasi, dan forecasting sudah menyaingi optimasi semata. Praktisi mature melaporkan “batu besar” waste sudah diambil; sisanya peluang kecil yang butuh lebih banyak usaha. Pusat gravitasi bergeser ke unit economics, kuantifikasi nilai AI, dan pengaruh terhadap pemilihan teknologi.

FinOps naik ke level kepemimpinan teknologi

Sebanyak 78 persen praktik FinOps kini melapor ke CTO atau CIO. Model operasi yang dominan tetap lean: enablement terpusat (60 persen) atau hub-and-spoke (21 persen)—total 81 persen—dengan eksekusi lewat champion di unit bisnis, bukan kerajaan staf pusat. Tim yang menjangkau VP/C-suite punya pengaruh 2–4 kali lebih besar pada pemilihan layanan cloud, provider, dan keputusan cloud versus data center dibanding yang hanya sampai level director.

Lima praktik yang menahan tagihan agar tidak “mengambang”

Kerangka berikut selaras dengan urutan yang menekankan visibilitas dulu, baru optimasi, baru model operasi berkelanjutan—seperti yang juga diuraikan dalam ringkasan praktik FinOps 2026. Angka di bawah berasal dari State of FinOps kecuali disebut lain.

1. Tag dan alokasi yang menjawab pertanyaan bisnis

Tag teknis (region, instance type) membantu engineer, tetapi FinOps butuh jawaban: siapa pemiliknya, budget mana, dan keputusan apa yang bisa diambil? Minimal: owner, cost_center, env, dan identitas produk/layanan. Tegakkan lewat policy-as-code di deploy—bukan lewat teguran setelah invoice tiba. Untuk biaya bersama (jaringan, cluster Kubernetes), tentukan model alokasi eksplisit agar “unallocated spend” tidak menjadi zona abu-abu abadi.

2. Normalisasi data lintas vendor

Saat lingkup mencakup multi-cloud, SaaS, dan AI, skema billing yang berbeda menjadi hambatan. Spesifikasi FOCUS (FinOps Open Cost and Usage Specification) dirancang untuk menormalisasi dataset biaya dan penggunaan. Anda tidak wajib mengadopsi tooling mahal di hari pertama; yang wajib adalah satu model alokasi yang dipakai finance dan engineering bersama.

3. Rightsize dulu, baru beli komitmen

Membeli Reserved Instance atau Savings Plan di atas kapasitas yang gemuk mengunci waste selama masa kontrak. Mulai dari lingkungan non-produksi: matikan di luar jam kerja, bersihkan volume yatim dan snapshot usang, lalu tinjau rekomendasi native provider setiap bulan. Setelah baseline bersih, baru diskusikan coverage dan utilization komitmen bersama finance.

4. Masukkan AI dan SaaS ke dalam lingkup yang sama

Dengan 98 persen praktik yang sudah mengelola belanja AI, pertanyaan “berapa yang kita belanjakan untuk AI?” harus bisa dijawab per produk atau proses—bukan satu baris misterius di invoice. Hubungkan token, GPU-hour, atau panggilan model ke outcome yang disepakati (tiket terselesaikan, waktu siklus, volume transaksi). Tanpa tautan itu, AI tetap terdengar strategis tetapi tak bisa dipertanggungjawabkan.

5. Ritme keputusan, bukan review reaktif

Cloud berubah mingguan. Minimal tiga siklus: review anomali mingguan, review tim bulanan (waste + forecast versus actual), dan review komitmen serta arsitektur per kuartal. Sematkan ke kalender yang sudah ada (standup produk, rapat anggaran), jangan buat kalender FinOps terpisah yang mudah diabaikan.

Apa artinya bagi organisasi di Indonesia

Banyak organisasi di Indonesia—perusahaan menengah, BUMD, faskes, lembaga keuangan lokal, logistik—sudah memakai cloud publik, SaaS, dan mulai mencoba AI, sering tanpa fungsi FinOps bernama. Anda tidak harus mendirikan “tim FinOps 10 orang”. Anda butuh kejelasan pemilik biaya dan keputusan sebelum arsitektur terkunci.

• Mulai dari peta belanja, bukan dari tool. Daftar akun cloud, proyek, SaaS wajib, dan eksperimen AI. Siapa yang approve? Siapa yang melihat invoice? Jika jawaban “bagian IT saja”, risiko showback akan lemah.
• Satukan bahasa finance dan engineering. Pilih 3–5 unit economics yang relevan: biaya per transaksi, per cabang, per pasien/hari, atau per pengiriman—bukan hanya total rupiah per bulan.
• Lindungi lingkungan non-produksi lebih dulu. Di banyak organisasi lokal, hemat tercepat datang dari staging yang menyala 24/7 dan salinan data produksi yang tak terkendali—bukan dari redesign aplikasi inti.
• Jangan biarkan AI jadi “biaya khusus tanpa pemilik”. Setiap PoC AI wajib punya sponsor, batasan spend, dan kriteria berhenti—sama seperti proyek integrasi.
• Hubungkan ke Operate, bukan hanya ke proyek. Setelah go-live, tagihan mengikuti uptime. Tanpa monitoring dan perubahan terkendali, “hemat sekali” di bulan pertama bisa hilang di bulan ketiga.

Pemetaan ke tiga fase MarkasDev:

Tahap Diagnose cocok ketika peta belanja dan pemilik masih kabur—lebih murah daripada membeli platform FinOps sebelum pertanyaan bisnis terjawab. Pada Deliver, masukkan estimasi biaya arsitektur dan tagging wajib ke kriteria penerimaan, terutama untuk server dan lingkungan serta integrasi yang menambah jalur data. Setelah live, Operate menjaga ritme anomali dan perubahan agar hemat tidak menguap; bedanya dengan pemeliharaan reaktif kami uraikan di maintenance vs Operate.

Jika keputusan arsitektur cloud masih digoyang tiap kuartal, konsultasi IT dengan keluaran tertulis—atau kerangka pendekatan Diagnose–Deliver–Operate—membantu menahan diskusi di fakta, bukan di preferensi vendor. Tulisan terkait soal fondasi data sebelum AI ada di integrasi data sebelum AI.

Langkah pertama yang realistis minggu ini

• Ekspor tagihan 90 hari terakhir per akun/proyek; tandai baris yang tak punya pemilik.
• Tetapkan tagging wajib untuk resource baru (owner, cost_center, env) dan blokir deploy yang melanggar di satu lingkungan dulu.
• Matikan atau jadwalkan non-produksi di luar jam kerja; catat penghematan sebagai baseline.
• Pilih satu metrik unit cost untuk produk atau layanan utama; laporkan bersamaan dengan uptime.
• Untuk PoC AI: tetapkan batas spend bulanan dan sponsor sebelum kunci API dibagikan ke tim.

Jika Anda ingin memetakan pemilik biaya dan risiko arsitektur sebelum anggaran cloud atau AI dikunci lebih besar, mulai dari percakapan Diagnose — atau baca dulu apa isi Diagnose. Hasilnya peta dan keputusan tertulis yang bisa Anda pakai, dengan atau tanpa kami.

Sumber

• FinOps Foundation — State of FinOps 2026 Report
• Gartner — Worldwide IT Spending Forecast (27 Juli 2026)
• N-iX — FinOps best practices for optimizing cloud spend in 2026
• FinOps Foundation — FOCUS specification
• FinOps Foundation — finops.org