Birkaç yılda bir, bir Türk emeklilik şirketi çekirdek BES platformunun gitmesi gerektiğine karar verir. Tedarikçi cevap vermiyordur, mimari 2008'den kalmadır, aktüeryal motor düzenleyici raporlama döngülerine ayak uyduramıyordur ve icra komitesindeki birileri sonunda bütçeyi imzalamıştır. Bir program başlar. Bir sistem entegratörü seçilir. Bir cutover tarihi bir slayta düşer.
Ve sonra, on sekiz ay sonra, aynı slayt bir çeyrek daha ötelenir. Sonra bir tane daha. Bunu birden çok kez izledim ve ekiplerin gerçekten mükemmel mühendislik işleri yapmasına rağmen göçün kaymaya devam ettiğini gördüm. Sebep neredeyse hiçbir zaman teknoloji değildir. Sebep, liderliğin göçü sanki bir çekirdek bankacılık değişimi ya da bir poliçe yönetim sistemi değişimiymiş gibi ele almasıdır — oysa hiçbiri değildir.
Bir BES çekirdek platform göçü, BT projesi kostümü giymiş bir yasal süreklilik sorunudur.
Neden Alışılmış Cutover Oyun Kitabı Geçerli Değil
Çoğu kurumsal göçte üç uygulanabilir strateji vardır: big-bang cutover, ürün veya bölge bazlı aşamalı geçiş veya modül modül strangler-pattern değişimi. Üçü de belirli bir anda belirli bir işlem için tek bir yetkili kayıt sisteminin var olduğunu varsayar.
BES size bu lüksü tanımaz. Herhangi bir takvim gününde, her katılımcı için, aynı anda şunları yapabilmelisiniz:
- EGM'ye (Emeklilik Gözetim Merkezi) doğru bir katılımcı bakiyesi raporlamak
- Savunulabilir bir hesaplama izi ile doğru devlet katkısını talep etmek
- Bir çekim, aktarım-çıkış veya fon değişim talebini düzenleyici SLA'lar içinde yerine getirmek
- Önceki yıllarla kuruşuna kadar mutabık yıllık katılımcı ekstreleri üretmek
- Son on yıldaki herhangi bir işlemi örnekleyen bir SPK veya Hazine denetimini geçmek
Big-bang cutover, tüm bunların ilk günden itibaren yeni sistemde çalışması gerektiği anlamına gelir — yeni sistemin hiç uygulamadığı iş akışları tarafından yazılmış veriler dahil. Ürün hattına göre aşamalı geçiş, iki sistemin aynı sponsorun farklı katılımcıları için eş zamanlı olarak yasal kaynak olması demektir — bu, bir sponsor konsolide rapor talep edene veya iki sözleşmesi olan bir katılımcı bunlar arasında aktarım yapana kadar sorun değildir. Bir strangler pattern, aktüeryal motorun yarısı eski deftere, yarısı yeniye yazılmış veriler üzerinde hesaplama yapması demektir.
Bunların hiçbiri imkansız değildir. Sadece on iki ay önceden duyurulan sabit bir tarihte bitirdiğiniz projeler değildirler.
Göçler Aslında Nerede Başarısız Olur
Geleneksel bilgelik, işlerin cutover haftasonunda bozulduğu yönündedir. BES göçlerinde cutover haftasonu genellikle iyi geçer. Ekip aylardır prova yapıyordur, runbook eksiksizdir, savaş odası kadroludur. Bozulan şey, öncesindeki altı aylık paralel çalışma dönemidir ve başarısızlık, düzeltmek için çok geç olana kadar neredeyse her zaman görünmezdir.
Pratikte paralel çalışma sapması şöyle görünür:
- Eski sistem devlet katkısı tahakkuklarını fon düzeyinde, günlük olarak yuvarlar. Yeni sistem katılımcı düzeyinde, aylık yuvarlar. Her ikisi de savunulabilir. Altı ay ve iki milyon katılımcı üzerinde, toplam fark düşük milyonlarca TL'dir. Kimse fark etmemiştir çünkü kimse bu granülerlikte fark alımı yapmıyordur.
- Bir katılımcı Cuma öğleden sonra eski sistemde bir fon değişimi gerçekleştirir. Yeni sisteme gecelik replikasyon, değişim mutabakata varmadan çalışır. Yeni sistem katılımcıyı eski dağılımda görüyordur. Pazartesi, katılımcı çağrı merkezini arar — ki artık yeni sistemden okuma yapıyordur — ve değişiminin hiç gerçekleşmediği söylenir. Onu tekrar yapar. Şimdi yeni sistemde, eski sistemin hiç görmediği yinelenen bir değişim vardır.
- Eski sistemde on yıllık manuel düzeltmeler serbest metin açıklamalarıyla yevmiye kaydı olarak işlenmiştir. Göç eşleştirmesi belgelenmiş 40 düzeltme tipini işler. Ayrılmış operasyon personeli tarafından girilmiş belgelenmemiş 340 tanesini işlemez.
Bunların her biri tek başına bir yuvarlama hatasıdır. Birlikte, altı ay sonra, iki sistem artık bir katılımcının bakiyesinin ne olduğu konusunda anlaşmıyordur ve hangisinin doğru olduğuna karar vermenin temiz bir yolu yoktur. Programın aslında başarısız olduğu an budur. Cutover sadece bunu resmileştirir.
Sahip Olmadığınız Mutabakat Yolu
Herhangi bir göç program yöneticisine, cutover'dan iki ay sonra yeni sistemin maddi olarak yanlış olduğunun keşfedilmesi durumunda ne olacağını sorun; geri alma planları ve yedek anlık görüntüleri hakkında kendinden emin cevaplar alırsınız. Onlardan, bir katılımcının bu iki aylık pencerede katkı yaptığı, devlet katkısı aldığı, bir fon değişimi gerçekleştirdiği ve kısmi bir çekim yaptığı — tümü yalnızca yeni sistemde kayıtlı — ve şimdi yasal kayıt sistemi olarak eski sisteme geri döndürülmesi gereken spesifik durumu adım adım anlatmalarını isteyin.
Dürüst cevap, temiz bir yolun olmadığıdır. Bir devlet katkısını geri ödeyemezsiniz. Zaten kabul edilmiş bir EGM gönderimini geri alamazsınız. Katılımcıyı tazmin edebilirsiniz, ama göçün hiç olmadığı karşıolgusal dünyayı geri getiremezsiniz.
Bu yüzden paralel çalışma dönemi bir test aşaması değildir. Asıl projenin kendisidir. İki sistem, cutover'dan önce sürekli doksan günlük bir pencere boyunca katılımcı bakiyeleri, devlet katkısı tahakkukları ve EGM'ye raporlanabilir pozisyonlar konusunda bit-bit anlaşmaya varmamışsa, düzenleyici karşısında savunulabilir bir konumunuz yoktur. Bir umudunuz vardır.
Aslında Ne İşe Yarar
Biten programlar ile sonsuza kadar kayan programlar arasındaki farkı yarattığını gördüğüm birkaç şey:
- Paralel çalışmanın ilk gününden itibaren sapmayı bir P1 olayı olarak ele alın. Bir sonraki yönlendirme komitesinde araştırılacak bir varyans değil. On-call rotasyonu ve aynı gün RCA'sı olan bir üretim olayı. Katılımcı düzeyinde mutabık olmayan herhangi bir kuruş bir bug'dır.
- Mühendislerin uygun bulduğu düzeyde değil, düzenleyicilerin önemsediği düzeyde mutabakat yapın. Fon düzeyinde toplamların eşleşmesi yeterli değildir. Katılımcı bazında, işlem bazında, her iki sistemdeki günün pozisyonlarının imzalanmış bir hash'i ile.
- Paralel çalışma sırasında eski sistemin iş mantığını dondurun. Yeni özellik yok, yeni düzeltme tipi yok, belgelenmemiş düzeltme yok. Eski sisteme yapılan her değişiklik, göç kapsamına yapılan bir değişikliktir. Çoğu program burada başarısız olur çünkü iş tarafı bir dondurmayı kabul etmez.
- Paralel çalışma başlamadan önce iç denetim fonksiyonunun mutabakat metodolojisini onaylamasını sağlayın. Sonra değil. Mutabakat yaklaşımınız bir SPK denetimini atlatamayacaksa, o bir mutabakat yaklaşımı değildir.
- Sistem entegratörünün önerdiğinin en az iki katı uzunlukta bir paralel çalışma dönemi için bütçe ayırın. Onlar kendi sözleşmelerini optimize ediyor. Siz on yıllık denetim izini optimize ediyorsunuz.
Bunların hiçbiri gösterişli değildir. Hiçbiri program panosunda iyi görünmez. Ve bunların hepsi, biten bir göç ile CIO'nun ayrılma sebebi olan bir göç arasındaki farktır.
Kimsenin Yapmak İstemediği Yönetici Konuşması
Bir BES çekirdek göçü yönetim kuruluna sunulduğunda, tanımlı bir cutover'lı on sekiz ila yirmi dört aylık bir program olarak sunulur. Gerçekte olan şey: son on iki ayı iki üretim sisteminin yasal olarak bağlayıcı çift operasyonu olan üç yıllık bir programdır ve cutover, aylar önce zaten başarılı olmuş veya başarısız olmuş bir mutabakat döneminin sonundaki bir formalitedir.
Bunu anlayan yönetim kurulları programı doğru finanse eder. Anlamayanlar, üç kez yeniden planlanacak ve geç teslim edilecek bir projeyi finanse eder ve her seferinde teknolojinin neredeyse hazır olduğu söylenir. Teknoloji neredeyse her zaman hazırdır. Yasal süreklilik, kimsenin bir plan yapmadığı şeydir.