Episode ini membahas demokratisasi data: self-service BI, semantic layer, dan business glossary. Kalian akan memahami arsitektur yang memungkinkan non-analis menjawab pertanyaan data sendiri, dan praktik mendokumentasikan metrik serta glossary bisnis yang menjadi fondasinya

Seiring pertumbuhan perusahaan, ada satu masalah yang tidak bisa dihindari: semua orang ingin bertanya ke data, tetapi tidak semua orang bisa menulis SQL. Tanpa sistem yang benar, analis menjadi bottleneck — antrean pertanyaan menumpuk, jawaban terlambat, dan angka yang sama dijawab berbeda oleh lima orang.
Solusinya adalah self-service BI: membangun lapisan data yang memungkinkan non-analis menjawab pertanyaan sendiri, dengan semantic layer sebagai terjemahan dari data teknis ke bahasa bisnis. Episode ini membedah arsitekturnya, peran business glossary, dan praktik mendokumentasikan metrik yang menjadi fondasi seluruh sistem.
Pola yang tidak sehat dan sangat umum:
Setiap departemen menyerbu analis untuk pertanyaan yang sebagian besar serupa. Hasilnya: analis tidak sempat analisis sungguhan, dan jawaban lambat untuk semua. Self-service BI memecah pola ini — bukan dengan melarang pertanyaan, tetapi dengan memberi alat yang aman untuk menjawab sendiri.
Lapisan pentingnya: pengguna bisnis tidak pernah menyentuh warehouse mentah — mereka berinteraksi dengan semantic layer lewat BI tool. Definisi metrik dikendalikan pusat, sehingga angka "revenue" sama di semua dashboard.
Semantic layer adalah lapisan definisi yang menerjemahkan data mentah ke bahasa bisnis: metrik (revenue, churn, CAC), dimensi (produk, region, bulan), dan relasinya. Tanpa semantic layer, tiap dashboard mendefinisikan metriknya sendiri — hasilnya adalah lima angka "revenue" yang berbeda.
Konsep intinya:
| Konsep | Arti | Contoh |
|---|---|---|
| Metric | Ukuran yang terstandar | Revenue, AOV, churn rate |
| Dimension | Cara memecah/grouping | Produk, region, bulan |
| Definition | Rumus tunggal | SUM(amount) WHERE status='completed' |
| Filter | Konteks default | exclude refunded |
Contoh definisi metrik yang terdokumentasi (memakai dbt MetricFlow atau tool semantic layer lain):
metrics:
- name: revenue
description: "Total order completed, eksklusif refund, dalam IDR"
type: sum
sql: amount
filters:
- status = 'completed'
- name: active_customers
description: "Customer unik yang melakukan order completed"
type: count_distinct
sql: customer_id
filters:
- status = 'completed'Sekarang, siapa pun yang membangun dashboard memakai revenue yang sama — pertanyaan "definisi revenue yang mana?" tidak lagi muncul.
Tip
Perhatikan peran analis di sini: bukan lagi menulis dashboard per departemen, tetapi membangun fondasi (model dbt + semantic layer) yang dipakai semua orang. Inilah pergeseran dari "report builder" menjadi "platform builder" — dan alasan analis yang menguasai dbt (episode 17) sangat dicari.
Business glossary adalah dokumen yang mendefinisikan istilah bisnis dalam bahasa yang dipahami semua orang — bukan SQL, bukan jargon teknis.
Istilah : Churn Rate
Definisi : Persentase pelanggan aktif yang tidak melakukan
pembelian dalam 30 hari terakhir.
Rumus : Pelanggan hilang / pelanggan aktif awal periode
Satuan : Persen (%)
Pemilik : Growth Analytics
Sumber : tabel fct_customer_monthly (dbt)
Update : Harian, H+1Glossary yang baik: satu definisi per istilah, ditulis untuk non-analis, dan ditautkan ke sumber teknis. Ini dokumen "hidup" yang diperbarui saat definisi bisnis berubah — bukan PDF yang disimpan di laci.
Untuk tim kalian, mulailah dari tiga metrik paling sering ditanyakan:
Langkah kerja:
1. Tulis definisi untuk tiap metrik (bahasa manusia dulu).
2. Terjemahkan ke definisi teknis (SQL/dbt/garis besar).
3. Dokumentasikan di satu tempat yang bisa diakses tim.
4. Verifikasi angka — cocokkan dengan query yang sudah dikenal.
5. Tautkan ke dashboard: pastikan dashboard memakai definisi yang sama.Lima langkah ini adalah investasi satu hari yang membayar puluhan jam per bulan.
Bagaimana tahu self-service BI berhasil? Metrik keberhasilannya:
| Metrik | Kondisi sehat |
|---|---|
| Persentase pertanyaan dijawab self-service | Meningkat seiring waktu |
| Waktu tanya-jawab rata-rata | Turun drastis |
| Angka "revenue" antar dashboard | Konsisten (satu definisi) |
| Waktu analis untuk deep analysis | Naik (karena tak lagi jadi penjawab query) |
Tanda keberhasilan tertinggi: analis tidak lagi menerima pertanyaan "berapa revenue bulan ini?" — karena orang sudah bisa menjawab sendiri, dan analis bisa fokus pada pertanyaan "kenapa revenue turun dan apa yang harus dilakukan?"
Inti yang harus dibawa pulang:
Di episode 24 selanjutnya kita mengotomasi semuanya: Otomasi Report & Scheduling — scheduled dashboard, email report, pipeline refresh dengan Airflow atau cloud scheduler, plus praktik mengotomasi laporan harian. Fondasi data sudah solid; sekarang data bekerja untuk kalian bahkan saat kalian tidur!