Apa Arti Sebenarnya dari "Lagi Analisis Data"?

Ada satu momen yang saya ingat betul waktu masih junior dulu. Manager saya nanya progress laporan, dan saya jawab, "masih analisis data, Pak." Dia manggut-manggut, seolah paham. Padahal kalau ditelusuri, tiga jam terakhir saya habiskan buat mastiin kenapa angka revenue di satu tabel beda sendiri dibanding tabel lain. Bukan analisis dalam artian yang orang bayangkan, tapi lebih ke: kenapa data ini nggak masuk akal.

Menurut diskusi di Reddit, banyak data analyst ngerasain hal yang sama: pekerjaan sehari-hari mereka jauh lebih luas dari sekadar "analisis" yang keliatan keren di LinkedIn. Ada proses bersihin data, nulis query berkali-kali, bikin dashboard yang belum tentu dipakai, sampai nerjemahin angka jadi rekomendasi yang bisa dimengerti orang non-teknis. Nah, di tulisan ini saya mau breakdown apa yang sebenarnya terjadi di balik kalimat "lagi analisis data", khususnya dari sisi analytics yang paling sering disalahpahami.

Data Wrangling: Bagian yang Paling Makan Waktu Tapi Jarang Dibahas

Kalau saya harus jujur, sebagian besar waktu kerja saya sebagai analyst nggak dihabiskan buat mikirin insight yang wow. Justru habis buat mastiin data yang saya pegang itu bener. Prosesnya dimulai dari business understanding, ngerti dulu apa yang sebenarnya ditanyakan stakeholder, baru masuk ke requirement understanding biar nggak salah arah. Setelah itu baru masuk ke data understanding, ngecek struktur tabel, kolom mana yang relevan, dan gimana relasi antar tabelnya.

Setelah itu baru masuk ke sanity check. Ini tahap yang sering diremehin padahal krusial banget. Saya pernah nemu kasus di mana angka transaksi tiba-tiba naik 300% dalam sehari. Bukan karena bisnis lagi bagus-bagusnya, tapi karena ada duplikasi data akibat sistem yang re-submit otomatis. Kalau saya nggak sanity check dulu, insight yang saya kasih ke stakeholder bisa salah total, dan itu bisa berujung ke keputusan bisnis yang keliru.

Setelah data dipastikan bersih, baru masuk proses cleaning, aggregation prep, sampai kadang bikin data pipeline sederhana biar prosesnya nggak perlu diulang manual tiap kali ada request baru. Ini semua masuk kategori analytics, meskipun keliatannya "cuma" beres-beres data. Justru di sinilah prinsip garbage in garbage out itu benar-benar berlaku. Data yang berantakan di awal, se-canggih apapun model atau visualisasi di ujungnya, hasilnya tetap nggak bisa dipercaya.

Pulling Data dan Visualization: Antara Ad-hoc Request dan Dashboard yang Beneran Dipakai

Bagian kedua dari kerja analytics yang sering kejadian adalah pulling data untuk menjawab pertanyaan mendadak dari stakeholder. Bentuknya bisa macam-macam. Kadang cuma satu angka simpel kayak "berapa total user aktif bulan lalu", tapi kadang juga pertanyaan yang lebih kompleks kayak "kenapa retention rate turun di segmen tertentu". Uniknya, pertanyaan yang keliatan simpel itu justru sering butuh effort paling besar, karena harus define dulu apa itu "user aktif" menurut standar bisnis yang berlaku.

Nah, soal dashboard, saya dulu sempat punya asumsi yang keliru. Saya pikir semakin lengkap dan estetik dashboard-nya, semakin gampang juga stakeholder mengambil keputusan. Ternyata nggak sesederhana itu. Saya pernah bikin dashboard dengan puluhan visualisasi, lengkap dengan filter dan drill-down, tapi ternyata yang dibuka cuma satu angka di pojok kiri atas. Sisanya nggak pernah disentuh.

Dari situ saya baru sadar, dashboard yang baik bukan soal seberapa banyak informasi yang bisa ditampilkan, tapi seberapa jelas dashboard itu menjawab satu pertanyaan spesifik yang emang dibutuhkan orang yang pakai. Ini bagian dari kerja analytics yang jarang keliatan dari luar: proses bolak-balik nanya ke stakeholder, "sebenarnya kamu mau tahu apa dari data ini?" Kadang jawabannya nggak langsung jelas, dan justru proses menggali pertanyaan itu yang makan waktu paling lama, bukan proses bikin chart-nya.

Statistical Analysis: Bagian yang Paling Sedikit Tapi Paling Dianggap "Analisis Beneran"

