Denetçilere açıklamak zorunda kaldığım her emeklilik raporlama olayı aynı noktaya varıyor. İşlem hattına değil. Hesaplama motoruna değil. Referans katmanına — kimsenin "değişmiyor" diye incelemediği o sıkıcı tablolara.
Ama değişiyorlar. Sadece iz bırakmayacak şekillerde değişiyorlar.
Statik veri yanılsaması
Herhangi bir emeklilik operasyon ekibine en yüksek riskli verilerinin ne olduğunu sorun; katkı işlemlerini, fon NAV beslemelerini veya katılımcı demografik verilerini gösterirler. Referans verisi — fon kodları, ürün parametreleri, katkı tipi eşlemeleri, kesinti kategorileri — veri ambarının "düşük oynaklık" olarak işaretlenmiş bir köşesinde durur. Bir kere yüklenir, bir kere gözden geçirilir ve unutulur.
Sonra şunlardan biri olur:
- Bir fon yeniden yapılandırılır ve yeni bir EGM kodu altında yeniden ihraç edilir, ancak eski kod eski sözleşmeler için aktif kalır
- Düzenleyici yeni bir katkı türü ekler (devlet katkısı takviyesi, otomatik katılım varyantları) ve mevcut eşlemelerin sadece genişletilmesi değil, yeniden kapsamlandırılması gerekir
- Bir ürün parametresi — örneğin hak ediş eşiği veya devlet katkısı uygunluk bayrağı — yeni poliçeler için değişir ancak eski poliçeler için tarihsel olarak doğru kalmalıdır
- İki fon birleşir ve devam eden fon, kaynak sistemde hiç eşlenmemiş yükümlülükleri devralır
Bu olayların hiçbiri uyarı tetiklemez. Hiçbiri işlem hatlarını bozmaz. İşler çalışmaya devam eder. Raporlar üretilmeye devam eder. Ve o referans katmanı üzerine kurulan her HAYMER gönderimi bu kaymayı miras alır.
Hatalar neden sessizdir
İşlem verisinin doğal koruyucu bantları vardır. Toplamlar dengelenmek zorundadır. NAV × birim, pozisyon değerine eşit olmalıdır. Katılımcı sayıları poliçe yönetim sistemiyle mutabık kalır. Bir şey bozulursa, aşağı akış mutabakatı bunu bir iki döngü içinde yakalar.
Referans verisinin bunların hiçbiri yoktur. Yanlış sınıflandırılmış bir katkı türü doğrulamayı geçemez değil — teknik olarak geçerli ama anlamsal olarak yanlış bir kayıt üretir. GEV raporu gönderilir. EGM ekstresi dengelenir. Düzenleyici, temiz şekilde ayrıştırılan ve tüm şema kontrollerinden geçen bir dosya alır. Altı ay sonra, hedefli bir denetim sırasında birisi X katılımcısının işveren katkısının neden 1. çeyrekte A kategorisi altında, 3. çeyrekte B kategorisi altında ve buna karşılık gelen bir olay olmadan raporlandığını sorar. Şimdi bir lookup tablosunun durumunu git geçmişinden yeniden inşa ediyorsunuz — tabii ki git'te olduğunu varsayarsak.
Kimsenin çözmediği sürümleme sorunu
Çoğu kurumsal referans verisi üç yerden birinde yaşar ve hepsi yanlıştır:
- Kaynak sistemin operasyonel tabloları. Yerinde üzerine yazılır. Geçmiş yoktur. İş birimi bir fon parametresini değiştirdiğinde, eski değer gitmiştir.
- SCD Type 2 olmayan bir veri ambarı boyut tablosu. Birisi "nasılsa sık değişmiyor" diye Type 1 olarak inşa etmiştir. Aynı sorun.
- Ürün ekibi tarafından yönetilen bir elektronik tablo. Gerçek geçmiş, e-posta zincirleri ve
fund_mapping_FINAL_v3_revised.xlsxadlı dosya sürümlerinde bir yerlerde vardır.
Aslında ihtiyacınız olan çift zamanlı (bitemporal) sürümlemedir: iş kuralının ne zaman uygulandığı için valid-from/valid-to ve bunu ne zaman bildiğiniz için knowledge-from/knowledge-to. Düzenleyici raporlama, bir eşleme hatası tespit edildiğinde önceki dönemlerin yeniden ifade edilmesini sık sık gerektirir. Çift zamanlı takip olmadan, denetçilerin soracağı iki soruyu yanıtlayamazsınız: ne raporladık ve ne raporlamalıydık?
Sahadan somut örüntüler
Materyal düzeltmeye yol açtığını gördüğüm birkaç örnek:
- Katkı türü yeniden sınıflandırması. Bir katkı kategorisi yıl ortasında iki alt kategoriye bölündü. Eşleme veri ambarında güncellendi ancak sürümlenmedi. Değişiklikten sonra yeniden üretilen her önceki dönem raporu, eski işlemlere karşı yeni eşlemeyi kullandı. "Doğru" olan raporlar bir gecede — geriye dönük olarak — "yanlış" oldu.
- Fon kodu yeniden kullanımı. Bir fon kapatıldı ve on sekiz ay sonra operasyon ekibi tarafından yeni bir fona aynı iç kod atandı. Bu koda katılan herhangi bir raporda geçmiş pozisyonlar aniden yeni fona aitmiş gibi görünmeye başladı.
- Ürün parametresi kayması. Devlet katkısı uygunluk kuralları yeni poliçeler için değişti. Parametre tablosu ürün başına tek bir bayrak sakladığından, eski poliçeler yeni kuralı devraldı ve sonraki gönderimlerde yanlış şekilde uygun olarak işaretlendi.
- Sessiz hiyerarşi değişiklikleri. Bir fon ailesi yeniden düzenlendi. Fon hiyerarşi tablosundaki üst-alt ilişkileri yerinde güncellendi. Aile düzeyinde toplulaştırılmış raporlama aniden önceki dönemlerle bağlanmayı bıraktı ve kimse nedenini açıklayamadı.
Her durumda, işlem verisi iyiydi. İşlem hatları iyiydi. Referans katmanı arıza noktasıydı ve bunu kanıtlamak aylar aldı.
Gerçekten işe yarayan şeyler
Bu işlem hatlarına yıllarca sahip olduktan sonra, çözümler pek göz alıcı değil:
- Referans verisini kendi SLA'i, sahibi ve değişiklik kontrol süreci olan birinci sınıf bir varlık olarak ele alın. Kaynak sistemin bir yan ürünü olarak değil.
- Çift zamanlı depolama, pazarlığa açık değil. Her referans tablosu valid-from, valid-to, knowledge-from, knowledge-to alır. Yerinde güncelleme yok. Asla.
- Değişmez kod atamaları. Bir fon kodu, ürün kodu veya katkı türü kodu bir kez verildiğinde, asla yeniden kullanılmaz. Bir fon kapanırsa, kodu kalıcı olarak emekliye ayrılır. Bu teknik değil, politik bir karardır ve iş biriminden gelmelidir.
- Her yüklemede referans verisi diff'leri. İşlem hattı, son çalıştırmadan bu yana referans katmanında neyin değiştiğine dair bir rapor üretmeli ve bu rapor bir log dosyasında oturmak yerine iş etkisini anlayan birine gitmelidir.
- Sabit önceki dönem raporlarına karşı regresyon testleri. Bugün geçen çeyreğin HAYMER gönderimini yeniden üretiyorsanız, bayt bazında aynı çıktıyı üretmelidir. Üretmiyorsa, referans katmanında hareket etmemesi gereken bir şey hareket etmiştir.
- Eşleme mantığını referans verisinin kendisinden ayırın. "Katkı türü X, Z tarihi itibarıyla raporlama kategorisi Y'ye eşlenir" kuralı, katkı türleri listesiyle aynı şey değildir. Bunları bağımsız olarak sürümleyin.
Rahatsız edici kısım
Çoğu ekip yanmadan bunu yapmaz. Referans verisi yönetişimi, bir denetçi sizden iki yıl önceki belirli bir raporlama tarihi itibarıyla fon ana verinizin tam durumunu yeniden üretmenizi isteyene ve bunu yapamayacağınızı fark edene kadar bir ek yük gibi görünür.
İşlem hattı ilgi görür çünkü bozulduğunda gürültülü bozulur. Referans katmanı ihmal edilir çünkü bozulduğunda hiç bozulmaz — sadece dış bir birisi fark edene kadar aşağı akıştaki her şeyi sessizce zehirler.
İkinci arıza modu için inşa edin. Kariyerleri bitiren o.