# BAB 7 — *Business Intelligence* dan Analitik Bisnis


```
Bagian          : III — Data, Informasi & Pengambilan Keputusan
Reader Outcome  : Pembaca mampu menginterpretasikan insight dari dashboard BI,
                  membedakan tipe analitik (deskriptif/diagnostik/prediktif/
                  preskriptif), dan mengevaluasi relevansinya untuk keputusan
                  manajerial.
Level           : Lanjutan
Estimasi Halaman: 18–24
```

---

## 7.1 Pembuka

Bab 6 memperkenalkan model keputusan Simon dan peran DSS sebagai *co-pilot* manajer. Template A.6 membantu Anda memetakan keputusan organisasi ke dalam tipologi terstruktur–semi-terstruktur–tidak terstruktur beserta *gap* informasinya. Tetapi pertanyaannya belum terjawab: dari mana *insight* yang mengisi *gap* informasi itu datang? Bagaimana data mentah — yang sudah dijamin kualitasnya di Bab 5 — berubah menjadi visualisasi, prediksi, dan rekomendasi yang bisa ditindaklanjuti?

Netflix membangun sistem rekomendasi yang diestimasi menghemat ratusan juta dolar per tahun dari penurunan *churn* — dan kini melayani lebih dari 260 juta pelanggan. Angka itu bukan keajaiban teknologi — ia adalah hasil evolusi analitik selama 15 tahun: dari laporan DVD rental sederhana (deskriptif) ke sistem yang memutuskan konten apa yang harus diproduksi (preskriptif). Di mana posisi organisasi Anda dalam spektrum analitik ini?

Bagaimana *Business Intelligence* dan analitik bisnis mengubah data organisasi menjadi *insight* yang bisa ditindaklanjuti — dan mengapa manajer harus memahami perbedaan antara analitik deskriptif, diagnostik, prediktif, dan preskriptif?

---

## 7.2 Model Utama

### Gambar 7.1 — Spektrum Analitik Bisnis: Empat Tipe dari Deskriptif ke Preskriptif

```mermaid
graph LR
    DESC["📊 DESKRIPTIF<br/>Apa yang terjadi?"]
    DIAG["🔍 DIAGNOSTIK<br/>Mengapa terjadi?"]
    PRED["🔮 PREDIKTIF<br/>Apa yang akan terjadi?"]
    PRES["🎯 PRESKRIPTIF<br/>Apa yang harus dilakukan?"]

    DESC -->|"+drill-down"| DIAG
    DIAG -->|"+forecasting"| PRED
    PRED -->|"+optimization"| PRES

    V["← Nilai Rendah ———— Nilai Tinggi →"]
    C["← Kompleksitas Rendah ——— Kompleksitas Tinggi →"]

    style DESC fill:#d4a574,color:#000000
    style DIAG fill:#b5793a,color:#ffffff
    style PRED fill:#8c4a1a,color:#ffffff
    style PRES fill:#5c2e0a,color:#ffffff
    style V fill:#ffffff,stroke:#8c4a1a,color:#8c4a1a
    style C fill:#ffffff,stroke:#8c4a1a,color:#8c4a1a
```

**Gambar 7.1 — Spektrum Analitik Bisnis: dari deskriptif (nilai rendah, kompleksitas rendah) ke preskriptif (nilai tinggi, kompleksitas tinggi). Gradasi warna mencerminkan peningkatan kematangan.**

Empat tipe analitik membentuk spektrum — bukan daftar pilihan. Setiap level membangun di atas fondasi level sebelumnya. Organisasi tidak bisa melompat ke prediktif tanpa deskriptif yang kuat, sama seperti Anda tidak bisa menjawab "mengapa terjadi?" jika belum tahu "apa yang terjadi?"

1. **Deskriptif** — Menjawab "apa yang terjadi?" melalui *reporting*, *dashboard* KPI, dan ringkasan historis. Ini adalah fondasi BI: tanpa ini, analitik lanjutan tidak mungkin. Contoh: "Penjualan Q1 turun 12% dibanding Q1 tahun lalu."

2. **Diagnostik** — Menjawab "mengapa terjadi?" melalui *drill-down analysis*, identifikasi *root cause*, dan korelasi antar-variabel. Contoh: "Penjualan turun karena *lead time* pengiriman naik 40% di region Jawa akibat masalah logistik mitra."

3. **Prediktif** — Menjawab "apa yang akan terjadi?" melalui *forecasting*, *machine learning*, dan proyeksi tren. Contoh: "Jika tren *lead time* berlanjut, penjualan Q2 diprediksi turun 18% dengan *confidence interval* 72%."

4. **Preskriptif** — Menjawab "apa yang harus dilakukan?" melalui *optimization*, *recommendation engine*, dan simulasi skenario. Contoh: "Untuk memulihkan penjualan, alokasikan 20% *budget* marketing ke region Jawa dan tambahkan 2 *distribution center* — simulasi menunjukkan ini mengembalikan *lead time* dalam 45 hari."

Semakin ke kanan pada spektrum, nilainya semakin tinggi — tetapi kebutuhan data, investasi teknologi, dan kompetensi SDM juga semakin besar. Kebanyakan organisasi masih beroperasi di sisi kiri: hanya 21% organisasi yang mencapai level prediktif-preskriptif (Gartner, 2023).

---

## 7.3 Definisi Kunci

📌 ***Business Intelligence* (BI)**
Kombinasi teknologi, proses, dan praktik yang mengubah data mentah menjadi informasi bermakna yang dapat ditindaklanjuti untuk pengambilan keputusan (Sharda et al., 2024).
**Relevansi manajerial:** BI bukan *tools* IT — ia adalah kapabilitas organisasi yang menjadi jembatan antara *data warehouse* dan ruang rapat manajer. Manajer adalah konsumen utama BI, bukan tim IT. Jika *output* BI tidak bisa dipahami dan ditindaklanjuti oleh manajer, investasi BI gagal.

