Produktivitas Data Analyst: Sistem Kerja biar Gak Kebanjiran Request

Produktivitas data analyst nggak ditentukan sama seberapa cepat kamu nulis query. Ditentukan sama seberapa banyak request yang berhasil kamu saring sebelum masuk.

Aku pernah ngitung ini di satu tim: dari 47 request yang masuk dalam sebulan, 19 hasilnya nggak pernah dibuka sama yang minta. Itu 40% waktu kerja yang nguap.

Masalahnya bukan analyst-nya lambat. Masalahnya nggak ada pintu masuk.

Ini sistem 5 langkah yang aku pakai. Setup-nya sehari, efeknya kerasa dari minggu pertama.

Kenapa request ad-hoc bisa numpuk?

Tiga penyebab yang selalu sama.

Nggak ada pintu tunggal. Request masuk lewat WhatsApp, Slack DM, email, dan colekan di pantry. Nggak ada yang ke-track, jadi nggak ada yang bisa diprioritaskan.

Request datang tanpa konteks. "Minta data penjualan dong." Penjualan apa, periode kapan, buat apa? Kamu balik nanya, mereka balas 4 jam kemudian, dan setengah hari hilang buat klarifikasi.

Semua dianggap urgent. Kalau semua urgent, nggak ada yang urgent — dan yang menang jadi siapa yang paling berisik, bukan yang paling penting.

Langkah 1: bikin satu pintu masuk

Semua request lewat satu form. Nggak ada pengecualian — termasuk buat bos kamu.

Google Form yang nyambung ke Sheets udah cukup buat tim di bawah 30 orang. Gratis dan setupnya 20 menit.

Isi form-nya cuma 5 pertanyaan:

1. Keputusan apa yang mau kamu ambil dari data ini? (bukan "data apa yang kamu mau")
2. Kapan butuhnya, dan kenapa tanggal itu?
3. Siapa yang bakal pakai hasilnya?
4. Apa yang terjadi kalau ini nggak dikerjain?
5. Udah ada dashboard yang jawab ini belum? (dengan link ke daftar dashboard yang ada)

Pertanyaan nomor 4 itu senjata utamanya. Di tim yang aku bantu, sekitar seperempat request berhenti di situ — orangnya sadar sendiri hasilnya nggak akan dipakai buat apa-apa.

Pertanyaan nomor 1 juga penting. "Aku mau data penjualan Q2" itu permintaan data. "Aku mau tau kota mana yang layak ditutup outlet-nya" itu pertanyaan bisnis — dan jawabannya mungkin cuma butuh 1 tabel, bukan 8 tab spreadsheet.

Cara ngasih taunya ke tim: jangan bilang "jangan chat aku lagi". Bilang "request lewat form dikerjain duluan, soalnya aku bisa lihat konteksnya langsung". Insentif, bukan larangan.

Langkah 2: prioritaskan pakai matriks dampak vs usaha

Setelah request masuk, taruh di satu dari 4 kotak.

	Usaha rendah	Usaha tinggi
Dampak tinggi	Kerjain sekarang	Jadwalin, pecah jadi tahap
Dampak rendah	Batch — kerjain barengan Jumat	Tolak, atau tawarin self-service

Kotak kanan bawah yang paling sering bikin analyst kelelahan. Request yang makan 2 hari, hasilnya dipakai sekali, terus dilupain.

Cara ngukur dampak tanpa debat: tanya berapa rupiah keputusan yang nyangkut. Request buat nentuin alokasi budget iklan Rp 400 juta dampaknya jelas beda dari request buat ngerapiin format laporan.

Kotak kiri bawah — dampak rendah, usaha rendah — jangan dikerjain satu-satu. Kumpulin, kerjain barengan sekali seminggu. Konteks switching itu mahal.

Langkah 3: time block, dua blok besar per minggu

Kerjaan analis butuh konsentrasi panjang. Query yang rumit nggak bisa dikerjain di sela-sela 20 menit antar meeting.

Ini pembagian yang aku pakai:

Hari	Blok	Isi
Senin	Pagi	Triase request minggu ini, balas semua yang masuk
Selasa–Rabu	Full	Kerja dalam — dashboard, data model, analisis besar
Kamis	Pagi	Request dampak tinggi usaha rendah
Jumat	Pagi	Batch request kecil, dokumentasi
Jumat	Sore	Otomatisasi — apa yang minggu ini kamu kerjain 3x manual?

Selasa dan Rabu itu yang harus dijaga mati-matian. Blokir kalender, matiin notifikasi, dan jangan terima meeting kecuali beneran genting.

