Ketika seseorang menerima sebuah file Excel, pertanyaan pertama yang sering muncul adalah:
“Data ini bisa dianalisis menjadi apa?”
Pertanyaan tersebut terlihat sederhana. Namun dalam praktiknya, jawabannya tidak selalu sederhana.
Satu file dapat berisi transaksi pengadaan. File lain berisi realisasi anggaran. Dataset berikutnya mungkin berisi absensi pegawai, penerimaan daerah, log keamanan sistem, atau daftar vendor.
Bahkan ketika dua file membahas hal yang sama, nama kolomnya belum tentu sama.
Satu file menggunakan Nama Vendor.
File lain menggunakan Penyedia.
File berikutnya mungkin menggunakan Nama Rekanan.
Bagi manusia yang memahami konteksnya, ketiganya mungkin memiliki arti yang hampir sama.
Bagi sistem, ketiganya hanyalah tiga nama kolom berbeda sampai ada mekanisme yang memahami maknanya.
Di sinilah persoalan data analytics menjadi lebih menarik.
Tantangannya bukan hanya membuat semakin banyak rumus analisis.
Tantangan yang lebih besar adalah membangun kemampuan untuk memahami data terlebih dahulu sebelum menentukan bagaimana data tersebut harus dianalisis.
Jangan Langsung Menganalisis Data yang Belum Dipahami
Bayangkan seseorang mengunggah sebuah Excel dengan 100.000 baris.
Sistem langsung menjalankan berbagai algoritma.
Ia menghitung rata-rata.
Mencari nilai ekstrem.
Membuat ranking.
Mengelompokkan transaksi.
Mencari korelasi.
Dalam hitungan detik, puluhan temuan muncul.
Terlihat mengesankan.
Tetapi ada satu pertanyaan penting:
Apakah sistem benar-benar memahami isi file tersebut?
Jika sebuah kolom dianggap sebagai nilai transaksi padahal sebenarnya merupakan nilai pagu, seluruh analisis berikutnya dapat kehilangan konteks.
Jika kolom tanggal salah dikenali, analisis tren waktu menjadi tidak relevan.
Jika identitas vendor tidak dipahami dengan benar, hubungan antartransaksi juga dapat menghasilkan interpretasi yang keliru.
Karena itu analisis yang baik tidak seharusnya dimulai dari algoritma.
Ia dimulai dari pemahaman terhadap data.
Data Intake Seharusnya Menjadi Gerbang Pertama
Sebuah sistem analisis yang fleksibel membutuhkan lapisan pertama yang dapat kita sebut sebagai Data Intake.
Tugasnya bukan mencari anomali.
Bukan membuat dashboard.
Bukan memberikan rekomendasi.
Tugas pertamanya jauh lebih mendasar:
mengenali apa yang baru saja diberikan oleh pengguna.
Berapa banyak file?
Berapa jumlah baris?
Kolom apa saja yang tersedia?
Tipe datanya apa?
Apakah terdapat data kosong?
Apakah terdapat duplikasi?
Apakah format tanggal konsisten?
Apakah beberapa file tampaknya memiliki hubungan?
Pertanyaan sederhana tersebut menjadi fondasi seluruh proses berikutnya.
Karena semakin baik sistem memahami struktur awal data, semakin kecil kemungkinan analisis dibangun di atas asumsi yang salah.
Masalah Nama Kolom yang Berbeda
Dalam dunia nyata, data jarang datang dalam format yang sempurna.
Misalnya tiga organisasi memiliki informasi vendor yang sama tetapi menyimpannya seperti berikut:
Dataset A
Vendor
Nilai
Tanggal
Dataset B
Nama Penyedia
Nilai Kontrak
Tanggal Transaksi
Dataset C
Rekanan
Nominal
Tgl
Manusia dapat melihat kemungkinan hubungan di antara kolom tersebut.
Sistem analisis yang fleksibel juga membutuhkan kemampuan serupa.
Caranya bukan memaksa seluruh pengguna mengganti nama kolom secara manual.
Sistem dapat memiliki canonical field.
Misalnya:
vendor_name
transaction_value
transaction_date
Kemudian kolom dari file pengguna dipetakan ke struktur tersebut.
Vendor, Nama Penyedia, dan Rekanan dapat diperkirakan sebagai kandidat untuk vendor_name.
Namun sistem tidak harus selalu merasa paling tahu.
Jika terdapat ketidakpastian, pengguna dapat mengonfirmasi atau memperbaiki mapping tersebut.
Dengan demikian automation membantu mempercepat pekerjaan tanpa menghilangkan kontrol manusia.
Data Quality Sebelum Insight
Setelah struktur data dipahami, tahap berikutnya bukan langsung mencari temuan.
Kualitas data perlu diperiksa.
Apakah terdapat nilai kosong?
Apakah satu transaksi muncul dua kali?
Apakah format angka konsisten?
Apakah terdapat tanggal yang tidak masuk akal?
Apakah sebuah identifier seharusnya unik tetapi ternyata digunakan berkali-kali?
Masalah seperti ini terlihat sederhana, tetapi dapat mengubah hasil analisis secara signifikan.
Misalnya sebuah transaksi tercatat dua kali akibat proses ekspor.
Jika sistem langsung melakukan ranking vendor, vendor tertentu dapat terlihat memiliki aktivitas lebih tinggi daripada kondisi sebenarnya.
Karena itu:
garbage in, garbage out tetap berlaku bahkan ketika sistem menggunakan teknologi yang sangat canggih.
AI tidak menghilangkan kebutuhan terhadap kualitas data.
Justru semakin otomatis sebuah sistem, semakin penting validasi dilakukan sebelum analisis berjalan.
Satu Dataset Bisa Memiliki Banyak Perspektif
Hal menarik berikutnya adalah bahwa sebuah dataset tidak selalu hanya cocok untuk satu jenis analisis.
Data transaksi pengadaan, misalnya, dapat dilihat dari berbagai perspektif.
Dari perspektif screening:
Apakah terdapat transaksi dengan karakteristik tidak biasa?
Dari perspektif procurement:
Vendor mana yang paling dominan?
Dari perspektif financial:
Bagaimana tren nilai transaksi terhadap periode sebelumnya?
Dari perspektif relationship analysis:
Apakah terdapat entitas berbeda yang memiliki atribut identitas yang sama?
Dari perspektif general analytics:
Bagaimana distribusi, ranking, tren, dan segmentasinya?
Datanya sama.
Pertanyaannya berbeda.
Karena itulah membangun satu aplikasi terpisah untuk setiap pertanyaan bukan selalu pendekatan paling efisien.
Yang lebih menarik adalah membangun lapisan analisis yang dapat memilih kemampuan berdasarkan kebutuhan data dan pertanyaan pengguna.
Dari Satu Mesin Menuju Banyak Analysis Engine
Bayangkan sebuah sistem bernama Master Analysis.
Pengguna tidak harus mengetahui engine apa yang harus digunakan.
Ia cukup membawa datanya.
Sistem kemudian melakukan:
Data Intake → Schema Understanding → Column Mapping → Validation → Analysis Routing
Setelah itu barulah data diarahkan kepada kemampuan analisis yang relevan.
Misalnya:
Transaction Screening Engine untuk mencari pola transaksi yang membutuhkan perhatian.
Financial Analysis Engine untuk tren anggaran, realisasi, deviasi, atau burn rate.
Procurement Analysis Engine untuk konsentrasi vendor, pola pengadaan, repeat winners, dan distribusi kontrak.
HR Analysis Engine untuk pola absensi, beban kerja, atau anomali payroll.
Revenue Analysis Engine untuk tren penerimaan dan outlier.
Cyber Log Analysis Engine untuk pola login dan aktivitas akses.
Document Analysis Engine untuk ekstraksi serta perbandingan dokumen.
General Data Analysis Engine untuk profiling, ranking, tren, korelasi, dan segmentasi.
Dengan pola seperti ini, sistem tidak menjadi kumpulan aplikasi yang berdiri sendiri.
Ia menjadi ekosistem kemampuan analisis.
Analysis Router: Tidak Semua Data Membutuhkan Semua Analisis
Salah satu kesalahan dalam automation adalah menjalankan seluruh kemampuan terhadap seluruh data.
Padahal tidak semua analisis relevan.
Dataset absensi tidak membutuhkan pemeriksaan konsentrasi vendor.
Log login tidak membutuhkan analisis burn rate anggaran.
Dokumen kontrak tidak diperlakukan seperti tabel transaksi.
Karena itu dibutuhkan Analysis Router.
Router bertugas menentukan:
Data ini memiliki karakteristik apa?
Engine mana yang relevan?
Pertanyaan apa yang dapat dijawab?
Pengguna kemudian dapat melihat pilihan analisis yang masuk akal berdasarkan data yang dimilikinya.
Bukan menghadapi puluhan menu yang sebenarnya tidak relevan.
Teknologi menjadi lebih kompleks di belakang layar agar pengalaman pengguna justru menjadi lebih sederhana.
Beberapa File Bisa Menjadi Satu Cerita
Kemampuan berikutnya yang sangat bernilai muncul ketika pengguna memiliki lebih dari satu dataset.
Misalnya:
File pertama berisi transaksi.
File kedua berisi master vendor.
File ketiga berisi kontrak.
File keempat berisi pembayaran.
Jika masing-masing dianalisis secara terpisah, kita mendapatkan empat kumpulan informasi.
Tetapi jika sistem memahami bahwa beberapa file memiliki hubungan melalui vendor_id, nomor kontrak, tanggal, atau identifier lainnya, analisis dapat berkembang lebih jauh.
Sekarang pertanyaannya tidak lagi:
“Apa isi file ini?”
Tetapi:
“Apa hubungan antara informasi dalam beberapa file tersebut?”
Di sinilah analytics mulai mendekati cara manusia memahami sebuah persoalan.
Kita jarang mengambil keputusan hanya berdasarkan satu tabel.
Kita menghubungkan berbagai evidence untuk membentuk gambaran yang lebih lengkap.
Temuan Harus Tetap Memiliki Evidence
Semakin pintar sebuah sistem analisis, semakin penting hasilnya dapat ditelusuri.
Jika sistem mengatakan:
“Vendor A memiliki konsentrasi transaksi tinggi.”
Pengguna harus dapat melihat transaksi yang menjadi dasar pernyataan tersebut.
Jika sistem menemukan hubungan antarentitas, pengguna harus dapat melihat atribut apa yang sama.
Jika sistem mengatakan terjadi perubahan signifikan, periode pembandingnya harus jelas.
Dengan demikian output bukan hanya:
Finding
tetapi:
Finding + Evidence + Context
Ini penting karena tujuan analytics bukan membuat sistem terlihat pintar.
Tujuannya adalah membantu manusia membuat keputusan yang dapat dipertanggungjawabkan.
AI Seharusnya Menjadi Penerjemah, Bukan Sumber Kebenaran
Dalam sistem seperti ini, AI dapat memberikan pengalaman yang jauh lebih natural.
Pengguna dapat bertanya:
“Apa yang paling perlu saya periksa dari data ini?”
atau:
“Vendor mana yang paling sering menerima transaksi?”
atau:
“Apakah ada perubahan yang tidak biasa dibandingkan tahun sebelumnya?”
AI dapat membantu menerjemahkan bahasa manusia menjadi permintaan analisis.
Namun perhitungan dan evidence tetap sebaiknya berasal dari data yang dapat diverifikasi.
Dengan demikian AI menjadi interface antara manusia dan mesin analisis, bukan mesin yang bebas membuat kesimpulan tanpa dasar.
Kompleksitas di Belakang, Kesederhanaan di Depan
Sistem analytics yang matang mungkin memiliki banyak komponen di belakang layar:
schema understanding,
column mapping,
data validation,
relationship detection,
analysis router,
berbagai analysis engine,
evidence layer,
dan AI interface.
Tetapi pengguna tidak harus memahami semuanya.
Pengalaman idealnya sederhana:
Upload Data
↓
Sistem Memahami Data
↓
Konfirmasi jika diperlukan
↓
Pilih Pertanyaan atau Tujuan Analisis
↓
Sistem Menjalankan Engine yang Sesuai
↓
Lihat Temuan dan Evidence
↓
Tentukan Tindakan
Ini adalah salah satu prinsip penting dalam digital solution.
Kompleksitas teknologi seharusnya diserap oleh sistem, bukan dipindahkan kepada pengguna.
Dari Aplikasi Menjadi Capability
Perubahan cara berpikir terbesar terjadi ketika kita berhenti melihat software sebagai kumpulan halaman dan tombol.
Yang sebenarnya sedang dibangun adalah capability.
Hari ini capability tersebut mungkin digunakan untuk transaction screening.
Besok untuk financial analysis.
Kemudian procurement.
Revenue.
HR.
Cybersecurity.
Dokumen.
Dan kebutuhan lain yang belum kita ketahui hari ini.
Jika fondasinya benar, penambahan kemampuan baru tidak selalu membutuhkan pembangunan sistem dari nol.
Engine baru dapat ditambahkan ke dalam ekosistem yang sama.
Di sinilah digital solution mulai memiliki kemampuan berkembang.
Bukan hanya menyelesaikan satu kebutuhan hari ini, tetapi menyediakan fondasi untuk menghadapi kebutuhan berikutnya.
Understand → Evidence → Analyze → Solve → Improve
Konsep Master Analysis pada akhirnya tetap kembali kepada cara berpikir yang sederhana.
Understand
Pahami data sebelum melakukan analisis.
Evidence
Pastikan struktur, kualitas, dan sumber data dapat dipertanggungjawabkan.
Analyze
Gunakan engine yang sesuai untuk menemukan pola dan informasi penting.
Solve
Terjemahkan temuan menjadi prioritas, pilihan, atau tindakan.
Improve
Pelajari hasilnya dan tambahkan kemampuan analisis ketika kebutuhan baru muncul.
Teknologinya dapat berubah.
Jenis datanya dapat berubah.
Engine-nya dapat bertambah.
Tetapi pola berpikir tersebut tetap sama.
Kesimpulan
Masa depan data analytics bukan hanya tentang membuat algoritma yang semakin canggih.
Tantangan yang lebih menarik adalah membuat analytics semakin mudah digunakan terhadap data dunia nyata yang tidak selalu rapi dan tidak selalu memiliki struktur yang sama.
Sistem harus mampu memahami data.
Memetakan strukturnya.
Memeriksa kualitasnya.
Menentukan analisis yang relevan.
Menghubungkan beberapa sumber.
Menampilkan evidence.
Dan akhirnya membantu manusia menentukan apa yang sebaiknya dilakukan.
Karena pengguna seharusnya tidak perlu memikirkan:
“Saya harus menggunakan engine yang mana?”
Pertanyaan yang jauh lebih natural adalah:
“Saya punya data. Apa yang bisa kita pelajari dari sini?”
Ketika sebuah sistem mampu menjawab pertanyaan tersebut dengan evidence yang dapat diperiksa, kita tidak lagi sekadar membangun dashboard.
Kita mulai membangun mesin untuk membantu manusia memahami data.
ArrezaMP — Data Analytics • Problem Solving • Digital Solutions
0 Komentar