---

📌 ***Data Warehouse***
Repositori data terpusat yang mengkonsolidasikan data dari berbagai sumber operasional (ERP, CRM, SCM) ke dalam format yang dioptimalkan untuk analisis dan pelaporan, bukan untuk transaksi (Laudon & Laudon, 2022).
**Relevansi manajerial:** Manajer tidak perlu membangun *data warehouse*, tetapi perlu memahami bahwa kualitas *insight* BI bergantung langsung pada kualitas dan kelengkapan data di *warehouse*. "Jika *data warehouse*-nya kotor, *dashboard*-nya bohong" — prinsip *garbage in, garbage out* dari Bab 5 berlaku penuh di sini.

---

📌 **ETL (*Extract, Transform, Load*)**
Proses mengekstrak data dari berbagai sumber, mentransformasikannya ke format standar, dan memuatnya ke *data warehouse* untuk analisis (Sharda et al., 2024).
**Relevansi manajerial:** ETL adalah alasan di balik keluhan "'angka di *dashboard* berbeda dari angka di Excel divisi saya." Jika proses transformasi tidak transparan dan tidak terdokumentasi, manajer kehilangan kepercayaan pada BI — dan kembali ke *spreadsheet* masing-masing.

---

📌 **Analitik Prediktif (*Predictive Analytics*)**
Penggunaan teknik statistik, *machine learning*, dan *data mining* untuk mengidentifikasi pola dari data historis dan memproyeksikan kemungkinan di masa depan (Davenport, 2023).
**Relevansi manajerial:** Prediksi bukan ramalan. Manajer harus membaca *output* prediktif sebagai "kemungkinan 78% bahwa X terjadi," bukan "X pasti terjadi." Ketidakpastian harus dikomunikasikan secara eksplisit — menyembunyikan *confidence interval* adalah bentuk manipulasi data.

---

## 7.4 Konsep Inti

### 7.4.1 Ekosistem BI: Dari *Data Warehouse* ke *Insight* Bisnis

BI bukan satu *software* — ia adalah ekosistem yang mencakup *data warehouse*, proses ETL, *OLAP cubes*, *reporting tools*, dan platform visualisasi. Memahami alur ini penting bagi manajer karena menentukan di mana masalah muncul ketika "angka di *dashboard* tidak masuk akal."

Alur BI: **Sumber Data** (ERP, CRM, data eksternal) → **ETL** (ekstraksi, pembersihan, standarisasi) → ***Data Warehouse*** (penyimpanan terpusat, terstruktur untuk analisis) → **Analitik** (*OLAP*, model statistik, *ML*) → **Visualisasi** (*dashboard*, laporan) → **Keputusan** manajerial.

Investasi global dalam platform BI dan kapabilitas analitik terus mengalami pertumbuhan substansial, didorong oleh adopsi *cloud* dan meningkatnya permintaan analitik di seluruh industri (Gartner, 2023). Pertumbuhan ini menunjukkan bahwa organisasi semakin serius meninvestasikan kapabilitas analitik — tetapi investasi di *tools* tanpa investasi di kualitas data dan *data literacy* SDM sering menghasilkan infrastruktur BI yang mahal tetapi tidak dimanfaatkan.

### 7.4.2 Arsitektur BI: Mengapa "Angka Tidak Cocok"

Keluhan paling umum manajer: "Angka di *dashboard* berbeda dari laporan Excel saya." Gartner (2023) menemukan bahwa 46% keluhan terhadap BI berkaitan dengan data yang "tidak *up-to-date*" atau "tidak cocok." Kedua masalah ini berakar di arsitektur ETL, bukan di *dashboard*.

**Mengapa angka berbeda?**
- ETL memproses data secara berkala (*batch*) — bukan *real-time*. *Dashboard* yang diperbarui setiap 6 jam akan menunjukkan angka berbeda dari *spreadsheet* yang baru di-*update* 10 menit lalu.
- Transformasi data mengubah definisi. "Pendapatan" di ERP bisa berarti *gross revenue*; di *warehouse*, setelah transformasi, bisa menjadi *net revenue* setelah retur. Jika manajer tidak memahami definisi metrik di *dashboard*, angkanya terasa "salah."
- Data dari sumber berbeda bisa konflik. CRM mencatat pelanggan A sebagai "Jakarta Selatan"; ERP mencatatnya sebagai "Jaksel." Tanpa standarisasi di ETL, keduanya menjadi entitas terpisah.

Manajer tidak perlu menguasai teknis ETL, tetapi harus bertanya: "Kapan data ini terakhir di-*update*?", "Bagaimana 'pendapatan' didefinisikan di *dashboard* ini?", dan "Apakah data dari semua sumber sudah terkonsolidasi?" Tiga pertanyaan ini mencegah sebagian besar kesalahan interpretasi.

### 7.4.3 Empat Tipe Analitik: Dari "Apa" ke "Harus Apa"

Setiap tipe analitik menjawab pertanyaan berbeda dan membutuhkan investasi yang berbeda. Organisasi yang hanya di level deskriptif "tahu apa yang terjadi tetapi tidak tahu mengapa, apalagi apa yang akan terjadi." Alokasi investasi yang tepat menjadi krusial.

