Veri yönetişimi kulağa büyük şirketlere özgü bir kavram gibi gelir: komiteler, uzun politikalar, imza döngüleri. Oysa beş kişilik bir acentede de aynı soru vardır: Bir müşterinin iletişim bilgisi yanlışsa bunu kim düzeltir, kim onaylar, kim fark etmekten sorumludur? Bu soruların cevabı yazılı değilse, cevap genellikle "herkes" olur ki bu da pratikte "hiç kimse" anlamına gelir. Bu yazıda acente ölçeğine uygun, hafif ama işleyen bir veri yönetişimi modelini adım adım tarif ediyoruz.
Yönetişim, güvenlikten ve kaliteden ne kadar farklı?
Bu üç kavram sık karıştırılır. Veri güvenliği verinin yetkisiz erişime karşı korunmasıyla, veri kalitesi verinin doğru ve kullanılabilir olmasıyla ilgilenir. Yönetişim ise bu ikisinin üstünde durur: hangi verinin kime ait olduğunu, hangi kuralların geçerli olduğunu ve anlaşmazlık çıktığında kimin karar vereceğini belirler. Yönetişim olmadan kalite çalışmaları sahipsiz kalır, güvenlik kuralları da gerekçesiz görünür.
Üç temel rol
Veri sahibi
Bir veri alanının iş açısından hesabını veren kişidir. Örneğin müşteri verisinin sahibi satış ve müşteri ilişkileri sorumlusu, tahsilat verisinin sahibi ise muhasebe ya da finans sorumlusu olabilir. Sahip, o verinin ne amaçla tutulduğuna, kimlerin görebileceğine ve hangi kalite seviyesinin kabul edilebilir olduğuna karar verir.
Veri sorumlusu (steward)
Günlük düzeyde veriye bakan kişidir. Hatalı kayıtları fark eder, düzeltme taleplerini toplar, kuralların uygulanıp uygulanmadığını izler. Küçük acentelerde sahip ve sorumlu aynı kişi olabilir; önemli olan rolün açıkça tanımlanmasıdır.
Veri kullanıcısı
Kaydı oluşturan, güncelleyen ya da rapor için okuyan herkesdir. Kullanıcının görevi kurallara uymak ve gördüğü sorunu bildirmektir; kendi başına toplu değişiklik yapmak değil.
Sorumluluk matrisi hazırlamak
Rolleri veri alanlarıyla eşleştirmenin en pratik yolu basit bir matristir. Satırlara veri alanlarını, sütunlara rolleri yazın ve her kesişime bir harf koyun: karar verir, uygular, bilgilendirilir. Örnek veri alanları şunlar olabilir:
- Müşteri kimlik ve iletişim bilgileri
- Teklif kayıtları ve teklif sonuçları
- Poliçe kayıtları ve yenileme tarihleri
- Tahsilat ve komisyon hareketleri
- Sigorta şirketi, branş ve ürün tanımları
- Kullanıcı hesapları ve yetki tanımları
Bu matris tek sayfayı geçmemelidir. Amacı bürokrasi üretmek değil, "bunu kime soracağım?" sorusunu saniyeler içinde cevaplamaktır.
Karar kuralları: Yazılı olmayan alışkanlıkları görünür kılmak
Her acentenin yazılı olmayan veri alışkanlıkları vardır. Bir müşteri vefat ettiğinde kaydı silinir mi, pasife mi alınır? İptal edilen poliçe kaydı nasıl işaretlenir? Aynı kişinin iki kaydı bulunduğunda hangisi esas alınır? Bu soruların her biri bir karar kuralına dönüştürülmelidir. Kuralları yazarken şu üç bilgiyi mutlaka ekleyin:
- Durum: Kuralın hangi durumda uygulanacağı.
- Eylem: Ne yapılacağı ve ne yapılmayacağı.
- Yetki: Eylemi kimin gerçekleştirebileceği.
Örneğin: "Mükerrer müşteri kaydı tespit edildiğinde birleştirme yalnızca veri sorumlusu tarafından yapılır; birleştirmede en güncel teyit tarihine sahip iletişim bilgisi esas alınır; işlem kayıt geçmişine not düşülür." Bu tek cümle, gelecekte yaşanacak onlarca tartışmanın önünü keser.
Yönetişimi yazılım ayarlarına yansıtmak
Kağıt üzerindeki kurallar, yazılımda karşılık bulmadığında zamanla unutulur. Rol bazlı yetkiler, belirli alanların yalnızca belirli kullanıcılarca düzenlenebilmesi ve değişikliklerin işlem kayıtlarında izlenebilmesi yönetişimin teknik ayağıdır. Bir sigorta acentesi yazılımı seçerken ya da mevcut sistemi yapılandırırken matristeki her "karar verir" hücresinin bir yetki ayarına karşılık gelip gelmediğini kontrol etmek faydalıdır. InsureHub'ın alt kullanıcı ve modül yetkisi yapısı bu eşleştirmeyi yapmak için bir zemin sunar.
Gözden geçirme ritmi
Yönetişim modeli bir kez kurulup bırakılırsa, ekip değiştikçe geçerliliğini yitirir. Üç ayda bir yapılacak kısa bir gözden geçirme yeterlidir:
- Rollerde değişiklik oldu mu, ayrılan ya da yeni gelen biri var mı?
- Son dönemde hangi veri sorunları tekrarladı ve hangi kurala bağlıydı?
- Yeni bir veri alanı, branş ya da entegrasyon eklendi mi?
- Yetki tanımları matrisle hâlâ uyumlu mu?
Küçük başlamanın avantajı
İlk denemede tüm veri alanlarını kapsamaya çalışmak yerine, en çok sorun çıkaran iki alanla başlamak daha gerçekçidir. Çoğu acente için bunlar müşteri iletişim bilgileri ve poliçe yenileme tarihleridir. Bu iki alanda sahiplik ve kurallar oturduktan sonra model kademeli olarak genişletilebilir. Müşteri kayıtlarının nasıl yapılandırılabileceğine dair fikir almak için acente CRM sayfasını inceleyebilirsiniz.
Örnek bir yönetişim olayı
Modelin nasıl çalıştığını somut bir durum üzerinden düşünelim. Bir şube çalışanı, yenileme listesinde aynı müşterinin iki kez göründüğünü fark ediyor. Yönetişim modeli yoksa çalışan kayıtlardan birini kendi kararıyla siler; silinen kayıtta bağlı bir kasko teklifi ve iletişim notları varsa bu geçmiş kaybolur. Model varsa akış farklıdır: Çalışan durumu veri sorumlusuna bildirir, sorumlu iki kaydı karşılaştırır, karar kuralına göre esas kaydı seçer, bağlı teklif ve poliçeleri bu kayda taşır ve işlemi kayıt geçmişine not eder. Aynı sorun tekrar ederse veri sahibi, giriş ekranında mükerrer kontrolün sıkılaştırılmasına karar verir. Böylece tek bir olay hem çözülür hem de bir sonraki benzer olayın önüne geçen bir iyileştirmeye dönüşür.
Dış kaynaklı veriler için ayrı kurallar
Acentelerde verinin önemli bir kısmı sigorta şirketlerinden, resmi sorgulardan ya da toplu aktarımlardan gelir. Bu verilerin sahipliği farklı ele alınmalıdır: Kaynakta düzeltilmesi gereken bir hata acente tarafında elle değiştirilirse, bir sonraki aktarımda değer eski haline dönebilir. Bu nedenle dış kaynaklı alanlar için "düzeltme kaynakta mı, sistemde mi yapılır?" sorusunun cevabı da matrise eklenmelidir.
Sonuç
Veri yönetişimi, kimin neyin sahibi olduğunu ve anlaşmazlıkta nasıl karar verileceğini belirleyen sade bir anlaşmadır. Acente ölçeğinde bir sayfalık matris, birkaç karar kuralı ve düzenli bir gözden geçirme ile başlayabilir. Bu düzeni yazılım ayarlarınıza nasıl yansıtabileceğinizi görmek için demo talebi oluşturabilirsiniz.