Bir kurumda “veri kalitesi” söylemi neredeyse her zaman aynı şekilde başlar: bir KPI yanlış çıkmıştır, bir regülatör raporu reddedilmiştir veya yeni bir AI projesi modelin halüsinasyonundan değil “temiz olmayan veriden” başarısız olmuştur. Sorunun kökü çoğu zaman teknolojide değil; veri kalitesinin program olarak değil proje olarak ele alınmasında yatar.
Program ile proje arasındaki fark
Proje yaklaşımı: bir takım iki ay çalışır, bir dizi temizleme yapar, dashboard kurar, kapanır. Üç ay sonra metrikler tekrar düşer. Program yaklaşımı: ölçüm, sahiplik, eşik, eskalasyon ve raporlama, organizasyonun rutinine yerleşir. Bir KPI gibi sürekli izlenir.
Programın altı sütunu
1) Boyutsal ölçüm. Veri kalitesi altı boyutta ele alınır: doğruluk, eksiksizlik, tutarlılık, zamanındalık, benzersizlik ve geçerlilik. Her boyut için somut bir formül vardır; “kötü” yerine sayısal bir değer rapor edilir.
2) Sahiplik. Her veri varlığının (müşteri tablosu, ürün kataloğu, hesap kayıtları) bir “data owner”ı, bir de “data steward”ı vardır. Owner iş tarafından, steward teknoloji tarafındandır. Eşik aşımında ilk telefon her ikisine birden gider.
3) Eşik ve SLA. Her boyut için renkli bir eşik tanımlanır: yeşil, sarı, kırmızı. Müşteri tablosunda doğruluk %95 altına düşerse sarı; %90 altına düşerse kırmızı. Kırmızı bir incident gibi yönetilir.
4) Otomasyon. dbt testleri (unique, not_null, accepted_values, relationships) ilk savunma hattıdır. Karmaşık iş kuralları için custom singular testler veya Great Expectations / Soda Core kullanılır. Bu testler CI / CD pipeline’ında çalışır; merge öncesi bozuk transformasyonu engeller.
5) Veri sözleşmesi (data contract). Producer ve consumer arasındaki, schema ve semantik beklentilerini içeren testlenebilir kontrat. Producer şemayı değiştirdiğinde consumer’ın bozulup bozulmayacağını CI gösterir. Bu, “sürpriz” schema kırılmalarını ortadan kaldırır.
6) Raporlama ve geri bildirim. Aylık veri kalitesi panosu üst yönetimde paylaşılır. Trend, eşik aşımı, en kötü beş tablo, sorumlu birimler. Bu pano olmadan program politik destek bulamaz.
Olgunluk modeli
Veri kalitesi programı dört seviyede ilerler:
- Seviye 1 — Reaktif. Sorunlar son kullanıcıdan duyulur. Düzeltmeler ad-hoc.
- Seviye 2 — İzlenen. Bazı tablolarda otomatik testler vardır. Eşik tanımlı değil, alarm yok.
- Seviye 3 — Yönetilen. Tüm kritik tablolar için boyutsal metrikler, eşik ve sahiplik tanımlı. Aylık pano üst yönetime gider.
- Seviye 4 — Otomatize. Veri sözleşmeleri CI / CD’de zorunlu. Eşik aşımları PagerDuty / Opsgenie ile incident olur. Trend analiz raporları otomatik üretilir.
Türkiye’de büyük kurumların büyük kısmı 2026 itibarıyla seviye 1-2’dedir. Seviye 3’e geçiş, bir defaya mahsus değil; yıllık planlanan bir programdır.
Pratik 90 günlük başlangıç
İlk 30 gün: kapsam tanımı (kritik 5-10 veri varlığı), sahiplik atama, mevcut metriklerin ölçümü. 30-60 gün: dbt + Soda otomasyonu, eşik ve SLA tanımı, ilk pano. 60-90 gün: data contract pilotu (üretici ekiplerden 1-2 tanesi), aylık üst yönetim raporlamasının başlatılması.
Bu 90 günün sonunda kurumun “veriler kötü” cümlesi yerine “Müşteri tablosunda doğruluk %88, eksiksizlik %94, tutarlılık %71” diyebilen bir dile geçmesi gerekir.
En sık yapılan üç hata
Tek bir teknoloji satın almak. Soda veya Great Expectations alıp arkasını bırakmak. Araç olmadan da olur, ama insan tarafı olmadan asla.
Sahip atayamamak. “Tüm verinin sahibi IT” kararı program ölmüştür demektir. Owner iş tarafında olmadığında eşik aşımları görmezden gelinir.
Kapsamı patlatmak. İlk dalgada 200 tabloyu kapsama almaya çalışmak. 5-10 kritik tablo ile başlayıp olgunluk yükseldikçe genişletmek tek doğru yoldur.
Sonuç
Veri kalitesi programı; teknoloji, yönetişim, insan ve süreç tarafının dengeli bir kombinasyonudur. Olgun bir program; AI, BI ve regülatör raporlamada sürekli güveni mümkün kılar. Bu güvenin yatırım maliyeti, bir incident bedelinin çok altındadır.