| Tipe | Pertanyaan | Teknik Utama | Contoh Bisnis | Nilai Bisnis |
|------|-----------|-------------|---------------|-------------|
| Deskriptif | Apa yang terjadi? | *Reporting*, KPI *dashboard* | Laporan penjualan bulanan per region | *Visibility* — mengetahui kondisi |
| Diagnostik | Mengapa terjadi? | *Drill-down*, *root cause*, korelasi | "Penjualan turun karena *lead time* naik" | *Understanding* — mengetahui penyebab |
| Prediktif | Apa yang akan terjadi? | *Forecasting*, ML, regresi | "*Demand* naik 25% di Q4 berdasarkan 3 tahun historis" | *Foresight* — mengantisipasi |
| Preskriptif | Apa yang harus dilakukan? | *Optimization*, simulasi, rekomendasi | "Alokasikan *budget* ke region X untuk ROI optimal" | *Action* — mengarahkan keputusan |

**Tabel 7.1 — Empat tipe analitik: pertanyaan, teknik, contoh, dan nilai bisnis di setiap level.**

Hanya 21% organisasi yang beroperasi di level prediktif-preskriptif, sementara 79% masih di deskriptif-diagnostik (Gartner, 2023). Ironisnya, 80% nilai bisnis dari analitik justru terkonsentrasi di level prediktif-preskriptif. Ini bukan masalah teknologi — *tools* prediktif semakin terjangkau — melainkan masalah kematangan organisasi: kualitas data, kompetensi SDM, dan kemauan manajer untuk bertransisi dari "melihat ke belakang" menjadi "melihat ke depan."

### 7.4.4 *Dashboard* sebagai Alat Komunikasi, Bukan Dekorasi

*Dashboard* bukan laporan yang dipercantik — ia adalah alat komunikasi yang harus menyampaikan "cerita data" secara instan. *Dashboard* yang efektif menjawab pertanyaan keputusan dalam 5 detik pertama, bukan meminta manajer "menggali" atau "scroll ke bawah."

Empat prinsip *dashboard* efektif (Few, 2012):

- **Satu pertanyaan per *dashboard*** — Jika *dashboard* menjawab lima pertanyaan sekaligus, ia tidak menjawab satupun dengan baik. Pisahkan *dashboard* operasional ("stok hari ini per gudang") dari *dashboard* strategis ("tren margin per lini produk 12 bulan terakhir").
- **KPI terpenting di kiri atas** — Mata manusia memindai dari kiri atas ke kanan bawah. Informasi paling kritis harus ada di posisi yang pertama kali dilihat.
- ***Exception highlighting*** — Warnai merah hanya yang melewati ambang batas. Jika semuanya merah, tidak ada yang merah. Jika semuanya hijau, *dashboard* tidak berguna — ia tidak menunjukkan di mana perhatian dibutuhkan.
- **Tren, bukan *snapshot*** — Angka tunggal ("penjualan Rp5 miliar") tanpa konteks tidak bermakna. Apakah naik atau turun? Dibanding kapan? Tren 6–12 bulan (garis) lebih informatif dari angka tunggal (kotak).

Prinsip-prinsip Few (2012) dan Tufte (2006) berlandaskan pada temuan psikologi persepsi visual: penyajian yang bersih dan terorganisir secara konsisten mempercepat pembacaan dan mengurangi beban kognitif pemirsa.

### 7.4.5 Visualisasi Data: Kapan Membantu, Kapan Menyesatkan

Visualisasi yang buruk bukan hanya tidak membantu — ia menyesatkan. 59% eksekutif mengakui pernah mengambil keputusan salah akibat visualisasi data yang *misleading* (Deloitte, 2023). Masalah ini bukan soal niat jahat — seringkali, pembuat *dashboard* sendiri tidak menyadari bahwa pilihan visualisasinya mendistorsi realitas.

Kesalahan umum dan koreksinya:

| Kesalahan | Mengapa Menyesatkan | Koreksi |
|-----------|--------------------|---------| 
| Sumbu Y terpotong (*truncated*) | Perbedaan kecil terlihat dramatis | Mulai sumbu Y dari nol, atau beri label eksplisit |
| Grafik 3D | Perspektif mendistorsi proporsi | Selalu gunakan grafik 2D |
| *Pie chart* > 5 kategori | Otak manusia buruk membandingkan sudut | Gunakan *bar chart* horizontal |
| Terlalu banyak warna | Mengalihkan dari data ke estetika | Maks 5 warna; *highlight* hanya anomali |
| "Spaghetti lines" (10+ garis di satu grafik) | Tidak ada garis yang bisa dibaca | Filter: tampilkan maks 3–4 garis per grafik |

**Tabel 7.2 — Kesalahan visualisasi umum dan dampaknya terhadap interpretasi manajerial.**

Prinsip utama dari Edward Tufte (2006): *data-ink ratio* — maksimalkan proporsi tinta yang merepresentasikan data, minimalkan tinta yang merepresentasikan dekorasi. Setiap elemen visual yang tidak menambah informasi harus dihilangkan.

### 7.4.6 *Predictive Analytics*: Titik Masuk AI ke dalam BI

Analitik prediktif adalah titik di mana AI dan *machine learning* masuk secara natural ke dalam ekosistem BI. Bukan sebagai proyek terpisah berlabel "transformasi AI," melainkan sebagai evolusi dari kemampuan analitik yang sudah ada — dari "melihat ke belakang" menjadi "melihat ke depan."

67% implementasi AI pertama di organisasi dimulai dari *predictive analytics* pada platform BI yang sudah ada — bukan proyek AI *standalone* (McKinsey, 2024). Alasannya: basis data sudah tersedia di *warehouse*, infrastruktur BI sudah berjalan, dan manajer sudah terbiasa mengonsumsi *output* analitik. Menambahkan layer prediktif di atas fondasi deskriptif yang solid adalah langkah evolusi, bukan revolusi.

