Belajar System Analyst - Data-Driven Decision Analysis

#Pendahuluan

Setelah di episode 23 kalian mampu menempatkan proyek dalam peta arsitektur organisasi, kita hadapi pertanyaan yang menentukan nasib semua fitur yang sudah dibangun: apakah ini berhasil? Rapat evaluasi TokoKita sering berakhir demokrasi suara — pemilik percaya program member bagus karena pelanggan tersenyum, kasir mengeluh antrean panjang, kepala cabang yakin promo efektif karena toko ramai. Semua berdasar perasaan, semuanya meyakinkan, tidak satu pun bisa dipertanggungjawabkan. Episode ini membahas data-driven decision analysis: cara analyst merumuskan KPI, mendesain pengukuran, dan membaca data untuk memutuskan.

Mengapa ini kompetensi analyst, bukan hanya urusan tim data? Karena keputusan desain kalian — field apa dikumpulkan, alur mana disederhanakan, fitur mana dirilis dulu — adalah hipotesis bisnis yang menyamar sebagai fitur. "Registrasi member di kasir akan meningkatkan retensi" adalah klaim terukur. Analyst yang tidak menuliskan cara membuktikannya melempar tanggung jawab evaluasi kepada kebetulan; yang menuliskannya mengubah setiap rilis menjadi eksperimen yang mengajari organisasi sesuatu.

#Dari Tujuan Bisnis ke Metrik: Kerangka GQM

Jebakan paling umum pengukuran adalah mulai dari data yang tersedia ("kita punya log apa saja?") alih-alih tujuan yang ingin dicapai. Kerangka GQM (Goal–Question–Metric) memaksa urutan yang benar:

1. Goal — tujuan bisnis, ditulis eksplisit: "Meningkatkan frekuensi kunjungan member ke level yang membuat mereka memilih TokoKita daripada pasar tradisional."
2. Question — pertanyaan yang jawabannya menunjukkan capaian tujuan: "Berapa persen member yang datang minimal dua kali dalam sebulan?"
3. Metric — ukuran konkret yang menjawab pertanyaan: repeat_rate_30d = member aktif ≥ 2 transaksi / total member aktif.

Tiga lapis itu penting karena tiap lapis menyaring kesalahan lapis bawahnya. Tanpa goal, metrik jadi koleksi dashboard kosmetik; tanpa question, angka tak tahu menjawab apa; tanpa metric yang didefinisikan presisi, dua orang membaca "member aktif" dengan arti berbeda dan rapat berubah debat filosofi.

#Kontrak Metrik: Definisi Tertulis yang Mengikat

Setiap metrik resmi wajib punya definisi tertulis — kontrak kecil yang mencegah perang interpretasi:

Dua kolom paling sering hilang di dunia nyata justru baseline dan target: tanpa baseline kalian tidak tahu apakah 38% bagus atau buruk; tanpa target, "naik" selalu bisa diklaim berhasil meski naiknya 0,4 poin dalam setahun.

#Leading vs Lagging: Menimbang Waktu Baca Sinyal

Metrik dibagi dua keluarga waktu, dan keduanya harus ada di framework kalian:

• Lagging — hasil akhir yang datang terlambat: omzet bulanan, repeat rate, churn. Akurat tapi seperti melihat foto mundur; saat angkanya turun, penyebabnya sudah berlalu berminggu-minggu.
• Leading — sinyal awal yang memprediksi hasil: jumlah registrasi member mingguan, rasio transaksi member per kasir, waktu sinkronisasi stok asisten (dari episode 22). Bergetar cepat, bisa ditindaklanjuti sekarang.

Framework yang sehat memasangkan keduanya: leading sebagai kemudi harian, lagging sebagai penentu arah strategis. Program member TokoKita contohnya: registrasi mingguan (leading) naik tajam, tetapi repeat rate (lagging) diam — sinyal bahwa kita berhasil mendata orang, gagal memberi alasan kembali. Tanpa pasangan ini, kita akan merayakan metrik vanity sementara bisnisnya tak bergerak.

#Instrumentasi adalah Requirement, Bukan Bonus

Metrik tidak lahir dari sihir; ia lahir dari data yang direncanakan sejak desain. Ini bagian pekerjaan analyst yang paling sering dilupakan: ketika menulis requirement fitur, tuliskan juga event tracking yang harus dibangun:

EVENT: member_registered
  Trigger : registrasi member sukses di POS
  Properti: store_id, cashier_id, kanal (kasir/wa),
            durasi_isi_detik
EVENT: assistant_question_answered        (ep.22)
  Trigger : asisten stok menjawab pertanyaan
  Properti: store_id, kategori_pertanyaan,
            butuh_klarifikasi (bool),
            sumber_data_usia_detik
 
Aturan umum:
- Nama event snake_case, kamus di 07-ops/tracking-plan.md
- Dilarang memasukkan data personal ke properti event
  (konsisten privacy analysis ep.20)

Perhatikan properti butuh_klarifikasi pada asisten stok: itu metrik mutu UX yang hanya bisa dibaca kalau kita memikirkannya sejak spec — setelah rilis, informasinya hilang selamanya. Dan aturan larangan data personal di event bukan keributan: event analytics adalah jalur kebocoran klasik yang luput dari review privasi.

#Membaca Data Tanpa Terjebak

Empat jebakan interpretasi yang wajib kalian kenali sebelum membawakan angka di rapat:

