طراحی داشبورد مدیریتی: KPI درست، منبع واحد حقیقت و کارایی با PostgreSQL

Çoğu dashboard projesi aynı şekilde biter: ilk hafta heyecanla açılan ekranlar, bir ay sonra kimsenin bakmadığı grafiklere dönüşür. Nedeni genellikle teknik değildir; ekran yöneticinin sorusuna değil, verinin elverdiğine göre tasarlanmıştır. Bu yazıda tersini yapmanın yolunu anlatıyoruz: önce soru, sonra gösterge, sonra veri modeli, en son görselleştirme.

1. Soru ile başlayın

Her gösterge bir karar sorusuna bağlanmalıdır. "Ciro grafiği" bir gösterge değil, bir veridir. "Bu ay hangi şubede hedefin gerisindeyiz ve neden?" ise bir sorudur ve cevabı için ciro, hedef, şube ve sapma nedenine dair kırılım gerekir. Örnek olarak bir lojistik şirketinin yöneticisi için sorular şunlar olabilir: teslimat gecikmelerinin kaynağı hangi bölge, araç başına maliyet nasıl değişiyor, hangi müşterilerin alacağı vadeyi aşıyor.

2. KPI seçimi: az ama bağlantılı

Bir yönetici ekranında beş ila sekiz gösterge yeterlidir. Her gösterge için şu dördü tanımlanır: tanım (formülü), kaynak (hangi tablo/sistem), yenilenme sıklığı ve sahibi. Tanımı yazılamayan gösterge ekrana alınmamalıdır; "verimlilik" gibi herkesin farklı hesapladığı kavramlar tartışmadan başka bir şey üretmez.

3. Tek doğru kaynak (single source of truth)

Dashboard'un güvenilirliği, aynı sorunun her yerde aynı cevabı vermesine bağlıdır. Bu, hesaplamaların raporlama aracında değil veri katmanında yapılması demektir. PostgreSQL'de görünümler (view) ve materyalize görünümler bu iş için idealdir: KPI formülü bir kez tanımlanır, tüm ekranlar aynı görünümü okur.

-- Örnek: aylık şube performansı (basitleştirilmiş)
create materialized view mv_branch_monthly as
select
  b.id            as branch_id,
  date_trunc('month', s.sold_at) as month,
  sum(s.net_amount)              as revenue,
  max(t.target_amount)           as target,
  sum(s.net_amount) - max(t.target_amount) as variance
from sales s
join branches b on b.id = s.branch_id
left join targets t on t.branch_id = b.id and t.month = date_trunc('month', s.sold_at)
group by b.id, date_trunc('month', s.sold_at);

create unique index on mv_branch_monthly (branch_id, month);
-- Yenileme (zamanlanmış görevle): refresh materialized view concurrently mv_branch_monthly;

4. Performans: her açılışta ham veriyi taramayın

Yönetici ekranı saniyeler içinde açılmalıdır. Materyalize görünümler, doğru indeksler ve dönem bazlı önceden hesaplanmış özetler bunu sağlar. Anlık veri gerektiren az sayıdaki gösterge (örneğin bugünkü kasa) ayrı ve hafif sorgularla beslenir. "Her şey canlı olsun" isteği, çoğu zaman "hiçbir şey açılmasın" sonucunu doğurur.

5. Yetkiye göre görüntüleme

Aynı dashboard'u grup yöneticisi tüm şirketler için, şube müdürü yalnızca kendi şubesi için görmelidir. Bu filtreleme arayüzde değil, veri katmanında (Row Level Security) uygulanmalıdır; aksi hâlde API'ye doğrudan erişen bir kullanıcı diğer şubelerin verisini çekebilir.

İyi bir dashboard, yöneticinin "neden" sorusunu bir tıkla kaynağa inerek cevaplayabildiği ekrandır. Sadece grafik gösteren ekran, güzel bir sunudur.

6. Görselleştirme ilkeleri

• Her göstergede karşılaştırma noktası olsun: hedef, geçen dönem veya ortalama.
• Renkleri anlam için kullanın (sapma yönü), süs için değil.
• Tablo, grafiğin yerini alamadığı yerde değil; grafik tabloyu süslemediği yerde kullanılsın.
• Zaman dilimi ve para birimi ekranın üstünde açıkça yazsın.

7. Çok kaynaklı veri: Excel'den API'ye

