Kısaca
Sigorta projelerinde iş analizi; ürün, tarife, hasar ve operasyon ihtiyaçlarını paydaşlardan toplayıp doğrulanabilir gereksinimlere, iş kurallarına ve kabul kriterlerine dönüştürme disiplinidir. Etkili gereksinim yönetimi, uçtan uca izlenebilirlik ve kontrollü bir değişiklik süreciyle projenin kapsam, takvim, maliyet ve kalite risklerini belirgin biçimde azaltır.
İş analizi, bir kurumun ihtiyaçlarını anlayıp bu ihtiyaçları karşılayacak çözümün gereksinimlerini tanımlama, doğrulama ve yönetme disiplini demektir. Sigorta projelerinde iş analisti; aktüerya, ürün, hasar, operasyon, hukuk, muhasebe ve satış kanallarının dilini yazılım ekibinin anlayacağı, test edilebilir gereksinimlere çevirir.
Sigorta yazılım projelerinde yaşanan gecikme ve bütçe aşımlarının önemli bir kısmı teknik sorunlardan değil, eksik veya yanlış anlaşılmış gereksinimlerden kaynaklanır. Bu yazıda sigorta projelerinde iş analizinin kapsamını, gereksinim türlerini, kullanılan teknikleri ve değişikliğin nasıl yönetileceğini ele alıyoruz.
Sigorta projelerinde iş analisti ne yapar?
Sigorta iş analisti, iş birimleri ile yazılım ekibi arasında köprü kurarak ihtiyacı doğru, eksiksiz ve test edilebilir biçimde tanımlar. Görevi yalnızca talep yazmak değil, talebin arkasındaki iş problemini ortaya çıkarmak ve çözüm seçeneklerini değerlendirmektir.
Başlıca sorumluluklar şunlardır:
- Paydaşları belirlemek ve gereksinim toplama oturumlarını yönetmek
- Mevcut süreci (as-is) ve hedef süreci (to-be) modellemek
- Ürün, teminat, tarife ve iş kurallarını yapılandırılmış biçimde belgelemek
- Kullanıcı hikâyelerini ve kabul kriterlerini yazmak
- Test senaryolarının gereksinimlerle uyumunu doğrulamak
- Kapsam değişikliklerinin etkisini analiz etmek
- Kullanıcı kabul testlerini (User Acceptance Test, UAT) koordine etmek
Uluslararası alanda iş analizi pratikleri, International Institute of Business Analysis (IIBA) tarafından yayımlanan BABOK (Business Analysis Body of Knowledge) rehberiyle çerçevelenir. Sigorta projelerinde bu genel çerçeve, sektöre özgü alan bilgisiyle tamamlanmalıdır.
Sigorta projelerinde hangi gereksinim türleri vardır?
Gereksinimler; iş, paydaş, çözüm ve geçiş gereksinimleri olarak katmanlanır. Çözüm gereksinimleri de fonksiyonel ve fonksiyonel olmayan olarak ikiye ayrılır. Bu ayrım, hangi gereksinimin neden var olduğunu ve nasıl doğrulanacağını netleştirir.
| Gereksinim türü | Tanım | Sigorta örneği |
|---|---|---|
| İş gereksinimi | Kurumun ulaşmak istediği hedef | Konut ürününü dijital kanalda satışa açmak |
| Paydaş gereksinimi | Belirli bir grubun ihtiyacı | Acentenin teklifi tek ekranda karşılaştırabilmesi |
| Fonksiyonel gereksinim | Sistemin yapması gereken davranış | Bina inşa yılına göre deprem teminatı fiyatının hesaplanması |
| Fonksiyonel olmayan gereksinim | Performans, güvenlik, erişilebilirlik gibi nitelikler | Teklif hesaplamanın yoğun saatte belirli süre içinde tamamlanması |
| İş kuralı | Sistemden bağımsız geçerli olan politika veya kısıt | Belirli bir yaş üzerindeki sürücüler için ek onay gerekmesi |
| Geçiş gereksinimi | Eski sistemden yeniye geçiş için gereken geçici ihtiyaç | Mevcut poliçelerin yenileme tarihleri korunarak taşınması |
Sigorta projelerinde en sık atlanan tür fonksiyonel olmayan gereksinimlerdir. Denetim izi, yetkilendirme, kişisel veri saklama süreleri ve raporlama performansı proje sonunda fark edildiğinde maliyeti yüksek değişikliklere yol açar.
Sigorta ürünü için gereksinimler nasıl belgelenir?
Sigorta ürünlerinde gereksinimler serbest metin yerine yapılandırılmış tablolar ve kural katalogları halinde belgelenmelidir. Teminatlar, limitler, muafiyetler, tarife faktörleri ve kabul kuralları tablo biçiminde tutulduğunda hem geliştirme hem test hem de ileride yapılacak değişiklikler kolaylaşır.
Ürün tanım dokümanı
Ürün tanım dokümanı, ürünün teminat yapısını, poliçe süresini, prim ödeme seçeneklerini, zeyil türlerini, iptal ve iade kurallarını ve ilgili genel şart ile özel şart referanslarını içerir. Ürün yapısının teknik karşılığı için sigorta ürün modelleme yazısı yol gösterir.
İş kuralı kataloğu
Her iş kuralı benzersiz bir numara, açıklama, kaynak (aktüerya kararı, mevzuat, şirket politikası), geçerlilik tarihi ve sahibiyle kayıt altına alınır. Böylece bir kuralın neden var olduğu ve kimin onayıyla değiştirilebileceği her zaman bilinir.
Karar tabloları
Tarife ve kabul kuralları gibi çok koşullu mantıklar için karar tabloları kullanılır. Her satır bir koşul kombinasyonunu ve sonucunu gösterir. Karar tabloları hem aktüerya ekibinin doğrulaması hem de test senaryosu üretimi için idealdir. Tarife tarafı için sigorta tarife kurgusu yazısına göz atabilirsiniz.
Kullanıcı hikâyesi ve kabul kriterleri nasıl yazılır?
Kullanıcı hikâyesi, bir ihtiyacı "bir kullanıcı olarak, bir amaçla, bir şeyi yapmak istiyorum" kalıbında kısa ve değer odaklı biçimde ifade eder. Kabul kriterleri ise hikâyenin ne zaman tamamlanmış sayılacağını test edilebilir koşullarla tanımlar.
Sigorta bağlamında iyi yazılmış bir hikâye örneği şöyledir: "Bir acente kullanıcısı olarak, kasko teklifinde araç bilgilerini plaka ile otomatik doldurmak istiyorum; böylece veri giriş hatalarını azaltabilirim."
Kabul kriterleri için "Verilen, Olduğunda, O zaman" (Given, When, Then) yapısı yaygın olarak kullanılır:
- Verilen: kullanıcı geçerli bir plaka girmiştir. Olduğunda: sorgu başarılı döner. O zaman: marka, model ve model yılı alanları otomatik dolar ve düzenlenemez.
- Verilen: sorgu servisi yanıt vermemektedir. Olduğunda: zaman aşımı gerçekleşir. O zaman: kullanıcı bilgilendirilir ve alanlar elle girilebilir hale gelir.
Bu yapı, davranış güdümlü geliştirme (Behavior Driven Development, BDD) araçlarıyla doğrudan otomatik teste dönüştürülebilir. Test tarafının kurgusu için sigorta yazılımlarında test otomasyonu yazısı tamamlayıcıdır.
Gereksinim yönetimi adım adım nasıl yürütülür?
Gereksinim yönetimi, gereksinimin toplanmasından üretime alınmasına ve sonrasındaki değişikliklere kadar süren bir yaşam döngüsüdür. Aşağıdaki adımlar sigorta projelerinde uygulanabilir bir akış sunar.
- Paydaş haritası çıkarın. Aktüerya, ürün, hasar, operasyon, hukuk, uyum, muhasebe, satış kanalları ve bilgi teknolojileri temsilcilerini belirleyin.
- Mevcut durumu analiz edin. Süreçleri, ekranları, raporları ve el ile yapılan işleri gözlemleyin; sorun noktalarını kayıt altına alın.
- Gereksinimleri toplayın. Çalıştaylar, birebir görüşmeler, doküman incelemesi ve prototiplerle ihtiyaçları ortaya çıkarın.
- Yapılandırın ve önceliklendirin. Gereksinimleri türlerine ayırın; MoSCoW (Must, Should, Could, Won't) gibi bir yöntemle önceliklendirin.
- Doğrulayın. Gereksinimlerin eksiksiz, tutarlı ve test edilebilir olduğunu paydaşlarla birlikte teyit edin.
- İzlenebilirlik kurun. Her gereksinimi ilgili tasarım, kod değişikliği ve test senaryosuyla ilişkilendirin.
- Değişikliği yönetin. Yeni talepleri etki analiziyle değerlendirip onay sürecinden geçirin.
- Kabulü yönetin. Kullanıcı kabul testlerini planlayın, bulguları sınıflandırın ve kapanışı onaylatın.
İyi bir gereksinim, onu yazan kişi odadan çıktıktan sonra da aynı şekilde anlaşılan gereksinimdir.
İzlenebilirlik ve değişiklik yönetimi neden önemlidir?
İzlenebilirlik, bir gereksinimin hangi iş hedefinden doğduğunu ve hangi kod ile testle karşılandığını gösterir; değişiklik yönetimi ise yeni taleplerin kapsamı kontrolsüz büyütmesini önler. Sigorta projelerinde mevzuat ve tarife değişiklikleri sık olduğu için bu iki disiplin özellikle kritiktir.
İzlenebilirlik matrisi sayesinde şu sorulara hızlı cevap verilir:
- Bir mevzuat değişikliği hangi gereksinimleri, ekranları ve raporları etkiliyor?
- Hangi gereksinimin henüz test senaryosu yok?
- Bir hata hangi iş kuralının yanlış uygulanmasından kaynaklanıyor?
- Denetimde istenen bir kontrolün sistemde nerede karşılandığı gösterilebiliyor mu?
Mevzuat kaynaklı gereksinimlerin ayrı etiketlenmesi, sigorta yazılımında mevzuat uyumu açısından da denetim kolaylığı sağlar. ProdayTech olarak sigorta projelerinde iş kuralı kataloğunu ve izlenebilirlik matrisini proje dokümanı değil, sistemle birlikte yaşayan bir varlık olarak ele alıyor ve her sürümde güncel tutuyoruz.
İş analizi kalitesi için kontrol listesi
- Tüm ilgili paydaşlar belirlendi ve gereksinim oturumlarına katıldı mı?
- İş hedefi ölçülebilir biçimde tanımlandı mı?
- Ürün, teminat ve tarife kuralları yapılandırılmış tablolarla belgelendi mi?
- Her iş kuralının kaynağı, sahibi ve geçerlilik tarihi var mı?
- Fonksiyonel olmayan gereksinimler (performans, güvenlik, KVKK, denetim izi) yazıldı mı?
- Her kullanıcı hikâyesinin test edilebilir kabul kriterleri var mı?
- Gereksinimler test senaryolarıyla ilişkilendirildi mi?
- Değişiklik talepleri etki analizi ve onay sürecinden geçiyor mu?
Proje yönetimi yaklaşımının tamamı için sigorta yazılım projeleri nasıl yönetilir yazısına göz atabilirsiniz.
Sık sorulan sorular
Sigorta iş analistinin sigorta bilgisi olması şart mı?
Temel iş analizi yöntemleri her sektörde geçerlidir, ancak sigorta projelerinde alan bilgisi büyük fark yaratır. Teminat, muafiyet, zeyil, muallak hasar, reasürans ve SBM bildirimleri gibi kavramları bilen bir analist, doğru soruları daha erken sorar ve gözden kaçan gereksinimleri yakalar. Alan bilgisi eksikse, sigorta uzmanlarıyla yakın çalışma ve yapılandırılmış öğrenme planı gerekir.
Agile projelerde gereksinim dokümanı yazmaya gerek var mı?
Var, ama biçimi farklıdır. Agile yaklaşımda uzun ve donmuş dokümanlar yerine kullanıcı hikâyeleri, kabul kriterleri ve sürekli güncellenen bir iş listesi kullanılır. Ancak sigorta projelerinde ürün tanımı, iş kuralı kataloğu ve mevzuat gereksinimleri gibi kalıcı bilgilerin yapılandırılmış biçimde tutulması denetim ve bakım açısından gereklidir.
İş analisti ile ürün sahibi arasındaki fark nedir?
Ürün sahibi, ürünün değerini ve önceliklerini belirleyen karar vericidir. İş analisti ise ihtiyaçları derinlemesine inceleyip gereksinimleri net, tutarlı ve test edilebilir hale getirir. Küçük ekiplerde iki rol aynı kişide birleşebilir; büyük sigorta projelerinde ise ürün sahibinin karar yetkisi ile analistin çözümleme derinliği ayrı kişilerde olduğunda daha verimli sonuç alınır.
Gereksinim değişiklikleri nasıl kontrol altında tutulur?
Her değişiklik talebi kayıt altına alınmalı, kapsam, takvim, maliyet ve test üzerindeki etkisi analiz edilmeli ve yetkili bir karar mekanizmasınca onaylanmalıdır. Mevzuat kaynaklı zorunlu değişiklikler ayrı bir kategori olarak önceliklendirilir ve yürürlük tarihine göre planlanır. İzlenebilirlik matrisi, değişikliğin etkilediği tüm bileşenlerin hızlıca görülmesini sağlayarak sürprizleri azaltır.
İş analizi projeye ne kadar zaman eklemelidir?
Sabit bir oran yoktur; projenin karmaşıklığına, ürün sayısına ve entegrasyon yoğunluğuna bağlıdır. Önemli olan, analizin projenin başında tek seferlik bir aşama değil, geliştirmeyle paralel ilerleyen sürekli bir faaliyet olmasıdır. Yetersiz analize harcanmayan zaman, genellikle test ve kabul aşamasında çok daha maliyetli yeniden çalışma olarak geri döner.