Contoh Indonesia: Tokopedia menggunakan *predictive analytics* untuk *demand forecasting* — membantu *seller* UMKM menyiapkan stok menjelang Ramadan berdasarkan pola pembelian 3 tahun terakhir. Model prediktif ini bukan AI eksotis — ia adalah regresi statistik dan *time series analysis* yang sudah ada selama beberapa dekade, sekarang dijalankan pada skala dan kecepatan yang baru.

Bank BTPN (Jenius) menggunakan analitik prediktif untuk mendeteksi potensi *churn* nasabah — nasabah yang saldo dan frekuensi transaksinya menurun diberi intervensi proaktif (penawaran khusus, *engagement* dari *relationship manager*) sebelum benar-benar berpindah ke bank lain.

### 7.4.7 Keterbatasan BI: Korelasi Bukan Kausalitas

BI sangat baik menemukan korelasi — dua variabel yang bergerak bersamaan. Tetapi manajer harus berhati-hati: korelasi bukan kausalitas. "Penjualan naik bersamaan dengan *campaign* marketing" tidak berarti *campaign* menyebabkan kenaikan — bisa jadi keduanya disebabkan oleh faktor ketiga: musim belanja.

Contoh klasik: konsumsi es krim berkorelasi positif dengan kasus tenggelam. Bukan karena es krim menyebabkan tenggelam — keduanya meningkat di musim panas karena orang lebih banyak di pantai dan lebih banyak membeli es krim.

Contoh di konteks bisnis: *dashboard* menunjukkan korelasi kuat antara jam *training* dan produktivitas karyawan. Manajer menyimpulkan: "training meningkatkan produktivitas, tambah budget training." Padahal kemungkinan lain: karyawan yang sudah produktif lebih sering dikirim *training* (*reverse causality*), atau departemen dengan *budget* besar mampu mengirim staf ke *training* sekaligus memiliki *tools* yang lebih baik (*confounding variable*).

Tiga pertanyaan yang harus ditanyakan manajer sebelum menyimpulkan kausalitas dari korelasi:
1. "Apakah ada variabel ketiga yang menyebabkan keduanya bergerak bersamaan?"
2. "Apakah arah hubungannya bisa terbalik?" (A menyebabkan B, atau B menyebabkan A?)
3. "Apakah hubungan ini masuk akal secara teori bisnis, bukan hanya secara statistik?"

Korelasi memotivasi investigasi — bukan kesimpulan. Manajer yang memahami perbedaan ini menghindari salah satu jebakan analitik paling mahal.

---

## 7.5 Komparasi

### Tabel 7.3 — Organisasi Tanpa BI vs Organisasi dengan BI Matang

| Dimensi | Tanpa BI (atau BI Minimal) | BI Matang (Deskriptif–Preskriptif) |
|---------|---------------------------|-------------------------------------|
| Basis keputusan | *Spreadsheet* manual, pengalaman, rapat | *Dashboard* terintegrasi + model analitik |
| Waktu akses informasi | Jam–hari (minta ke IT, tunggu laporan) | Detik–menit (*self-service*, *real-time*) |
| Konsistensi angka | "Versi kebenaran" berbeda per divisi | *Single source of truth* dari *warehouse* |
| Deteksi anomali | Ditemukan terlambat — sering setelah berdampak | *Alert* otomatis saat KPI melewati ambang |
| Kemampuan prediksi | Tidak ada — reaktif terhadap kejadian | *Forecasting* 30–90 hari ke depan |
| Investasi tipikal | Rendah (Excel gratis) | Moderat–tinggi (platform + SDM + *governance*) |
| Risiko utama | Keputusan tanpa bukti, konflik data antar-divisi | *Dashboard fatigue*, korelasi disalahartikan sebagai kausalitas |

💡 **Insight:** BI matang tidak menghilangkan risiko — ia mengganti risiko lama (keputusan tanpa data) dengan risiko baru (data disalahinterpretasikan). Manajer yang memahami kedua jenis risiko ini lebih siap memanfaatkan BI secara kritis, bukan secara naif.

---

## 7.6 Realitas Lapangan

### Fenomena 1: "*Dashboard Cemetery*" — Monumen Kegagalan Investasi Data

Gartner (2023) melaporkan 75% *dashboard* BI yang dibangun tidak pernah menjadi basis keputusan aktual. Di Indonesia, fenomena ini lebih tajam: beberapa pemerintah daerah membangun "*command center*" berbiaya miliaran rupiah dengan layar besar, visualisasi dinamis, dan data *streaming* — tetapi pada akhirnya hanya dinyalakan saat ada kunjungan pejabat atau tamu asing.

Akar masalahnya konsisten: *dashboard* dibangun tanpa *decision owner* yang jelas. Tidak ada satu orang pun yang bertanggung jawab atas keputusan spesifik berdasarkan data di *dashboard* itu. Tanpa *decision owner*, *dashboard* menjadi instalasi seni digital — indah, tetapi tidak menggerakkan apa-apa.

💡 **Insight:** *Dashboard* yang tidak memiliki "pelanggan keputusan" sejak hari pertama perancangannya akan berakhir di "kuburan *dashboard*." Sebelum membangun *dashboard*, tanyakan: "Siapa yang akan mengambil keputusan berbeda karena data ini?" Jika jawabannya tidak ada — jangan bangun.

### Fenomena 2: *Self-Service BI* — Demokratisasi atau Anarki Data?

*Self-service BI* (Power BI, Tableau, Google Data Studio) memberdayakan manajer untuk membuat analisis sendiri tanpa menunggu tim IT membuatkan laporan. Ini terdengar ideal — sampai setiap divisi membuat "versi kebenarannya sendiri."

