Veri kalitesini iyileştirme: 30 günde ölçülebilir şekilde daha iyi raporlar sağlayan pratik kontroller

Birçok şirket, yeni panolar, ek KPI’lar veya farklı bir BI aracıyla daha iyi raporlar elde etmeye çalışıyor. Pratikte sorun çoğunlukla bunun öncesinde yatıyor: Kim Veri kalitesini iyileştirmek istiyorsa, verilerin oluştuğu, aktarıldığı, yoğunlaştırıldığı ve yorumlandığı noktaları istikrara kavuşturmak zorunda. Kötü veri kalitesi sadece “yanlış sayılarda” görünmez; günlük işleyişte ortaya çıkar: departmanlar kararı değil kaynağı tartışır, IT “Rapor yanlış” ile ilgili ticket’lar alır ve her analiz Excel’de manuel düzeltmeler gerektirir.

İyi tarafı: Kayda değer iyileşmeler için büyük bir program gerekmez. Net bir 30 günlük yaklaşım – az ama etkili kontrollere odaklanmış – ile raporlar ölçülebilir şekilde stabil hale getirilebilir. Önemli olan, kontrollerin tek seferlik bir temizleme değil, bir işletme kontrol sistemi olarak anlaşılmasıdır: sınır değerler, sorumlular, dokümantasyon ve yükseltme yolları ile.

Bu yazı, sistem ortamını “yeniden icat etmeden” dört hafta içinde uygulamaya koyabileceğiniz, pratik veri kalite kontrollerini tanımlar. Odak, işletme, yönetim, arayüzler, veri akışları ve IT ile departman arasındaki işbirliğinin etkileri üzerinedir.

Neden modern araçlara rağmen raporlar başarısız olur: kurumsal ortamlarda tipik nedenler

Yerleşik ortamlarda veriler birçok istasyon üzerinden üretilir: ERP, CRM, depo, portaller, özel kurumsal yazılımlar, import/export süreçleri, hizmet sağlayıcı arayüzleri. Her istasyon bir alanın anlamını değiştirebilir. Klasik bir örnek “müşteri”: Sistem A’da fatura alıcısıdır, Sistem B’de teslimat adresi, Sistem C’de lokasyon. Bu terimler bir analizde birleştirildiğinde, teknik olarak her şey doğru yüklense bile görünürde “yanlış” metrikler ortaya çıkar.

Raporları güvenilmez kılan tipik nedenler:

• Belirsiz semantik: Alanlar aynı isimde olabilir ancak sistemlere göre farklı şey ifade eder. Semantik burada veri formatı değil, alanın uzmanlık anlamını ifade eder.
• Sessiz arayüz kopmaları: Bir kaynaktaki bir alan değiştirilir (ör. yeni durum değerleri), hedef hat bunu “olduğu gibi” alır ve analizler bozulana kadar fark edilmez.
• Zayıf ana veriler: Çift kayıtlar, güncel olmayan adresler, tutarsız ürün katalogları ve bunlardan kaynaklanan yanlış eşlemeler.
• ETL/ELT kalite geçitleri olmadan: ETL (Extract, Transform, Load) bir DWH’ye yönelik yükleme ve dönüşüm hatlarını ifade eder. Kontroller olmadan hatalı veriler olduğu gibi yüklenir.
• Manuel düzeltmeler: Excel düzeltmeleri gölge mantık oluşturur. Rapor “doğru” görünür, ancak yeniden üretilebilir değildir.

Sonuç genelde benzerdir: Yönetim raporlarına düşmeden önce sapmaları erken tespit eden ve izlenebilir kılan güvenilir bir mekanizma eksiktir.

30 günde ölçülebilir: “daha iyi veri kalitesi”nin somut anlamı

“Daha iyi” ölçülebilir olmalı, aksi takdirde sadece bir his olarak kalır. 30 günlük bir plan için hem IT hem de departmanın kabul edeceği birkaç göstergede uzlaşmak faydalıdır. Etkili olduğu görülen üç seviye şunlardır:

