Segment Kodu Problemi: BES Raporlamasında Ürün Sınıflandırması Neden En Sessiz Şekilde Bozulmuş Katmandır

Türkiye'deki her emeklilik şirketinin bir yerlerde DIM_PRODUCT_SEGMENT ya da REF_URUN_SEGMENT gibi bir isimde bir tablosu vardır. İçinde belki 40 satır bulunur. Önemsiz görünür. Önemsiz değildir. Deneyimlerime göre, tüm BES raporlama yığınının en sessiz şekilde bozulmuş tek katmanıdır ve kimsenin fark etmemesinin nedeni, bir düzenleyici size 2013'ten kalma bir rakamı savunmak zorunda bırakan bir soru sorana kadar sessizce başarısız olmasıdır.

Bu katmana, şu ya da bu şekilde, yaklaşık on yıldır sahibim. İşte gerçekte ne yanlış gidiyor.

Rahat Yalan: Segment Bir Boyuttur

Miras aldığım ya da inşa ettiğim her veri modelinde, ürün segmenti bir boyut niteliği olarak ele alınır. Bir poliçeniz vardır, poliçenin bir ürünü vardır, ürünün bir segmenti vardır. Star schema, temiz join, herkes mutlu.

Bu, şu sorulardan birine cevap vermek zorunda kalana kadar sorunsuz çalışır:

• Bu 2011 poliçesinin 2016 raporlama tarihi itibarıyla segment sınıflandırması neydi?
• 2019 SEDDK genelgesi grup emekliliği tanımlarını yeniden yazdığında hangi poliçeler A segmentinden B segmentine geçti?
• 2022 Q2 HAYMER ekstresi neden Q1 ekstresine göre "Otomatik Katılım" segmentinde 14.000 daha fazla poliçe gösteriyor, o çeyrekte hiç yeni AK poliçesi almadığımız halde?

Üçünün de cevabı aynı: segment ürünün bir özelliği değildir. Belirli bir zaman aralığı için geçerli olan yasal bir tanımlamadır ve satır yazıldığı gün pipeline'ınızın hangi mapping tablosunun hangi versiyonuna karşı çalıştığına bağlıdır.

Çürüme Nasıl Başlar

Bir BES pipeline'ında segment kodunun tipik yaşam döngüsü şöyle görünür:

1. Ürün, diyelim ki 2010'da piyasaya sürülür. Birisi, o dönemde yürürlükte olan tanımlara göre başlangıçta BIR_001 segmentini atar.
2. 2013'te düzenleyici, "bireysel" ile "gruba bağlı bireysel"in ne olarak nitelendiğini yeniden tanımlayan bir genelge yayımlar. Kimse tarihsel satırları güncellemez. Mapping tablosuna yalnızca yeni poliçeler için bir yama uygulanır.
3. 2016'da Otomatik Katılım başlar. Yeni bir segment kodu eklenir. Birisi, dönüştürülen bir alt küme poliçe için backfill scripti yazar. Script bir kez çalıştırılır, sonuçlar versiyonlanmaz.
4. 2018'de ürün ekibi orijinal ürün adını emekliye ayırır ve yeni bir SKU'ya katar. Mapping tablosu manuel bir UPDATE alır. Geçmiş yok. Effective date yok. Bir Jira ticket'ının ötesinde changelog yok, o ticket da o zamandan beri arşivlenmiş bir Confluence sayfasına referans veriyor.
5. 2021'de aktüeryadan biri GEV gönderiminin neden geçen yılın audit dosyasından farklı bir segment dağılımı gösterdiğini sorar. Üç kişi iki hafta audit dosyası üretildiğinde hangi mapping versiyonunun yürürlükte olduğunu yeniden inşa etmeye çalışır. Başaramazlar. Kıdemli bir yönetici mevcut rakamların "yeterince yakın" olduğuna karar verir ve onaylar.

Bu tam sıralamanın birden fazla kurumda oynandığını izledim. Detaylar değişir, örüntü değişmez.

Kimsenin Uygulamadığı Çözüm Neden Tek Çözümdür

Segment kodu bir boyut niteliği olarak değil, bitemporal bir gerçek olarak modellenmelidir. Spesifik olarak:

• Valid time: segment sınıflandırmasının yürürlükteki düzenleyici tanımlar altında poliçeye yasal olarak uygulandığı dönem.
• Transaction time: sisteminizin bu sınıflandırmanın doğru olduğuna inandığı dönem.

