Level 2 — Data Terhubung (Integrated / Warehouse)
Ringkasan Level
Ini adalah titik balik teknis paling penting dalam perjalanan maturity data: perusahaan mulai memindahkan data dari berbagai source system ke satu tempat pusat secara otomatis dan rutin (bukan manual export-import lagi). Muncul istilah seperti data warehouse, pipeline, ETL/ELT. Ini level di mana peran "Data Engineer" biasanya mulai dibutuhkan secara eksplisit.
Penting dicatat: di level ini data belum tentu bersih atau termodel dengan baik — ia baru "terhubung" secara fisik/lokasi. Kualitas dan kepercayaan terhadap data adalah pekerjaan Level 3.
Alur Dimensi Teknis: Dari Kelelahan Manual ke Otomasi Terpusat
Level 2 dimulai persis dari titik sakit yang muncul di akhir Level 1: proses Manual Export-Import yang makin lama makin tidak tertahankan. Solusinya adalah membangun Pipeline Data (ETL/ELT) — proses otomatis yang mengambil data dari tiap source system (Extract), mengubah formatnya bila perlu (Transform), lalu menyimpannya di satu tempat (Load). Alih-alih staf finance mengunduh dan menggabung file tiap akhir bulan, sebuah job berjalan sendiri setiap malam tanpa campur tangan manual.
Tempat tujuan pipeline ini adalah Data Warehouse / Data Lake — rumah tunggal bagi data dari berbagai source system, sebuah konsep yang dibakukan oleh Bill Inmon lewat bukunya Building the Data Warehouse [Inmon, 1990], yang juga memperkenalkan gagasan data warehouse sebagai "single version of the truth" bagi organisasi. Data Warehouse cocok untuk data terstruktur yang dioptimalkan untuk analisis; Data Lake lebih fleksibel, bisa menampung data mentah terstruktur maupun tidak terstruktur. Begitu warehouse ini berjalan, pertanyaan lama "data terstruktur vs tidak terstruktur" dari Level 1 sekarang punya konsekuensi nyata: keduanya perlu strategi penyimpanan yang berbeda dalam satu ekosistem yang sama.
Karena pipeline berjalan otomatis dan terjadwal, muncul pertanyaan baru yang di Level 1 tidak relevan: seberapa sering data ini di-update? Ini disebut Data Freshness & Latency — apakah data warehouse mencerminkan kejadian satu hari lalu, satu jam lalu, atau real-time. Konsultan perlu menyepakati ekspektasi ini dengan bisnis, karena freshness yang lebih tinggi selalu berarti biaya dan kompleksitas yang lebih besar — tidak semua use case butuh data real-time.
Alur Dimensi Organisasi: Dari Sentralisasi Data ke Kebutuhan Kendali Baru
Memindahkan data ke satu tempat pusat butuh seseorang yang membangun dan merawat pipeline itu sendiri — inilah kelahiran peran Data Engineer secara eksplisit (bisa internal atau outsourced). Tanpa peran ini, pipeline yang tidak dirawat akan diam-diam rusak dan menghasilkan data yang menyesatkan tanpa ada yang sadar.
Karena sekarang data dari berbagai domain (penjualan, keuangan, pelanggan) sekarang hidup berdampingan di satu warehouse, peran Data Steward informal dari Level 1 tidak lagi cukup — dibutuhkan Data Owner (Formal), individu/tim dengan tanggung jawab jelas atas kualitas dan definisi suatu domain data — peran yang dibakukan dalam kerangka kerja DAMA-DMBOK [DAMA International, 2017] sebagai pihak yang akuntabel atas keputusan terkait suatu domain data, berbeda dari Data Custodian yang menangani perawatan teknisnya — karena sekarang keputusan tentang domain itu (mis. "apakah 'unit terjual' dihitung sejak booking fee masuk atau sejak akad?") berdampak ke banyak tim sekaligus yang mengakses warehouse yang sama.
Sentralisasi data juga menciptakan risiko baru yang tidak ada saat data masih tersebar: kebocoran data jadi jauh lebih berdampak karena semua ada di satu lokasi. Inilah yang mendorong kebutuhan Access Control & Data Security Dasar — aturan siapa boleh mengakses data apa, terutama data sensitif pelanggan (PII). Ini prasyarat kepercayaan organisasi terhadap warehouse itu sendiri — tanpa kendali akses yang jelas, tim enggan menaruh data sensitif ke tempat pusat.
Begitu data pelanggan (KTP, riwayat keuangan, nomor kontak) ikut tersentralisasi di warehouse, kewajiban hukum yang sebelumnya terasa abstrak jadi konkret: Kepatuhan Data Pribadi (UU PDP) — di Indonesia, UU Perlindungan Data Pribadi No. 27/2022 mewajibkan pengendali data punya dasar hukum yang sah untuk memproses data pribadi (umumnya consent eksplisit), serta melaporkan insiden kebocoran ke otoritas dan pihak terdampak. Ini bukan proyek terpisah dari access control di atas — keduanya saling menopang: aturan akses yang jelas adalah pondasi teknis, kepatuhan UU PDP adalah kewajiban hukumnya. Perusahaan yang baru sadar soal ini di Level 4-5, setelah data sudah tersebar dipakai banyak sistem, akan jauh lebih mahal membenahinya dibanding menanamkannya sejak warehouse pertama kali dibangun.
Alur Dimensi Strategi: Dari Satu Tempat ke Satu Kebenaran (yang Belum Sempurna)
Dengan data tersentralisasi di satu warehouse, untuk pertama kalinya muncul Single Source of Truth (SSOT) — Versi Awal: satu tempat rujukan tunggal yang menggantikan versi-versi data berbeda di tiap departemen — gagasan yang secara langsung berakar dari konsep "single version of the truth" milik Inmon [Inmon, 1990]. Ini secara langsung mengurangi fenomena "dua orang beda jawaban" dari Level 0 — karena sekarang semua menarik data dari lokasi yang sama.
Namun SSOT versi awal ini punya batas: lokasi datanya sama, tapi maknanya belum tentu. Yang jelas berubah secara nyata adalah Kecepatan Menjawab Pertanyaan Bisnis (Time-to-Insight) — pertanyaan yang dulu butuh dua hari sekarang bisa dijawab dalam hitungan menit lewat query ke warehouse. Ini adalah bukti ROI paling konkret dan mudah dikomunikasikan ke stakeholder non-teknis. Tapi justru karena kecepatan ini, celah baru mulai terlihat: makin cepat orang bisa query data mentah, makin cepat pula muncul keluhan "kok angka laporan saya beda dengan laporan si A" — karena definisi metrik belum disepakati. Inilah pintu masuk ke Level 3.
Rujukan Istilah (Ringkas)
| Istilah | Definisi Singkat | Muncul Karena |
|---|---|---|
| Pipeline Data (ETL/ELT) | Proses otomatis extract-transform-load data | Manual Export-Import di Level 1 tidak lagi tertahankan |
| Data Warehouse / Data Lake | Tempat penyimpanan pusat untuk analisis | Pipeline butuh tujuan akhir yang tersentralisasi |
| Data Freshness & Latency | Seberapa "baru" data warehouse dibanding kejadian asli | Pipeline berjalan terjadwal, muncul pertanyaan seberapa sering |
| Data Engineer | Peran pembangun & pemelihara pipeline dan warehouse | Pipeline & warehouse butuh yang merawat agar tidak diam-diam rusak |
| Data Owner (Formal) | Penanggung jawab formal kualitas & definisi domain data | Banyak tim sekarang berbagi warehouse yang sama |
| Access Control & Data Security Dasar | Aturan siapa boleh akses data apa | Sentralisasi data menciptakan risiko kebocoran baru |
| Kepatuhan Data Pribadi (UU PDP) | Kewajiban hukum mengelola data pribadi secara sah | Data pelanggan ikut tersentralisasi, kewajiban jadi konkret |
| Single Source of Truth (SSOT) Awal | Satu tempat rujukan tunggal, versi belum sempurna | Data tersentralisasi mengurangi (belum menghilangkan) versi berbeda |
| Time-to-Insight | Kecepatan menjawab pertanyaan bisnis dengan data | Query langsung ke warehouse jauh lebih cepat dari proses manual |
Indikator Capaian Level 2
Checklist detail tersedia di:
- Untuk perusahaan:
/assessment/checklist-perusahaan.md— bagian Level 2 - Interpretasi untuk klien:
/assessment/interpretasi-perusahaan.md— bagian Level 2
Ringkasan capaian yang dicari di level ini:
- Ada satu tempat pusat (warehouse/lake) tempat data dari minimal sumber-sumber utama bisnis (penjualan, keuangan, operasional) disatukan.
- Proses pemindahan data ke tempat pusat ini berjalan otomatis dan terjadwal, bukan manual export-import.
- Ada pemantauan (monitoring) sederhana untuk mengetahui kalau pipeline gagal berjalan.
- Sudah ada Data Owner formal untuk minimal domain data utama.
- Ada aturan dasar siapa boleh akses data apa, terutama data sensitif pelanggan.
- Perusahaan sudah memahami kewajiban dasar UU Perlindungan Data Pribadi (PDP) dan mulai menyesuaikan cara menyimpan/memakai data pelanggan.
- Waktu untuk menjawab pertanyaan bisnis lintas-sumber sudah berkurang signifikan dibanding sebelumnya.
Jebakan Umum di Level 2
- "Data lake" jadi "data swamp" — semua data ditumpuk mentah tanpa struktur maupun dokumentasi, sehingga sulit dipakai walau secara teknis sudah "terhubung".
- Membangun pipeline tanpa monitoring — pipeline diam-diam gagal berminggu-minggu dan tidak ada yang sadar sampai laporan terlihat aneh.
- Terlalu fokus infrastruktur, lupa people & process — investasi besar ke tools tapi tidak ada yang jadi Data Owner, sehingga kualitas data tetap rendah walau lokasinya sudah tersentralisasi.
- Memilih tools yang terlalu kompleks untuk skala bisnis saat ini — over-engineering yang membuat biaya maintenance tidak sepadan dengan manfaat.
Sinyal Siap Naik ke Level 3
- Data sudah konsisten mengalir ke warehouse, tapi mulai muncul keluhan "angkanya beda antara laporan A dan laporan B" — pertanda butuh pemodelan dan definisi metrik formal.
- Tim mulai butuh mengakses data warehouse langsung untuk analisis (bukan cuma lewat laporan jadi), tapi kesulitan karena struktur data masih mentah dan sulit dipahami.
- Ada kebutuhan bisnis yang jelas untuk metrik standar yang dipakai bersama lintas departemen (mis. definisi "unit terjual" yang sama untuk semua tim).
Sumber rujukan istilah di halaman ini: lihat 09-daftar-pustaka.md.
Sebelumnya: 02-level-1-data-tercatat.md | Lanjut ke: 04-level-3-data-termodel.md