• Girdi kalitesi: Kaynaktaki geçerli kayıtların oranı (ör. tam teslimat adresine sahip siparişler).
• Pipeline kalitesi: Kalite ihlali olmadan başarılı şekilde denetlenmiş yük işlerinin oranı (ör. aykırı değer yok, beklenmeyen null değerler yok).
• Rapor kalitesi: Rapor şikayetlerinin sayısı, çözüm süresi, manuel düzeltmelerin sayısı.

Küçük bir başlangıç kapsamına güvenirken: düzenli kullanılan iki ila üç kritik rapor (örn. ciro/katkı payı, teslimat zamanına uyum, stok göstergeleri). Bu raporlar için “kritik alanlar” tanımlayın ve kontrolleri tam olarak buralarda kurun. Bu, veri kalitesinin sonsuz bir şantiye olarak başlamasını engeller.

Her ortamda çalışan 5 kontrol kategorisi ile veri kalitesini iyileştirme

Aşağıdaki kontrol kategorileri, kullanılan BI-Tool’dan bağımsız olarak çalışacak şekilde seçilmiştir. Bunlar veritabanında, ETL hattında veya ayrı kontrol işleri olarak uygulanabilir. Önemli olan araç değil, tutarlı uygulamadır.

1) Tamlık kontrolleri: Zorunlu alanlar gerçekten dolu olmalı

Tamlık en hızlı kaldıraçtır, çünkü genellikle karmaşık mantık olmadan kontrol edilebilir. Tipik örnekler: müşteri kimliği, ürün numarası, kayıt tarihi, maliyet merkezi, durum, para birimi. Uygulamadaki tuzak: “NULL değil” yeterli değildir. Bir alan teknik olarak dolu olabilir ama iş açısından boş olabilir (örn. “0”, “–”, “bilinmiyor”).

Pratik kurallar:

• Her rapor için, metrikler açısından gerçekten önemli olan 10–20 zorunlu alan tanımlayın.
• sert (rapor güncellenemez) ile yumuşak (rapor güncellenir, ancak uyarı ve ticket ile) şekilde ayırın.
• Oranı takip edin: “Kayıtların %X’i tüm zorunlu alanları karşılıyor” – bu, 30 günde iyi ölçülebilir.

2) Geçerlilik kontrolleri: Değer aralığı, format ve mesleki konvansiyonlar

Geçerlilik demek: Bir değer sadece mevcut olmakla kalmaz, aynı zamanda izin verilen aralıkta makul olmalıdır. Bu teknik olabilir (tarih ISO biçiminde) veya mesleki olabilir (durum izin verilen değerlerden biri olmalı). Özellikle arayüzlerde beklenmedik yeni değerler sıkça gelir. Bir geçerlilik kontrolü bu tür değişiklikler için erken uyarı sistemi gibi çalışır.

Sağlam geçerlilik kontrollerine örnekler:

• Numarasyonlar (değer listeleri): durum değerleri, belge tipleri, muhasebe türleri.
• Değer aralıkları: Miktarlar >= 0, indirimler 0 ile 100 arasında, kayıt tarihi gelecekte olmamalı (tanımlanmış istisna ile).
• Format kuralları: ülkeye göre posta kodu uzunluğu, IBAN biçimi, e-posta kuralları (meşru istisnaları engellememek için toleransla).

Önemli olan istisnaları bilinçli yönetmektir: Çok katı bir kontrol aksi halde kaçış süreçlerine yol açar (“o zaman 999 gireriz”). Bu nedenle belgelenmiş gerekçe ve sona erme tarihi ile bir istisna sınıfı tanımlayın.

3) Tutarlılık kontrolleri: aynı öğe tüm tablolarda aynı olmalı

