Merumuskan Masalah

Sepanjang Course ini kita mengumpulkan peralatan yang mumpuni: pandas untuk mengolah data, statistika untuk menyimpulkan, dan machine learning untuk memprediksi. Peralatan semacam itu justru sering menyesatkan ketika dipakai tanpa arah — analisis yang canggih atas pertanyaan yang keliru tetap menghasilkan keputusan yang keliru. Section baru ini membahas sisi lain pekerjaan data science: tata kelola proses kerja, mulai dari merumuskan masalah sampai memeriksa kualitas hasil sebelum diserahkan. Kita mulai dari titik nol setiap proyek: sebuah keluhan yang samar dari pemilik bisnis, yang harus kita ubah menjadi masalah analitik yang jelas dan terukur.

Dari Keluhan Bisnis ke Pertanyaan Terukur #

Masalah jarang datang dalam bentuk pertanyaan yang siap dijawab. Yang datang biasanya keluhan: “pelanggan kok pada pergi?”, “promosi kemarin tidak terasa efeknya”, “stok sering habis pas akhir pekan”. Keluhan semacam itu bukan masalah analitik — keluhan tidak menunjuk data apa pun, tidak punya satuan, dan tidak memiliki batas waktu. Tugas kita pada tahap ini adalah menerjemahkannya menjadi pertanyaan yang bisa dijawab dengan data.

Pertanyaan analitik yang baik memiliki tiga ciri. Pertama, pertanyaan menunjuk data yang benar-benar bisa dikumpulkan atau sudah dimiliki. Kedua, pertanyaan memiliki satuan pengukuran yang jelas — persen, rupiah, jumlah pelanggan — sehingga jawabannya berupa angka, bukan opini. Ketiga, pertanyaan dibatasi rentang waktu dan lingkup yang masuk akal, misalnya “enam bulan terakhir” atau “pelanggan kafe di cabang Bandung”. Perhatikan perbedaannya pada tabel berikut:

Ketiga pertanyaan di kolom kanan bisa dijawab dengan data transaksi yang lazim dimiliki sebuah kedai. Kalau keluhan dibiarkan dalam bentuk mentah, tim data akan menebak-nebak sendiri apa yang dimaksud pemilik — dan hasil akhirnya mudah sekali meleset dari kebutuhan sebenarnya.

Masalah Analitik dan Masalah Keputusan #

Merumuskan masalah berarti mengerjakan dua sisi sekaligus. Masalah analitik menjawab “apa yang perlu kita ketahui dari data?”, sedangkan masalah keputusan menjawab “apa yang akan dilakukan stakeholder setelah mengetahuinya?”. Keduanya harus dirumuskan bersamaan; masalah analitik tanpa keputusan penerima menghasilkan laporan yang indah namun tidak pernah dipakai, sedangkan keputusan tanpa masalah analitik yang jelas berarti menebak dengan kata-kata puitis.

Hubungan kedua sisi ini juga menentukan bentuk keluaran yang kita janjikan. Bila keputusannya adalah menghubungi pelanggan tertentu, keluaran yang tepat adalah daftar pelanggan berisiko — bukan laporan umum tentang “kecenderungan pasar”. Bila keputusannya menyetop anggaran promosi, keluaran yang tepat adalah perbandingan dampak promosi terhadap biayanya.

Memetakan Stakeholder #

Proyek yang sehat tidak berdiri di atas satu orang. Sebelum menganalisis, kita petakan siapa saja yang berkepentingan dengan hasilnya — peta kecil yang biasa disebut stakeholder map. Untuk proyek retensi pelanggan Toko Kopi Kita, peta tersebut terlihat seperti ini:

Peta sederhana ini sering menemukan hal yang tidak terduga sebelum analisis dimulai. Ketika menanyakan definisi “pelanggan aktif” kepada tim kasir, kita mungkin menemukan bahwa pencatatan keanggotaan baru rapi sejak Oktober 2025 — artinya data sebelum itu tidak layak dipakai untuk analisis retensi. Menemukan keterbatasan semacam ini pada tahap perumusan jauh lebih murah daripada menemukannya setelah model selesai dilatih.

Merumuskan dalam Satu Struktur #

