Self-service panolar neden çalışmıyor?
(briefer.cloud)- "self-serve dashboards" pratikte iyi çalışmıyor. Çünkü mühendisler veya veri bilimciler, iş kullanıcıları için sorgu yazmaya ve panolar hazırlamaya çok zaman harcıyor.
"self-serve BI" neden çalışmıyor
- Tek gerçek "self-serve BI" aracı SQL'dir. Ancak çoğu "self-serve BI" sağlayıcısı SQL'i başka bir şey gibi göstermeye çalışıyor.
- İş paydaşlarının veriyi sorgulamasının önündeki tek engel SQL sorgusu yazmak değil. Verinin ne anlama geldiğini, nereden geldiğini, nasıl hesaplandığını anlamıyorlar; ayrıca sonuçları nasıl yorumlayıp doğrulayacaklarını da bilmiyorlar.
Deneme 1: geleneksel "açılır menü ve onay kutusu" yaklaşımı
- Bu arayüz, yalnızca "fareyle SQL" denemesinden ibaret. SQL'den daha iyi değil; hatta daha yavaş, daha az güvenilir, daha kısıtlı ve başka araçlara genellenebilir değil.
- CFO gibi biri bu arayüzü kullanarak veriyi sorgulamayacaktır. Çünkü veriyi anlayabileceği bağlam yoktur ve sonuçlar konusunda güven duyamaz.
Deneme 2: text-to-SQL yaklaşımı
- LLM'ler doğal dili SQL'e çevirmede neredeyse fazla başarılı. Soru uygun olmasa bile bir sorgu üretmeye çalışacaktır.
- Teknik kişiler, sorunun uygun olmadığını fark eder ve daha fazla bağlam ister. Mevcut veri türlerini açıklar ve doğru, faydalı sorular oluşturmak için iş tarafıyla birlikte çalışır.
- LLM'ler "self-serve BI" için gerçek çözüm olabilir, ancak şu anki halleriyle değil. Daha fazla bağlama ihtiyaçları var; belirsizliği ifade etmede ve daha fazla bilgi istemede daha yetkin olmaları gerekiyor.
Gerçekte işe yarayan şey
- "self-serve BI" sorunu SQL değil, verinin bağlamı ve anlamıdır. Çözüm, arayüzden bağımsız olarak insanlara sorguladıkları veri hakkında eğitim vermektir.
- Teknik ekibin tüm bilgiyi dokümante etmesi ciddi bir ek yük yaratır ve hızla güncelliğini yitirir.
- "self-serve BI" için gerçek çözüm, teknik olmayan kişiler için BI'ı "self-serve" hale getirmek değil; teknik kişilerin daha iyi araçlar kullanarak iş paydaşlarını daha verimli desteklemesini sağlamaktır.
Daha iyi araçlar için öneriler:
- LLM'leri iş paydaşlarına değil, teknik kişilere verin.
- Python, R gibi rahat oldukları araçlarla veriyi özgürce işleyebilmelerini sağlayın.
- Teknik kişilerin yaptıkları işi kolayca paylaşabilmesini sağlayın. Notebook'lar ve iç veri uygulamaları; container'lar, bağımlılıklar ve altyapıyla uğraşmak zorunda olduğu için paylaşılması zordur.
1 yorum
Hacker News yorumları
Bir şirkette BI aracıyla pano hazırlıyorduk; sayılar tuhaf gelince sorgu oluşturucusuna baktım ve sorgunun bazı bölümlerinin inner join mi yoksa left join mi olduğu hiç anlaşılmıyordu.
O panoyu hazırlayan iş analisti de bilmiyordu; aslında amaç inner join kullanmaktı ama left join çalışmıştı ve gösterilen veri gerçekte olduğundan bir basamak daha büyük çıkıyordu.
O günden sonra SQL bilmeyen insanlar için SQL'in üzerine konan bu tür soyutlama katmanlarına güvenmemeye başladım.
Veriye erişebilen ama verinin kendisini, ilişkileri ve ürettikleri sonucun ne anlama geldiğini bilmeyen çok fazla insan var.
Son 25 yılda dağıtık/embedded mühendisler ve bilim insanları, self-servis panolar, low-code BI/veri araçları, şimdi de LLM tabanlı metinden SQL'e/görselleştirmeye araçlar çözüm gibi ortaya çıktı; ama sonuçta veriyi anlamama ve çıktılara güven sorunu çözülemedi.
Üstelik SQL de çözüm değil. Veriyi çekebilecek kadar SQL bilen çok kişi var; ama veri yapısını ve şemayı, doğru kullanım biçimini bilen az.
Bu sorunu deneyim dışında çözen bir araç henüz yok; LLM'lerin bir gün bunu yapması mümkün olabilir ama açıkçası olasılık düşük görünüyor.
Panolar KPI'ları hızlıca görmek ve derine inmek için iyi; ama nihayetinde önemli olan veri yönetimi pratikleri ve veriyi/ilişkileri/metrikleri doğru anlayıp bunları iş içgörüsüne bağlama becerisi.
Gelecek umut verici, ama bugüne kadar yeni nesil araçlar verdikleri sözleri tutmadığı için artık kolay kolay inanmıyorum.
Makul varsayılanlar ile insanın ayağına kurşun sıkan mekanizmalar arasındaki fark sadece bakış açısı.
Büyük şirketlerde ince bir hata ya da tasarım geliri olduğundan yüksek gösteriyorsa, kimsenin buna dokunup gelir düşüşünün sorumluluğunu almak istemediği durumlar gördüm.
Örneğin ücretsiz plan düğmesinin ortalama çözünürlükte katın altında kalması, state hesaplamasının yanlış olup indirimin uygulanmaması ya da birinin
falsedeğerini atlaması yüzünden kayıt teknik olarak gerekmese de kayıt istenmesi gibi.Sayının düşmesini kendi hataları gibi göstereceğinden benzer bir his yaşayıp yaşamadıklarını merak ediyorum.
Karmaşık mantık akışlarını uygularken zor olan kısım IDE'ye kod yazmak değil; problemi modelleme ve etkili algoritmalar tasarlama becerisi.
Bu araçlar kod yazmaya gerek olmadığı vaadiyle teknik olmayan kullanıcıları hedefliyor; ama kullanıcı hâlâ çözümü mühendislik açısından tasarlamanın karmaşık kısmını anlamadığı için yolunu kaybediyor ya da hatalı sonuçlar üretiyor.
Karmaşık bir iş sürecini no-code araçla büyütme girişimleri, sonunda çok sayıda deneme yanılmadan sonra duvara çarpıyor ve en sonunda gerçek bir mühendise devrediliyor.
Ancak mühendis, gerçek bir programlama diliyle kod yazarken doğal olarak sahip olduğu destekleri kaybetmiş hâlde çalışmak zorunda kalıyor.
Görsel akış oluşturucuya hapsolunca paylaşımlı depo, düzgün sürüm kontrolü, kod incelemesi, otomatik testler ve CI/CD neredeyse imkânsız hale geliyor.
Kullanıcılar temelde yalnızca kendi bakış açılarından gördüğü için, onların düşünme biçimleriyle de bakabilecekleri alternatif yollar hazırlamak gerekir.
Eğitimde yoklamayı zaman bazlı işleyen bir ürün biliyorum; çünkü okul, kampüs ve tarihe göre ders programı kombinasyonları değişiyor ve spor etkinlikleri, telafi mesaileri, birleştirilmiş sınıf etkinlikleri, 14 günlük döngülü programlar gibi esnek olmak gerekiyor.
Bu, o karmaşık ders programından ders bazlı yoklama ya da sabah/öğleden sonra yoklaması için birleştirilmiş view'lar oluşturulamayacağı anlamına gelmiyor.
İş kullanıcılarının kendi soruları, veri modeli ve açılır menüler arasındaki ilişkiyi öğrenemeyeceği ya da bunun için fazla aceleci oldukları varsayımı saçma.
Aksine, deneyimime göre öğrenmek istiyorlar; ancak veri modelleyicilerin alanı yeterince anlamadığı için soruların nüansını modele yansıtamadığı çok oluyor.
Sonuçta self-servisi sadeleştirme adına nüansları gizleyerek yanıta ulaşma süresini uzatıyorlar ya da tamamen kaldırıp yanlış ve yanıltıcı yanıtlar üretiyorlar.
Teknik olmayan örtmecesinden de hoşlanmıyorum. LLM, BI sorgu oluşturma araçları ve SQL arasında yeterince ara nokta var; yetkinlik duvarının mutlak olduğunu ilan etmeye gerek yok.
Bilgisayar, programlama ve veri analizinde uzman olmak güzel; ama mümkünse öğrendikleri ya da çalıştıkları alanı merkeze alıp bu becerileri ikincil olarak geliştirmelerini söylüyorum.
Alan uzmanının veriyi bilmemesi, veri uzmanının da alanı bilmemesi sorununa çözüm, ikisinin aynı kişi olması.
Şu anda kurumsal beceriksizlik yeni bir seviyeye ulaşmış gibi görünüyor.
Elektronik tabloları eleştiren bir Dilbert karikatürü vardı; BI araçları ve AI araçları için de aynen geçerli.
“Bu sunumdaki elektronik tabloda elbette hatalar ve yanlış bilgilerle dolu. Zaten yönetimin önceden aldığı kararları güçlendirmediği sürece kimse tekrar bakmayacak, o yüzden sorun değil” gibiydi.
Gerçekte de bozuk raporlar ve panolar her yerde.
Aylarca, bazen yıllarca hiç güncellenmediği hâlde kimse fark etmeden süreçlerde, karar almada ve iş akışlarında kullanılanlar var.
Veri güncellenmiyor ama tarih/saat bazında pivotlandığı için her çalıştırıldığında aynı veriyi yeniden düzenliyor; bu yüzden ciddi şekilde bozuk olsa bile belli olmuyor.
Çeşitli formüllerin ve “matematiğin” tamamen yanlış olup hayalî sayılar ürettiği durumlar da çok.
Dünya merkezi EDW ve ERP sistemlerinden uzaklaştıkça veri sorunu üstel biçimde zorlaştı; yatırım seviyesi buna ayak uyduramadı, hepsi bu.
Son 24 yıldır iş kullanıcılarına veri sunuyorum; ister sorgu aracı olsun, ister MS Access, Power BI ya da Excel’deki veri küpleri, bunları gerçekten kullanan kişi sayısı çok az
Muhtemelen 40 yıl önce de terminal ve basılı raporlardan veri kazıyıp analiz yapan kişiler yine onlardı
Yine de yöneticiler temel metrik panolarını seviyor ve yeni BI araçları KPI panoları oluşturmayı ve sürdürmeyi çok daha kolaylaştırıyor
Ünvanı “özel asistan” gibi bir şey olabilir ama SharePoint formları, Access ve Excel’i hack’ler gibi kullanıp harika şeyler çıkarırlar
Onların zeki yeteneklerini fark edip daha güçlü araçlar vermek harika olur. Sonra daha iyi bir işe geçebilirler; bu da harika bir şeydir
Bilgisayarlar o kadar pahalıydı ki “bilgisayar departmanı” şirket içinde ayrı bir birimdi; örneğin batı bölümü bilgi işlem kaynağına ihtiyaç duyarsa sahada kurulu mainframe’i olan bilgisayar departmanıyla sözleşme yapardı
Bizim grubumuz, yeni ve “ucuz” mini bilgisayarlar kullanan küçük ve çevik bir iç analiz ekibiydi
Finansman yapısı sayesinde kullanıcı ihtiyaçlarına çok daha hızlı yanıt verebilmek avantajımızdı
Bir gün fabrikada yürürken, bir kullanıcının bizim ürettiğimiz yeşil çizgili raporun satırlarını kesip başka bir kâğıda yapıştırdığını ve fotokopi çektiğini gördüm
Raporu başka bir kritere göre sıralıyormuş; “Bunu biz sizin için yapabiliriz!” deyince “Gerçekten mi?” diye tepki verdi
İşi bitirmesi gereken kişi bir şekilde bitirir. İç müşterilere hizmet veren bilgisayar sistemleri grubunun amacı bu süreci olabildiğince verimli kılmaktır
Başka biri de PC, tablet digitizer ve AutoCAD kullanarak uçak üzerindeki noktaları kaydedip radar profili çıkarıyordu
Bu, CAD’in asıl kullanımından ziyade Jane's Combat Aircraft çizimlerinden veri yakalamaya yönelik yaratıcı bir kullanımdı
O verinin başından beri mevcut olduğuna inanamıyorlar
Entegrasyon gerekli bir iş operasyonu, ama anlaşılması kolay veri paydaşların gerçekten hoşuna gidiyor. Çok kolay bir değer katma yolu
Yazıda görünen geleneksel BI arayüzü Metabase; mevcut BI arayüzleri arasında oldukça iyi olanlardan biri
Metabase, GUI’nin oluşturduğu SQL’i görmenize izin veriyor ve o soruyu saf SQL’e de dönüştürebiliyor; bu yüzden self-servis aşamasından yönetişime geçmek için iyi
Mantığı değiştirmek ve doğrulamak kolay, teknik becerisi düşük kişiler için de kendini geliştirecek bir yol oluşuyor
Ancak yazının ana fikri doğru. Profesyonel olarak veri işi yapan biri olarak baktığımda da BI araçlarının daha fazla insana veriyi doğru anlama ya da doğru kullanma için gereken becerileri kazandırması nadir
Veri iyi yönetilirse araç kolay olur ve insanlar da çözebilir, ama dünya karmaşık olduğu için veri de karmaşıklaşıyor
Veri yönetimi maliyeti kolayca görünürken faydaları pek görünmez
“Self-servis BI” konusunda benzer bir sonuca vardım ama çözümüm biraz farklı
Soyutlama katmanını daha yukarı taşımak; çok özelleştirilebilir panolar yapmak ama iş kullanıcılarına SQL göstermemek daha iyi diye düşünüyorum
Örneğin 20 filtre, ayrıştırma boyutları ve “kullanılan varsayımları” kontrol eden 20 parametresi olan bir pano
“Geçen ay Google reklam performansını yaş gruplarına göre görmek istiyorum” sorusu, önceden tanımlı 3-4 açılır menüyü değiştirme işine dönüşür
Burada parametreler önemli. Çünkü yalnızca doğrulanmış ayarları açarsınız, keyfî SQL’e izin vermezsiniz
Elbette böyle panoları yapmak zor; Looker, Tableau, Excel gibi araçlarda epey görselleştirme uzmanlığı gerektirir, ama sonuçta soruların %70’i self-servis hâle gelir
Kalan %30’dan vazgeçmek daha iyi; iş sorularını veri sorularına çevirecek birine ihtiyaç vardır. Bu bir insan problemidir
Böylece CFO ya da herhangi biri belirli bir dönem için yanıt gerektiğinde o panoyu açıp sadece temel parametreleri biraz ayarlar
Görseldeki Metabase’i kullanıyoruz ve genel olarak teknik olmayan kullanıcılar da gerçekten kullanıyor
Benimsenmesine yardımcı olan şey, “ofis saatleri” düzenleyip “belirli bir lokasyonun ya da eyaletin satışlarını nasıl alırsınız” gibi örnekleri doğrudan göstermekti
Tüm sorunları, sorguları ve dışa aktarımları çözmedi ama eskiden mühendisliğe gelen isteklerin önemli bir kısmı artık o aşamaya kadar gelmiyor
Metabase’in iyi olmasının bir başka nedeni de self-host edilebilmesi ve GSuite SSO kullanabilmesi
Temel metrik “yardım talepleri azaldı, demek ki kullanıcılar daha bağımsız” değildir
Çünkü bu kullanıcıların tamamen yanlış metrikler çıkarıp yorumlama olasılığı çok yüksektir
Düşük teknik beceriye sahip kullanıcılar veriye erişince “düşündüğüm kadar zor değilmiş” diye inanıp kötü analizlerden oluşan bir piramit kuruyor; bunu defalarca gördüm
Doğru analiz her zaman bağlam gerektirir
Örneğin yinelenen gelir için finans ekibi teslimat tarihini yeniden doldurduğundan, aylık gelir hesaplamasında teslimat tarihi kullanılmamalıdır
Katalog fiyatı USD olarak saklanır ama gerçekte kur her ay
monthly_discounttablosuna göre ayarlanırÖnceki yıldan satılmamış stoğu gösterme geleneği nedeniyle satın alma tarihi null olan kalemler satış raporundan çıkarılmalıdır
Fiyat yerel para biriminde olduğu için kur tablosuyla join yapmadan geliri toplamak olmaz
Şirketteki programcı olmayanlar için kurmuştum; açıkçası benim hazırladığım panolara bakmaktan öte pek kullanmıyorlar ama tepkileri iyiydi
Gerçekten kullanışlı bir araç
Üst düzey yöneticilerin büyük paralar alıp BI SQL sorgusu çalıştıramaması bana hep komik geliyor
Oysa SQL zaten yöneticilerin verileri daha kolay sorgulayabilmesi için yapılmıştı
Eski bir satışçı/yönetici olarak böyle insanlara pek sempati duymuyorum
Ama kendisi yapmıyor. Çünkü temel ekonomi ilkelerini biliyor
Başkasının 3 günde yapacağı işi kendisi yarım günde yapabilse bile, o yarım gün CEO’nun yapabileceği işleri yapamadığı zaman oluyor
Yetkin bir CxO, asıl zaman alan kısmın ayrıntıları kusursuz oturtmak olduğunu da bilir
null işlemenin tuhaflıkları, tarih işleme, uyuşmayan merge’leri ele alma gibi konularda SQL “üst seviye” olsa bile güvenilir bir yanıt almak zaman ve odaklanma gerektirir
Bunu uzmanlık olarak yapan biri varsa, işi ona bırakmak doğrudur
BI panolarının çok basit sorgularda iyi çalışabileceğini düşünüyorum
Teknik olmayan bir kullanıcıdan veri join’i yapmasını isteme aşamasına gelindiyse zaten fazla derine inilmiş demektir; o noktada SQL kullanmak daha iyidir
Join bazılarına temel bir şey gibi görünebilir ama kişisel olarak benim de bazen anlamakta zorlandığım, SQL’den daha az ifade gücüne sahip pano UI’larında ise kafa karışıklığı yaratan bir kombinasyon
Sonuçta bu bir ödünleşim. SQL’e kıyasla teknik olmayan kullanıcılar için daha erişilebilir yapılabilir, ama kaçınılmaz olarak SQL’den daha az güçlü olur
Yine de aradaki alanda çok kullanım var. Gerçekte “BI”ın önemli bir kısmı “elimizde iki veri sütunu var, birini diğerine göre çiz” seviyesinde
Yazar SQL’i tek “self-service” BI aracı olarak görüyor ama açıkçası bence bu Excel
Birçok BI aracı, Excel’i yeni ve bu yüzden daha az tanıdık bir arayüzle yeniden yapmaya yakın
Excel’den nefret etme meminin, geçmişte karmaşık işleri Excel’le yapmaya çalışmaktan doğduğunu düşünüyorum
Karmaşık veri manipülasyonunu SQL’le, “bunu pasta grafiği olarak göster” işini Excel’le yaparsanız BI aracına gerçekten gerek kalmayabilir
Temel veri kaynakları temizlenmiş, dönüştürülmüş ve erişim kontrolü iyi ayarlanmışsa VLOOKUP ve pivot’larla şaşırtıcı derecede ileri gidilebilir
Veri kaynağı birden fazla olduğunda teknik olmayan kullanıcılara self-service fırsatı vermek, her zaman çevrimdışı veri karıştırmaya yol açar
Sonra “Veri ekibi, neden ‘sizin’ veriniz ‘benim’ verimle uyuşmuyor?” sorusu gelir; üstelik her zaman kendi tarafının doğru olduğu varsayımıyla
Temel sorun, modern araçların Smalltalk iş istasyonları ya da Emacs gibi klasik masaüstlerinden farklı olması
Bu tür ortamlar tamamen bütünleşik tek bir ortamdı; her şey kullanıcının elindeydi ve son kullanıcı programlama kavramı yerleşikti
org-mode’da güzel görünen slaytları bir anda hazırlayabilir, hızlıca kod parçaları yazıp çalıştırarak sonuç alabilirsiniz
Ancak pano açısından ciddi sınırları var. Verileri hızlıca çizebilirsiniz ama sonuç kaba bir statik görsele daha yakındır; PGF/TikZ ile şık hale getirmek ise seçenek olamayacak kadar çok zaman alır ve hâlâ statiktir
Emacs’ın kendisi doğru araç, ama daha eski bir dönemin aracı
Modern araçlar daha gösterişli ve hızlı işlemler sunuyor, fakat yalnızca çok sınırlı eylemlere izin veriyor; esnek olmayan UI’lara hapsolmuş durumdalar ve başka şeylerle de entegre değiller
R, RStudio/quarto ile birlikte hızlı, dağınık ama iyi görünen içerikleri en çabuk üretmenin yolu olabilir; ancak Emacs’ın esnekliğinin çok gerisinde
Sonuçta klasik paradigmayı ve modern donanım gücünü temel alarak modern yazılım yığınının tamamını yeniden yazmadıkça bir çözüm yok gibi görünüyor