Tutarlılık, çelişkili raporların en yaygın nedenidir. Tipik durumlar: Bir sipariş “tamamlandı” olarak görünür ama hâlâ açık kalemler vardır. Bir müşteri “pasif”tir ancak yeni kayıtlar vardır. Bir ürün “engellenmiş”tir ama tahsis ediliyor. Tutarlılık kontrolleri alanlar ve tablolar arasındaki ilişkileri denetler.

Hızlı etki gösteren pratik tutarlılık kontrolleri:

• Durum mantığı: Bitiş durumu bir bitiş tarihi gerektirir; iptal işlemi bir iptal nedeni gerektirir.
• Referans bütünlüğü: Her belge kaydının geçerli bir maliyet merkezine sahip olması; her kalemin geçerli bir ürün ana kaydına sahip olması. (Veritabanı yabancı anahtarları zorlamasa bile, kontrol bunu izleyebilir.)
• Toplam kontrolü: Kalemlerin toplamı = belge toplamı (yuvarlama toleransı ile).

Bu kontroller özellikle değerlidir; aksi takdirde ancak toplantılarda fark edilen anlamsal kopuklukları görünür kılar. IT işletmesi ve proje yönetimi için tutarlılık kontrolleri, kaynak sistemdeki değişikliklerin yansıyıp yansımadığının iyi bir göstergesidir.

4) Çift Kayıt ve Kimlik Kontrolleri: „Bir müşteri“ gerçekten bir müşteri mi

Çift kayıtlar neredeyse her zaman süreç ve sistem sınırlarından kaynaklanır: yeni satış kanalları, portallar, manuel kayıt, migrasyonlar. İlgili birim bunu çift satış, yanlış segmentasyon veya belirsiz sorumluluk olarak fark eder. IT genellikle sadece farklı anahtarlar görür.

Ana veri yönetimi büyüklüğünde bir projeye gerek kalmadan pragmatik başlangıç:

• En önemli ana veri alanları için bir ya da iki eşleme kuralı tanımlayın (ör. Müşteri: İsim+Posta Kodu+Sokak; Tedarikçi: USt-ID veya IBAN).
• Bir „Çift Kayıt Şüphesi“-raporu oluşturun: otomatik silme olarak değil, bir sorumlu ile çalışma listesi olarak.
• Bir devralma kural seti belirleyin: Adres, ödeme koşulları, sınıflandırma için hangi veri kaynağının yetkili olduğu (System of Record)?

30 gün sonra ölçülebilir etki „artık çift kayıt yok“ değil, şu olacaktır: Çift kayıtlar daha hızlı bulunur, sorumlular bunları çözer ve en önemli raporlar çift sayımdan daha az etkilenir.

5) Aykırı Değer ve Drift Kontrolleri: Sayılar „komisch“ hale gelmeden önce

Birçok veri hatası „NULL“ değildir, aksine yavaş ilerler: Bir arayüz aniden %20 daha az kayıt getirir, bir durum farklı kullanılır, bir lokasyon yanlış dövizle muhasebeleştirir. Drift kontrolleri trendleri ve dağılımları inceler. Bunlar, günlük veya haftalık çalışan operasyonel göstergeler için özellikle faydalıdır.

Kolay uygulanabilir mekanizmalar:

• Hacim kontrolü: Gün/hafta başına kayıt sayısı bir aralık içinde (ör. Minimum/Maximum, hareketli ortalama).
• Dağılım kontrolü: Belirli durum değerleri veya kategorilerin payı beklenen aralıkta kalır (ör. „iptal“ aniden 10x artmaz).
• Gecikme kontrolü: Kaynak sistemdeki olay ile DWH/raporda kullanılabilir hale gelmesi arasındaki süre (günlük operasyon için önemli).

Drift kontrollerinin kabul görmesi için net alarm kurallarına ihtiyaç vardır. Aksi halde „alarm yorgunluğu“ oluşur: Çok sayıda uyarı, az eylem. Bu nedenle hangi sapmanın sadece kaydedileceğini ve hangisinin bir ticket oluşturacağını tanımlayın.