1. Korelasi bukan kausalitas — cabang yang pakai asisten stok omzetnya naik 12%. Apakah asisten penyebabnya? Atau cabang itu saja yang kepala tokonya paling rajin sejak awal? Bandingkan dengan cabang serupa yang tidak memakai (grup pembanding) sebelum mengklaim.
2. Sampel kecil berbohong dengan percaya diri — minggu promo lebaran naik 40% bukan tren; hari kerja dan musim memompa angka. Untuk skala TokoKita (belasan cabang), putuskan kecil saja berdasarkan satu minggu adalah kesalahan klasik.
3. Rata-rata menyembunyikan bentuk data — waktu jawab asisten rata-rata 8 detik terdengar baik, sampai kalian lihat separuh jawaban instan dan separuh lagi nyangkut 60 detik saat sync lambat. Median atau distribusi sering lebih jujur.
4. Angka agregat menelan kasus penting — repeat rate naik secara nasional padahal dua cabang anjlok; agregat menyembunyikan kebakaran lokal. Selalu sediakan potongan per cabang sebelum menyimpulkan.

Pola amannya sederhana: sebelum mempresentasikan temuan, tanyakan pada diri sendiri "apa penjelasan alternatif lain untuk angka ini, dan data apa yang bisa membedakannya?" Kalimat itu sendiri sudah menaikkan mutu diskusi di ruangan.

#Praktik: Framework KPI Program Digital TokoKita

Gabungan seluruh elemen di atas menjadi 07-ops/kpi-framework.md:

# Framework KPI - Program Member & Asisten Stok v1.0
 
## Tujuan utama (goal)
Member menjadikan TokoKita pilihan belanja rutin,
terlihat dari frekuensi kunjungan yang naik dan bertahan.
 
## KPI inti (lagging)
K-01 repeat_rate_30d   baseline 31% -> target 45% (6 bln)
K-02 active_member_pct baseline 58% -> target 70%
     (member >= 1 transaksi / total terdaftar)
 
## Sinyal harian (leading)
K-03 registrasi_member_mingguan  x validitas HP >= 90%
K-04 transaksi_member_per_cabang_harian
K-05 assistant_adoption          (pertanyaan/asisten/
     kepala-toko/minggu, ep.22)
 
## Metrik mutu (anti-Goodhart, wajib berpasangan)
M-01 validitas nomor HP registrasi
M-02 tingkat klarifikasi asisten (butuh_klarifikasi)
 
## Ritme
Harian  : dashboard K-03..K-05 (kepala cabang)
Mingguan: review KPI lengkap bersama pemilik (30 menit)
Bulanan : evaluasi target + revisi definisi bila perlu
 
## Tata kelola
Semua definisi terkunci di dokumen ini; perubahan definisi
wajib catat versi & tanggal (mencegah moving the goalposts).

Dokumen pendek ini mengubah rapat evaluasi dari duel opini menjadi pembacaan fakta: semua orang melihat definisi yang sama, baseline yang sama, dan target yang sama. Perubahan definisi yang dicatat versinya mencegah kebiasaan manis yang merusak: mengganti rumus metrik tepat saat angkanya jelek agar terlihat membaik.

#Kesalahan Umum

1. Dashboard dulu, tujuan belakangan — membangun dashboard dari log yang tersedia lalu mencari pertanyaan. Balik urutannya dengan GQM: goal → question → baru metric.
2. Terlalu banyak KPI — dua puluh metrik berarti tidak ada prioritas; fokus layaknya spotlight, bukan lampu sorak serba menyala. Tiga sampai lima KPI inti cukup untuk usia sebesar TokoKita.
3. Tanpa baseline — meluncurkan fitur tanpa mengukur kondisi sebelumnya membuat evaluasi mustahil selamanya; kalian hanya punya "sesudah" tanpa "sebelum".
4. Menjatuhkan keputusan besar dari sampel kecil — satu cabang satu minggu bukan dasar mematikan fitur atau menggulirkannya ke seluruh jaringan. Tetapkan ambang minimum data sebelum rapat keputusan.
5. Mengukur lalu melupakan — KPI dicatat rapi tiap minggu tapi tidak ada yang bertanya "lalu kita apa?" Pengukuran tanpa tindak lanjut hanyalah ritual; jembatannya ke sistem perbaikan berkelanjutan — topik episode berikutnya.

#Penutup

Inti yang harus dibawa pulang:

• GQM menjaga urutan yang benar: tujuan bisnis → pertanyaan penentu → metrik terdefinisi; kontrak metrik mencegah perang interpretasi di rapat.
• Pasangkan lagging (hasil akhir) dengan leading (sinyal harian), dan tiap metrik target dengan metrik mutu untuk menetralkan Goodhart's law.
• Instrumentasi adalah requirement resmi: tracking plan ditulis sejak spec fitur, bebas data personal, konsisten dengan tata kelola privasi seri ini.
• Baca data dengan skeptis sehat: korelasi-kausalitas, sampel kecil, rata-rata penipu, dan agregat penelan masalah lokal.
• Framework KPI TokoKita mengunci 5 KPI, 2 metrik mutu, ritme tinjauan, dan tata kelola perubahan definisi.

Angka sudah terukur dan terbaca — langkah pamungkasnya adalah mengubah temuan menjadi perbaikan nyata secara terjadwal, bukan insidental. Di episode 25 selanjutnya kita membahas continuous improvement systems: membangun loop umpan balik dari lapangan ke backlog, menrioritaskan perbaikan dengan disiplin, dan menutup lingkaran kepada stakeholder sehingga sistem TokoKita membaik setiap bulan tanpa menunggu krisis. Pastikan tetap semangat!