Bunlar iki farklı eksendir ve her ikisine de ihtiyacınız vardır. HAYMER size 31.12.2015'te bir poliçenin hangi segmente ait olduğunu sorduğunda, 31.12.2015'te yürürlükte olan düzenleyici tanımı, 31.12.2015'te var oldukları haliyle poliçe niteliklerine uygulayarak cevap vermeniz gerekir — bugün mapping tablonuzun tuttuğu tanımı değil.

Pratikte bu şu anlama gelir:

• policy_id, segment_code, valid_from, valid_to, recorded_from, recorded_to ve bir regulation_version_id içeren bir SEGMENT_ASSIGNMENT tablosu.
• Hangi genelgenin, hangi yürürlük tarihinin ve hangi sınıflandırma mantığının yürürlükte olduğunu yakalayan bir REGULATION_VERSION tablosu.
• Her mapping tablosu değişikliği aynı versiyonlamadan geçer. Yerinde UPDATE yok. Hiçbir zaman.
• Raporlar hangi düzenleme versiyonu altında üretildiklerini beyan eder ve bu, rapor çıktısıyla birlikte saklanır.

Bu egzotik bir şey değildir. Yarı ciddi herhangi bir muhasebe sisteminin chart-of-accounts değişiklikleri için kullandığı aynı örüntüdür. Emeklilik pipeline'larının bunu yapmamasının nedeni, segmentin başlangıçta reference data olarak ele alınmış olmasıdır ve Türk finans IT'sinde reference data kültürü, açıkça söylemek gerekirse, berbat durumdadır. Excel sheet'ler e-posta ile gönderilir. DBA'ler tek seferlik UPDATE'ler çalıştırır. Bir denetçi soruncaya kadar kimse hiçbir şeyi versiyonlamaz.

Bunun Gerçek Maliyeti

Maliyet, felaket boyutlarına ulaşana kadar görünmez. Gördüğüm ya da çözmek için çağrıldığım şeylerden bazı somut örnekler:

• İki segmentin bir sistemde sessizce birleştirildiği ve diğerinde birleştirilmediği için on sekiz ay boyunca yaklaşık %3 sapmalı olan iç AUM raporlaması ile düzenleyicinin toplam rakamları arasındaki bir mutabakat.
• Dört yıl öncesine ait belirli bir tarih itibarıyla yaklaşık 200.000 poliçe için segment sınıflandırmasının yeniden inşa edilmesini gerektiren bir audit bulgusu. Yeniden inşa, üç kişilik bir ekibin yaklaşık altı haftasını aldı ve nihai cevap "mevcut en iyi yeniden inşa" ifadesiyle savunuldu — bu, denetçi dilinde "uydurduk" demektir.
• Mapping çeyrek ortasında yamanmış ve finans küpü point-in-time değil mevcut mapping'ten yeniden inşa edilmiş olduğu için iki tam çeyrek boyunca komisyon giderini segmentler arasında yanlış tahsis eden bir ürün karlılık analizi.

Bunların hiçbiri pipeline hatası olarak görünmez. Hiçbir şey error fırlatmaz. Rakamlar sessizce gerçeklikten sapar ve saptıkları gerçekliğin kendisi de hareket halindedir çünkü düzenleyici terimleri sürekli yeniden tanımlamaya devam eder.

Rahatsız Edici Kısım

Bir BES pipeline'ına sahipseniz ve bunu henüz yapmadıysanız, rastgele seçilmiş bir 2012 poliçesinin herhangi bir tarihsel raporlama tarihinde hangi segmente ait olduğunu yüzünüz kızarmadan neredeyse kesinlikle cevaplayamazsınız. Bir rakam üretebilirsiniz. Onu savunamazsınız.

Çözüm teknik olarak zor değildir. Politik olarak zordur, çünkü herkesin önemsiz olarak muamele ettiği bir katmanın yıllardır sessizce yanlış olduğunu ve üzerine inşa edilen tarihsel raporların en iyi ihtimalle o hafta canlı olan mapping altında üretilmiş yaklaşık değerler olduğunu kabul etmeyi gerektirir.

Regulation version tablosuyla başlayın. Mevcut her raporu, git history'sinden ve eski Jira ticket'larından yeniden inşa etmek zorunda kalsanız bile, üretildiği mapping versiyonuna geriye dönük olarak ekleyin. Sonra, yeni işler için, segmenti bir boyut olarak ele almayı bırakın. Zaten hiç öyle olmadı.