30 Günlük Plan: IT ve ilgili birimlerin kontrolleri devasa bir proje olmadan nasıl hayata geçireceği

Aşağıdaki dört haftalık döngü pratik açıdan uygundur. Hem klasik DWH/ETL kurulumları hem de modern veri platformları için uygundur. Amaç mükemmellik değil, işleyen bir kalite döngüsüdür.

Hafta 1: Odak oluşturma – Kapsam, veri kaynakları, sahiplik

IT ve ilgili birimle ortak bir toplantı ile başlayın (60–90 dakika). Sonuç bir şartname değil; sınırları net bir çalışma talimatıdır.

• 2–3 rapor seçin, iş açısından kritik olan ve düzenli kullanılan raporlar olsun.
• Veri kaynaklarını ve rapora kadar olan yolu tanımlayın: Kaynak sistem → Arayüz → Staging/ODS → DWH → BI. (ODS, Operasyonel Veri Deposu anlamına gelir; operasyonel veriler için bir ara depodur.)
• Sahipleri belirleyin: her rapor için bir iş sahibi (anlam/kurallar) ve bir teknik sahip (pipeline/işletim).
• Temel değerleri ölçün: mevcut hata oranları, şikâyet sayısı, tipik nedenler.

Burada küçük bir “veri terimleri listesi” hazırlamak faydalıdır: Hangi metrik ne demek, hangi alanlar buna giriyor? Bu sonraki tartışmaları azaltır.

Hafta 2: Kontrolleri kurma – önce eksiklik ve geçerlilik

İkinci haftada ilk otomatik kontroller oluşturulur. Hedef, günlük işi bloke etmeden hızlı sinyal almaktır.

• Seçilen raporların zorunlu alanları için eksiklik kontrolleri uygulayın.
• Durum değerleri, tarih aralıkları, temel formatlar için geçerlilik kontrolleri ekleyin.
• Kontrol sonuçlarını olaylar olarak tanımlayın: “OK”, “Uyarı”, “Hata”. Bu sınıflandırma, teknik ayrıntı metninden daha işletimsel olarak önemlidir.

Önemli: Kontrol sonuçlarını tarihsel olarak saklayın. Aksi halde iki hafta sonra iyileşip iyileşmediğinizi söyleyemezsiniz. Başlangıç için her kontrol için basit bir denetim kaydı yeterli olur (zaman, etkilenen kaynak, ihlal sayısı).

Hafta 3: Tutarlılık ve sapma – yalnızca temizlemek yerine veri akışlarını istikrara kavuşturma

Şimdi raporları “sarsan” nedenlere odaklanma zamanı. Tutarlılık kontrolleri tablolar/sistemler arasındaki kırılmaları ortaya çıkarır, sapma kontrolleri ise zaman içinde yavaşça oluşan değişiklikleri tespit eder.

• Rapor metriklerine doğrudan etki eden 3–5 tutarlılık kontrolü uygulayın (ör. toplam karşılaştırması, durum mantığı).
• Her veri kaynağı için 1–2 sapma kontrolü (genellikle hacim ve gecikme en iyi başlangıçtır) kurun.
• Kısa bir haftalık gözden geçirme (30 dakika) kararlaştırın: Hangi ihlaller tekrar ediyor? Hangileri “gerçek” hatalar, hangileri kural güncellemesi gerektiriyor?

İşbirliğinin karşılığını verdiği nokta budur: Birçok “veri problemi” aslında süreç problemidir (ör. durum bakımının yapılmaması, satışta zorunlu alanların eksik doldurulması). Eğer iş birimi sahiplik üstlenirse, etki yaratmayan ticket’lar yerine somut önlemler ortaya çıkar.

Hafta 4: İşletimleştirme – Eskalasyon, Ticketler, onaylar, raporlama hijyeni

İşletimsel olarak bağlanmadan kontroller pilot sonrası kaybolur. Dördüncü hafta rutin ve net yollar getirir.