Gartner (2024) menyebut ini "*data anarchy*": 42% perusahaan yang mengadopsi *self-service BI* mengalami konflik internal akibat angka berbeda dari divisi berbeda. Tidak jarang rapat manajemen berakhir bukan dengan keputusan, tetapi dengan debat tentang "angka siapa yang benar."

Solusinya bukan membatasi akses — itu mengembalikan era ketergantungan pada IT. Solusinya: *single source of truth* (semua *self-service* mengambil data dari *warehouse* yang sama) + definisi metrik yang distandarkan organisasi ("pendapatan" artinya X, bukan Y) + *data steward* yang memastikan konsistensi.

💡 **Insight:** Demokratisasi analitik hanya berhasil jika ada fondasi yang kokoh di bawahnya: semua *self-service* mengambil dari *warehouse* yang sama, dan semua metrik menggunakan definisi yang sama. Tanpa fondasi itu, setiap divisi akan membangun "kebenarannya" sendiri — dengan *tools* yang lebih mahal dari *spreadsheet*, tetapi konflik yang sama tajamnya.

### Fenomena 3: Analitik Prediktif di Sektor Publik Indonesia — Potensi Besar, Realisasi Terbatas

Indonesia memiliki beberapa contoh analitik prediktif di sektor publik. BMKG menggunakan model prediktif untuk prakiraan cuaca dan peringatan dini bencana. BPJS Kesehatan mulai menerapkan *predictive models* untuk deteksi *fraud* klaim — mengidentifikasi pola klaim mencurigakan sebelum pembayaran diproses.

Tetapi di luar silo-silo ini, adopsi *predictive analytics* di sektor publik Indonesia masih terbatas. Hambatan utamanya bukan ketersediaan *tools* — *open-source platforms* seperti Python dan R gratis. Hambatannya tiga lapis: (1) kualitas data yang rendah — seperti dibahas di Bab 5, banyak data pemerintah masih tidak konsisten lintas-lembaga, (2) kurangnya SDM *data scientist* di instansi pemerintah, dan (3) budaya keputusan yang masih berbasis konsensus dan senioritas, bukan berbasis model prediktif.

💡 **Insight:** Indonesia memiliki data yang cukup untuk analitik prediktif di banyak sektor — kesehatan, pendidikan, logistik publik, distribusi bantuan sosial. Tetapi "pipa" dari data ke keputusan masih tersumbat oleh tiga hambatan yang saling menguatkan: data kotor, SDM langka, dan budaya organisasi yang belum siap menggunakan prediksi sebagai input keputusan.

---

## 7.7 Salah Kaprah

### ⚠️ Salah Kaprah 1: "*Dashboard* yang penuh angka = BI yang baik"

> *"Dashboard-nya oke — lihat, banyak sekali grafiknya. Warnanya juga bagus."*

*Dashboard* yang "sibuk" dengan terlalu banyak KPI, grafik, dan angka justru menghambat keputusan. *Information overload* di *dashboard* sama berbahayanya dengan *information scarcity* — keduanya melumpuhkan manajer. *Dashboard* dengan 20 grafik memaksa manajer memilih mana yang relevan — dan pemilihan itu sendiri menghabiskan energi kognitif yang seharusnya digunakan untuk memutuskan.

**Koreksi:** *Dashboard* yang baik menjawab satu pertanyaan keputusan dengan jelas. Jika Anda perlu *scroll* untuk menemukan *insight*, *dashboard* itu gagal. *Less is more* — kurangi elemen visual, perbesar yang penting.

### ⚠️ Salah Kaprah 2: "BI hanya untuk perusahaan besar dengan *data scientist*"

> *"BI itu mahal. UMKM mana bisa pakai Tableau atau Power BI."*

*Tools* BI modern dirancang untuk *business user*, bukan programmer. Power BI memiliki *free license* yang sudah cukup untuk UMKM. Google Data Studio (sekarang Looker Studio) sepenuhnya gratis. Metabase adalah *open-source*. UMKM dengan data transaksi di Google Sheets sudah bisa membangun *dashboard* deskriptif yang bermakna — yang menjawab pertanyaan "produk mana yang paling laku bulan ini?" atau "jam berapa pengunjung paling ramai?"

**Koreksi:** BI dimulai dari pertanyaan bisnis yang baik, bukan dari *tools* yang mahal. Mulailah dari "keputusan apa yang ingin saya ambil lebih baik?" — kemudian cari *tools* yang sesuai skala dan anggaran.

### ⚠️ Salah Kaprah 3: "Kalau korelasinya tinggi, berarti ada hubungan sebab-akibat"

> *"Dashboard menunjukkan: jam training naik → produktivitas naik. Kesimpulan: tambah budget training!"*

Ini adalah *logical fallacy* paling berbahaya di analitik. Korelasi hanya menunjukkan bahwa dua variabel bergerak bersamaan — bukan bahwa satu menyebabkan yang lain. Tanpa *controlled experiment* atau teknik *causal inference*, menyimpulkan kausalitas dari korelasi adalah spekulasi yang terlihat ilmiah tetapi sesungguhnya tidak.

**Koreksi:** Sebelum bertindak berdasarkan korelasi, tanyakan: "Apakah ada variabel ketiga?" dan "Apakah hubungan ini masuk akal secara teori bisnis?" Korelasi yang menginspirasi investigasi lebih lanjut bernilai; korelasi yang langsung dijadikan kesimpulan berbahaya.

### ⚠️ Salah Kaprah 4: "Prediksi AI selalu lebih akurat dari analis manusia"