Ironisnya, bagian yang paling sering dibayangkan orang saat denger kata "data analyst", yaitu analisis statistik yang dalam, justru porsinya paling kecil dari keseluruhan kerja analytics. Ini termasuk menguji hipotesis dari sebuah eksperimen, misalnya A/B test buat fitur baru, atau deep dive buat nyari tahu pola perilaku pengguna dan performa produk maupun konten.

Saya pernah pegang eksperimen yang hasilnya nggak sesuai ekspektasi tim product. Kita berharap fitur baru bakal naikin conversion, tapi setelah dianalisis secara statistik, hasilnya nggak signifikan. Yang menarik, justru dari situ saya belajar bahwa hasil yang "gagal" secara statistik tetap punya value, asal kita jujur menyampaikannya. Daripada maksain nyari pola yang sebenarnya nggak ada, lebih baik bilang terus terang bahwa datanya belum cukup kuat buat bikin klaim itu.

Proses statistical analysis ini juga biasanya nggak berdiri sendiri. Sebelum masuk ke situ, ada proses peer review, baik itu review terhadap kode yang dipakai, slide presentasi, sampai logika analisisnya sendiri. Ini penting banget karena analisis statistik gampang banget disalahartikan kalau nggak dijelaskan konteksnya dengan benar. Angka signifikan secara statistik belum tentu signifikan secara bisnis, dan sebaliknya. Di titik inilah kerja analytics beririsan langsung dengan kemampuan komunikasi, bukan cuma kemampuan teknis semata.

Kenapa Ketiga Bagian Ini Sering Disamaratakan Jadi "Analisis Data"

Kalau saya pikir-pikir lagi, mungkin masalahnya ada di bahasa yang kita pakai sehari-hari. Kalimat "lagi analisis data" itu praktis, gampang diucapkan, tapi menyembunyikan banyak sekali proses di baliknya. Buat orang di luar tim data, kalimat itu terdengar seperti satu aktivitas tunggal. Padahal di dalamnya ada data wrangling yang makan waktu berjam-jam, ada proses pulling data yang harus bolak-balik klarifikasi kebutuhan, dan ada statistical analysis yang butuh ketelitian ekstra biar kesimpulannya nggak salah kaprah.

Saya sendiri butuh waktu cukup lama buat sadar bahwa ekspektasi orang lain terhadap kata "analisis" itu seringkali nggak sama dengan apa yang benar-benar saya kerjakan. Stakeholder mungkin membayangkan saya lagi nemuin insight-insight tersembunyi kayak di film-film, padahal kenyataannya saya lagi struggling nyari tahu kenapa ada baris data yang hilang di satu sumber tapi ada di sumber lain.

Menariknya, gap ekspektasi ini justru bisa jadi masalah kalau nggak dikomunikasikan dengan baik. Kalau stakeholder mikir analisis itu instan, mereka bisa frustrasi kenapa laporan yang diminta belum kelar-kelar. Padahal dari sisi analyst, waktu yang terpakai itu emang perlu buat mastiin hasil akhirnya bisa dipercaya. Di sinilah saya belajar bahwa bagian penting dari kerja analytics bukan cuma soal teknis mengolah data, tapi juga soal gimana cara menjelaskan proses itu ke orang yang nggak paham detail teknisnya, tanpa bikin mereka ngerasa dibohongin atau dikasih excuse.

Jadi kalau ada yang nanya, sebenarnya apa sih yang dilakukan data analyst saat bilang lagi analisis data, jawaban paling jujur yang bisa saya kasih adalah: tergantung di fase mana. Bisa jadi lagi bersihin data yang berantakan, bisa jadi lagi cari cara terbaik buat visualisasiin angka biar gampang dimengerti, atau bisa juga lagi nguji apakah pola yang keliatan itu beneran ada atau cuma kebetulan. Ketiganya sama-sama penting, dan ketiganya sama-sama layak disebut kerja analytics, meskipun porsinya jauh dari seimbang.

Memahami proporsi kerja ini penting, baik buat kamu yang baru mulai karier sebagai analyst maupun buat kamu yang bekerja bareng analyst sebagai stakeholder. Kalau ekspektasinya lebih realistis, komunikasi soal timeline dan hasil juga jadi lebih sehat. Langkah praktis yang bisa kamu coba mulai sekarang adalah, lain kali saat ada yang bilang "lagi analisis data", coba tanya lebih spesifik: lagi di tahap wrangling, pulling, atau statistical analysis. Jawaban itu bakal ngasih gambaran lebih jelas soal seberapa jauh progressnya, dan seberapa besar effort analytics yang sebenarnya sedang dikerjakan.