Membuat biaya TI menjadi bahasa strategis: membangun cost transparency per unit dan kapabilitas, menerapkan siklus FinOps di landscape multi-cloud Bumi Niaga, dan menggunakan analisis biaya untuk mengoptimalkan nilai portofolio bukan sekadar memotong anggaran

Setelah di episode 14 security menjadi properti desain Bumi Niaga, kita hadapi dimensi yang menentukan apakah roadmap kalian bertahan hidup di rapat anggaran: biaya. Strategic theme ketiga Bumi Niaga dari episode 8 — efisiensi biaya grup 15% — tidak akan tercapai lewat retorika; ia butuh mesin pengukuran dan mekanisme optimasi. Alatnya: IT cost transparency dan FinOps.
Ini kompetensi EA yang sering diremehkan engineer, padahal di sinilah kredibilitas di mata CFO dibangun. EA yang bisa menjawab "berapa biaya kapabilitas Fulfillment per transaksi?" didengar; EA yang hanya bisa bilang "tagihan cloud kami naik" digeser.
Langkah nol: tagihan agregat tidak berguna — biaya harus terurai sampai unit pemilik dan kapabilitas. Fondasi teknisnya sudah kalian siapkan: tagging standard di landing zone (episode 7). Hierarki alokasi yang saya rekomendasikan:
Level 1 - Unit bisnis : BelanjaKu | KirimKu | BayarKu | Korporat
Level 2 - Kapabilitas : Order Management, Fulfillment, ...
Level 3 - Environment/app : prod vs nonprod, nama aplikasi (ep 6)
Level 4 - Jenis biaya : compute, storage, network, license, supportDengan struktur itu, pertanyaan-pertanyaan manajerial langsung terjawab: biaya nonprod ternyata 40% dari total BelanjaKu (kandidat scheduling auto-shutdown), storage log dua lini tumbuh tak terkendali (retention policy belum ada), dan biaya "Korporat" yang membengkak biasanya shared services yang belum dialokasikan.
Untuk biaya bersama — platform data grup, interconnect, event backbone — gunakan model showback dulu, chargeback kemudian: tampilkan alokasi biaya ke tiap unit tanpa menagih, agar perilaku terbentuk; chargeback formal dilakukan setelah metrik alokasi stabil dan dipercaya semua pihak. Chargeback prematur pada data yang rapuh akan membunuh kredibilitas program ini di awal.
FinOps adalah praktik operasional yang mendamaikan tiga pihak yang biasanya berbeda insentif: finance (prediksi biaya), engineering (kecepatan delivery), dan business (nilai per rupiah). Siklusnya tiga fase yang berulang tiap periode:
| Fase | Aktivitas Inti | Contoh Tindakan |
|---|---|---|
| Inform | Alokasi, dashboard, anomaly detection | Alert tagihan harian deviasi >20%; dashboard per unit |
| Optimize | Tuning rate & resource | Rightsizing, committed use discount, spot untuk batch |
| Operate | Policy & accountability | Budget owner sign-off kuarteran, target unit economics |
Prinsip pembeda FinOps dari "hemat-listrik era IT": keputusan biaya didelegasikan ke engineer dengan umpan balik cepat. Engineer yang melihat biaya deployment-nya sendiri di dashboard akan rightsizing tanpa diperintah — asalkan tagging jalan dan datanya dekat dengan pekerjaannya.
Angka absolut ("cloud kita Rp X miliar") kurang berguna tanpa penyebut. Ubah ke unit economics per bisnis:
Unit economics membuat percakapan berubah kualitas: "infrastruktur naik 30%" terdengar buruk; "biaya per order turun 12% walau volume naik 45% — efisiensi skala bekerja" adalah cerita sukses yang identik secara kas. Inilah cara EA membuktikan theme efisiensi tercapai tanpa mengorbankan pertumbuhan.
FinOps harian harus dilengkapi optimasi struktural tingkat portofolio — area eksklusif EA. Empat tuas terbesar:
Warning
Waspadai optimasi yang merusak: menekan biaya dengan memangkas redundancy (backup, DR, capacity headroom) memindahkan pengeluaran ke risiko. Optimasi sah menurunkan biaya per unit nilai; optimasi berbahaya menurunkan total biaya dengan mengorbankan resilience — dan tagihannya keluar saat insiden (episode 20).
Terakhir, masukkan biaya ke alur governance yang sudah kalian bangun: ARB menilai proposal dengan estimasi TCO 3 tahun (lisensi + infrastruktur + operasi + migrasi), bukan hanya harga akuisisi — keputusan build-vs-buy dan konsolidasi butuh angka jujur ini. Tiap inisiatif roadmap (episode 8) membawa target unit economics-nya sendiri sehingga keberhasilannya bisa diaudit finansial, dan exception infrastruktur (episode 9) punya expiry seperti exception arsitektur lain.
Metrik bulanan yang layak masuk dashboard EA (episode 25): alokasi biaya per kapabilitas, unit economics tren per lini, coverage tagging (target di atas 95%), persentase workload dengan committed discount, dan jumlah anomaly yang belum ditindaklanjuti.
Cost model hanya seakurat tagging-nya. Karena itu tagging bukan anjuran — ia policy landing zone yang ditegakkan mesin:
tags-required:
unit: [belanjaku, kirimku, bayarku, korporat]
capability: capability-map-L2-name # rujukan capability map ep 4
application: portfolio-id # rujukan inventaris ep 6
environment: [prod, nonprod]
enforcement:
on-deploy: deny-if-missing # pipeline menolak tanpa tag
weekly-scan: report-unowned-resources # sisa tanpa owner masuk reportDua mekanisme ini menutup lubang klasik alokasi biaya: resource tanpa tag tidak bisa lahir diam-diam (deny on deploy), dan yang lolos — biasanya buatan tangan dari konsol — muncul di laporan mingguan dengan pemiliknya dipanggil. Dalam satu kuarter, coverage tagging naik ke angka yang membuat chargeback layak diperdebatkan.
Kerjakan di ea-lab/case-study/finops/:
Inti yang harus dibawa pulang:
Biaya kini bisa diperdebatkan dengan angka. Di episode 16 kita lanjut ke sisi pasokannya: vendor & licensing strategy — memetakan landscape vendor Bumi Niaga, memahami model lisensi dari perpetual sampai consumption, dan menyusun sourcing strategy yang menjaga daya tawar tanpa memecah kompleksitas. Sampai jumpa di episode 16!