• Alarm ve ticket kuralları: Hangi kontrol sınıfı otomatik olarak bir ticket üretir? Alıcı kimdir? Hangi yanıt süresi gerçekçidir?
• Sürüm koruması: Arayüzlerde veya veri modellerinde değişiklik yapıldığında, üretime geçmeden önce asgari bir kontrol seti sınanır (kalite geçidi).
• Veri sahipleri çalışma listeleri: olası çift kayıtlar, eksik sınıflandırmalar, sona erme tarihi olan istisnalar.

30 günün sonunda kısa bir sonuç belgesine sahip olmalısınız: Bazeline vs. güncel durum (hata oranları, şikayetler, çözüm süresi). Bu güven oluşturur – ve bir sonraki genişletmeyi planlanabilir kılar.

Kontrollerin teknik olarak en mantıklı olduğu yer: Kaynak, Arayüz, DWH veya BI?

Projelerde sıkça sorulan soru şudur: „Kontrolleri nereye koyuyoruz?“ Yanıt, etkinin ve işletmenin gereksinimlerine bağlıdır. Kural: Mümkün olduğunca erken kontrol edin, ama rapora gerektiği kadar yakın olun.

• Kaynak sistem: Zorunlu alanlar ve süreç kuralları için ideal (ör. durum mantığı). Avantaj: Hatalar hiç oluşmaz. Dezavantaj: Değişiklikler uzman birim onayı gerektirir ve süreçleri etkileyebilir.
• Arayüz: Format ve eşleme kontrolleri için uygun. Avantaj: sonraki sistemleri korur. Dezavantaj: katı reddetmeler durumunda veri birikmeleri oluşabilir.
• DWH/Staging: Tutarlılık kontrolleri, toplam kontrolü, hacim ve drift kontrolleri için uygundur. Avantaj: merkezi ve iyi izlenebilir. Dezavantaj: Hatalar zaten „giriş yapmış“ olur ve geriye dönük ele alınmalıdır.
• BI: Daha çok son koruma katmanı olarak (ör. uyarı notları). Avantaj: kullanıcılara hızlıca görünür. Dezavantaj: nedenleri temiz şekilde düzeltmek için genellikle çok geçtir.

30 günlük bir başlangıç için DWH/Staging genellikle pragmatik bir noktadır; çünkü BT orada kontrolü elinde tutar ve operasyonel süreçlere müdahale etmez. Orta ve uzun vadede, seçili kontrollerin kaynağa doğru ötelenmesi genellikle fayda sağlar.

Hafif Veri Yönetişimi: Veri kalitesini günlük işleyişte gerçekten sağlayan roller

„Data Governance“ terimi komiteler ve yönergeler çağrıştırır. Hızlı iyileştirmeler için sorumlulukları netleştiren yalın bir model yeterlidir. Projelerde üç rol işe yaradı:

• Veri Sahibi (İş Birimi): Anlam, kurallar ve istisnaların sorumluluğunu taşır. Bir değerin alan açısından kabul edilebilir olup olmadığına karar verir.
• Veri Bakım Sorumlusu (operasyonel): Çalışma listelerini (örn. çift kayıtlar, eksik sınıflandırmalar) işler ve sürekli bakımın sağlanmasından sorumludur.
• Teknik Sorumlu (IT): Kontrolleri, izlemeyi, arayüzleri ve eskalasyonları işletir; izlenebilirlik sağlar (loglar, geçmiş, yeniden üretilebilirlik).

Önemli olan, eskalasyonların belirsizlik içinde sona ermemesidir: Bir kontrol tekrar tekrar ihlal ediliyorsa, ya süreç değişikliği, iş yazılımında UI uyarlaması ya da bilinçli bir kural değişikliği gerekir. „Yok saymak“ bir seçenek değildir; aksi takdirde denetim sistemi güvenilirliğini yitirir.

Tipik takılma noktaları – ve bunlardan nasıl kaçınılır

Aynı anda çok fazla kontrol