Jumat sore buat otomatisasi itu investasi. Kalau kamu 3 kali seminggu ngejalanin query yang sama dengan tanggal beda, itu kandidat pertama buat dijadwalin otomatis.

Langkah 4: bangun template query yang bisa dipakai ulang

Sebagian besar request ad-hoc itu variasi dari 5–6 pola yang sama.

Simpan template-nya di satu tempat, kasih parameter, tinggal ganti tanggal.

-- Template: performa penjualan per dimensi
-- Ganti {{DIMENSI}} dengan: kota, kategori, channel, atau sales_id
-- Ganti {{TGL_AWAL}} dan {{TGL_AKHIR}} sesuai request

WITH periode_ini AS (
    SELECT
        {{DIMENSI}},
        SUM(total_belanja) AS revenue,
        COUNT(DISTINCT id) AS jml_transaksi,
        COUNT(DISTINCT pelanggan_id) AS jml_pelanggan
    FROM transaksi
    WHERE status = 'selesai'
      AND tanggal_transaksi BETWEEN '{{TGL_AWAL}}' AND '{{TGL_AKHIR}}'
    GROUP BY {{DIMENSI}}
),
periode_lalu AS (
    SELECT
        {{DIMENSI}},
        SUM(total_belanja) AS revenue_lalu
    FROM transaksi
    WHERE status = 'selesai'
      AND tanggal_transaksi BETWEEN
          '{{TGL_AWAL}}'::date - INTERVAL '1 month'
      AND '{{TGL_AKHIR}}'::date - INTERVAL '1 month'
    GROUP BY {{DIMENSI}}
)
SELECT
    i.{{DIMENSI}},
    i.revenue,
    l.revenue_lalu,
    ROUND(
        100.0 * (i.revenue - l.revenue_lalu) / NULLIF(l.revenue_lalu, 0),
        1
    ) AS growth_persen,
    i.jml_transaksi,
    ROUND(i.revenue / NULLIF(i.jml_transaksi, 0)) AS avg_transaksi
FROM periode_ini i
LEFT JOIN periode_lalu l USING ({{DIMENSI}})
ORDER BY i.revenue DESC;

Satu template ini nutupin request "penjualan per kota", "penjualan per kategori", dan "penjualan per channel" sekaligus. Ganti satu kata.

Yang bikin template ini kepakai: kolom growth-nya udah ikut. Stakeholder yang minta angka mentah hampir selalu bakal nanya "ini naik apa turun dibanding bulan lalu?" 10 menit kemudian.

Jawab duluan. Hemat satu putaran bolak-balik.

Kalau CTE masih asing, itu cara mecah query panjang jadi blok-blok yang kebaca. Fungsi NULLIF di situ buat nyegah error kalau revenue bulan lalu kebetulan nol.

Langkah 5: skrip buat nunda request tanpa bikin ribut

Ini bagian yang paling bikin analyst gugup. Padahal polanya cuma satu.

Jangan bilang "nggak bisa". Bilang "bisa, tapi ini yang harus digeser."

Contoh balasan yang aku pakai:

"Bisa dikerjain. Estimasi 1,5 hari.

Antrean aku minggu ini: dashboard forecast buat rapat board (Rabu), analisis churn buat tim retensi (Kamis).

Kalau ini mau masuk minggu ini, salah satu dari dua itu mundur ke minggu depan. Yang mana yang boleh mundur?"

Tiga hal terjadi setelah pesan ini.

Pertama, kamu nggak nolak — kamu bikin biayanya kelihatan. Kedua, keputusan trade-off pindah ke orang yang punya wewenang. Ketiga, dan ini yang paling sering, request-nya mundur sendiri.

Dari pengalamanku, sekitar 6 dari 10 request "urgent" jadi nggak urgent begitu orangnya harus milih apa yang dikorbanin.

Buat request yang beneran nggak layak dikerjain, tawarin alternatif:

"Angka ini udah ada di dashboard penjualan, tab 'Per Kota'. Aku kirim link-nya — kalau ada yang nggak jelas, aku bantu 10 menit di call."

Ngajarin sekali lebih hemat daripada ngerjain 12 kali.

Contoh kasus: 47 request jadi 21 dalam 6 minggu

Ini data dari satu tim data 2 orang yang support 34 karyawan di perusahaan retail.

Sebelum sistem dipasang — rata-rata sebulan:

• 47 request masuk (WhatsApp 21, Slack 15, email 8, colekan langsung 3)
• 19 hasilnya nggak pernah dibuka lagi
• Rata-rata 2 jam per request habis buat klarifikasi bolak-balik
• 0 hari kerja yang bebas interupsi