> *"Model AI bilang demand naik 30%. Ikuti saja, AI kan lebih pintar."*

Model prediktif dibangun dari data historis. Jika masa depan berbeda secara mendasar dari masa lalu — pandemi, disrupsi regulasi, *black swan event* — prediksi AI bisa jauh meleset. Model *demand forecasting* yang dilatih pada data 2017–2019 tidak memprediksi pandemi 2020. Model *credit scoring* yang dilatih pada era *boom* ekonomi tidak memprediksi *default rate* saat resesi.

**Koreksi:** Prediksi AI harus diperlakukan sebagai "salah satu *input*" keputusan, bukan jawaban final. Manajer harus memahami asumsi model (data apa yang dipakai, periode kapan, variabel apa yang disertakan) dan mengevaluasi apakah asumsi itu masih valid untuk konteks saat ini.

---

## 7.8 Studi Kasus

### 📊 Studi Kasus A (Dasar): *Dashboard* COVID-19 DKI Jakarta — BI untuk Keputusan Krisis

**Sumber:** Hayati & Rahardjo (2022); Gartner (2023)

**Kondisi Awal (❌):**
Maret 2020 — awal pandemi di Indonesia. Data COVID-19 di Jakarta tersebar di rumah sakit, puskesmas, dan laboratorium yang masing-masing menggunakan sistem pencatatan berbeda. Tidak ada satu *dashboard* yang bisa menjawab pertanyaan paling mendasar: "Berapa kasus hari ini dan di mana konsentrasinya?" Keputusan PSBB pertama diambil berdasarkan estimasi dan laporan telepon dari direktur RS — bukan data terintegrasi.

**Transformasi (✅):**
Tim Jakarta Smart City membangun *dashboard* BI *real-time* yang mengintegrasikan data *testing*, *tracing*, dan *treatment* dari 44 rumah sakit rujukan dan 344 puskesmas. *Dashboard* ini menjadi basis keputusan PSBB/PPKM: pemberlakuan, pelonggaran, dan pengetatan kembali ditentukan berdasarkan *positivity rate* dan *bed occupancy rate* — bukan estimasi.

| Dimensi | Sebelum *Dashboard* | Sesudah *Dashboard* |
|---------|--------------------|--------------------|
| Pembaruan data | Delay 24–48 jam | *Real-time* (interval 15 menit) |
| Basis keputusan PSBB | Estimasi + *polling* RS via telepon | Data *positivity rate* + *bed occupancy* |
| Transparansi publik | Konferensi pers manual | *Dashboard* publik corona.jakarta.go.id |
| Level analitik | Deskriptif (menghitung kasus) | Prediktif (*forecasting peak*) |
| Kecepatan keputusan | Hari–minggu | Jam — berdasarkan ambang batas yang terdefinisi |

**Tabel 7.4 — Dashboard COVID-19 Jakarta: dampak BI real-time terhadap kecepatan dan kualitas keputusan kebijakan publik.**

💡 **Pelajaran:** *Dashboard* COVID-19 Jakarta berhasil karena dirancang dari pertanyaan keputusan ("Kapan memberlakukan PSBB?"), bukan dari data yang tersedia. *Decision owner* jelas (Gubernur dan tim gugus tugas), *action threshold* jelas (*bed occupancy* > 70% = perketat), dan transparansi publik memastikan akuntabilitas. Ini adalah contoh BI yang bekerja sesuai prinsip — dan membuktikan bahwa prinsip *dashboard* efektif berlaku di sektor publik sama kuatnya dengan di sektor swasta.

### 📊 Studi Kasus B (Lanjutan): Netflix — Evolusi dari BI Deskriptif ke Analitik Preskriptif

**Sumber:** Sharda et al. (2024); McKinsey (2023)

**Kondisi Awal (❌):**
Netflix tahun 2006 adalah perusahaan *DVD rental*. BI mereka di level deskriptif: laporan popularitas judul, demografi pelanggan, dan metrik operasional pengiriman DVD. Data ini cukup untuk menjalankan operasi — tetapi tidak cukup untuk bersaing di era *streaming* yang akan datang.

**Evolusi Analitik (✅):**
Selama 15 tahun, Netflix berevolusi secara bertahap melalui keempat level analitik — setiap level dibangun di atas fondasi level sebelumnya:

| Level Analitik | Aplikasi di Netflix | Dampak Bisnis |
|---------------|--------------------|--------------| 
| Deskriptif | *Viewing reports* — apa yang ditonton, kapan, berapa lama | Operasional dasar |
| Diagnostik | *Churn analysis* — mengapa pelanggan *unsubscribe* | Strategi retensi: mengurangi *cancellation* |
| Prediktif | *Recommendation engine* — apa yang akan ditonton selanjutnya | Penurunan signifikan *churn rate*, diestimasi menghemat ratusan juta dolar per tahun |
| Preskriptif | Keputusan produksi konten (*House of Cards* dikembangkan berdasarkan data preferensi penonton) | *Hit rate* serial orisinal yang konsisten lebih tinggi dari rata-rata industri |

**Tabel 7.5 — Netflix: evolusi 15 tahun dari BI deskriptif ke analitik preskriptif.**

*Recommendation engine* Netflix — yang menyumbang 80% konten yang ditonton di platform — adalah model preskriptif berbasis *deep learning*. Tetapi model itu tidak akan ada tanpa 10 tahun data deskriptif dan diagnostik yang membentuk fondasinya. Netflix tidak melompat ke AI — ia berjalan ke sana, satu level analitik pada satu waktu.

