Her birkaç yılda bir, SEDDK veya EGM BES için yeni bir raporlama çerçevesi yayımlar. Sektör bunu bir mühendislik problemi olarak ele alır: yeni şema, yeni alanlar, yeni gönderim formatı, yeni son teslim tarihi. Ekipler projeler kurar, tedarikçilerle pazarlık eder, warehouse'u genişletir, teslim eder. Düzenleyici ilk gönderimi kabul eder. Herkes yoluna devam eder.
Sonra biri geçmiş karşılaştırması yapar — belki bir aktüeryal inceleme, belki bir iç denetim, belki 2019'daki bir durum değişikliğinin yeniden yapılandırılmasını gerektiren bir müşteri şikayeti — ve her şey darmadağın olur. Eski veri, yeni çerçevenin sandığı anlama gelmiyordur. Ve yakalandığı sırada gerçekte ne anlama geldiğini kimse yazmamıştır.
Bu, grandfathering sorunudur ve BES'te neredeyse başka herhangi bir düzenlemeye tabi pipeline'dan daha kötüdür, çünkü ürünün kendisi, altında sürekli değişen kurallar tarafından yönetilen çok on yıllık bir sözleşmedir.
Temel mesele: tanımlar geriye dönük uyumlu değildir
Yeni bir raporlama kuralı bir alanı yeniden tanımladığında — diyelim ki "aktif katılımcı" olarak neyin sayıldığı veya katkı payı gecikmesi ile sözleşme askıya alma arasındaki bir durum geçişinin nasıl sınıflandırılacağı — üç kötü seçeneğiniz vardır:
- Geçmişi yeni tanım altında yeniden hesaplayın. Ucuz, hızlı ve hukuken savunulamaz. Geçmiş hakkında, o zamanki yürürlükteki kurallar altında hiçbir zaman doğru olmayan şeyler iddia ediyorsunuz.
- Geçmişi eski tanım altında dondurup yeniyi sadece ileriye dönük uygulayın. İlke olarak doğru, ancak trend çizgilerinin anlamsız olduğu ve aynı katılımcının kesişim tarihinde iki çelişkili durumda görünebildiği raporlar üretir.
- Her ikisini de sonsuza kadar paralel olarak sürdürün. Dürüst cevap. Aynı zamanda kimsenin bütçelemediği cevap.
Çoğu şirket sessizce birinci seçeneği tercih eder. Yeni pipeline eski kayıtları yeni mantık üzerinden okur. 2020'de eski katılım payı kuralları altında bir şekilde sınıflandırılan bir sözleşme, durum tanımı değiştiği için 2024 raporunda yeniden sınıflandırılır. Kimse bunu işaretlemez. Düzenleyici tutarlı rakamlar görür. Denetçi, dikkatli bakarsa, kendi hukuki tarihini yeniden yazan bir şirket görür.
Somut bir örnek: devlet katkısı hak ediş hesaplaması
Devlet katkısı hak ediş takvimi defalarca revize edilmiştir. Her revizyon, hangi katkı dönemlerinin hangi hak ediş kademesine sayılacağını ve sınırlarda kısmi yılların nasıl ele alınacağını değiştirmiştir.
2013'te katılan, 2016'da katkıları durduran, 2019'da yeniden başlayan ve 2022'de çıkan bir katılımcının hak ediş pozisyonu, hangi kural setinin hangi dönemi yönettiğine bağlıdır. Hukuken doğru cevap birleştirilmiş bir hesaplamadır: 2013–2015 için kural A, 2016–2018 için kural B, sonrası için kural C. Kullanışlı cevap — ve çoğu raporlama pipeline'ının fiilen ürettiği cevap — mevcut kuralı tüm katkı geçmişine uygulamaktır, çünkü mevcut veri modelinin ifade ettiği budur.
İki rakam farklıdır. Bazen küçük miktarlarda. Bazen katılımcıya çıkışta borçlu olunanı değiştirecek kadar. Ve pipeline yalnızca mevcut kural yorumunu sakladığı için, orijinal hesaplama ham işlem loglarına geri dönmeden yeniden üretilemez — çoğu şirketin sakladığı ancak artık yorumlayacak kodunun bulunmadığı loglara.
Bu neden "daha iyi veri yönetişimi" ile çözülemez
Standart danışman cevabı şudur: şemalarınızı sürümleyin, yürürlük tarihli kural tanımları saklayın, bitemporal bir model tutun. Bu doğru bir tavsiyedir ve ben de kendim verdim. Ayrıca, pipeline'ınız 2013'te bunların hiçbiri olmadan inşa edildiyse — ki bugün üretimdeki neredeyse her BES pipeline'ını bu tanımlıyor — size yardımcı olmaz.
Bitemporality'yi hiç bunun için tasarlanmamış bir sisteme sonradan uyarlamak bir migrasyon değildir. Bir arkeoloji projesidir. Hayatta kalan eserlerden, bir veri parçasının yazıldığı anda ne anlama geldiğini yeniden yapılandırmaya çalışıyorsunuz — genellikle onu yazan kişi şirketten ayrılmadan yıllar önce.
Pratik kısıtlamalar:
- Kaynak sistemler değiştirildi, bazen iki kez. Orijinal alan semantikleri artık var olmayan tedarikçi dokümantasyonunda yaşıyor.
- Operasyon ekipleri, uç durumları ele almak için belgelenmemiş iş kuralları uyguladı. Bu kurallar o zaman doğruydu ve şimdi görünmez.
- Düzenleyici yazışmalar — belirli bir kuralın nasıl yorumlanması gerektiğini açıklığa kavuşturan gerçek mektuplar — veri soy kütüğünde değil, e-posta arşivlerinde ve fiziksel dosyalarda oturuyor.
- Orijinal yorumları SEDDK ile müzakere eden kişiler emekli oldu veya bir rakipte çalışıyor.
Gerçekten ne işe yarıyor
Denetim altında ayakta kalan iki yaklaşım gördüm. Hiçbiri ucuz değil.
Birincisi kayıt düzeyinde açık kural seti etiketlemesi. Her geçmiş kayıt, yakalanmasını hangi düzenleyici çerçevenin yönettiğine dair bir işaret taşır. Raporlama katmanı daha sonra çerçeveler arasında — belgelenmiş, gözden geçirilebilir mantıkla — açıkça çeviri yapmak zorundadır. Yeni bir çerçeve geldiğinde, çeviri kurallarını bir kez yazarsınız, hukuk ve aktüerya ile gözden geçirir ve dondurursunuz. Eski raporlar yeniden üretilebilir kalır. Yeni raporlar savunulabilir, çünkü çeviri görünürdür.
İkincisi raporun kendisinde süreksizliği kabul etmek. Bazı şirketler — daha dikkatli olanlar — düzenleyici değişiklik tarihlerinde açık kesintilerle trend verileri yayımlar ve metodolojiyi dipnotla belirtir. Bu, grafikleri çirkinleştirdiği için yönetim tarafından sevilmez. Denetçiler tarafından sevilir çünkü gerçektir.
En kötü yaklaşım, ve en yaygın olanı, sessiz geriye dönük yeniden sınıflandırmadır: eski veriler üzerinde yeni mantığı çalıştırın, düzgün bir trend çizgisi yayımlayın ve kimsenin sormayacağını umun. Bu, çalışmayana kadar çalışır. Başarısız olduğunda, bir düzenleyici bulgu olarak başarısız olur ve bulgu veri hakkında değildir — şirketin kendi tarihini yanlış temsil etmesi hakkındadır.
Rahatsız edici sonuç
Bir BES pipeline'ı aslında bir veri pipeline'ı değildir. Sözleşmelerin olgunlaşmasından daha hızlı değişen kurallar tarafından yönetilen uzun süreli bir sözleşmenin hukuki kaydıdır. Bir çerçeve migrasyonunu bir mühendislik projesi olarak ele almak — yeni şema içeri, eski şema dışarı — gördüğüm uyum sorunlarının çoğunu üreten kategori hatasıdır.
Yeni pipeline'ı inşa etmeden önce, eski verinin ne anlama geldiğini söyleyeceğinize karar verin. Yazın. Hukukun imzalamasını sağlayın. Sonra inşa edin. Pipeline kolay olan kısımdır.