Setelah 6 minggu:

Metrik	Sebelum	Sesudah
Request masuk per bulan	47	21
Berhenti di intake form	—	11
Diselesaikan lewat dashboard yang udah ada	—	9
Waktu klarifikasi rata-rata	2 jam	15 menit
Hari kerja dalam per minggu	0	2

Yang paling ngagetin: 9 request diselesaikan sama dashboard yang udah ada dari 4 bulan lalu. Orang nggak tau dashboard itu ada.

Jadi masalahnya sebagian bukan beban kerja. Masalahnya distribusi — kerjaan yang udah selesai nggak ketemu sama orang yang butuh.

Aksi yang paling murah dari semua ini: bikin satu halaman berisi daftar dashboard yang ada, dengan satu kalimat penjelasan tiap dashboard jawab pertanyaan apa. Makan waktu 40 menit. Ngilangin 9 request per bulan.

Kesalahan umum waktu nerapin sistem ini

Bikin form yang kepanjangan. Lebih dari 6 pertanyaan, orang bakal balik ke WhatsApp. Lima cukup.

Ngasih pengecualian buat bos. Sekali kamu terima request bos lewat DM, sistemnya mati. Semua orang bakal ikut.

Nggak pernah nunjukin antrean. Kalau stakeholder nggak bisa lihat kamu lagi ngerjain apa, mereka bakal ngira kamu nganggur. Bikin antrean itu publik.

Otomatisasi terlalu dini. Jangan bikin pipeline buat laporan yang baru diminta sekali. Tunggu sampai request-nya berulang 3 kali.

Buat kerangka prioritas yang lebih formal, prinsip appetite dari Shape Up-nya Basecamp lumayan cocok dipinjam buat tim data — tentuin dulu berapa waktu yang layak dihabiskan, baru desain solusinya.

FAQ

Gimana cara nolak request dari stakeholder tanpa bikin ribut?

Jangan bilang "nggak bisa". Bilang "bisa, tapi ini yang harus digeser". Tunjukin daftar antrean kamu dan minta mereka yang mutusin mana yang turun prioritas. Ini mindahin keputusan trade-off ke orang yang punya wewenang, dan biasanya request yang nggak penting bakal mundur sendiri begitu mereka lihat biayanya.

Berapa banyak request ad-hoc yang wajar per minggu?

Nggak ada angka baku, tapi patokan yang aku pakai: kalau lebih dari 40% waktu kamu habis buat request dadakan, sistemnya yang rusak, bukan kamu yang lambat. Sisakan minimal 2 hari penuh per minggu buat kerjaan yang punya dampak panjang — bikin dashboard, rapiin data model, atau otomatisasi laporan rutin.

Perlu nggak pakai tool khusus buat ngatur request?

Nggak. Google Form yang nyambung ke Sheets udah cukup buat tim di bawah 30 orang, dan gratis. Yang penting bukan tool-nya, tapi apakah semua request lewat satu pintu. Request yang masuk lewat WhatsApp jam 9 malam nggak akan pernah ke-track, sebagus apa pun tool yang kamu bayar.

Gimana cara ngurangin request yang berulang?

Cek request 3 bulan terakhir dan hitung mana yang polanya sama. Kalau ada 5 orang beda nanya angka penjualan per kota tiap minggu, itu bukan 5 request — itu satu dashboard yang belum dibikin. Dari yang aku lihat, 30–40% request ad-hoc bisa hilang cuma dengan satu dashboard self-service yang bener.

Apa yang harus ada di intake form request data?

Empat hal: keputusan apa yang mau diambil dari data ini, kapan deadline-nya dan kenapa, siapa yang bakal pakai hasilnya, dan apa yang terjadi kalau request ini nggak dikerjain. Pertanyaan terakhir yang paling ampuh — sekitar seperempat request bakal berhenti di situ karena si peminta sadar sendiri hasilnya nggak akan dipakai.

Penutup

Sistem ini nggak bikin kamu nulis query lebih cepat. Sistem ini ngurangin jumlah query yang nggak perlu kamu tulis.

Mulai dari yang paling murah: bikin satu halaman daftar dashboard yang udah ada. Di tim yang aku bantu, itu doang ngilangin 9 dari 47 request per bulan.

Habis itu baru pasang intake form-nya.

Mau bikin dashboard self-service yang beneran dipakai orang, bukan cuma dibuka sekali? Mampir ke panduan prinsip desain dashboard. Dan buat rapiin query yang bakal dibaca orang lain, cek SQL style guide.