Artificial Intelligence semakin pintar.
Algoritma semakin canggih.
Dashboard semakin interaktif.
Sistem dapat memproses ratusan ribu bahkan jutaan baris data dalam waktu yang sebelumnya sulit dibayangkan.
Tetapi ada satu persoalan lama yang tidak otomatis hilang karena teknologi semakin maju:
bagaimana jika data yang dianalisis ternyata tidak benar?
Sebuah sistem dapat menghitung dengan sangat cepat.
Namun jika terdapat transaksi ganda, tanggal tidak konsisten, identitas berbeda untuk entitas yang sama, nilai kosong, format angka keliru, atau hubungan antar-data yang salah, kecepatan justru membuat kesalahan tersebut diproses lebih cepat.
Karena itu sebelum berbicara tentang AI, predictive analytics, anomaly detection, atau berbagai model canggih lainnya, terdapat satu fondasi yang harus diperhatikan:
Data Quality.
Ketika Angka Terlihat Benar, Tetapi Sebenarnya Salah
Bayangkan sebuah dataset berisi transaksi selama satu tahun.
Dashboard menunjukkan:
Total transaksi: Rp125 miliar
Angkanya terlihat jelas.
Sistem menghitungnya dengan benar.
Tetapi kemudian diketahui terdapat 300 transaksi yang tercatat dua kali akibat proses integrasi data.
Apakah Rp125 miliar masih menggambarkan kondisi sebenarnya?
Belum tentu.
Masalahnya bukan pada rumus penjumlahan.
Masalahnya berada pada data yang diberikan kepada rumus tersebut.
Komputer melakukan apa yang diperintahkan dengan sempurna.
Ia menjumlahkan seluruh baris.
Tetapi komputer tidak otomatis mengetahui bahwa beberapa baris seharusnya tidak dihitung dua kali.
Inilah perbedaan antara:
calculation accuracy
dan
data validity.
Perhitungannya dapat benar secara matematis, tetapi hasil akhirnya tetap menyesatkan jika data dasarnya tidak valid.
Garbage In, Garbage Out Masih Berlaku
Istilah Garbage In, Garbage Out sudah lama dikenal dalam dunia komputasi.
Maknanya sederhana:
Jika input yang diberikan buruk, output yang dihasilkan juga berpotensi buruk.
Prinsip ini justru semakin penting ketika analytics semakin otomatis.
Bayangkan sistem dapat menghasilkan 50 insight hanya dalam beberapa detik.
Jika kualitas datanya baik, kemampuan tersebut sangat berguna.
Tetapi jika terdapat masalah mendasar pada data, sistem dapat menghasilkan 50 insight yang terlihat meyakinkan tetapi dibangun dari fondasi yang salah.
Semakin profesional tampilannya, semakin berbahaya hasil yang salah tersebut karena manusia cenderung mempercayainya.
Karena itu teknologi yang lebih pintar harus diikuti dengan mekanisme validasi yang lebih kuat.
Data Kosong Tidak Selalu Berarti Nol
Salah satu persoalan sederhana yang sering menyebabkan kesalahan interpretasi adalah missing value.
Misalnya sebuah kolom mencatat nilai transaksi.
Beberapa baris kosong.
Apa arti kosong tersebut?
Apakah nilainya nol?
Belum dimasukkan?
Tidak tersedia?
Tidak berlaku?
Terjadi kegagalan saat ekspor?
Jawabannya dapat sangat berbeda.
Jika seluruh nilai kosong otomatis diubah menjadi nol, rata-rata transaksi dapat turun.
Jika seluruh baris kosong dibuang, jumlah transaksi dapat berubah.
Jika dibiarkan, beberapa perhitungan mungkin tidak dapat dilakukan.
Karena itu sistem analytics tidak boleh hanya melihat:
“Ada 1.250 nilai kosong.”
Pertanyaan yang lebih penting adalah:
“Apa arti nilai kosong tersebut dalam konteks proses bisnis?”
Sekali lagi, analytics membutuhkan konteks.
Duplikasi Dapat Mengubah Seluruh Cerita
Masalah berikutnya adalah duplicate data.
Bayangkan terdapat transaksi:
TRX-001 | Vendor A | Rp500 juta
Kemudian transaksi yang sama muncul dua kali.
Sistem dapat menganggapnya sebagai dua transaksi berbeda.
Akibatnya:
jumlah transaksi meningkat,
total nilai meningkat,
frekuensi Vendor A meningkat,
ranking vendor berubah,
bahkan pola anomali dapat ikut berubah.
Satu kesalahan kecil dapat menyebar ke banyak hasil analisis.
Karena itu pemeriksaan duplikasi bukan pekerjaan administratif yang membosankan.
Ia merupakan bagian dari analytical integrity.
Nama Berbeda Bisa Merujuk pada Entitas yang Sama
Masalah kualitas data tidak selalu berupa angka salah.
Kadang persoalannya adalah konsistensi identitas.
Misalnya:
PT Maju Jaya
PT. Maju Jaya
Maju Jaya, PT
PT MAJU JAYA
Bagi manusia, kemungkinan besar semuanya merujuk pada entitas yang sama.
Tetapi sistem dapat menganggapnya sebagai empat vendor berbeda.
Akibatnya analisis konsentrasi vendor menjadi terpecah.
Vendor yang sebenarnya memiliki 40 transaksi mungkin terlihat sebagai empat vendor dengan masing-masing 10 transaksi.
Sekarang pola penting dapat tersembunyi bukan karena algoritmanya lemah, tetapi karena identitas datanya tidak konsisten.
Inilah mengapa proses normalisasi dan entity resolution sangat penting dalam analytics.
Format yang Sama Belum Tentu Memiliki Makna yang Sama
Misalnya terdapat dua kolom:
Nilai
dan
Total
Keduanya berisi angka rupiah.
Apakah keduanya sama?
Belum tentu.
Nilai mungkin berarti nilai kontrak.
Total mungkin berarti realisasi pembayaran.
Atau sebaliknya.
Secara teknis keduanya sama-sama numeric.
Tetapi secara semantik keduanya berbeda.
Analytics tidak cukup hanya memahami tipe data.
Sistem juga perlu memahami makna data.
Di sinilah konsep seperti schema understanding dan column mapping menjadi penting.
Sebelum menganalisis:
Kenali dulu apa yang sebenarnya direpresentasikan oleh setiap kolom.
Outlier Bisa Menjadi Kesalahan Data atau Temuan Penting
Bayangkan sebagian besar transaksi berada antara Rp10 juta sampai Rp500 juta.
Kemudian terdapat satu transaksi:
Rp85 miliar.
Nilai tersebut sangat berbeda.
Tetapi kita belum tahu penyebabnya.
Ada beberapa kemungkinan.
Pertama, transaksi tersebut memang benar dan merupakan proyek besar.
Kedua, terjadi kesalahan input.
Mungkin seharusnya:
Rp850 juta
tetapi salah memasukkan angka nol.
Ketiga, format data berubah saat proses impor.
Keempat, transaksi tersebut memang merupakan kondisi tidak biasa yang perlu diperiksa lebih lanjut.
Karena itu anomaly detection dan data quality memiliki hubungan yang sangat dekat.
Sesuatu yang tidak biasa dapat menjadi temuan, tetapi dapat pula menjadi masalah kualitas data.
Sistem harus mampu membedakan keduanya melalui evidence dan verifikasi.
Konsistensi Waktu Juga Penting
Tanggal sering dianggap sederhana.
Padahal format tanggal merupakan salah satu sumber masalah paling umum.
Misalnya:
01/02/2026
Apakah itu:
1 Februari 2026?
atau
2 Januari 2026?
Tergantung format yang digunakan.
Masalah semakin kompleks jika dataset menggabungkan beberapa sumber.
Satu sistem menggunakan:
DD/MM/YYYY
Sistem lain:
MM/DD/YYYY
Sistem berikutnya:
YYYY-MM-DD
Jika tanggal salah ditafsirkan, analisis tren dapat berubah.
Transaksi yang sebenarnya terjadi Februari dapat dianggap terjadi Januari.
Lonjakan bulanan dapat muncul hanya karena kesalahan parsing.
Sekali lagi, grafiknya mungkin terlihat sangat profesional.
Tetapi cerita yang disampaikan grafik tersebut salah.
Jangan Membersihkan Data Secara Membabi Buta
Data cleaning memang penting.
Namun terdapat jebakan lain:
terlalu agresif membersihkan data.
Misalnya sebuah nilai ekstrem langsung dihapus karena dianggap outlier.
Padahal mungkin justru nilai tersebut merupakan informasi paling penting dalam dataset.
Atau beberapa transaksi yang terlihat duplikat langsung dihapus.
Padahal ternyata transaksi tersebut memang terjadi dua kali secara sah.
Karena itu data cleaning seharusnya tidak berarti:
“hapus semua yang terlihat aneh.”
Pendekatan yang lebih baik:
Detect → Flag → Verify → Decide.
Temukan masalah potensial.
Tandai.
Periksa evidence.
Barulah tentukan tindakan.
Dengan demikian proses pembersihan data tidak menghilangkan informasi penting secara tidak sengaja.
Data Quality Bukan Hanya Tugas Tim IT
Sering kali kualitas data dianggap sebagai urusan teknis.
Padahal banyak masalah data hanya dapat dipahami oleh orang yang mengetahui proses bisnis.
Programmer mungkin dapat melihat:
Kolom ini memiliki 35% missing value.
Tetapi pengguna bisnis yang memahami proses dapat menjelaskan:
Kolom tersebut memang kosong untuk transaksi dengan kategori tertentu.
Analis dapat menemukan:
Nomor rekening digunakan oleh beberapa entitas.
Tetapi subject-matter expert perlu menentukan apakah kondisi tersebut normal atau membutuhkan pemeriksaan.
Karena itu kualitas data membutuhkan kolaborasi antara:
teknologi + analytics + domain knowledge.
Tidak satu pun cukup berdiri sendiri.
Data Quality Harus Menjadi Bagian dari Sistem
Dalam sistem analytics yang matang, pemeriksaan kualitas data sebaiknya tidak dilakukan hanya ketika terjadi masalah.
Ia menjadi bagian dari alur standar.
Misalnya:
Upload Data
↓
Structure Understanding
↓
Data Quality Check
↓
Column Mapping
↓
Validation
↓
Analysis
↓
Evidence
Dengan pola tersebut, sistem dapat memberikan informasi kepada pengguna sebelum analisis dimulai:
5.000 baris ditemukan
12 kolom terdeteksi
37 nilai kosong
8 kemungkinan duplikasi
2 kolom membutuhkan konfirmasi
1 format tanggal tidak konsisten
Pengguna sekarang mengetahui kondisi datanya.
Analytics menjadi lebih transparan.
Confidence Lebih Baik daripada Kepastian Palsu
Sistem analytics tidak selalu harus mengatakan:
“Data ini benar.”
Dalam banyak situasi, pernyataan yang lebih bertanggung jawab adalah:
“Data ini cukup untuk analisis, dengan beberapa catatan.”
Misalnya:
Data Quality: Good
atau:
Data Quality: Requires Review
Kemudian sistem menjelaskan alasannya.
Pendekatan seperti ini lebih sehat dibandingkan memberikan kesan bahwa seluruh dataset sempurna.
Karena data dunia nyata hampir selalu memiliki keterbatasan.
Tujuan analytics bukan menciptakan ilusi kesempurnaan.
Tujuannya adalah mengetahui keterbatasan tersebut sebelum membuat keputusan.
AI Tidak Boleh Menyembunyikan Masalah Data
AI dapat membantu mengenali pola data.
AI dapat membantu memetakan nama kolom.
AI dapat membantu mendeteksi ketidakkonsistenan.
AI bahkan dapat membantu menjelaskan kemungkinan masalah.
Tetapi AI tidak boleh membuat pengguna lupa bahwa evidence tetap berasal dari data.
Jika AI memberikan kesimpulan dengan bahasa yang sangat meyakinkan, pengguna harus tetap dapat melihat:
Data apa yang digunakan?
Kolom mana?
Berapa jumlah record?
Apa yang dikecualikan?
Apakah terdapat missing value?
Apakah terdapat perubahan atau normalisasi?
Dengan demikian AI mempercepat pemahaman tanpa menghilangkan transparansi.
Understand → Evidence → Analyze → Solve → Improve
Kualitas data memiliki posisi penting dalam Thinking DNA ini.
Understand
Pahami struktur dan makna data.
Evidence
Pastikan data cukup relevan, valid, konsisten, dan dapat ditelusuri.
Analyze
Barulah gunakan metode analisis yang sesuai.
Solve
Gunakan hasilnya untuk menentukan pilihan atau tindakan.
Improve
Perbaiki tidak hanya analisis, tetapi juga proses yang menghasilkan data.
Tahap terakhir sangat penting.
Jika masalah yang sama terus muncul pada dataset setiap bulan, solusi terbaik mungkin bukan terus membersihkan data.
Solusinya adalah memperbaiki sumber proses yang menghasilkan data buruk tersebut.
Analytics akhirnya membantu memperbaiki sistem, bukan sekadar memperbaiki spreadsheet.
Kesimpulan
Teknologi analytics akan terus berkembang.
Model AI akan semakin pintar.
Komputasi akan semakin cepat.
Kemampuan analisis akan semakin luas.
Namun satu prinsip tidak berubah:
keputusan yang baik membutuhkan evidence yang dapat dipercaya.
Data yang buruk dapat menghasilkan grafik yang bagus.
Data yang buruk dapat menghasilkan dashboard yang modern.
Data yang buruk bahkan dapat menghasilkan jawaban AI yang terdengar sangat meyakinkan.
Tetapi tampilan profesional tidak dapat menggantikan kualitas evidence.
Karena itu sebelum bertanya:
“Insight apa yang bisa kita dapatkan?”
Ada pertanyaan yang harus datang lebih dahulu:
“Seberapa jauh kita dapat mempercayai data yang digunakan untuk menghasilkan insight tersebut?”
Data analytics yang matang tidak terburu-buru menghitung.
Ia memastikan fondasinya terlebih dahulu.
Karena pada akhirnya:
Analisis hanya sekuat data yang menjadi evidence-nya.
Dan ketika kualitas data menjadi bagian dari proses, analytics tidak hanya menjadi lebih canggih.
Analytics menjadi lebih dapat dipercaya.
ArrezaMP — Data Analytics • Problem Solving • Digital Solutions
0 Komentar