💡 **Pelajaran:** Perjalanan Netflix dari deskriptif ke preskriptif membuktikan bahwa analitik lanjutan bukan revolusi — ia evolusi bertahap. Organisasi yang ingin "langsung ke AI" tanpa fondasi BI deskriptif yang kuat sedang membangun rumah tanpa fondasi. Mulailah dari pertanyaan deskriptif yang dijawab dengan baik, lalu naik ke diagnostik, prediktif, dan akhirnya preskriptif — sesuai kematangan data dan organisasi.

---

## 7.9 Template Praktis

### 🔧 Template A.7 — Desain Kerangka *Dashboard* BI

```
==============================================
TEMPLATE A.7 — DESAIN KERANGKA DASHBOARD BI
==============================================

Nama Organisasi         : ________________________________________
Departemen/Pengguna     : ________________________________________
Tanggal Perancangan     : ________________________________________

═══════════════════════════════════════════════════════════════

PERTANYAAN KEPUTUSAN
Dashboard ini menjawab pertanyaan : ________________________________________
Keputusan yang akan berubah       : ________________________________________
Decision owner                    : ________________________________________
Frekuensi monitoring              : [ ] Real-time  [ ] Harian  [ ] Mingguan  [ ] Bulanan

KPI UTAMA (Maksimal 5)
1. ________________________________  Target: ________  Alert if: ________
2. ________________________________  Target: ________  Alert if: ________
3. ________________________________  Target: ________  Alert if: ________
4. ________________________________  Target: ________  Alert if: ________
5. ________________________________  Target: ________  Alert if: ________

SUMBER DATA
Data source 1  : ____________________________  Update freq: ________
Data source 2  : ____________________________  Update freq: ________
Data source 3  : ____________________________  Update freq: ________

VISUALISASI (untuk setiap KPI)
KPI 1 → Tipe chart: [ ] Bar  [ ] Line  [ ] Gauge  [ ] Table  [ ] Heatmap
KPI 2 → Tipe chart: [ ] Bar  [ ] Line  [ ] Gauge  [ ] Table  [ ] Heatmap
KPI 3 → Tipe chart: [ ] Bar  [ ] Line  [ ] Gauge  [ ] Table  [ ] Heatmap
KPI 4 → Tipe chart: [ ] Bar  [ ] Line  [ ] Gauge  [ ] Table  [ ] Heatmap
KPI 5 → Tipe chart: [ ] Bar  [ ] Line  [ ] Gauge  [ ] Table  [ ] Heatmap

ACTION THRESHOLD
Jika KPI melewati batas  : ________________________________________
Siapa yang harus tahu    : ________________________________________
Aksi yang harus diambil  : ________________________________________
Deadline respons         : ________________________________________

═══════════════════════════════════════════════════════════════

LEVEL ANALITIK DASHBOARD
[ ] Deskriptif  (apa yang terjadi)
[ ] Diagnostik  (drill-down: mengapa)
[ ] Prediktif   (forecast)
[ ] Preskriptif (rekomendasi aksi)

EVALUASI DESAIN
Dashboard menjawab pertanyaan keputusan dalam < 5 detik?  [ ] Ya  [ ] Tidak
Setiap KPI memiliki action threshold?                      [ ] Ya  [ ] Tidak
Decision owner sudah ditetapkan?                           [ ] Ya  [ ] Tidak
```

---

## 7.10 Peta Konsep

### Gambar 7.2 — Peta Konsep Bab 7: *Business Intelligence* dan Analitik Bisnis

```mermaid
mindmap
  root((BI & Analitik<br/>Bisnis))
    Arsitektur BI
      Data Sources
      ETL Process
      Data Warehouse
      Visualization Layer
    4 Tipe Analitik
      Deskriptif — Apa yang terjadi
      Diagnostik — Mengapa terjadi
      Prediktif — Apa yang akan terjadi
      Preskriptif — Apa yang harus dilakukan
    Dashboard Efektif
      Decision Question
      KPI Selection
      Action Threshold
      Visualisasi yang Jujur
    Keterbatasan
      Correlation bukan Causation
      Data Quality Dependency
      Dashboard Fatigue
    Tren BI
      Self-Service BI
      AI-Augmented Analytics
      Predictive sebagai Titik Masuk AI
```

**Gambar 7.2 — Peta konsep BI dan analitik bisnis: lima kluster dari arsitektur BI hingga tren yang membentuk masa depan analitik.**

---

## 7.11 Rangkuman

**Poin-poin Penting:**

1. BI bukan satu *software* — ia ekosistem: *data source* → ETL → *warehouse* → analitik → visualisasi → keputusan. Manajer harus memahami alur ini untuk bisa mempercayai dan mengkritisi *output* BI. Pertanyaan kunci: "Kapan data terakhir di-*update*?" dan "Bagaimana metrik ini didefinisikan?"

2. Empat tipe analitik (deskriptif, diagnostik, prediktif, preskriptif) membentuk spektrum kematangan. 79% organisasi masih di level deskriptif-diagnostik, padahal 80% nilai bisnis terkonsentrasi di prediktif-preskriptif. Setiap level membangun di atas fondasi level sebelumnya — tidak bisa dilompati.

3. *Dashboard* yang baik dimulai dari pertanyaan keputusan, bukan dari data yang tersedia. Setiap *dashboard* harus memiliki *decision owner*, *action threshold*, dan kemampuan menjawab pertanyaan dalam 5 detik pertama. *Dashboard* tanpa *decision question* adalah dekorasi.

4. Visualisasi data yang buruk — sumbu terpotong, grafik 3D, *pie chart* berlebihan — menyesatkan keputusan. 59% eksekutif mengakui pernah salah keputusan akibat visualisasi yang *misleading*. Prinsip Tufte: maksimalkan *data-ink ratio*, hilangkan dekorasi.