Kaynakların bir kısmı hâlâ Excel olabilir. Bu normaldir; önemli olan Excel aktarımının doğrulama kurallarından geçmesi ve her yüklemenin kayıt altına alınmasıdır. Zamanla API ile beslenen kaynaklar arttıkça Excel adımı azalır; ama "önce tüm kaynaklar otomatik olsun, sonra dashboard yapalım" yaklaşımı projeyi süresiz erteler.

8. Yayın sonrası: kullanım verisine bakın

Hangi ekranların açıldığını, hangi filtrelerin kullanıldığını ölçün. Üç ay bakılmayan bir gösterge ya yanlış sorudur ya da yanlış yerdedir; kaldırmak, eklemek kadar değerlidir.

Veri modeli: boyutlar ve ölçütler

Dashboard'un altındaki veri, boyutlar (şube, dönem, ürün grubu, müşteri) ve ölçütler (ciro, maliyet, adet, gün) olarak düşünülmelidir. Her ölçüt hangi boyutlarla kırılabileceğini önceden bilmelidir; "ciroyu müşteriye göre görebiliyoruz ama maliyeti göremiyoruz" durumu, kaynak sistemlerde maliyetin müşteriyle ilişkilendirilmemesinden kaynaklanır ve dashboard'da değil kaynakta çözülür. Bu nedenle dashboard projesi çoğu zaman kaynak sistemlerde küçük veri modeli düzeltmeleriyle başlar.

Yenileme sıklığı ve "son güncelleme" etiketi

Her gösterge, verinin ne zaman yenilendiğini görünür biçimde taşımalıdır. "Dünkü veri" olduğunu bilen yönetici doğru karar verir; bilmeyen yönetici "sistem yanlış" der. Yenileme sıklığı ihtiyaca göre değişir: kasa bakiyesi saatlik, aylık kârlılık dönem kapanışında. Hepsini anlık yapmaya çalışmak hem maliyetli hem de gereksizdir.

Uyarılar: dashboard'a bakmayı beklemeyin

Yöneticiler her gün dashboard açmaz; önemli sapmalar onlara gitmelidir. Eşik tabanlı uyarılar (alacak vadesi aşıldı, bütçe sapması belirli oranı geçti, stok asgari seviyenin altına indi) e-posta veya mesaj olarak iletilir ve uyarı, ilgili ekrana bağlantı taşır. Eşikleri finans veya operasyon ekibi tanımlar ve değiştirir; eşiklerin koda gömülmesi, ilk değişiklik talebinde geliştirme maliyeti doğurur.

-- Örnek: uyarı kuralı tablosu (kavramsal)
create table alert_rules (
  id          serial primary key,
  metric_key  text not null,        -- örn. 'receivables_overdue'
  comparator  text not null,        -- '>', '<'
  threshold   numeric not null,
  scope       jsonb not null default '{}',   -- şube, şirket filtresi
  recipients  text[] not null,
  is_active   boolean not null default true
);

Mobil görünüm

Yöneticiler dashboard'u çoğunlukla telefondan açar. Masaüstü için tasarlanıp küçültülen ekran, telefonda kullanılmaz. Mobil görünüm için öncelik sırası: önce özet kartlar (beş ila sekiz gösterge), sonra tek bir grafik, en son tablolar. Filtreler az ve büyük olmalı; "tüm şirketler / şube seç / dönem seç" üçlüsü çoğu ihtiyacı karşılar.

Veri kalitesi göstergeleri

Dashboard'un kendisi de izlenmelidir: eksik yükleme (bir şubenin bu ayki verisi gelmemiş), doğrulamadan reddedilen satırlar, eşleme bekleyen yeni kodlar. Bu "veri sağlığı" paneli yöneticiye değil, veri sorumlusuna hitap eder ve ana dashboard'daki rakamların neden eksik olabileceğini açıklar.

Örnek: lojistik yöneticisi görünümü (kurgusal)

• Bugün planlanan ve tamamlanan sevkiyat sayısı; gecikenler ayrı kart.
• Bölge bazında geciken sevkiyat listesi; tıklayınca sevkiyat kartı.
• Araç başına haftalık maliyet eğilimi; dağıtım anahtarı ekranda yazılı.
• Vadesi geçmiş alacaklar; müşteri bazında, tutara göre sıralı.
• Veri sağlığı: takip cihazından veri gelmeyen araçlar.

Bu örnek yalnızca yapıyı göstermek içindir; gerçek göstergeler keşif aşamasında yöneticinin sorularından türetilir.

Cy Logic'in veri analitiği ve raporlama hizmeti bu ilkeleri izler: dağınık kaynakları tek doğru kaynakta birleştirmek ve yetkiye göre görüntülenen, hızlı ve sorgulanabilir ekranlar kurmak.