Agar rumusan masalah tidak menguap dalam percakapan, kita simpan dalam satu struktur berulang: keluhan asal, pertanyaan terukur, data yang dibutuhkan, dan keluaran yang dijanjikan. Struktur ini menjadi kontrak awal antara kita dan stakeholder — semua pihak bisa menyetujui atau mengoreksinya sebelum pekerjaan teknis dimulai.

rumusan_masalah = [
    {
        "keluhan": "Pelanggan lama jarang kembali lagi.",
        "pertanyaan": "Berapa persen pelanggan aktif Desember 2025 "
                      "yang tidak bertransaksi lagi sepanjang Januari 2026?",
        "data": "riwayat transaksi Juli-Desember 2025",
        "keluaran": "angka retensi 30 hari dan daftar pelanggan yang hilang",
    },
    {
        "keluhan": "Stok bahan sering habis di akhir pekan.",
        "pertanyaan": "Berapa rata-rata penjualan gelas pada Sabtu-Minggu "
                      "lima pekan terakhir?",
        "data": "penjualan harian lima pekan terakhir",
        "keluaran": "angka kebutuhan stok akhir pekan",
    },
]

for nomor, r in enumerate(rumusan_masalah, start=1):
    print(f"Rumusan {nomor}")
    print("  Keluhan    :", r["keluhan"])
    print("  Pertanyaan :", r["pertanyaan"])
    print("  Data       :", r["data"])
    print("  Keluaran   :", r["keluaran"])

Output yang Dihasilkan:

Rumusan 1
  Keluhan    : Pelanggan lama jarang kembali lagi.
  Pertanyaan : Berapa persen pelanggan aktif Desember 2025 yang tidak bertransaksi lagi sepanjang Januari 2026?
  Data       : riwayat transaksi Juli-Desember 2025
  Keluaran   : angka retensi 30 hari dan daftar pelanggan yang hilang
Rumusan 2
  Keluhan    : Stok bahan sering habis di akhir pekan.
  Pertanyaan : Berapa rata-rata penjualan gelas pada Sabtu-Minggu lima pekan terakhir?
  Data       : penjualan harian lima pekan terakhir
  Keluaran   : angka kebutuhan stok akhir pekan

Mari kita telaah bentuk datanya:

1. List of dict: setiap elemen rumusan_masalah memuat empat kunci yang sama — keluhan, pertanyaan, data, dan keluaran. Konsistensi kunci inilah yang membuat rumusan mudah dibandingkan dan diperiksa.
2. Pertanyaan sudah menyebut satuan dan waktu: “berapa persen”, “Desember 2025”, “lima pekan terakhir”. Bila salah satu keluhan belum bisa ditulis sejujur ini, itu pertanda perumusan belum selesai — kembali dulu ke stakeholder, jangan buru-buru menyentuh data.
3. Keluaran berupa benda nyata: “daftar pelanggan” dan “angka kebutuhan stok”, bukan “wawasan”. Keluaran yang berwujud benda bisa diperiksa selesai atau tidaknya; “wawasan” tidak.

Struktur semacam ini sederhana, tetapi ia menjadi rujukan bagi seluruh keputusan berikutnya: metrik apa yang relevan, data apa yang dikumpulkan, dan bagaimana bentuk laporan akhir.

Rangkuman #

• Keluhan bisnis harus diterjemahkan menjadi pertanyaan analitik yang terukur: menunjuk data nyata, memiliki satuan, dan dibatasi waktu serta lingkup.
• Masalah analitik (apa yang perlu diketahui) dan masalah keputusan (apa yang akan dilakukan setelahnya) dirumuskan bersamaan — keputusan penerima menentukan bentuk keluaran yang dijanjikan.
• Peta stakeholder yang kecil sekalipun sering menemukan keterbatasan data dan definisi yang belum seragam jauh sebelum analisis dimulai.
• Rumusan masalah disimpan sebagai struktur berulang — keluhan, pertanyaan, data, keluaran — yang menjadi kontrak awal proyek.

Rumusan masalah yang telah disepakati menyebut “berapa persen pelanggan hilang” dan “berapa besar nilai yang berisiko hilang”, tetapi belum menyebut satu hal penting: angka berapa yang kita anggap berhasil. Tanpa janji itu, analisis apa pun bisa dinyatakan gagal atau berhasil secara sewenang-wenang setelah selesai. Kita tetapkan standarnya lebih dulu pada chapter berikutnya: Menentukan Metrik Keberhasilan .