Mengapa dashboard swalayan tidak berhasil
(briefer.cloud)- "self-serve dashboards" pada praktiknya tidak benar-benar berjalan dengan baik. Alasannya, engineer atau data scientist akhirnya menghabiskan banyak waktu untuk menulis kueri dan menyiapkan dashboard bagi pengguna bisnis.
Mengapa "self-serve BI" tidak berhasil
- SQL adalah satu-satunya alat "self-serve BI". Namun, sebagian besar vendor "self-serve BI" mencoba menyamarkan SQL sebagai sesuatu yang lain.
- Menulis kueri SQL bukan satu-satunya hambatan bagi pemangku kepentingan bisnis untuk mengueri data. Mereka tidak memahami makna data, asalnya, atau bagaimana data dihitung, serta tidak tahu cara menafsirkan dan memverifikasi hasilnya.
Percobaan 1: pendekatan "dropdown dan checkbox" yang sudah ada
- Antarmuka ini pada dasarnya hanya mencoba "SQL-by-mouse". Tidak lebih baik daripada SQL, malah lebih lambat, kurang andal, lebih terbatas, dan tidak bisa digeneralisasi ke alat lain.
- Orang seperti CFO tidak akan menggunakan antarmuka ini untuk mengueri data. Mereka tidak punya konteks untuk memahami data dan tidak bisa yakin terhadap hasilnya.
Percobaan 2: pendekatan text-to-SQL
- LLM hampir terlalu efektif dalam menerjemahkan bahasa alami ke SQL. Bahkan saat pertanyaannya tidak tepat, model tetap akan mencoba menghasilkan kueri.
- Orang teknis akan menyadari bahwa pertanyaannya tidak tepat dan akan meminta konteks tambahan. Mereka akan menjelaskan jenis data yang tersedia dan bekerja sama dengan pihak bisnis untuk menyusun pertanyaan yang akurat dan berguna.
- LLM bisa menjadi solusi nyata untuk "self-serve BI", tetapi belum dalam bentuknya saat ini. Model membutuhkan lebih banyak konteks dan harus lebih mampu mengekspresikan ketidakpastian serta meminta informasi tambahan.
Apa yang benar-benar berhasil
- Masalah dalam "self-serve BI" bukanlah SQL, melainkan konteks dan makna data. Solusinya adalah mengajari orang tentang data yang mereka kueri, apa pun antarmukanya.
- Mendokumentasikan seluruh pengetahuan bagi tim teknis menimbulkan overhead yang besar dan cepat menjadi usang.
- Solusi sejati untuk "self-serve BI" bukanlah menjadikan BI benar-benar "self-serve" bagi orang nonteknis, melainkan membantu orang teknis mendukung pemangku kepentingan bisnis dengan lebih efisien menggunakan alat yang lebih baik.
Usulan untuk alat yang lebih baik:
- Berikan LLM kepada orang teknis, bukan kepada pemangku kepentingan bisnis.
- Biarkan mereka bebas mengolah data menggunakan alat yang nyaman seperti Python, R, dan lainnya.
- Permudah orang teknis untuk membagikan hasil kerja mereka. Notebook dan aplikasi data internal sulit dibagikan karena harus menangani container, dependensi, dan infrastruktur.
1 komentar
Komentar Hacker News
Di sebuah perusahaan yang membuat dasbor dengan alat BI, angkanya terasa aneh, jadi mereka melihat query generator, tetapi sama sekali tidak bisa mengetahui apakah sebagian query itu inner join atau left join
Business analyst yang membuat dasbor itu juga tidak tahu, dan sebenarnya yang dimaksud adalah inner join, tetapi yang dijalankan adalah left join sehingga data yang ditampilkan keluar satu digit lebih besar daripada kenyataannya
Sejak itu saya tidak lagi percaya pada lapisan abstraksi semacam ini yang ditaruh di atas SQL untuk orang yang tidak tahu SQL
Terlalu banyak orang bisa mengakses data, tetapi tidak memahami data itu sendiri, relasinya, atau arti dari hasil yang mereka buat
Selama 25 tahun terakhir, berbagai hal muncul seolah-olah menjadi solusi—engineer dan scientist terdistribusi/embedded, dasbor self-service, alat BI/data low-code, dan sekarang text-to-SQL/visualisasi berbasis LLM—tetapi pada akhirnya tidak menyelesaikan kurangnya pemahaman data maupun masalah kepercayaan terhadap output
Namun SQL juga bukan solusinya. Banyak orang cukup tahu SQL untuk mengambil data, tetapi jarang yang juga memahami struktur dan skema data serta cara penggunaannya yang benar
Sampai sekarang belum ada alat yang menyelesaikan masalah ini selain pengalaman, dan meski LLM mungkin suatu hari bisa, terus terang kemungkinannya tampak kecil
Dasbor bagus untuk melihat KPI dengan cepat dan menelusurinya lebih dalam, tetapi pada akhirnya yang penting adalah praktik pengelolaan data dan kemampuan memahami data/relasi/metrik dengan benar lalu menghubungkannya menjadi insight bisnis
Masa depan memang menarik, tetapi sejauh ini alat generasi berikutnya belum pernah menepati janjinya, jadi saya sama sekali tidak mudah percaya
Default yang masuk akal dan jebakan yang menembak kaki sendiri hanyalah perbedaan sudut pandang
Di perusahaan besar, saya pernah melihat kasus ketika bug atau desain yang halus membuat pendapatan terlihat lebih tinggi, tak seorang pun ingin menyentuhnya lalu memikul tanggung jawab atas turunnya pendapatan
Misalnya tombol paket gratis berada di bawah lipatan layar pada resolusi rata-rata, perhitungan state salah sehingga diskon tidak diterapkan, atau seseorang menghilangkan
falsesehingga pendaftaran diwajibkan padahal secara teknis tidak perluSaya penasaran apakah ada perasaan serupa, takut disalahkan karena angkanya turun
Bagian sulit dalam menerapkan alur logika yang kompleks bukanlah mengetik kode di IDE, melainkan kemampuan memodelkan masalah dan merancang algoritma yang efektif
Alat-alat seperti ini menargetkan pengguna nonteknis dengan janji bahwa mereka tidak perlu menulis kode, tetapi pengguna tetap tersesat atau menghasilkan output yang salah karena tidak memahami bagian kompleks dari merancang solusi secara engineering
Upaya menumbuhkan proses bisnis kompleks dengan alat no-code pada akhirnya, setelah banyak trial and error, akan mentok pada dinding, lalu pada akhirnya diserahkan ke engineer sungguhan
Namun engineer harus bekerja dalam keadaan kehilangan dukungan yang biasanya dianggap wajar saat menulis kode dengan bahasa pemrograman sungguhan
Jika terkurung dalam visual flow builder, shared repository, version control yang layak, code review, automated testing, dan CI/CD hampir mustahil dilakukan
Pengguna pada dasarnya hanya melihat dari sudut pandang mereka sendiri, jadi harus disediakan cara alternatif agar mereka juga bisa melihatnya sesuai cara berpikir mereka
Saya tahu sebuah produk yang memproses absensi pendidikan berbasis waktu, karena kombinasi jadwal berbeda untuk tiap sekolah, kampus, dan tanggal, serta harus fleksibel untuk acara olahraga, shift pengganti, kegiatan kelas gabungan, dan jadwal rotasi 14 hari
Namun itu bukan berarti tidak bisa dibuat view yang menyintesis jadwal kompleks tersebut menjadi absensi berbasis kelas atau absensi pagi/sore
Asumsi bahwa pengguna bisnis tidak bisa mempelajari hubungan antara pertanyaan mereka, model data, dan dropdown, atau terlalu terburu-buru untuk itu, benar-benar tidak masuk akal
Justru berdasarkan pengalaman, mereka mau belajar, tetapi data modeler sering kali tidak cukup memahami domain sehingga gagal menangkap nuansa pertanyaan
Akibatnya, atas nama menyederhanakan self-service, nuansa disembunyikan sehingga waktu untuk mendapatkan jawaban bertambah lama, atau malah dihapus sehingga menghasilkan jawaban yang tidak akurat dan menyesatkan
Saya juga tidak suka eufemisme nonteknis. Ada cukup banyak titik tengah antara LLM, alat pembuat query BI, dan SQL, jadi tidak perlu menyatakan bahwa tembok kemampuan itu absolut
Menjadi ahli komputer, pemrograman, dan analisis data itu bagus, tetapi jika memungkinkan saya menyarankan mereka menempatkan domain yang mereka pelajari atau kerjakan sebagai pusatnya, lalu mengembangkan kemampuan tersebut sebagai pelengkap
Solusi untuk masalah ketika ahli domain tidak tahu data dan ahli data tidak tahu domain adalah membuat keduanya menjadi orang yang sama
Sekarang ketidakmampuan organisasi tampaknya telah mencapai level baru
Ada komik Dilbert yang mengkritik spreadsheet, dan itu juga berlaku apa adanya untuk alat BI dan alat AI
Kurang lebih begini: “Spreadsheet dalam presentasi ini tentu saja penuh kesalahan dan informasi keliru. Tidak masalah, karena toh tak seorang pun akan melihatnya lagi kecuali untuk memperkuat keputusan yang sudah dibuat manajemen”
Di dunia nyata pun laporan dan dasbor yang rusak ada di mana-mana
Ada yang sama sekali tidak diperbarui selama berbulan-bulan, kadang bertahun-tahun, tetapi tetap digunakan dalam proses, pengambilan keputusan, dan alur kerja tanpa ada yang tahu
Ada juga data yang tidak diperbarui, tetapi dipivot berdasarkan tanggal/waktu sehingga setiap kali dijalankan data yang sama disusun ulang, membuat kerusakannya tidak terlalu terlihat meski sebenarnya parah
Banyak juga kasus berbagai rumus dan “matematika” yang sepenuhnya salah lalu menghasilkan angka khayalan
Seiring dunia menjauh dari sistem EDW dan ERP tersentralisasi, masalah data menjadi sulit secara eksponensial, sementara tingkat investasi tidak mampu mengimbanginya
Selama 24 tahun terakhir saya telah menyediakan data untuk pengguna bisnis, tetapi baik itu alat kueri, MS Access, Power BI, maupun data cube di Excel, yang benar-benar menggunakannya hanya segelintir orang
Mungkin mereka adalah orang yang sama yang 40 tahun lalu pun akan mengambil data dari terminal dan laporan cetak untuk dianalisis
Meski begitu, para eksekutif menyukai dasbor metrik utama, dan alat BI baru membuat dasbor KPI jauh lebih mudah dibuat dan dipelihara
Jabatannya mungkin seperti “asisten pribadi”, tetapi mereka mengoprek formulir SharePoint, Access, dan Excel hingga menghasilkan sesuatu yang keren
Akui kecerdasan mereka dan beri mereka alat yang lebih kuat, maka hasilnya luar biasa. Kadang mereka lalu pindah ke pekerjaan yang lebih baik, dan itu juga hal yang bagus
Komputer begitu mahal sehingga “departemen komputer” menjadi divisi tersendiri di perusahaan; misalnya jika divisi bisnis wilayah barat membutuhkan sumber daya komputasi, mereka akan membuat kontrak dengan departemen komputer yang memiliki mainframe terpasang di lokasi
Grup kami adalah tim analitik internal kecil dan lincah yang menggunakan minicomputer baru yang “murah”
Keuntungannya, berkat struktur pendanaan, kami bisa merespons kebutuhan pengguna jauh lebih cepat
Suatu hari saat berjalan di pabrik, saya melihat seorang pengguna memotong baris dari laporan bergaris hijau yang kami buat, menempelkannya ke kertas lain, lalu memfotokopinya
Ternyata ia sedang mengurutkan laporan berdasarkan kriteria lain, jadi saya berkata, “Itu bisa kami lakukan untuk Anda!” dan ia menjawab, “Benarkah?”
Orang yang harus menyelesaikan pekerjaan akan menyelesaikannya dengan cara apa pun. Tujuan grup sistem komputer yang melayani pelanggan internal adalah membuat proses itu seefisien mungkin
Orang lain menggunakan PC, digitizer tablet, dan AutoCAD untuk mencatat titik-titik pada pesawat dan membuat profil radar
Itu bukan penggunaan CAD sebagaimana mestinya, melainkan cara kreatif untuk menangkap data dari gambar Jane's Combat Aircraft
Mereka tidak percaya bahwa data itu sebenarnya sudah ada sejak awal
Integrasi memang operasi bisnis yang diperlukan, tetapi data yang mudah dipahami benar-benar disukai para pemangku kepentingan. Itu nilai tambah yang sangat mudah
Antarmuka BI tradisional yang disebut dalam tulisan itu adalah Metabase, dan saat ini termasuk salah satu antarmuka BI yang cukup bagus
Metabase memungkinkan kita melihat SQL yang dihasilkan GUI, dan juga mengubah pertanyaan itu menjadi SQL murni, sehingga cocok untuk beralih dari self-service ke tata kelola
Logika mudah diubah dan divalidasi, dan orang dengan keterampilan teknis rendah pun mendapat jalur untuk meningkatkan kemampuan
Namun inti tulisannya benar. Bahkan dari sudut pandang orang yang bekerja secara profesional dengan data, alat BI jarang benar-benar memberi lebih banyak orang pemahaman yang akurat tentang data atau keterampilan yang diperlukan untuk menggunakannya dengan benar
Jika data dikelola dengan baik, alatnya mudah dan orang-orang bisa memahaminya, tetapi dunia ini kompleks sehingga datanya juga menjadi kompleks
Biaya pengelolaan data mudah terlihat, sementara manfaatnya tidak terlalu terlihat
Saya sampai pada kesimpulan serupa tentang “self-service BI”, tetapi solusinya agak berbeda
Menurut saya lebih baik menaikkan lapisan abstraksinya: membuat dasbor yang sangat bisa dikustomisasi, tetapi tidak mengekspos SQL kepada pengguna bisnis
Misalnya dasbor dengan 20 filter, dimensi penguraian, dan 20 parameter yang mengontrol “asumsi yang digunakan”
Pertanyaan seperti “Saya ingin melihat performa iklan Google bulan lalu berdasarkan kelompok usia” menjadi sekadar mengubah 3–4 dropdown yang sudah ditentukan sebelumnya
Di sinilah parameter menjadi penting. Karena yang diekspos hanya kontrol yang sudah divalidasi, bukan SQL sembarangan
Tentu saja dasbor seperti ini sulit dibuat dan membutuhkan keahlian visualisasi yang cukup besar di Looker, Tableau, Excel, dan sejenisnya, tetapi hasilnya sekitar 70% pertanyaan bisa menjadi self-service
Untuk 30% sisanya, lebih baik diterima saja bahwa itu tidak bisa, dan dibutuhkan orang yang menerjemahkan pertanyaan bisnis menjadi pertanyaan data. Itu adalah masalah manusia
Dengan begitu, entah CFO atau siapa pun yang membutuhkan jawaban untuk periode tertentu, mereka bisa membuka dasbor itu dan hanya sedikit menyesuaikan parameter default
Saya menggunakan Metabase yang terlihat pada gambar, dan secara umum pengguna nonteknis pun benar-benar memakainya
Hal yang membantu adopsinya adalah mengadakan “office hours” dan langsung menunjukkan contoh seperti “cara mengambil penjualan untuk lokasi atau negara bagian tertentu”
Itu tidak menyelesaikan semua masalah, kueri, atau ekspor, tetapi banyak permintaan yang dulu masuk ke engineering kini tidak sampai ke tahap itu
Alasan lain Metabase bagus adalah bisa di-host sendiri dan bisa memakai SSO GSuite
Metrik utamanya bukan “permintaan bantuan menurun, jadi pengguna lebih mandiri”
Sebab sangat mungkin pengguna itu menghasilkan dan menafsirkan metrik yang sepenuhnya keliru
Saya berulang kali melihat pengguna berkemampuan teknis rendah mendapatkan akses ke data lalu berpikir “ternyata tidak sesulit itu” sambil membangun piramida analisis yang kacau
Analisis yang benar selalu membutuhkan konteks
Misalnya untuk pendapatan berulang, tim keuangan mengisi ulang tanggal pengiriman, jadi tanggal pengiriman tidak boleh dipakai untuk menghitung pendapatan bulanan
Harga katalog disimpan dalam USD, tetapi sebenarnya kurs disesuaikan setiap bulan berdasarkan tabel
monthly_discountKarena ada praktik menandai stok tahun sebelumnya yang belum terjual, item dengan tanggal pembelian null harus dikeluarkan dari laporan penjualan
Karena harga dalam mata uang lokal, penjualan tidak boleh dijumlahkan tanpa melakukan join dengan tabel kurs
Saya menyiapkannya untuk non-programmer di perusahaan, dan sejujurnya mereka hampir tidak menggunakannya selain melihat dasbor yang sudah saya buat, tetapi responsnya positif
Ini alat yang benar-benar berguna
Selalu lucu melihat eksekutif senior dibayar mahal tetapi tidak bisa menjalankan kueri BI SQL
Padahal SQL awalnya dibuat agar manajer bisa mengajukan pertanyaan ke data dengan lebih mudah
Dari sudut pandang mantan tenaga penjualan/manajer, saya tidak terlalu bersimpati pada orang seperti itu
Namun ia tidak melakukannya sendiri. Karena ia memahami prinsip ekonomi dasar
Meski ia bisa menyelesaikan dalam setengah hari pekerjaan yang butuh 3 hari bagi orang lain, setengah hari itu menjadi waktu ketika ia tidak mengerjakan hal yang hanya bisa dilakukan CEO
CxO yang kompeten juga tahu bahwa bagian yang benar-benar memakan waktu adalah menyempurnakan detailnya
Meski SQL itu “tingkat tinggi”, untuk mendapatkan jawaban yang dapat dipercaya tetap butuh waktu dan fokus, seperti keunikan penanganan null, penanganan tanggal, dan penggabungan yang tidak cocok
Jika ada orang yang memang spesialis di bidang itu, sebaiknya serahkan kepadanya
Menurut saya dasbor BI bisa bekerja dengan baik untuk kueri yang sangat sederhana
Jika sudah sampai tahap meminta pengguna nonteknis menjalankan join data, itu sudah terlalu jauh, dan saat itu lebih baik memakai SQL saja
Join mungkin terlihat dasar bagi sebagian orang, tetapi bagi saya pribadi kadang juga sulit dipahami, dan dalam UI dasbor yang daya ungkapnya lebih rendah daripada SQL, itu kombinasi yang membingungkan
Pada akhirnya ini soal kompromi. Bisa dibuat lebih mudah diakses bagi pengguna nonteknis dibanding SQL, tetapi pasti menjadi kurang kuat daripada SQL
Meski begitu, ruang di antaranya tetap banyak manfaatnya. Dalam praktiknya, sebagian besar “BI” hanya setingkat “ada dua kolom data, tolong plot salah satunya terhadap yang lain”
Penulis menyebut SQL sebagai satu-satunya alat BI “swalayan”, tetapi sejujurnya menurut saya itu adalah Excel
Banyak alat BI pada dasarnya seperti membuat ulang Excel dengan antarmuka yang baru sehingga kurang familier
Menurut saya meme kebencian terhadap Excel muncul karena dulu orang mencoba melakukan hal-hal rumit dengan Excel
Jika manipulasi data yang kompleks dilakukan dengan SQL, lalu “tampilkan ini sebagai diagram pai” dilakukan dengan Excel, alat BI mungkin benar-benar tidak diperlukan
Jika sumber data dasarnya sudah dibersihkan, ditransformasikan, dan kontrol aksesnya baik, VLOOKUP dan pivot saja bisa membawa kita sangat jauh
Ketika ada lebih dari satu sumber data, memberi kesempatan swalayan kepada pengguna nonteknis selalu berujung pada pencampuradukan data secara offline
Lalu muncul pertanyaan, “Tim data, kenapa data ‘kalian’ tidak cocok dengan data ‘saya’?”, dengan asumsi bahwa pihak merekalah yang selalu benar
Masalah intinya adalah alat modern berbeda dari desktop klasik seperti workstation Smalltalk atau Emacs
Lingkungan seperti itu merupakan satu lingkungan yang sepenuhnya terintegrasi, semuanya berada di tangan pengguna, dan konsep pemrograman pengguna akhir sudah tertanam di dalamnya
Di org-mode, kita bisa membuat slide yang terlihat bagus dalam sekejap, menulis dan menjalankan potongan kode dengan cepat, lalu mendapatkan hasilnya
Namun dari sudut pandang dasbor, batasannya besar. Data bisa diplot dengan cepat, tetapi hasilnya cenderung berupa gambar statis yang kasar; membuatnya indah dengan PGF/TikZ memakan terlalu banyak waktu sehingga sulit menjadi pilihan, dan tetap saja statis
Emacs sendiri adalah alat yang tepat, tetapi alat dari era yang lebih lama
Alat modern menyediakan manipulasi yang lebih mewah dan cepat, tetapi hanya memungkinkan tindakan yang sangat terbatas, terjebak dalam UI yang tidak fleksibel, dan juga tidak terintegrasi dengan hal lain
R bersama RStudio/quarto mungkin merupakan cara tercepat untuk membuat konten yang cepat, berantakan, tetapi terlihat bagus, namun masih jauh dari fleksibilitas Emacs
Pada akhirnya, tampaknya tidak ada solusi kecuali menulis ulang seluruh stack perangkat lunak modern berdasarkan paradigma klasik dan kemampuan perangkat keras modern