Bu kalıbı görecek kadar çok düzenleyici incelemede bulundum. Denetçi dosyayı açar, sunulan değere şöyle bir bakar ve prosedürel gibi görünen ama aslında öyle olmayan bir şey sorar: "Bu rakam nereden geliyor?"
Bu anda başarısız olduğunu gördüğüm ekipler nadiren yanlış rakamı olanlardır. Onlar, düzenleyiciyi poliçe yönetim sisteminden başlayıp staging katmanı, dönüşümler ve mutabakat üzerinden formdaki değere kadar adım adım gezdiremeyen ekiplerdir. Bir diyagramla değil. Zaman damgaları ve sorumlularıyla birlikte, satır satır.
Sizi Öldüren Varsayım
Çoğu BES ve sigorta veri ekibi, düzenleyici raporlamayı bir çıktı problemi olarak ele alır. Pipeline'ı kur, teslim tarihine yetiştir, kutucuğu işaretle. İç KPI, sunum doğruluğudur — rakam finansın kapattığıyla eşleşti mi?
Bu çerçeveleme yapısal olarak yanlıştır. Doğruluk zaten olması gerekendir. EGM ve SEDDK'nın bir inceleme sırasında gerçekten test ettiği şey, kuruluşunuzun rakam üzerinde kanıta dayalı kontrole sahip olup olmadığıdır. İki farklı soru:
- Doğruluk: Değer doğru mu?
- Kanıta dayalı kontrol: Değerin tam olarak nasıl üretildiğini, her adımı kimin onayladığını ve herhangi bir girdi farklı olsaydı ne olacağını artifact'lerle ispatlayabilir misiniz?
İlk soru bir sorguyla cevaplanır. İkincisi mimariyle cevaplanır ve inceleme sırasında geriye dönük olarak eklenemez.
Chain of Custody Aslında Ne Demek
Bir BES bağlamında, EGM'ye sunulan tek bir katkı payı rakamı şu yolları geçebilir:
- Emeklilik yönetim sistemi (sözleşme düzeyindeki kayıtlar)
- Banka dosyalarına karşı tahsilat mutabakatı
- Portföy yönetim sisteminden günlük NAV hesaplaması
- Genel muhasebede bir tahakkuk düzeltmesi
- Düzenleyici taksonomi için bir yeniden sınıflandırma
- Önceki dönemden bilinen bir düzeltme için manuel bir müdahale
Her adım, rakamın şekil değiştirdiği bir yerdir. Düzenleyicinin incelemesi bu adımlardan birini soracaktır — genellikle bir Excel ve e-posta onayıyla hallettiğiniz adımı. Cevabınız "operasyon ekibi bize düzeltilmiş dosyayı gönderdi" ise, güvenilirliğinizi zaten kaybettiniz.
Firmaların Başarısız Olduğu Takip Soruları
Pratikte zayıf pipeline'ları ifşa eden sorular hep aynı birkaç tanedir:
- Bu toplama ait kaynak kaydı sunum tarihi itibarıyla gösterin.
- Yeniden sınıflandırmayı kim onayladı ve iş kuralı referansı neydi?
- Sunumdan sonra altta yatan poliçe iptal edilirse, bu bir sonraki döneme nasıl yansır?
- Aynı alan, geçen ay sunulan aktüerya raporunda neden farklı bir değere mutabakat ediyor?
- Mevcut sürümü değil, sunum tarihinde çalışan dönüşüm mantığının sürümünü sağlayın.
Sonuncusu, aslında yetkin ekiplerin çöktüğünü gördüğüm noktadır. dbt veya SQL mantığını sürekli deploy ederler, dönüşümlerini bir sunum zaman damgasına karşı versiyonlamazlar ve düzenleyici rakamı hangi kodun ürettiğini sorduğunda, bunu fiziksel olarak yeniden üretemezler.
Yapısal Hazırlık Nasıl Görünür
İncelemelerden drama olmadan sağ çıkan firmalar dört uygulamayı paylaşır:
Değiştirilemez sunum snapshot'ları. Her düzenleyici sunum dondurulmuş bir artifact üretir: kaynak extract'leri, dönüşüm kodu sürümü, ara tablolar, nihai değerler ve onay izi. Saklanmış, hash'lenmiş, sunum ID'si ile erişilebilir. "Yeniden inşa edebiliriz" değil — fiiliyatta saklanmış.
Teknik olmayan bir denetçinin takip edebileceği lineage. Otomatik kolon düzeyinde lineage içeride faydalıdır ama toplantıda işe yaramaz. Her rapor satırı için otomatik olarak üretilen ama SQL diliyle değil, iş kuralının diliyle yazılmış, insan tarafından okunabilir bir chain-of-custody belgesine ihtiyacınız var.
Manuel müdahaleler birinci sınıf olaylar olarak ele alınır. Her override, düzeltme ve manuel müdahale bir ticket, onaylayıcı, gerekçe kodu ve bağlantılı bir iş kuralı ile loglanır. Birisi bir değeri pipeline'a girmeden önce Excel'de düzenliyorsa, bu tolere edilecek bir operasyonel gerçek değil, bir kontrol boşluğudur.
Kontrol listesi değil, ürün olarak mutabakat. Kaynak sistem, warehouse ve sunulan değer arasındaki mutabakat; varyans eşikleri, istisna logları ve onay ile birlikte kalıcı bir artifact olmalıdır. Ekibin sunumdan bir gece önce çalıştırıp attığı bir şey değil.
Altta Yatan Kültürel Sorun
Bunun çoğu bir teknoloji sorunu değil. Bunu iyi yapacak araçlar on yıldır var. Sorun şu: Türk sigorta ve emeklilik firmalarındaki veri ekipleri, savunulabilirlik üzerinden değil, teslimat üzerinden ölçülüyor. Audit'e hazır bir pipeline ürettiği için kimse terfi almıyor. Doğru rakamla teslim tarihine yetiştikleri için terfi alıyorlar.
İç teşvik yapısı, kanıta dayalı kontrolü doğrulukla aynı ağırlıkta ödüllendirmediği sürece, bir sonraki inceleme öncekine benzeyecek: sürekli belgelenmiş olması gereken şeyi yeniden inşa etmek için bir telaş ve düzenleyicinin firmanın ne yaptığını bildiğine dair güveninin yavaş yavaş erimesi.
Rakam hiçbir zaman asıl mesele değildi. Düzenleyici zaten bir rakam üretebileceğinizi varsayıyor. Öğrenmek istedikleri şey, bir sonraki rakamla güvenilecek kadar kendi makinenizi anlayıp anlamadığınız.