Veri ve Yapay Zekâ

Veri Odaklı Karar Kültürü Bir Şirkette Nasıl Kurulur?

10.07.2026 · 3 dk okuma · 1 okunma

Veri Odaklı Karar Kültürü Bir Şirkette Nasıl Kurulur?

Veri odaklı karar almak, ekranlarda daha çok grafik göstermek değildir. Birçok şirkette pano sayısı arttıkça karar kalitesi aynı kalır; çünkü ölçülen şeyle verilecek karar arasında bağ kurulmamıştır. Bu yazıda, veriyi rapordan karara taşıyan pratik bir çerçeve kuruyoruz.

Veri odaklı karar kültürünün beş temel adımı
Her metrik bir karara bağlı olmalı; kararı değiştirmeyen sayı rapordan çıkarılmalıdır.

Her metrik bir karara bağlanmalı

Bir raporun ilk satırında şu cümle yazılabiliyor olmalı: "Bu sayı X eşiğinin altına inerse şunu yaparız." Cümle kurulamıyorsa metrik gösteri amaçlıdır ve panodan çıkarılmalıdır. Örnek karşılaştırma:

  • Zayıf metrik: Toplam kullanıcı sayısı. Artması hoş, ama hangi kararı değiştirir?
  • Güçlü metrik: Kayıt olduktan sonra ilk hafta içinde en az bir işlem yapan kullanıcı oranı. Düşerse ilk deneyim akışı elden geçirilir.
  • Zayıf metrik: Toplam destek talebi sayısı.
  • Güçlü metrik: Aynı konuda tekrar açılan talep oranı. Yükselirse çözüm kalitesi veya dokümantasyon sorunludur.

Tek doğruluk kaynağı kurmak

Kurumlarda en çok zaman kaybettiren tartışma, "senin rapordaki sayı benimkiyle tutmuyor" tartışmasıdır. Kaynağı neredeyse her zaman tanım farkıdır: biri iptal edilen siparişi sayıyor, diğeri saymıyordur.

Çözüm, tanımı koda ve belgeye tek yerde yazmaktır. Kısa bir veri sözlüğü tutun: metriğin adı, açık tanımı, hangi tabloya dayandığı, hangi kayıtların dışarıda bırakıldığı ve sahibi. Bu tek sayfa, aylık toplantılarda saatler kazandırır.

Ölçüm planını sistemin içine gömün

Raporun elle Excel’de birleştirilmesi gerekiyorsa, o rapor er ya da geç güncellenmeyi bırakır. Ölçümün sürdürülebilir olması için verinin doğduğu yerde toplanması gerekir:

  1. Kritik olaylar (kayıt oluşturma, onay, iptal, hata) zaman damgasıyla saklanmalı.
  2. Silme yerine yumuşak silme (soft delete) tercih edilmeli; silinen kayıt da bir bilgidir.
  3. Durum değişiklikleri geçmişiyle tutulmalı; "şu an onaylı" bilgisi, "ne zaman onaylandı" sorusunu cevaplamaz.
  4. Raporlar sorgu olarak sürümlenmeli, kişisel dosyalarda yaşamamalı.

Veri kalitesi: raporda değil kaynakta düzeltin

Bozuk veriyi rapor aşamasında temizlemek, aynı işi her ay tekrarlamak demektir. Kalıcı çözüm giriş noktasındadır: zorunlu alanlar, biçim doğrulaması, seçim listeleri (serbest metin yerine), tekilleştirme kuralları ve ilişkisel bütünlük kısıtları. Telefon numarasının on farklı biçimde yazılabildiği bir sistemde hiçbir rapor güvenilir olamaz.

Kural: Bir alan raporlanacaksa, o alan serbest metin olmamalıdır. Serbest metin ancak insan okuyacaksa uygundur.

Ortalamalara güvenmeyin

Ortalama, dağılımı gizler. Sayfa yüklenme süresi ortalaması 1,2 saniye görünürken kullanıcıların yüzde onu 6 saniye bekliyor olabilir. Bu yüzden yüzdelik dilimlere (p50, p90, p95) bakmak gerekir. Aynı ilke işlem sürelerinde, destek yanıt sürelerinde ve sipariş hazırlama sürelerinde de geçerlidir: kötü deneyimi yaşayan azınlık, ortalamanın içinde kaybolur.

