Bir acentenin raporlarında aynı sigorta şirketinin üç farklı isimle göründüğü durumlar sanıldığından daha yaygındır. Bir kullanıcı şirketin kısa adını, bir diğeri tam unvanını, toplu aktarımla gelen kayıtlar ise şirket kodunu kullanmıştır. Sonuç olarak şirket bazlı üretim raporu üç satıra bölünür ve hiçbiri gerçeği yansıtmaz. Bu tür sorunların kaynağı işlem verisi değil, ana veridir. Bu yazıda ana veri kavramını, acentelerde hangi listelerin ana veri sayılması gerektiğini ve bu listelerin nasıl yönetileceğini ele alıyoruz.
İşlem verisi ile ana veri arasındaki fark
İşlem verisi her gün yeniden oluşur: yeni bir teklif, düzenlenen bir poliçe, alınan bir tahsilat. Ana veri ise bu işlemlerin üzerine kurulduğu, görece sabit referans listeleridir. Bir poliçe kaydı oluşturulurken seçilen sigorta şirketi, branş, ürün, şube ve temsilci ana veridir. İşlem verisindeki bir hata tek bir kaydı etkiler; ana verideki bir hata ise o listeye bağlı binlerce kaydın raporlanma biçimini bozar.
Acentelerde ana veri sayılması gereken listeler
- Sigorta şirketleri: Çalışılan şirketlerin tek ve resmi isim listesi, varsa kısa ad ve kod eşleşmeleriyle birlikte.
- Branşlar: Trafik, kasko, DASK, konut, sağlık gibi ana branşların sabit listesi.
- Ürünler: Her branşın altındaki şirket ürünleri ya da paket türleri.
- Organizasyon yapısı: Şubeler, ekipler ve temsilciler.
- Durum kodları: Teklif, poliçe ve tahsilat durumlarının sabit seçenekleri.
- Coğrafi referanslar: İl, ilçe ve DASK süreçlerinde kullanılan adres kodlama yapısı.
Branş listesi neden özellikle önemli?
Branş, acente raporlarının neredeyse tamamında birincil kırılımdır. Trafik, kasko ve DASK süreçleri farklı sorgu akışlarına, farklı bilgi ihtiyaçlarına ve farklı yenileme davranışlarına sahiptir. Trafik sorgusu araç ve sürücü bilgisine, kasko sorgusu araç değeri ve teminat tercihlerine, DASK sorgusu ise konutun adres kodu, yapı tarzı ve metrekaresine dayanır. Bu akışların ayrı tutulması kadar, raporlarda da aynı branş adının tutarlı kullanılması gerekir. "Kasko", "Oto Kasko" ve "Kasko Paket" gibi varyasyonlar serbest metinle girildiğinde branş bazlı analiz anlamını yitirir. Bu yüzden branşlar kullanıcının yazdığı değil, sabit bir listeden seçtiği değerler olmalıdır.
Ana veri yönetimi için beş ilke
1. Tek kaynak
Her ana veri listesinin yalnızca bir yerde tanımlanması gerekir. Excel dosyalarında, yazılım ayarlarında ve e-posta şablonlarında ayrı ayrı tutulan şirket listeleri zamanla birbirinden uzaklaşır.
2. Serbest metin yerine seçim
Ana veriye karşılık gelen alanlar açılır listeden ya da arama destekli seçim kutusundan doldurulmalıdır. Serbest metin, yazım farklılıklarının en büyük kaynağıdır.
3. Silme yerine pasifleştirme
Çalışmayı bıraktığınız bir sigorta şirketini ya da ayrılan bir temsilciyi listeden silmek, geçmiş kayıtları sahipsiz bırakır. Pasif işaretlemek, yeni kayıtlarda seçilmesini engellerken geçmiş raporların bütünlüğünü korur.
4. Kod ve isim ayrımı
Şirket isimleri unvan değişikliği, birleşme ya da marka yenilemesi nedeniyle değişebilir. Kayıtların arkasında değişmeyen bir iç kod tutulursa, isim güncellemesi tek bir yerde yapılır ve tüm geçmiş kayıtlara otomatik yansır.
5. Değişiklik yetkisi
Ana veri listelerini değiştirme yetkisi sınırlı sayıda kullanıcıda olmalıdır. Her kullanıcının yeni bir branş ya da şirket ekleyebildiği bir yapıda liste kısa sürede şişer.
Dış kaynaklarla eşleştirme tablosu
Sigorta şirketlerinden gelen dökümler, poliçe aktarımları ve entegrasyon yanıtları kendi kodlarını kullanır. Bir şirket bir ürünü kendi sisteminde bir kodla, başka bir şirket benzer ürünü başka bir adla tanımlayabilir. Bu farkları her aktarımda elle düzeltmek yerine bir eşleştirme tablosu tutmak gerekir. Tablo, dış sistemdeki kodu acentenin kendi ana veri listesindeki karşılığına bağlar. Yeni bir kod geldiğinde eşleşme bulunamazsa kayıt "eşleşmeyen" olarak işaretlenir ve veri sorumlusunun önüne düşer. Böylece bilinmeyen değerler sessizce sisteme karışmaz.
Çoklu şirketle çalışan acenteler için bu tablo özellikle değerlidir; çünkü teklif programı üzerinden gelen yanıtların aynı branş ve ürün kırılımında raporlanabilmesi bu eşleşmeye dayanır.
Mevcut karmaşayı toparlamak
Ana veri sorunu zaten oluşmuşsa toparlama çalışması şu sırayla yürütülebilir:
- İlgili alandaki tüm farklı değerleri ve her birinin kaç kayıtta kullanıldığını listeleyin.
- Aynı varlığa karşılık gelen değerleri gruplayın ve her grup için esas değeri seçin.
- Esas değerleri yeni sabit listeye taşıyın, iç kodlarını atayın.
- Eski kayıtları esas değerlere toplu olarak güncelleyin; güncelleme öncesi bir yedek alın.
- Alanı serbest metinden seçim kutusuna çevirin ki sorun tekrar etmesin.
- Bir ay sonra yeni varyasyon oluşup oluşmadığını kontrol edin.
Ana verinin rapor güvenilirliğine etkisi
Yönetici panellerinde görülen şirket bazlı üretim, branş bazlı yenileme oranı ya da şube karşılaştırmaları, işlem verisinin ana veri listeleriyle gruplanmasıyla oluşur. Ana veri dağınıksa bu grafikler teknik olarak doğru hesaplansa bile yanıltıcı olur. Bu yüzden rapor kalitesiyle ilgili şikâyetlerin ilk incelenmesi gereken yeri çoğu zaman ana veri listeleridir. InsureHub gibi bir acente yazılımı içinde şirket, branş ve kullanıcı tanımlarının merkezi olarak tutulması, bu düzenin kurulmasını kolaylaştırır.
Kullanıcı ve şube listelerinde dikkat edilecekler
Organizasyon verisi de ana veridir ve en sık değişen gruptur. Bir temsilci şube değiştirdiğinde geçmiş poliçelerinin hangi şubeye yazılacağı önceden belirlenmelidir: Kayıt anındaki şube mi, temsilcinin bugünkü şubesi mi? Çoğu analiz için kayıt anındaki şubenin korunması daha doğru sonuç verir; aksi halde bir şubenin geçmiş performansı, ekip değişiklikleriyle geriye dönük olarak değişir. Bu karar ana veri politikasına yazılmalıdır.
Sonuç
Ana veri, raporların görünmeyen iskeletidir. Tek kaynak, sabit seçim, pasifleştirme, kod-isim ayrımı ve sınırlı değişiklik yetkisi ilkeleri uygulandığında şirket, branş ve şube bazlı analizler güvenilir hale gelir. Kendi referans listelerinizin yazılımda nasıl yönetilebileceğini görmek için demo talep sayfasından bilgi alabilirsiniz.