SEDDK bir değişiklik taslağı yayımlar. 48 saat içinde, CFO ofisinden biri bir etki tahmini ister: kaç katılımcı etkilenecek, kaç sözleşme yeniden hesaplanacak, kaç aşağı akış raporu değişecek, uygulama ne kadar sürecek ve — herkesin hakkında yalan söylediği o soru — mevcut pipeline bunu absorbe edebilir mi yoksa yeniden mi inşa edilmesi gerekir.
Her emeklilik şirketi bir sayı üretir. Bu sayıların neredeyse hiçbiri, üç ay sonra gerçek değişiklik talebiyle karşılaştığında ayakta kalmaz. Bu döngünün yıllarca GEV, HAYMER ve devlet katkısı akışlarında tekrarlandığını izledim. Örüntü değişmiyor.
Tahmin Pipeline'dan Değil, Hafızadan Üretiliyor
Bir kural değişikliği geldiğinde, etki analizine atanan analist pipeline'ı okumaz. Okuyamaz. Pipeline 40+ stored procedure, birkaç SSIS paketi, birinin 2019'da yazdığı üç Python job'u ve yalnızca iki kişinin anladığı — biri geçen yıl ayrılmış olan — bir mutabakat katmanından oluşur.
Böylece analist, insani olarak makul olanı yapar: ekibe sorar. "Eğer SEDDK devlet katkısı hak kazanma penceresini 10 yıldan 7 yıla indirirse, ne bozulur?" Ekip, son 18 ayda dokunduklarını hatırlayarak cevap verir. Bu cevap her zaman eksiktir çünkü:
- Hak kazanma kontrolü en az üç yerde tekrarlanmıştır (günlük hesaplama job'u, aylık raporlama extract'i ve yıllık hak yeniden hesaplaması).
- Bu yerlerden biri, hiçbir zaman parametreleştirilmemiş sabit kodlanmış bir eşik kullanır.
- Aşağı akıştaki HAYMER gönderiminin, yeni kuralın kabul ettiği kayıtları sessizce reddedecek kendi doğrulaması vardır.
- Aktüerya ekibinin kullandığı bir rapor, eski pencereyi varsayan türetilmiş bir bayrak üzerinden join yapar.
Bunların hiçbiri bir dokümanda yoktur. Pipeline'da yaşar. Ve kimse tahmini yazmadan önce pipeline'ı okumaz.
Bu Neden Sürekli Oluyor
Üç yapısal sebep, hiçbiri daha fazla analist işe alarak çözülemez:
1. Pipeline'lar bir domain modeli etrafında değil, mevzuat etrafında artımlı olarak inşa edildi. Son 15 yıldaki her SEDDK genelgesi bir dal, bir bayrak, bir özel durum ekledi. Tek bir "hak kazanma kuralı" yok — her biri belirli bir genelge için yazılmış, örtüşen hak kazanma kurallarının on yedi uygulaması var. Yeni bir genelge geldiğinde, on yedisini de izlemeden etkisini kapsamlandıramazsınız.
2. Veri soy ağacı (lineage) araçları iş mantığını yakalamaz. Bir sütunun A tablosundan B tablosuna, oradan C raporuna aktığını gösteren bir soy ağacı diyagramı üretebilirsiniz. Bu, ortadaki hesaplama mantığının eski kuralı varsayıp varsaymadığı hakkında size hiçbir şey söylemez. Sütun düzeyinde soy ağacı gereklidir ve köklü biçimde yetersizdir.
3. Doğru kapsamlandırabilecek insanlar, mevcut sprint'i teslim eden aynı insanlardır. HAYMER pipeline'ını gerçekten bilen kıdemli mühendis, her taslak genelge çıktığında iki haftalık bir keşif çalışması için müsait değildir. Böylece tahmin, kim boşsa ona devredilir — bu da en az bilenin yapması demektir.
Yanlış Tahminin Gerçek Maliyeti
Maliyet tahminin kendisi değildir. Maliyet, tahminin üzerine yapılan taahhütlerdir.
- Hukuk, tahmine dayalı bir müşteri iletişim takvimini onaylar.
- IT, altı sprint'e dönüşen iki sprint'lik bir çabayı bütçeler.
- Yönetim kuruluna değişikliğin "düşük etkili" olduğu söylenir — oysa aslında devlet katkısı mutabakatına dokunur, bu da etkilenen her katılımcının düzeltilmiş bir hak mektubuna ihtiyacı olduğu anlamına gelir.
- Operasyon, uyum son tarihinden üç hafta önce batch penceresinin yeni yeniden hesaplama yükünü kaldıramayacağını keşfeder.
Dört aylık bir projeye dönüşen bir "küçük parametre değişikliği" gördüm — çünkü tahmin, parametrenin yalnızca üç ayda bir yenilenen bir snapshot tablosuna karşı çalışan eski bir aktüerya job'u tarafından tüketildiğini yüzeye çıkaramamıştı.
Gerçekten Ne İşe Yarar
Dokümantasyon değil. Dokümantasyon, pipeline'ın değiştiğinden daha hızlı çürür. Yardımcı olan şey daha dar ve daha sıkıcıdır:
-
Açıklayıcı değil, çalıştırılabilir bir kural envanteri. Her iş kuralı — hak kazanma pencereleri, katkı üst limitleri, hakediş eşikleri — pipeline'ın çağırdığı adlandırılmış bir fonksiyon veya view olarak var olmalıdır. Kural tek bir yerde tanımlanmış ve her yerden referans veriliyorsa, etki analizi bir grep işlemine dönüşür. 17 stored procedure içine gömülüyse, hiçbir analiz asla doğru olmayacaktır.
-
Mevzuat senaryolarına bağlı regresyon fixture'ları. Her tarihsel genelge için bir fixture tutun: girdi verisi, beklenen çıktı. Yeni bir genelge geldiğinde, en azından fixture'ları önerilen bir değişikliğe karşı çalıştırıp neyin hareket ettiğini görebilirsiniz. Bu size tahmini vermez ama düşünmediğinizi söyler.
-
Sürekli bir "pipeline arkeolojisi" bütçesi. Ayda iki mühendis-günü, şu anda kimsenin sahiplenmediği bir pipeline bölümünü okumaya ve haritalamaya ayrılır. Bir yıl içinde bu gerçek bir harita üretir. Bu olmadan harita her zaman kodu en son değiştirenin kafasındakidir.
-
Etki tahminini kabul kriterleri olan bir teslim edilebilir olarak ele almak. "İşte bir sayı" değil, "işte incelenen pipeline bileşenleri, işte ertelenenler, işte güven aralığı." Bu, tahmin yapan kişiyi bakmadığı şeyi kabul etmeye zorlar.
Tahminin Dürüst Versiyonu
Her emeklilik şirketinin danışma dönemlerinde SEDDK veya EGM'ye geri göndermesi gereken tahmin şudur: "Bilmiyoruz, çünkü pipeline'larımız sizin önceki kurallarınızın 15 yılını kodluyor ve verdiğiniz danışma penceresinde bunları tam olarak izleyemiyoruz." Kimse bunu göndermez. Herkes bir sayı gönderir. Ve sonra, üç ay sonra, herkes aynı şeye şaşırır.
Pipeline'lar kendilerini belgelemeyecek. Kural envanteri çalıştırılabilir hale gelene ve arkeoloji finanse edilene kadar, etki tahmini şu anda olduğu şey olarak kalacak: bir plan kılığına sokulmuş eğitimli bir tahmin.