Korelasyon ile nedensellik ayrımı

İki eğrinin birlikte yükselmesi birinin diğerine sebep olduğunu göstermez. Kampanya yapılan ay satışların artması, kampanyanın işe yaradığını kanıtlamaz; o ay sezon başlangıcı da olabilir. Nedenselliği ölçmenin en sağlam yolu karşılaştırmalı denemedir: değişikliği kullanıcıların bir kısmına uygulayıp diğer kısmı ile karşılaştırmak. Küçük ölçekte bile "önce-sonra" yerine "uygulanan-uygulanmayan" karşılaştırması çok daha güvenilir sonuç verir.

Yapay zekâ katmanı ne zaman devreye girmeli?

Yapay zekâ, temiz ve düzenli veri üzerinde anlam kazanır. Sıralama şudur: önce ölçüm, sonra raporlama, sonra tahmin. Sipariş verisi tutarsızken talep tahmini modeli kurmak, hatalı girdiyi daha karmaşık biçimde hatalı çıktıya çevirir. Buna karşılık düzenli veriye sahip bir şirkette basit istatistiksel yöntemler bile ciddi kazanç sağlar: stok tükenme tahmini, tekrar eden destek konularının otomatik gruplanması, anormal işlem tespiti.

Raporu kimin okuduğunu düşünün

Aynı veri, farklı rollere farklı biçimde sunulmalıdır. Sahadaki yöneticinin ihtiyacı günlük ve işlem odaklıdır: bugün kaç talep bekliyor, hangisi gecikti? Üst yönetimin ihtiyacı ise eğilimdir: son altı ayda ortalama çözüm süresi düşüyor mu?

Tek bir panoya her iki kitleyi sığdırmaya çalışmak, iki tarafın da kullanmadığı bir ekranla sonuçlanır. Pratik ayrım şudur: operasyon ekranları listeler ve aksiyon düğmeleri içerir, yönetim ekranları ise az sayıda büyük sayı ve zaman içindeki değişim gösterir. Ayrıca her rapor, "en son ne zaman güncellendi" bilgisini görünür biçimde taşımalıdır; güncelliği bilinmeyen bir sayı, karar için kullanılamaz.

Panonun kendisini de ölçün

Altı ayda bir şu soruyu sorun: Bu pano nedeniyle hangi kararlar değişti? Cevabı olmayan panolar kapatılmalıdır. Veri kültürünün olgunluk göstergesi rapor sayısı değil, veriye dayanarak vazgeçilen fikirlerin sayısıdır. Ölçümü ürünle birlikte tasarlama yaklaşımı üzerine kapsamlı bir kaynak olarak Our World in Data gibi platformların veri sunum biçimleri incelenebilir; sadelik ve tanım açıklığı konusunda iyi örneklerdir.

Sonuç

Veri odaklı karar kültürü üç alışkanlıkla kurulur: her metriği bir karara bağlamak, tanımları tek yerde tutmak ve ölçümü otomatikleştirmek. Bu üçü olmadan alınan her araç, yanlış sayıyı daha güzel gösteren bir yatırıma dönüşür.

Paylaş:

Sık Sorulan Sorular

Başlangıçta veritabanı üzerinde çalışan basit raporlar ve düzenli bir veri sözlüğü yeterlidir. Araç yatırımı, ölçüm tanımları netleştikten sonra anlamlıdır; aksi hâlde pahalı bir pano yanlış sayıyı daha hızlı gösterir.

Kararı değiştirebilecek metrikler izlenmelidir. Toplam ziyaret sayısı çoğu şirkette bir karar üretmez; dönüşüm oranı, ortalama işlem süresi ve tekrar eden hata sayısı üretir.

Girişte doğrulama, zorunlu alanlar, tekilleştirme kuralları ve düzenli tutarlılık kontrolleri. Bozuk veriyi raporda düzeltmek yerine kaynağında engellemek gerekir.

Genellikle hayır. Tek bir işlem veritabanı ve iyi tasarlanmış raporlama sorguları uzun süre yeter. Veri hacmi ve kaynak sayısı arttığında ayrı bir raporlama katmanı düşünülmelidir.