5. Korelasi bukan kausalitas — peringatan terpenting bagi manajer yang menggunakan BI. Korelasi memotivasi investigasi, bukan kesimpulan. Selalu tanyakan: "Ada variabel ketiga?" dan "Masuk akal secara teori bisnis?"

6. AI masuk secara natural di level prediktif-preskriptif sebagai evolusi BI — bukan proyek terpisah. 67% implementasi AI pertama dimulai dari *predictive analytics* pada platform BI yang sudah ada.

7. *Self-service BI* memberdayakan manajer tetapi berisiko menciptakan "anarki data" jika tidak ada *single source of truth* dan definisi metrik yang distandarkan. Demokratisasi data tanpa *governance* menghasilkan konflik, bukan kolaborasi.

---

**Menuju Bab 8:**

BI dan analitik memberi manajer kemampuan melihat apa yang terjadi, memahami mengapa terjadi, dan memprediksi apa yang akan terjadi. Tetapi *insight* tanpa *framing* masalah yang benar hanya menghasilkan jawaban untuk pertanyaan yang salah. Sebelum mencari jawaban dengan BI, manajer harus terlebih dulu mendefinisikan masalah organisasi yang benar — membedakan gejala dari akar masalah. Bab 8 membahas *problem framing* sebagai kompetensi manajerial yang kritis — dan mengapa mendefinisikan masalah yang tepat sering lebih sulit dari menemukan solusinya.

---

🔥 *"Business Intelligence bukan tentang berapa banyak grafik yang Anda tampilkan di layar, tetapi tentang berapa banyak pertanyaan bisnis yang mampu Anda jawab sebelum pesaing Anda bertanya."*

---

## 7.12 Latihan & Refleksi

### Pertanyaan Diagnostik

Suatu *dashboard* menunjukkan kenaikan penjualan setelah program diskon dijalankan. Analisis temuan tersebut pada tingkat deskriptif, diagnostik, prediktif, dan preskriptif, tentukan data tambahan yang diperlukan, dan jelaskan risiko kekeliruan apabila korelasi diperlakukan sebagai kausalitas.

### Pertanyaan Reflektif

1. Di level analitik mana organisasi yang Anda kenal saat ini beroperasi (deskriptif / diagnostik / prediktif / preskriptif)? Apa hambatan utama untuk naik ke level berikutnya — teknologi, data, SDM, atau budaya?

2. Evaluasi satu *dashboard* yang ada di organisasi Anda: apakah ia dirancang dari "pertanyaan keputusan" atau dari "data yang kebetulan tersedia"? Apakah ada *decision owner* dan *action threshold* yang jelas?

3. Berikan contoh keputusan bisnis di mana korelasi di *dashboard* atau laporan pernah — atau berpotensi — disalahartikan sebagai kausalitas. Apa konsekuensinya?

4. Apakah *self-service BI* (semua manajer bisa buat analisis sendiri) lebih banyak manfaat atau risikonya bagi organisasi yang Anda kenal? Prasyarat apa yang harus dipenuhi sebelum mengadopsinya?

### Latihan Artefak

**Latihan 7.1 — Desain Kerangka *Dashboard* BI (Template A.7)**

Gunakan Template A.7 untuk merancang kerangka 1 *dashboard* untuk satu keputusan manajerial spesifik di organisasi yang Anda pilih.

1. Rumuskan pertanyaan keputusan yang jelas dan spesifik — bukan generik
2. Pilih maksimal 5 KPI yang langsung relevan dengan keputusan tersebut
3. Tentukan *action threshold* untuk setiap KPI — "jika melewati X, maka lakukan Y"
4. Pilih tipe visualisasi yang tepat untuk setiap KPI berdasarkan prinsip Bab 7

**Kriteria output yang baik:**
- Pertanyaan keputusan spesifik, bukan "bagaimana performa perusahaan?"
- KPI terhubung langsung ke keputusan — bukan informasi "menarik tapi tidak *actionable*"
- Setiap KPI memiliki *action threshold* dan *decision owner* — bukan sekadar angka
- Evaluasi akhir: "Bisakah *dashboard* ini menjawab pertanyaan dalam 5 detik?"

*Output Artefak 7.1 menjadi dasar untuk memahami bagaimana BI mendukung problem framing organisasi di Bab 8.*

---

## Referensi

Davenport, T. H. (2023). *The AI advantage* (Updated ed.). MIT Press.

Deloitte. (2023). *Data visualization survey: Insights and impact*. Deloitte Insights.

Few, S. (2012). *Show me the numbers: Designing tables and graphs to enlighten* (2nd ed.). Analytics Press.

Gartner Research. (2023). *Analytics and BI platforms: Market guide*. Gartner, Inc.

Gartner Research. (2024). *Top strategic technology trends for 2025*. Gartner, Inc.

Hayati, N., & Rahardjo, B. (2022). Implementasi *business intelligence* untuk pengambilan keputusan strategis. *Jurnal Sistem Informasi*, *18*(2), 89–104.

Laudon, K. C., & Laudon, J. P. (2022). *Management information systems* (17th ed.). Pearson.

McKinsey & Company. (2023). *The economic potential of generative AI*. McKinsey & Company.

McKinsey & Company. (2024). *The state of AI in 2024*. McKinsey Digital.

Mikalef, P., Boura, M., Lekakos, G., & Krogstie, J. (2021). Big data analytics capabilities and innovation. *British Journal of Management*, *32*(2), 507–527.

Sharda, R., Delen, D., & Turban, E. (2024). *Business intelligence, analytics, and data science* (5th ed.). Pearson.

Tufte, E. R. (2006). *Beautiful evidence*. Graphics Press.


