Belajar BI Analyst - Enterprise BI & Stakeholder
Episode ini membahas BI di skala enterprise: scaling dari satu tim ke seluruh perusahaan, mengelola stakeholder dengan bahasa bisnis, governance report, serta praktik menyusun roadmap BI yang realistis untuk satu kuartal ke depan
#Pendahuluan
Sejauh ini kalian belajar BI sebagai skill individual: query, model, dashboard, dan analitik. Episode ini menaikkan level: BI sebagai fungsi organisasi — bagaimana BI dijalankan di perusahaan yang besar, dengan banyak tim, banyak stakeholder, dan kepentingan yang saling bertabrakan.
Mengapa ini penting? Karena di dunia nyata, kemampuan teknis hanya 50% dari pekerjaan BI Analyst. 50% lainnya adalah mengelola manusia: mendengarkan kebutuhan stakeholder, menyampaikan trade-off, dan membangun roadmap yang disepakati. Kalian yang bisa menjembatani keduanya akan naik jauh lebih cepat.
#Dari Tim Kecil ke Enterprise
Perbedaan cara kerja BI di skala berbeda:
| Aspek | Tim Kecil / Startup | Enterprise |
|---|---|---|
| Data | Sedikit, mudah dipahami | Banyak sistem, banyak definisi |
| User | 5-50 orang | Ratusan-ribuan |
| Organisasi BI | 1-2 orang | Tim BI, Data Engineer, Analytics Engineer |
| Permintaan | Ad-hoc, cepat | Proses, prioritas, governance |
| Tool | 1 tool | Platform BI + data catalog + pipeline |
Masalah yang muncul saat skala bertambah tidak teknis, melainkan koordinasi: siapa pemilik metrik, siapa yang boleh mengubah dashboard, dan bagaimana menyepakati prioritas. Inilah yang akan kalian atasi sebagai BI Analyst senior/lead.
#Stakeholder Management: Bahasa Bisnis, Bukan SQL
Stakeholder BI datang dari banyak latar: CEO, CFO, Head of Marketing, tim operasional. Kesalahan terbesar BI Analyst pemula: berbicara bahasa teknis kepada orang yang tidak peduli teknis.
| Alih-alih Mengatakan | Katakan |
|---|---|
| "Query-nya lambat karena join-nya besar" | "Dashboard butuh waktu 3 detik lebih lama; kita bisa percepat minggu depan" |
| "Perlu refactor model dulu" | "Saya perlu 2 hari agar angka revenue konsisten di semua report" |
| "Data quality-nya jelek" | "Sekitar 2% transaksi belum tervalidasi — kita jangan jadikan dasar bonus" |
Tiga kebiasaan stakeholder management yang wajib:
- Konfirmasi pertanyaan sebelum jawaban: tanyakan "keputusan apa yang mau diambil dari data ini?" sebelum menghabiskan berhari-hari membangun dashboard.
- Tunjukkan trade-off dengan jelas: "kalau ini selesai lebih cepat, yang itu bergeser" — stakeholder tidak bisa melihat beban kerja kalian.
- Dokumentasikan kesepakatan: setiap permintaan punya konteks, tujuan, dan deadline yang tercatat — menghindari "saya tidak pernah minta itu".
#Report Governance: Siapa Berkuasa atas Angka
Di enterprise, "report resmi" vs "report informal" harus jelas. Ini melindungi keputusan perusahaan dari angka yang belum tervalidasi:
| Level | Status | Contoh | Perubahan |
|---|---|---|---|
| Certified | Resmi, divalidasi, dipakai untuk keputusan | Laporan keuangan kuartal | Hanya pemilik yang mengubah |
| Published | Dipakai tim, definisi mengikuti semantic layer | Dashboard operasional | Review ringan |
| Experimental | Eksplorasi, belum dijamin | Analisis ad-hoc analyst | Bebas, tapi berlabel jelas |
Aturan praktisnya: dashboard yang mempengaruhi keputusan bernilai besar harus certified — dengan pemilik, dokumentasi, dan proses perubahan yang jelas. Semua dashboard lain bebas, asal tidak menyamar sebagai certified (label transparan, seperti yang kita bahas di episode 14).
#Roadmap BI: Prioritas yang Disepakati
BI tidak bisa melayani semua permintaan sekaligus — dibutuhkan roadmap yang menyepakati apa yang dikerjakan dan apa yang ditunda. Empat langkah menyusunnya:
#1. Kumpulkan Permintaan & Kategorikan
Dari semua stakeholder, kumpulkan kebutuhan lalu kategorikan berdasarkan dampak dan urgensi:
Peta Prioritas (kuadran dampak vs urgensi):
[Q1 - Kerjakan sekarang] Revenue report real-time (dampak tinggi, urgent)
[Q2 - Kerjakan segera] Data quality fix di pipeline (dampak tinggi, tidak urgent)
[Q3 - Jadwalkan] Dashboard HR baru (dampak rendah, urgent)
[Q4 - Tunda/singkirkan] Dashboard "kebanggaan" tanpa pengguna (dampak rendah)#2. Negosiasikan Trade-off
Sampaikan ke stakeholder utama: "dua dari lima permintaan bulan ini bisa selesai; ini pilihan prioritasnya." Biarkan mereka yang menyepakati — bukan kalian yang diam-diam memilih.
#3. Tulis Roadmap Realistis
Roadmap kuartalan yang sehat mencakup: inisiatif (bukan semua item kecil), owner, dan target. Contoh:
Q3 Roadmap BI:
1. Baseline data quality (audit + dbt test penuh) [Sprint 1-2]
2. Semantic layer untuk 3 KPI utama (revenue, margin, AOV) [Sprint 2-4]
3. Dashboard real-time untuk tim operasional [Sprint 5-7]
4. Self-service portal go-live (episode 13) [Sprint 8-9]#4. Review Berkala
Sprint review bulanan: apa yang selesai, apa yang berubah, apa feedback stakeholder. Roadmap adalah dokumen hidup — bukan ukiran batu.
Important
Keterampilan yang paling diremehkan BI Analyst senior adalah mengatakan tidak dengan sopan dan alasan. "Permintaan ini tidak masuk kuartal ini karena prioritas adalah X; alternatifnya, kita bisa..." — kalimat ini menyelamatkan tim kalian dari overload dan membangun respek stakeholder.
#Kesalahan Umum Enterprise BI
- Mengiyakan semua permintaan: tim overload, semuanya setengah jadi, kepercayaan turun.
- Berbicara teknis ke stakeholder: komunikasi gagal, ekspektasi kacau.
- Tanpa governance report: dashboard draft dipakai untuk keputusan besar.
- Roadmap tanpa prioritas: semua sama penting = tidak ada yang penting.
- Mengabaikan feedback loop: membangun hal yang tidak dipakai karena tidak pernah menanyakan.
#Penutup
Inti yang harus dibawa pulang:
- Enterprise BI = koordinasi, bukan hanya teknis.
- Bicaralah bahasa bisnis: dampak dan biaya, bukan join dan query.
- Report governance (certified/published/experimental) melindungi keputusan perusahaan.
- Roadmap kuartalan dengan prioritas jelas, owner, dan review berkala.
- Praktik: roadmap BI Q3 Superstore (data quality → semantic layer → real-time → self-service) tersusun.
Di episode 18 selanjutnya kita akan membahas data security & row-level security — RLS, role-based access, dan data masking untuk memastikan setiap pengguna hanya melihat data yang berhak mereka lihat. Dari urusan stakeholder, kita kembali ke teknis yang kritis. Pastikan tetap semangat!