Level 3 — Data Termodel (Modeled / Trusted)
Ringkasan Level
Ini adalah level di mana data berubah dari "sekumpulan tabel mentah di satu tempat" menjadi representasi logika bisnis yang bisa dipercaya. Kata kuncinya adalah trust (kepercayaan). Organisasi menyepakati definisi metrik bersama ("apa itu 'unit terjual'? apa itu 'revenue'?"), data dimodelkan mengikuti struktur yang mencerminkan bagaimana bisnis benar-benar berjalan, dan mulai ada kontrol kualitas data yang sistematis.
Level 3 sering menjadi level tersulit untuk dicapai bukan karena tekniknya rumit, tapi karena butuh konsensus organisasi — menyatukan definisi yang berbeda-beda antar departemen adalah pekerjaan politik-organisasional, bukan cuma teknis.
Alur Dimensi Teknis: Dari Tabel Mentah ke Struktur yang Bermakna
Level 3 dimulai dari masalah yang muncul di akhir Level 2: warehouse sudah berisi data dari berbagai sumber, tapi strukturnya masih menyerupai salinan mentah dari source system masing-masing — belum mencerminkan bagaimana bisnis sebenarnya berpikir. Solusinya adalah Dimensional Modeling (Star Schema), teknik yang dibakukan Ralph Kimball lewat bukunya The Data Warehouse Toolkit [Kimball, 1996]: memisahkan data menjadi tabel fakta (kejadian terukur, mis. tiap transaksi penjualan unit) dan tabel dimensi (konteks yang menjelaskannya, mis. data unit, data pembeli, waktu). Dengan struktur ini, pertanyaan seperti "tipe unit apa paling laris di proyek mana pada kuartal berapa" bisa dijawab tanpa query yang rumit.
Tapi struktur yang rapi saja belum menjamin dua laporan menghasilkan angka yang sama — masalah yang sudah disinggung di akhir Level 2. Untuk itu dibutuhkan Metric Definition (Definisi Metrik Resmi): dokumentasi formal tentang bagaimana tepatnya suatu metrik dihitung, termasuk semua pengecualiannya. "Unit terjual" harus didefinisikan persis: dihitung sejak booking fee masuk, sejak akad, atau sejak serah terima kunci? Apakah unit yang batal setelah booking tetap dihitung? Ini adalah solusi definitif atas masalah "dua laporan beda angka" — bukan lagi karena datanya beda tempat (sudah selesai di Level 2), tapi karena sekarang cara menghitungnya disepakati sama.
Model dan definisi yang bagus tetap bisa rusak diam-diam kalau data yang masuk error — misalnya tiba-tiba ada nilai transaksi negatif yang tidak wajar, atau jumlah baris data harian anjlok drastis. Untuk mendeteksi ini sebelum sampai ke laporan, dibangun Data Quality Rules & Testing: aturan otomatis yang memvalidasi data dan memberi alert saat anomali terjadi.
Terakhir, model, definisi, dan quality rules yang sudah dibangun ini tidak berguna kalau tidak ada yang tahu keberadaannya. Maka disusun Data Catalog & Dokumentasi — katalog yang mencatat data apa saja yang tersedia, artinya, asalnya, dan siapa yang bisa dihubungi. Tanpa ini, warehouse yang sudah rapi secara teknis tetap sulit dipakai karena orang tidak tahu apa yang tersedia.
Alur Dimensi Organisasi: Dari Definisi ke Kesepakatan Bersama
Definisi metrik resmi tidak bisa dibuat sepihak oleh satu tim — kalau tim Finance mendefinisikan "revenue" berbeda dari tim Sales, masalah lama akan muncul lagi dalam bentuk baru. Karena itu dibutuhkan Data Governance: kerangka kebijakan dan forum formal (mis. rapat bulanan) tempat definisi metrik dan kebijakan data disepakati bersama lintas departemen — bukan lagi keputusan informal seperti Level 1-2. Kerangka kerja paling banyak dirujuk untuk area ini adalah DAMA-DMBOK [DAMA International, 2017], yang menempatkan Data Governance sebagai inti dari sebelas area pengetahuan manajemen data, termasuk pembakuan peran Data Owner dan Data Steward.
Untuk benar-benar menerjemahkan kebutuhan bisnis ke dalam model data yang presisi, dibutuhkan kapabilitas baru: Analytics Engineer — peran yang menjembatani Data Engineer (pembangun pipeline) dengan kebutuhan bisnis yang dimodelkan, menulis transformasi data yang mengikuti definisi metrik resmi yang sudah disepakati.
Dan karena sekarang keputusan tentang data melibatkan banyak pihak (Data Owner, Analytics Engineer, tim Legal untuk isu privasi, tim bisnis yang memakai), muncul kebutuhan RACI untuk Data — kejelasan siapa Responsible, Accountable, Consulted, Informed untuk tiap domain data, supaya proses governance di atas tidak berhenti di diskusi tanpa keputusan jelas.
Governance yang matang juga berarti siap menghadapi skenario terburuk, bukan cuma mengatur hari-hari normal. Kalau di Level 2 perusahaan baru mulai sadar soal aturan akses dan kepatuhan UU PDP, di Level 3 kesadaran itu perlu dituangkan jadi Prosedur Insiden/Kebocoran Data — langkah tertulis siapa dihubungi pertama kali, bagaimana investigasi awal dilakukan, dan kapan/bagaimana wajib melapor ke otoritas serta pihak yang terdampak begitu ada indikasi kebocoran. RACI untuk Data di atas adalah yang membuat prosedur ini bisa langsung dijalankan saat insiden benar-benar terjadi, bukan sekadar dokumen yang tidak pernah dibaca — tanpa kejelasan peran, insiden data biasanya baru direspons setelah dampaknya sudah menyebar luas.
Alur Dimensi Strategi: Dari Kesepakatan ke Kepercayaan Penuh
Hasil dari seluruh proses di atas — model yang rapi, definisi yang disepakati, quality control yang berjalan — adalah munculnya Trusted Insight ("Insight yang Pakem"): angka yang bisa diandalkan sebagai dasar keputusan tanpa keraguan. Ketika direksi melihat "tingkat pembatalan booking 5%", mereka tidak lagi bertanya "ini dihitung dari mana?" — karena definisi dan sumbernya sudah disepakati dan divalidasi. Inilah tujuan inti dari seluruh perjalanan Level 0 sampai Level 3.
Begitu ada metrik-metrik yang dipercaya, organisasi mulai bisa melihat bagaimana metrik-metrik itu saling berhubungan — disusun sebagai Metric Tree / KPI Hierarchy: metrik utama (North Star Metric) diturunkan menjadi metrik pendukung yang lebih granular (mis. Revenue = Jumlah Transaksi × Rata-rata Nilai Transaksi). Struktur ini membantu organisasi fokus pada metrik yang benar-benar penting dan memahami driver di baliknya — dan menjadi fondasi bagi Level 4, di mana insight ini mulai dipakai aktif dalam operasional sehari-hari, bukan cuma laporan sesekali.
Rujukan Istilah (Ringkas)
| Istilah | Definisi Singkat | Muncul Karena |
|---|---|---|
| Dimensional Modeling (Star Schema) | Model data fakta & dimensi mengikuti logika bisnis | Warehouse Level 2 masih menyerupai salinan mentah |
| Metric Definition | Dokumentasi formal cara suatu metrik dihitung | Struktur rapi belum menjamin angka konsisten antar laporan |
| Data Quality Rules & Testing | Validasi otomatis kualitas data dengan alert anomali | Model & definisi bisa rusak diam-diam kalau data masuk error |
| Data Catalog & Dokumentasi | Katalog data yang tersedia, artinya, dan asalnya | Model & definisi tidak berguna kalau tidak diketahui keberadaannya |
| Data Governance | Kerangka kebijakan & forum kesepakatan lintas departemen | Definisi metrik tidak bisa dibuat sepihak satu tim |
| Analytics Engineer | Peran pemodel data sesuai kebutuhan bisnis | Butuh kapabilitas menerjemahkan kebutuhan bisnis ke model presisi |
| RACI untuk Data | Kejelasan peran Responsible-Accountable-Consulted-Informed | Governance melibatkan banyak pihak, butuh kejelasan tanggung jawab |
| Prosedur Insiden/Kebocoran Data | Langkah tertulis menangani & melapor insiden data | Governance matang berarti siap hadapi skenario terburuk, bukan cuma hari normal |
| Trusted Insight ("Insight Pakem") | Angka yang diandalkan tanpa keraguan untuk keputusan | Hasil gabungan model, definisi, dan quality control yang matang |
| Metric Tree / KPI Hierarchy | Struktur hubungan metrik utama & metrik pendukung | Setelah metrik dipercaya, organisasi bisa melihat keterkaitannya |
Indikator Capaian Level 3
Checklist detail tersedia di:
- Untuk perusahaan:
/assessment/checklist-perusahaan.md— bagian Level 3 - Interpretasi untuk klien:
/assessment/interpretasi-perusahaan.md— bagian Level 3
Ringkasan capaian yang dicari di level ini:
- Ada dokumen definisi metrik resmi untuk metrik bisnis utama, disepakati lintas departemen (bukan hanya versi satu tim).
- Data warehouse sudah dimodelkan mengikuti struktur logika bisnis (bukan sekadar salinan mentah dari source system).
- Ada aturan/otomasi validasi kualitas data yang berjalan rutin, dengan mekanisme alert kalau ada anomali.
- Ada katalog/dokumentasi data yang bisa diakses tim terkait, minimal untuk domain data utama.
- Ada forum atau proses formal (governance) untuk membahas dan menyepakati perubahan definisi data/metrik.
- Ada prosedur tertulis langkah-langkah yang harus dilakukan kalau terjadi kebocoran/insiden data.
- Kejelasan peran (siapa bertanggung jawab apa) untuk tiap domain data sudah terdokumentasi.
Jebakan Umum di Level 3
- Membangun model data tanpa melibatkan pemilik bisnis — Analytics Engineer membuat model berdasarkan asumsi sendiri, hasilnya tidak sesuai kebutuhan riil dan ditolak/diabaikan pengguna bisnis.
- Governance jadi birokrasi yang memperlambat, bukan mempercepat — proses persetujuan definisi metrik jadi begitu berat sehingga tim malah kembali membuat metrik versi sendiri di luar sistem resmi.
- Terlalu banyak metrik didefinisikan sekaligus — lebih baik mulai dari metrik paling kritikal dan berkembang bertahap daripada mencoba mendefinisikan semuanya sekaligus.
- Quality rules dibuat tapi alert-nya diabaikan — tim kebanjiran notifikasi false positive sehingga alert penting jadi tidak diperhatikan ("alert fatigue").
Sinyal Siap Naik ke Level 4
- Trust terhadap data sudah cukup tinggi sehingga stakeholder mulai secara rutin bertanya "bagaimana caranya saya bisa lihat data ini sendiri?" — sinyal kebutuhan self-service.
- Insight dari data mulai dipakai bukan cuma untuk laporan retrospektif, tapi mulai ada permintaan untuk prediksi atau otomasi keputusan.
- Kualitas data sudah cukup stabil sehingga tim data bisa mulai fokus ke value creation (membangun kapabilitas baru), bukan lagi sibuk memadamkan kebakaran kualitas data.
Sumber rujukan istilah di halaman ini: lihat 09-daftar-pustaka.md.
Sebelumnya: 03-level-2-data-terhubung.md | Lanjut ke: 05-level-4-data-beroperasi.md