Data First Yol Haritası: Veri Kalitesi, Sahiplik ve Veri Ürünü Nasıl Kurulur

Veri kalitesi projesi çoğu zaman teknik bir temizlik görevi olarak başlar ve organizasyonel bir çatışmayla biter. Konya’da gıda ambalaj malzemesi üreten, 312 çalışanlı bir imalat şirketi düşünün: BT ekibi geçen yılın sonunda müşteri verilerini ERP, CRM ve lojistik modülü arasında standardize etmek için altı haftalık bir temizleme projesi başlattı. Yinelenen kayıtları birleştirdiler, eksik alanları tamamladılar, adres formatlarını normalize ettiler. Proje başarıyla kapandı; raporlar üzerinde doğru çalışmaya başladı. Dört ay sonra, aynı kirlilik geri döndü. Nedeni basitti: veriyi kirleten süreç — sipariş girişinde her departmanın kendi notasyon alışkanlığı — olduğu gibi duruyordu. Teknik temizlik, organizasyonel sorunun üstüne sürülmüş bir boya katmanıydı. Bu yazı, o döngüyü kıran üç yapı taşını ve bunların sıralanmasının neden bu kadar önemli olduğunu ele alıyor.Tezimi doğrudan söyleyeyim: Veri kalitesi programı başlatmadan önce sahiplik modeli kurmayan şirketler, temizlik çalışmasını en geç altı ay içinde sıfırdan tekrarlamak zorunda kalır. Çünkü kirli veriyi üreten süreç hâlâ yerinde durmaktadır ve temizleyecek sorumlusu yoktur. Bu, BT’nin kötü iş çıkardığı anlamına gelmiyor; mülkiyet tanımlanmadan işletilen her veri alanı doğası gereği bozunur. ‘Data First’ denilen yaklaşımın Türkiye’deki en yaygın yanlış uygulaması tam da buradadır: şirketler teknik araçla (kalite taraması, MDM platformu, veri kataloğu) başlar, ama bu araçları kimin işleteceğini, kimin hesap vereceğini ve hangi ölçütle başarıyı tanımlayacaklarını belirlemeyi erteleyerek bırakır. Sıralama yanlış olunca, araç yatırımı değil süreç yatırımı kaybolur.Doğru sıralama şöyledir: sahiplik önce, kalite programı ikinci, veri ürünü üçüncü. Sahiplik modeli, her kritik veri alanı için tek bir ‘data owner’ — veri sahibi — belirlemekle başlar. Bu kişi BT’den değil, o verinin iş sonucunu yaratan birimden gelir: müşteri verisi için satış direktörü, ürün verisi için üretim planlama müdürü, tedarikçi verisi için satın alma sorumlusu. ‘Sahiplik’ kelimesi burada teknik erişim yetkisi değil, tanım otoritesi anlamına geliyor. Veri sahibi şu üç soruyu yanıtlamak zorundadır: bu alanın doğru değeri nedir, kim girebilir, ve kalite düşünce nasıl ölçülür? Bu üç soruyu yanıtlamadan açılan her kalite projesi, sorumlusuz bir temizlik kampanyasına dönüşür. Konya örneğine dönecek olursak, o şirkette sipariş verilerinin ‘sahibi’ yoktu; satış, lojistik ve muhasebe her biri alanı kendi ihtiyacına göre dolduruyordu. Sahiplik atandıktan sonra veri giriş kuralları iki haftada yazıldı ve bu sefer tutuldu.Sahiplik modeli kurulduktan sonra kalite programını başlatmak anlamlı hale gelir. Kalite, genellikle dört boyutta ölçülür: doğruluk, tamlık, tutarlılık ve zamanlılık. Ancak bu dört boyut her şirkette aynı ağırlıkla önemli değildir. İzmir’deki bir soğuk zincir lojistik firması için zamanlılık hayatta kalma meselesidir — teslimat zamanı verisi altmış dakika gecikirse iş kaybı doğrudandır. Aynı firmanın müşteri adres formatı tutarlılığı ise ikincil öneme sahiptir. Kalite programını doğru boyutlandırabilmek için her veri alanına ‘kalite boyutu ağırlığı’ atanmalı, ve bu ağırlık iş etkisiyle bağlanmalı. Ölçüm için basit bir başlangıç noktası: ERP’den haftalık otomatik çıktı alan bir kontrol panosu. Sahada gördüğüm tablo şu: Türkiye’deki KOBİ’lerin büyük çoğunluğu kalite ölçümünü ya hiç yapmıyor ya da yalnızca hata şikâyeti gelince geriye dönük yapıyor. Proaktif kalite izleme, yani alarmın yangın çıktıktan sonra değil duman görününce çalışması, gerçek programın ayırt edici özelliğidir. Bunu kurmak için veri ambarı veya sofistike araç şart değil; ERP’nin standart raporlama modülü ile başlanabilir, koşul yeter ki ölçütler veri sahibiyle birlikte yazılmış olsun.Üçüncü yapı taşı olan ‘veri ürünü’ kavramı Türkiye’de henüz az kullanılıyor, ama 2024 itibarıyla kurumsal ERP dönüşümü tartışmalarında giderek daha fazla yer buluyor. Veri ürünü (data product), belirli bir kullanım amacına göre paketlenmiş, kalitesi tanımlanmış, sorumlusu belli ve tüketilebilir bir veri varlığıdır. Klasik veri ambarı anlayışından farkı şudur: veri ambarı ‘depolar’, veri ürünü ‘teslim eder’. Ankara’daki orta ölçekli bir ilaç distribütörü, satış ekibine ve finans birimine ayrı veri ürünleri tanımlamış durumda: biri bölge bazında haftalık satış performansı, diğeri tedarikçi bazında ödeme dönüşüm süresi. Her ürünün bir sahibi, bir SLA’sı (servis düzeyi anlaşması) ve bir güncelleme sıklığı var. Satış ekibi sabah raporu açtığında verinin iki günden eski olmadığından emin. Bu güveni sağlayan teknik altyapı karmaşık değil: otomatik veri çekme + basit dönüşüm + güncel kontrol timestamp’i. Ama bu güveni veren sahip tanımı ve SLA kavramı olmadan aynı teknik altyapı salt bir rapor üretici olarak kalır, veri ürünü olmaz. EU AI Act’ın Nisan 2024’te kabul edilmesiyle birlikte bir başka boyut daha ekleniyor: AB pazarına açık Türk şirketleri için ‘yüksek riskli’ AI uygulamalarında kullanılan verinin kalite belgesi artık denetim kapsamına giriyor. Veri ürünü yaklaşımı, bu belgeleme yükümlülüğü için de hazırlık zemini oluşturuyor.Peki bu üç yapı taşını kurmanın önündeki gerçek engeller neler? İlki, sahiplik tartışmasının kısa sürede siyasi bir gerilime dönüşmesidir. ‘Bu veri kimin?’ sorusu, ‘bu veri üzerindeki güç kimin?’ sorusuna kayar; departmanlar direnir. Bu gerilimi yönetmenin yolu, sahipliği ayrıcalık değil sorumluluk olarak çerçevelemektir: veri sahibi olmak, o veriyle ilgili sorunlarda birinci muhatap olmak demektir, ek kaynak veya yetki değil. İkinci engel, kalite standartlarının gerçekçi sınırının çizilmemesidir. Türkiye’deki bir KOBİ’nin ERP’deki her alanı yüzde yüz kalitede tutması mümkün ve gerekli değildir. Bütün alanları eşit önemsemek, hiçbirini önemsememekle aynı sonucu verir. Üçüncü engel: mevcut BT ekibinin kapasitesi. Çoğu KOBİ’de bir ya da iki kişilik BT kadrosu, veri kalitesi izlemesini günlük işletilebilir görev olarak taşıyamaz. Bu durumda otomasyona veya çözüm ortağı desteğine ihtiyaç vardır; ancak burada dikkat edilmesi gereken nokta şudur: otomasyon, sahibi olmayan bir veri alanının kalite sorununu çözmez, yalnızca onu daha hızlı üretir. Sıralama yine kritik: önce sahip, sonra otomasyon.Pazartesi sabahı ne yapmalısınız? İlk adım, şirketinizdeki en kritik beş veri alanını listeleyin — satış siparişleri, müşteri kaydı, ürün tanımı, tedarikçi bilgisi, stok hareketleri başlangıç için yeterli. İkinci adım, her alan için tek bir isim yazın: bu veriyi doğru tutmaktan birinci derecede sorumlu kim? Bu isim BT’den gelemez; ilgili iş biriminden gelmelidir. Üçüncü adım, o veri sahibiyle otuz dakikalık bir toplantı yapın ve tek bir soru sorun: ‘Bu alanın kabul edilebilir kalite eşiği nedir ve bunu nasıl ölçeriz?’ Cevabı not edin, ERP’den haftalık tek bir kontrol raporu çekin. Dördüncü adım, altı hafta boyunca bu raporu aynı toplantıda gözden geçirin. Altı hafta sonra eğer sahip bağlılığı sürdüyse, kalite programının çekirdeği çalışıyor demektir; veri ürünü tanımına geçmeye hazırsınız. Bu sıra basit görünüyor. Ama Konya’daki o gıda ambalaj şirketi, teknik temizlikten önce bu dört adımı atsaydı, ikinci temizlik projesine hiç gerek kalmazdı. Veri sorunlarının büyük çoğunluğu teknik değil örgütseldir; bu gerçeği kabul etmeden başlanan her ‘Data First’ girişimi araç alır, sonuç almaz.