TL;DR
Data governance adalah kumpulan aturan soal siapa yang punya tiap dataset, siapa yang boleh akses, gimana kualitasnya dijaga, dan gimana satu angka didefinisikan. Buat tim kecil, cukup mulai dari empat hal: daftar dataset dengan pemiliknya, kamus metrik, aturan akses bertingkat, dan pemeriksaan kualitas data yang jalan otomatis.
Data governance adalah kumpulan aturan soal siapa yang punya tiap dataset, siapa yang boleh mengaksesnya, gimana kualitasnya dijaga, dan gimana satu angka didefinisikan.
Kedengeran kayak urusan perusahaan besar. Padahal masalah yang dia selesaiin itu masalah tim kecil banget: dua orang bikin laporan omzet, angkanya beda, dan nggak ada yang tau siapa yang benar.
Aku susun kerangka enam langkah yang bisa dijalanin tim 3 sampai 10 orang, tanpa alat berbayar.
Data governance adalah cara sebuah tim ngatur siapa bertanggung jawab atas data apa, aturan mainnya gimana, dan siapa yang berhak mutusin kalau ada perbedaan. Isinya empat hal utama: kepemilikan data, hak akses, standar kualitas, dan definisi metrik. Tujuannya satu, biar angka yang keluar dari sistem bisa dipercaya dan konsisten antar tim.
Yang sering disalahpahami: governance bukan alat, dan bukan jabatan. Dia dokumen plus kebiasaan.
Tanda tim kamu butuh ini sekarang juga:
penjualan_final_v2 itu isinya apa dan siapa yang bikinKalau tiga dari empat tanda itu ada, kamu udah telat sebulan.
Karena biayanya kelihatan di depan dan manfaatnya kelihatan belakangan. Nyusun katalog dataset makan waktu dua hari, dan hasilnya nggak nambah satu grafik pun ke dashboard.
Biayanya baru kelihatan waktu ada masalah. Di satu tim yang aku bantu, rapat direksi sempat tertunda dua minggu cuma gara-gara angka omzet dari tim keuangan dan tim penjualan selisih Rp340 juta. Setelah ditelusuri, penyebabnya sepele: satu tim ngitung omzet sebelum retur, satu lagi sesudah retur.
Dua definisi, dua angka, dua minggu terbuang. Satu baris di kamus metrik bisa nyegah itu.
Satu spreadsheet, enam kolom. Ini pondasi semuanya.
| Kolom | Contoh isi |
|---|---|
| nama_tabel | fct_penjualan_harian |
| isi_singkat | Ringkasan penjualan per hari per cabang |
| sumber | Sistem kasir, tarik jam 01.00 tiap hari |
| pemilik_bisnis | Rina, Kepala Penjualan |
| penanggung_jawab_teknis | Adi, Data Engineer |
| tingkat_sensitivitas | Internal |
Dua kolom pemilik itu yang paling penting, dan yang paling sering digabung jadi satu. Jangan digabung. Pemilik bisnis nentuin arti datanya, penanggung jawab teknis mastiin pipeline-nya jalan.
Isi dulu 20 tabel yang paling sering dipakai. Sisanya nyusul.
Kamus metrik adalah daftar definisi resmi tiap angka yang dipakai perusahaan. Satu metrik, satu definisi, satu rumus, satu pemilik. Ini dokumen yang paling cepat ngasih hasil, soalnya sebagian besar pertengkaran soal angka sebenernya pertengkaran soal definisi.
Formatnya:
Nama metrik : Omzet bersih
Definisi : Total nilai transaksi setelah dikurangi retur dan diskon,
sebelum pajak
Rumus : SUM(nilai_transaksi) - SUM(nilai_retur) - SUM(diskon)
Sumber : fct_penjualan_harian
Pemilik : Rina, Kepala Penjualan
Dipakai di : Dashboard Direksi, Laporan Bulanan Cabang
Catatan : Transaksi batal tidak dihitung sama sekali,
bukan dihitung sebagai returBaris Catatan itu yang nyelamatin. Di situ kamu simpan semua kasus khusus yang biasanya cuma ada di kepala satu orang.
Mulai dari 10 metrik yang paling sering muncul di rapat. Kalau kamu belum familiar sama istilah metrik dan KPI, dua halaman itu bisa jadi pijakan.
Tiga tingkat udah cukup buat tim kecil:
Aturan praktisnya: kolom sensitif jangan pernah ada di lingkungan pengembangan dalam bentuk asli. Samarkan jadi 0812****7789 sebelum data disalin ke tempat latihan atau uji coba.
Ini bukan cuma soal rapi. Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi ngatur bahwa data pribadi cuma boleh dipakai sesuai tujuan yang disetujui pemiliknya, dan wajib dijaga keamanannya. Buat tim data, artinya akses harus dibatasi dan dicatat.
Aturan tanpa pemeriksaan itu cuma niat baik. Empat pemeriksaan ini yang paling banyak nangkap masalah:
Kalau kamu udah pakai dbt, empat pemeriksaan itu bawaan dan tinggal ditulis di file yaml. Caranya aku tulis di dbt tests buat cegah angka salah.
Kalau belum, bikin query pemeriksaan yang jalan tiap pagi dan kirim hasilnya ke chat tim. Sederhana pun nolong.
Pemeriksaan ini yang bikin standar kualitas data beneran jalan, bukan cuma tertulis di dokumen.
Tiga hal yang wajib punya riwayat:
Kode transformasi. Taruh di Git. Semua perubahan SQL harus lewat pull request, bahkan kalau reviewernya cuma satu orang.
Definisi metrik. Kalau definisi omzet bersih berubah, catat tanggal berlakunya. Tanpa ini, angka historis kamu jadi campuran dua definisi dan nggak bisa dibandingin.
Perubahan skema. Kolom yang dihapus atau diganti nama harus diumumkan sebelum dieksekusi. Dashboard yang tiba-tiba kosong biasanya korban kolom yang diganti nama diam-diam.
Ini langkah yang paling sering dilewat, dan yang paling bikin governance mandek.
Kalau tim penjualan mau ubah definisi omzet dan tim keuangan nggak setuju, siapa yang mutusin? Tulis namanya. Satu orang, bukan komite.
Buat tim di bawah 10 orang, biasanya cukup satu penanggung jawab data yang punya wewenang mutusin definisi, plus rapat 30 menit sebulan sekali buat bahas usulan perubahan.
Toko_berkah punya tim data isi 4 orang buat 12 cabang. Sebelum ada aturan main, ini kondisinya:
Yang mereka kerjain dalam dua minggu: katalog 20 tabel utama, kamus 12 metrik, tiga tingkat akses, dan 24 pemeriksaan kualitas data yang jalan tiap pagi.
Hasilnya setelah tiga bulan:
| Ukuran | Sebelum | Sesudah |
|---|---|---|
| Tabel tanpa pemilik | 19 | 0 |
| Versi laporan omzet | 3 | 1 |
| Waktu jawab pertanyaan angka | 2 hari | 2 jam |
| Masalah data ketahuan sebelum masuk dashboard | Nggak pernah | 17 kali dalam 3 bulan |
Baris terakhir itu yang paling berharga. Tujuh belas kali angka salah ketahan sebelum sampai ke mata direksi.
Total waktu yang dihabiskan buat nyusun semuanya: sekitar 26 jam kerja, dibagi 4 orang selama 2 minggu.
1. Bikin dokumen 40 halaman di awal. Nggak ada yang baca. Mulai dari satu spreadsheet katalog dan satu kamus metrik.
2. Nunjuk data engineer sebagai pemilik semua data. Dia nggak tau arti bisnis dari kolom status_pelanggan. Pemilik harus orang bisnis.
3. Beli alat katalog sebelum punya kebiasaan. Alat mahal yang isinya kosong nggak nolong apa-apa.
4. Nggak nentuin pengambil keputusan. Tanpa ini, setiap perbedaan definisi berakhir jadi rapat tanpa kesimpulan.
5. Ngeskip penyamaran data sensitif di lingkungan uji. Ini yang paling berisiko secara hukum, dan paling gampang diperbaiki.
6. Nulis definisi metrik tanpa catatan kasus khusus. Justru kasus khusus yang bikin dua orang dapat angka beda.
7. Mikir governance selesai setelah dokumennya jadi. Kamus metrik yang nggak diperbarui 6 bulan lebih berbahaya dari nggak punya, soalnya orang percaya sama isinya.
Butuh, tapi versi ringan. Yang kamu perlu cuma dua dokumen: daftar dataset dengan pemiliknya, dan kamus metrik. Dua-duanya muat di satu spreadsheet dan bisa disusun dalam sehari. Justru tim kecil yang paling rugi kalau nggak punya, soalnya satu orang keluar bisa bikin separuh pengetahuan soal data ikut hilang.
Data quality itu soal kondisi datanya: lengkap, akurat, konsisten, atau nggak. Data governance itu soal aturan mainnya: siapa yang tanggung jawab kalau datanya jelek, siapa yang boleh ngubah, dan gimana keputusannya diambil. Kualitas data itu salah satu hasil dari governance yang jalan, bukan hal yang sama.
Buat tim di bawah 10 orang, nggak perlu. Spreadsheet buat katalog dan kamus metrik, Git buat riwayat perubahan kode transformasi, plus test bawaan dbt buat kualitas data. Itu udah nutup sebagian besar kebutuhan. Alat katalog berbayar baru masuk akal kalau jumlah tabelnya udah ratusan dan penggunanya lintas divisi.
Orang yang paling paham arti datanya, bukan yang paling jago teknisnya. Data penjualan sebaiknya dimiliki kepala penjualan, bukan data engineer. Engineer tanggung jawab soal pipeline-nya jalan, pemilik tanggung jawab soal definisi dan kebenaran isinya. Kalau dua peran ini dicampur ke satu orang teknis, definisinya sering meleset dari kenyataan bisnis.
Indonesia punya Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi. Intinya, data pribadi pelanggan cuma boleh dikumpulin dan dipakai sesuai tujuan yang disetujui, dan harus dijaga keamanannya. Buat tim data, konsekuensi praktisnya: batasi akses ke kolom sensitif, samarkan nomor telepon dan NIK di lingkungan pengembangan, dan catat siapa mengakses apa.
Tiga hal buat dikerjain minggu ini:
Buat gambaran kerangka yang lebih lengkap beserta istilah bakunya, penjelasan Google Cloud soal data governance cukup rapi dan netral.
Kalau kamu lagi mikirin di mana semua data ini disimpan, mampir ke bahasan data lake, warehouse, dan lakehouse.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.