Takımlar 100 kural tanımlasa ama hiçbirini tutarlı şekilde işletmezse, kazanılan bir şey olmaz. Seçilen raporlara doğrudan etki eden birkaç kontrolden başlayın. İşletme stabil çalıştığında genişletin.

Aktionspfad olmayan Kontroller

Sadece „kırmızı“ gösteren bir kontrol hayal kırıklığı yaratır. Her kuralın bir Owner’ı, bir işleme şekli (Ticket, iş listesi, süreç) ve raporun engellenip engellenmeyeceğine yoksa sadece uyarı verip vermeyeceğine dair bir kararı olmalıdır.

Uç nedenleri düzeltmek yerine „bir kere temizleyelim“

Tek seferlik temizlik baz çizgilerini iyileştirmeye yardımcı olabilir. Kalıcı etki ancak neden ele alındığında sağlanır: zorunlu alanlar, giriş formları, arayüz sözleşmeleri, durum mantığı, migrasyonlar. Aksi halde sorun geri döner.

Veri kökeninin izlenebilirliğinin olmaması

Tekrarlayan belirsizlikler için basit bir Data Lineage görünümü faydalıdır: Bir alan nereden geliyor, hangi dönüşümler uygulanıyor, en son kim neyi değiştirdi? Data Lineage tam olarak bu köken zincirini ifade eder. Bunun büyük bir araç olarak gelmesine gerek yok — genellikle her rapor için bakımlı bir özet yeterlidir.

Daha iyi veri kalitesi kararları nasıl iyileştirir – „daha güzel gösterge panelleri“ ötesinde

Yarar yalnızca daha az hata şeklinde değil, daha hızlı ve güvenilir kararlar olarak kendini gösterir:

• Daha az koordinasyon çabası: Toplantılar yeniden sayı kaynakları yerine önlemler üzerine döner.
• Daha hızlı kök neden analizi: Kontrol geçmişleri bir hatanın ne zaman başladığını gösterir (ör. bir sürüm veya arayüz değişikliğinden sonra).
• Daha istikrarlı planlama: Tahminler ve stok kararları veri artefaktleri tarafından daha az sapmaya uğrar.
• Daha az gölge-IT: Resmi raporlar güvenilir olduğunda, kendi Excel dünyalarını kurma baskısı azalır.

Özellikle IT-Leitung ve proje sorumluları için kritik olan: Veri kalitesi bir işletim sistemi meselesidir. Mimari (veri akışları), işletme (Monitoring, Ticket’lar), süreçler (bakım yükümlülükleri) ve modernizasyon (arayüzler, veri modelleri) arasında bağlantı kurar.

Fazit: 30 gün içinde rakam tartışmasından yönetilebilir bir kalite sürecine

Veri kalitesini iyileştirmek araçtan ziyade disiplin meselesidir: net tanımlar, az sayıda etkili Kontrol, tarihsel olarak kaydedilmiş ölçümler ve günlük işleyişte çalışan bir eylem yolu. 2–3 kritik raporla başlayıp bütünlük ve geçerliliği hızlıca otomatikleştirir, ardından tutarlılık ve drift’i eklerseniz, raporlarda bir ay içinde ölçülebilir bir stabilite elde edersiniz — ve ek yük olmadan büyüyebilecek bir Data Governance temeli ortaya çıkar.

Hangi kontrollerin sistemlandığınızda en hızlı etkiyi sağlayacağını ve bunun işletme içinde nasıl sağlam şekilde yerleştirileceğini incelemek isterseniz, bunu bir sonraki adımda yapılandırılmış şekilde konuşabilirsiniz:

Bu konu için ayrıca Raporlamayı İyileştirme ve Ana Veri Kalitesi önemlidir. Yazı bu boyutları anlaşılır şekilde konumlandırır ve günlük hayatta nelerin önemli olduğunu gösterir.

Proje veya modernizasyon girişimini Net-Base ile görüşün.