Bir yönetim toplantısında "bu ay işler iyi gidiyor" cümlesini kaç kez duydunuz? Peki bu cümlenin arkasında hangi sayı vardı? Sahada en sık karşılaştığımız durum, kararların hâlâ tecrübeye, sezgiye ve birkaç kişinin kafasındaki rakama dayanması. Oysa veriye dayalı karar alma, tahmini tamamen ortadan kaldırmasa da, kararın altına sağlam bir zemin koyar. Bu yazıda, firmalara özel geliştirdiğimiz dashboard ve raporlama çözümlerinde nelere dikkat ettiğimizi, neyin işe yarayıp neyin yaramadığını paylaşmak istiyorum.
Veriye Dayalı Karar Almak Tam Olarak Ne Demek?
Veriye dayalı karar alma, basitçe "rapor çıkarmak" değildir. Asıl mesele, doğru sorunun doğru veriyle, doğru zamanda yanıtlanabilmesidir. Bir satış müdürünün gece yarısı aklına takılan "hangi bölgede ciro düştü" sorusuna sabah toplantısını beklemeden cevap bulabilmesi, işte bu kültürün göstergesidir.
Bu kültürü kuran üç temel taşı var:
- Erişilebilirlik: Veri, onu kullanacak kişinin önünde, ek bir talep açmadan durmalı.
- Güvenilirlik: İki ayrı rapor aynı soruya farklı yanıt veriyorsa, kimse hiçbirine güvenmez.
- Bağlam: Çıplak bir sayı tek başına anlamsızdır; hedefe, geçmişe ve sektöre göre yorumlanmalıdır.
Dashboard Tasarımında İlk Hata: Her Şeyi Göstermek
Projelerimizde en çok düzelttiğimiz şeylerden biri, "ne kadar çok grafik o kadar iyi" yanılgısı. Yirmi kutucuğun sığdırıldığı bir ekranda gözünüz hiçbir yere odaklanamaz. İyi bir dashboard, bir soruya hizmet eder ve o soruyu ekrana girer girmez yanıtlar.
Tasarıma başlarken kendimize sorduğumuz soru şu: Bu ekrana bakan kişi ilk üç saniyede ne anlamalı? Eğer cevap net değilse, ekran kalabalıktır.
Rol Bazlı Tasarım
Bir genel müdürün ihtiyacıyla bir saha ekibinin ihtiyacı aynı değildir. Yönetim seviyesi özet ve eğilim ister; operasyon seviyesi ise tek tek işlem detayını ister. Bu yüzden tek bir "dev dashboard" yerine, role göre katmanlanmış ekranlar kurmayı tercih ediyoruz:
- Stratejik katman: Birkaç kritik gösterge, eğilimler, hedefe uzaklık.
- Taktik katman: Departman performansı, dönemsel karşılaştırmalar, anormallikler.
- Operasyonel katman: Günlük işlem listeleri, anlık durum, detaya inilebilir tablolar.
Doğru Metriği Seçmek
Bir göstergeyi panoya koymadan önce şunu soruyoruz: Bu sayı değişirse, biri bir karar verecek mi? Cevap hayırsa, o gösterge muhtemelen sadece ekran kalabalığı yapacaktır. Buna sahada "gösteriş metriği" diyoruz; iyi görünür ama hiçbir eyleme yol açmaz.
İşe yarayan metriklerin ortak özellikleri var:
- Eyleme dönüşebilir: Düştüğünde veya yükseldiğinde ne yapılacağı bellidir.
- Bağlamlı: Hedef, önceki dönem veya bütçe ile yan yana sunulur.
- Sahibi olan: Her metriğin sorumlusu bellidir; "herkesin" metriği kimsenin metriğidir.
Öncü ve Ardıl Göstergeler
Ciro, ardıl bir göstergedir; olan bitmiştir. Teklif sayısı, görüşme adedi veya sepet terk oranı ise öncü göstergelerdir ve geleceği önceden haber verir. Sağlıklı bir panonun, sadece sonucu değil, sonuca giden yolu da göstermesi gerekir. Yöneticilerin asıl müdahale edebildiği yer, öncü göstergelerdir.
Raporlamanın Görünmeyen Yüzü: Veri Altyapısı
Kullanıcı şık bir grafik görür; ama o grafiğin arkasında işin asıl zor kısmı vardır. Verinin farklı sistemlerden toplanması, temizlenmesi, tutarlı hale getirilmesi ve tek bir doğruluk kaynağında birleştirilmesi gerekir. Bu adım atlanırsa, en güzel dashboard bile yanlış kararlara yol açar.
Bu katmanda dikkat ettiğimiz birkaç ilke:
- Tek doğruluk kaynağı: "Müşteri sayısı" gibi bir kavram her departmanda aynı şekilde hesaplanmalı.
- Veri tazeliği: Her rapor anlık olmak zorunda değil; ama kullanıcının verinin ne kadar güncel olduğunu bilmesi şart.
- İz sürülebilirlik: Bir sayıya tıklayıp "bu nereden geldi" diye sorabilmek güveni kurar.
Sahada gözlemlediğimiz en yaygın güven krizi, panodaki sayının kullanıcının kendi Excel'iyle tutmamasından doğar. Bu yüzden ilk işimiz çoğu zaman tek bir tanım üzerinde mutabakat sağlamaktır.
Statik Raporlardan Kendi Kendine Hizmet Eden Analitiğe
Eskiden raporlama, ay sonunda bir uzmanın hazırladığı PDF dosyalarıydı. Bugün hedef, kullanıcının kendi sorusunu kendi sorabildiği bir ortam kurmak. Buna "self-service analitik" diyoruz. Doğru kurgulandığında, IT veya analiz ekibinin üzerindeki "şu raporu da çıkarır mısın" yükü ciddi ölçüde azalır.
Ancak bu özgürlüğün bir sınırı olmalı. Herkesin her veriye sınırsız erişmesi hem güvenlik hem de tutarlılık açısından risklidir. Bu yüzden esnekliği, rol bazlı yetkilendirme ve önceden tanımlı güvenilir veri kümeleriyle dengeliyoruz.
Karar Almayı Hızlandıran Küçük Detaylar
Bir panonun işe yarayıp yaramadığı genelde küçük detaylarda belli olur:
- Uyarı ve eşikler: Bir değer kritik sınırı aştığında kullanıcının panoyu açmasını beklemeden haberdar olması.
- Karşılaştırma kolaylığı: "Geçen yıla göre" veya "hedefe göre" karşılaştırmanın tek tıkla gelmesi.
- Detaya inebilme: Bir toplam sayıdan başlayıp tek bir işleme kadar inebilmek.
- Mobil erişim: Kararın çoğu zaman masa başında değil, sahada veya yolda verildiğini unutmamak.
Nereden Başlamalı?
Bir kurum dashboard projesine başlarken çoğu zaman "her şeyi ölçelim" diye yola çıkar. Bizim önerimiz tam tersi: Önce kurumun gerçekten cevaplamak istediği 5-10 kritik soruyu netleştirin. Pano, o sorulara cevap vermek için kurulur; veri o sorulara göre toplanır.
Pratik bir başlangıç yol haritası şöyle olabilir:
- Kararı verecek kişilerle oturup gerçek soruları çıkarın.
- Bu soruları yanıtlamak için hangi verinin gerektiğini ve nerede olduğunu tespit edin.
- Küçük ama gerçek bir kapsamla başlayın; tek bir departman, tek bir süreç.
- Kullanıcı geri bildirimiyle hızlıca yineleyin, ekranı sadeleştire sadeleştire olgunlaştırın.
Veriye dayalı karar alma bir araç satın alma meselesi değil, bir alışkanlık kurma meselesidir. Doğru tasarlanmış bir dashboard, bu alışkanlığı kurmanın en görünür ve en etkili adımıdır. Biz QuantKOD olarak, firmalara özel projelerimizde önce bu kültürü, sonra teknolojiyi konuşmayı tercih ediyoruz; çünkü en güçlü altyapı bile, kimse bakmıyorsa bir işe yaramıyor.
Sıkça Sorulan Sorular
Dashboard ile rapor arasındaki fark nedir?
Bir dashboard'da kaç metrik olmalı?
Raporların yanlış sonuç vermesinin en yaygın sebebi nedir?
Self-service analitik güvenlik riski oluşturur mu?
Yazar
Doğukan Azer ÇİFTCİYazılım Mühendisi
QuantKOD’da yazılım mühendisi. Ölçeklenebilir mimariler, özel yazılım geliştirme ve doğru teknoloji seçimleri üzerine yazıyor.