Birden fazla sigorta şirketiyle çalışan acentelerde ay sonu çoğu zaman aynı manzarayla geçer: Her şirketten farklı sütun adlarına, farklı tarih biçimlerine ve farklı kodlamalara sahip dökümler gelir. Bu dosyalar elle düzenlenir, bir tabloda birleştirilir ve acentenin kendi kayıtlarıyla karşılaştırılır. Süreç her ay baştan tekrarlanır ve her tekrar yeni hata fırsatları doğurur. Veri dünyasında bu işin adı ETL'dir: çıkarma (extract), dönüştürme (transform) ve yükleme (load). Bu yazıda ETL mantığını acente dökümleri özelinde, uygulanabilir adımlarla ele alıyoruz.
ETL neden bir süreç olarak düşünülmeli?
Dökümleri düzenlemek tek seferlik bir dosya işi gibi görünür. Oysa her ay aynı dönüşümler tekrarlanıyorsa, bu dönüşümlerin yazılı ve tekrarlanabilir bir sürece bağlanması gerekir. Süreç haline gelmeyen düzenleme işi, onu yapan kişiye bağımlı kalır; o kişi izinliyken rapor gecikir, yeni biri yaptığında ise sonuçlar farklılaşır.
1. Çıkarma: Kaynakları tanımlamak
İlk adım, hangi verinin nereden ve hangi sıklıkla geldiğini listelemektir. Her kaynak için şu bilgiler kayıt altına alınmalıdır:
- Kaynağın adı ve hangi şirkete ya da sisteme ait olduğu
- Dosya biçimi ve alınma yöntemi
- Kapsadığı dönem ve ne zaman hazır olduğu
- İçerdiği ana alanlar: poliçe numarası, branş, prim, komisyon, tarih
- Bilinen özellikler: örneğin iptallerin negatif tutar olarak mı, ayrı satırda mı gösterildiği
Bu liste bir kez hazırlandığında, yeni katılan bir çalışan bile hangi dosyanın nereden geleceğini ve neye dikkat edileceğini bilir. Ham dosyaların hiçbir değişiklik yapılmadan ayrı bir klasörde saklanması da önemlidir; dönüşümde bir hata fark edildiğinde orijinal veriye geri dönebilmek gerekir.
2. Dönüştürme: Ortak biçime getirmek
Dönüştürme, ETL'in en emek isteyen ve en çok değer üreten aşamasıdır. Burada farklı kaynaklardan gelen veri, acentenin kendi ortak biçimine çevrilir.
Sütun eşleştirme
Her kaynaktaki sütunların ortak şemadaki karşılığı belirlenir. Bir şirketin "Net Prim" dediği alan ile diğerinin "Prim Tutarı" dediği alanın aynı anlamı taşıyıp taşımadığı kontrol edilmelidir; bazen isim benzer olsa da vergi dahil ya da hariç olma farkı bulunur.
Biçim standardizasyonu
Tarihler tek bir biçime, para tutarları tek bir ondalık düzenine, poliçe numaraları ise baştaki sıfırlar ve boşluklar temizlenmiş tek bir yazıma getirilir. Bu küçük farklar, eşleştirme aşamasında kayıtların bulunamamasının en yaygın nedenidir.
Kod eşleştirme
Şirketlerin branş ve ürün kodları acentenin ana veri listesine bağlanır. Trafik, kasko ve DASK gibi branşlar ayrı süreçler olarak yönetildiğinden, dökümdeki her satırın doğru branşa atanması branş bazlı komisyon ve üretim analizinin temelidir. Eşleşmeyen kodlar ayrı bir listeye düşürülmeli, sessizce "diğer" kategorisine atılmamalıdır.
Kalite kontrolleri
Dönüşüm sırasında basit ama etkili kontroller yapılmalıdır:
- Dosyadaki satır sayısı ile dönüşüm sonrası satır sayısı aynı mı?
- Toplam prim ve komisyon tutarları dönüşüm öncesi ve sonrası eşit mi?
- Zorunlu alanlarda boş değer var mı?
- Aynı poliçe numarası aynı dönemde birden fazla kez görünüyor mu?
Bu kontrollerden biri başarısız olursa yükleme durdurulmalı ve neden incelenmelidir.
3. Yükleme: Hedefe aktarmak
Dönüştürülmüş veri, raporlamanın yapılacağı hedefe aktarılır. Bu hedef bir raporlama tablosu, bir veri ambarı ya da acente yazılımındaki bir içe aktarma ekranı olabilir. Yüklemede iki temel karar vardır:
- Tam yükleme mi, artımlı yükleme mi? Her ay tüm dönemi yeniden yüklemek basittir ama veri büyüdükçe yavaşlar. Yalnızca yeni ve değişen kayıtları yüklemek daha verimlidir ancak değişikliklerin doğru tespit edilmesini gerektirir.
- Tekrar çalıştırılabilirlik. Aynı dosya yanlışlıkla iki kez yüklendiğinde kayıtlar çiftlenmemelidir. Her yüklemeye bir parti numarası verilmesi ve aynı dönemin aynı kaynağı için önceki partinin geri alınabilmesi bu riski ortadan kaldırır.
Mutabakat: ETL'in asıl çıktısı
Dökümler hazırlandıktan sonra en değerli adım, acentenin kendi poliçe kayıtlarıyla karşılaştırmadır. Bu karşılaştırma üç grup üretir: her iki tarafta bulunan ve tutarları uyuşan kayıtlar, her iki tarafta bulunan ama tutarları farklı olan kayıtlar ve yalnızca bir tarafta bulunan kayıtlar. İkinci ve üçüncü grup, operasyon ekibinin inceleme listesidir. Bu liste görev olarak atanıp takip edildiğinde, farklar bir sonraki aya kontrolsüz taşınmaz.
Elle mi, otomatik mi?
ETL süreci başlangıçta bir tablo programındaki yazılı adımlarla bile yürütülebilir. Önemli olan adımların belgelenmiş ve her ay aynı şekilde uygulanıyor olmasıdır. Kaynak sayısı ve hacim arttıkça bu adımların betiklerle ya da entegrasyonlarla otomatikleştirilmesi doğal bir sonraki basamaktır. Sigorta şirketleriyle doğrudan veri alışverişi yapılabilen akışlarda, poliçe bilgisinin elle aktarım yerine teklif programı ve entegrasyon katmanı üzerinden kayda geçmesi dönüştürme yükünü belirgin biçimde azaltır.
ETL kurgusunda karşılaşılan tuzaklar
- Ham dosyayı düzenleyip üzerine kaydetmek ve orijinali kaybetmek.
- Toplam kontrolü yapmadan yüklemek.
- Eşleşmeyen kodları elle tahmin ederek atamak.
- Dönüşüm kurallarını yalnızca bir kişinin hafızasında tutmak.
Süreci belgelemek
Her kaynak için tek sayfalık bir dönüşüm notu tutmak, ETL'in kişiden bağımsız yürümesini sağlar. Notta sütun eşleşmeleri, özel durumlar, kontrol adımları ve son güncelleme tarihi yer almalıdır. Bir şirket döküm biçimini değiştirdiğinde yalnızca ilgili not güncellenir ve süreç kesintisiz devam eder.
Sonuç
ETL, ay sonu dosya düzenleme işini tekrarlanabilir ve denetlenebilir bir sürece dönüştürür. Kaynakları tanımlamak, ortak biçime çevirmek, kontrollü yüklemek ve mutabakatı görev olarak takip etmek, şirket bazlı raporların güvenilirliğini belirler. Poliçe kayıtlarınızın bu sürece nasıl kaynak olabileceğini görmek için sigorta acentesi yazılımı sayfasını inceleyebilir ya da demo talep edebilirsiniz.